JShell: packages

[Maurizio Cimadamore]

I suggest we restart from scratch - I don't know where the problem is 
exactly, but I don't see why the following is failing:


$ <JDK9_HOME>/bin/java 
-Xbootclasspath/p:<KULLA_JDK_BUILD>/jdk/modules/*jdk.jshell*:<KULLA_JDK_BUILD>/jdk/modules/*jdk.compiler*:<KULLA_JDK_BUILD>/jdk/modules/*java.compiler*jdk.internal.jshell.tool.JShellTool
Exception in thread "main" java.lang.NoClassDefFoundError: 
jdk/internal/jline/TerminalFactory$Flavor
     at 
jdk.internal.jshell.tool.ConsoleIOContext.<init>(ConsoleIOContext.java:70)
     at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:242)
     at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:233)


Why is the tool failing to locate jline? Note that JDK9 home is a recent 
JDK9 repo which has the jdk.internal.le package.

By any chance, maybe jline is not part of rt.jar?

Maurizio

On 18/09/15 02:08, Jonathan Gibbons wrote:
> Then I am indeed confused as to the issue/interaction between 
> -Xbootclasspath/p: and .jimage files.
>
> -- Jon
>
> On 09/17/2015 05:55 PM, Robert Field wrote:
>>
>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>