JShell: packages

[Maurizio Cimadamore]

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