JShell: packages

[Maurizio Cimadamore]

I had a productive chat with Alan - there's no bug here. The problem is 
caused by the fact that when you use bootclasspath, you force jshell to 
be loaded by the bootloader and, unfortunately, both jline and jdi are 
NOT in the bootloader (they are on the app loader); since 
bootclassloader doesn't delegate, you then get errors. As I understand, 
there's an hack to make this sort of things work with the exploded 
build, but it's just an accident that things work there.

In other words, using -Xbootclasspath to launch jshell is NOT the right 
way to do things, as jshell depends on stuff that's not in the boot 
loader. Unfortunately, until -Xoverride is available, this means there's 
no solution, as what we really need here is a way to use a -classpath 
that overrides the JDK classes, but that is clearly not possible.

To verify this, I've added both jdk.jdi and jdk.internal.le to this file 
in my vanilla JDK 9 repo:

jdk/make/src/classes/build/tools/module/boot.modules

And, after rebuilding, all the problems were gone, demonstrating that 
the issues were really originating from the classloader mismatch.

Any thoughts?

Maurizio

On 18/09/15 11:22, Maurizio Cimadamore wrote:
> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>