JShell: packages

[Jonathan Gibbons]

We should not change any of these packages.

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