JShell: packages

[Sundararajan Athijegannathan]

Oops.. sorry I just saw Maurizio's email which was sent earlier. Please 
ignore my email.. (similar content).

No bug in -Xbootclasspath/p:

-Sundar

On 9/18/2015 6:30 PM, Sundararajan Athijegannathan wrote:
> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>