JShell: packages

[Maurizio Cimadamore]

Adding Alan

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