JShell: packages

[Robert Field]

Jline is already in its own jdk.internal package.



On September 17, 2015 5:25:27 PM Jonathan Gibbons 
<jonathan.gibbons at oracle.com> wrote:

> If the problem is just with jline, I was thinking we should temporarily
> put it in its own package, such as jdk.internal.jline, and leave alone
> the packages that Robert listed.
>
> Or am I missing something here? (again?)
>
> -- Jon
>
> On 09/17/2015 05:20 PM, Maurizio Cimadamore wrote:
>>
>>
>> On 17/09/15 19:52, Jonathan Gibbons wrote:
>>> We should not change any of these packages.
>> Now I'm confused :-)
>>
>> As you say, we need a workaround for the Xbootclasspath issue - the
>> simpler workaround would be to change the way jshell uses jdk.internal
>> package names; I'm assuming fixing the bootstrap vs. jimage issue
>> would take much longer.
>>
>> So, what do you mean by "we should not change any of these packages" ?
>>
>> Maurizio
>>>
>>> My understanding from Maurizio is that there is a bug or anti-feature
>>> in the system today such that the choice of package for jline is
>>> problematic, and so we were simply discussing the possibility of
>>> using a different package for jline for the immediate short term as a
>>> workaround for the -Xbootclasspath/p: issue.   When Jigsaw gets
>>> integrated, the -Xbootclasspath/p: option will go away, and we will
>>> have to use the new -Xoverride option instead.   In advance of that,
>>> we should ensure that -Xoverride works in a way that is satisfactory
>>> with jline in its propoer long term home.
>>>
>>> -- Jon
>>>
>>> On 09/17/2015 11:08 AM, Robert Field wrote:
>>>> There were extensive discussions and approvals around package
>>>> names.  This is what we have now:
>>>>
>>>> jdk.jshell
>>>>
>>>>     JShell API and core implementation.
>>>>
>>>> jdk.internal.jshell.remote
>>>>
>>>>     The remote side of the implementation
>>>>
>>>> jdk.internal.jshell.debug
>>>>
>>>>     Single class supporting debugging of the implementation through
>>>>     external tools
>>>>
>>>> jdk.internal.jshell.tool
>>>>
>>>>     The JShell tool (built on the API)
>>>>
>>>>
>>>> The package jdk.jshell has all the public API.
>>>>
>>>> jdk.internal.jshell.* includes some classes with public access
>>>> modifiers but these packages are not public APIs (we want the
>>>> ability to change them as needed) -- my understanding is that
>>>> packages with those characteristics should be named "jdk.internal.*".
>>>>
>>>> -----
>>>>
>>>> However we have problems --
>>>>
>>>>>     some weird bug I encountered where if I set bootclasspath that
>>>>>     mentions some jdk.internal classes (but which doesn't have
>>>>>     JLine - because it comes from langtools), _every_ class from
>>>>>     that package will not be fetched from the jimage file - meaning
>>>>>     that I'll be left w/o jline. In other words, bootstrapping
>>>>>     doesn't work - and I have reasons to believe that bootstrapping
>>>>>     with the new module options (when they will become available -
>>>>>     i.e. moduleOverride) won't work too.
>>>>
>>>>
>>>> and the proposal --
>>>>
>>>>>     * workaround problem #1 by putting jshell in a package other
>>>>>     than jdk.internal (i.e. jdk.jshell could be good); this will
>>>>>     avoid -Xbootstrap accidentally making jline unavailable
>>>>
>>>>
>>>> -Robert
>>>>
>>>>
>>>
>>
>