JShell: source in langtools vs JDK?

[Maurizio Cimadamore]

Ok, I chatted with Jon, here's an action item for this:

* 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
* fix problem #3 - i.e. by using

-bootclasspath System.getProperty(“sun.boot.class.path”)

to launch the agent VM (will need to change once -Xoverride arrive)

* leave jshell in langtools - stuff like problem #2 can easily be fixed 
up by looking up the jdi library in the target.java.home


Deal?

Maurizio



On 17/09/15 17:39, Maurizio Cimadamore wrote:
>
>
> On 17/09/15 17:36, Maurizio Cimadamore wrote:
>>
>>
>> On 17/09/15 17:28, Robert Field wrote:
>>>
>>> On 09/17/15 09:25, Maurizio Cimadamore wrote:
>>>>
>>>>
>>>> On 17/09/15 16:59, Jonathan Gibbons wrote:
>>>>> In the short term, would it help those folk actively working on 
>>>>> the kulla code base to have recent full builds of the kulla forest 
>>>>> available from somewhere (i.e, with jline and jdi present), so 
>>>>> that we can minimize any short term inconvenience until kulla is 
>>>>> integrated?
>>>> I don't think that would help; note that the issues I pointed out 
>>>> in my writeup essentially boils down to the fact that part of the 
>>>> jshell environment (the remote agent) is insensitive to whatever 
>>>> parameter you pass on the command line when you run jshell/run 
>>>> tests (this is problem #3 in my email). As a consequence, you will 
>>>> be rnning some weird two headed beast which has some bits coming 
>>>> from the jshell under development, while other bits will fall back 
>>>> to the jshell version available in the 'recent build' (which 
>>>> presumably doesn't contain the fix/enhancement the dev is working on).
>>>
>>> That seems a bug that needs to be addressed rather than a factor in 
>>> the location of the source.
>> If it's a bug great - I wasn't sure if the lack of bootclasspath 
>> propagation was a necessary/design choice as I'm not an expert with JDI.
> So, assuming that gets fixed, we are left with #1 - Jon, what is your 
> feeling about the behavior of -override? I.e. assuming I have two 
> modules like this:
>
> jdk.internal.le
>       jdk
>           internal
>                  jline
>
> and
>
> jdk.jshell
>       jdk
>           internal
>                  jshell
>
>
> If I run with -override set to override jdk.jshell, will I still be 
> able to see jdk.internal.jline ?
>
> Maurizio
>
>>
>> Maurizio
>>>
>>> -Robert
>>>
>>>>
>>>> I somewhat agree that #1 and #2 *should* go away in the long run 
>>>> when modules will be fully supported; that is, assuming that 
>>>> -override will do the right thing and not (as currently with 
>>>> -Xbootclasspath) omit all classes in same package available in 
>>>> jimage but not in the overriding module (problem #1).
>>>>
>>>> Maurizio
>>>
>>
>