JShell: packages

[Jonathan Gibbons]

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
>>>>>
>>>>>
>>>>
>>>
>>