JShell: source in langtools vs JDK?

[Maurizio Cimadamore]

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