JShell: packages

[Sundararajan Athijegannathan]

I think I got the issue here. There is no bug in the way 
-Xbootclasspath/p: works.

There are three .jimage files in jdk9-dev - bootmodules.jimage, 
extmodules.jimage, appmodules.jimage. Boot, extension and 
"app"/"launcher" loaders load classes from these .jimage files respectively.

jdk.internal.le modules (which contains jline classes in 
jdk.internal.jline.* packages) is part of appmodules.jimage - and hence 
would be loaded by app/launcher loader. jshell classes also live in the 
same .jimage file.

But, with your command line, you're putting jshell classes alone in 
bootstrap class path - leaving jline classes in appmodules.jimage. 
Bootstrap loader will only search classes in your prepended boot path 
and bootmodules.jimage and so won't find jline classes. You need to put 
all dependencies of jshell in bootclasspath/p:

-Sundar

On 9/18/2015 3:52 PM, 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>