JShell: packages

[Jonathan Gibbons]

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
>>>
>>>
>>
>