Incompatible change to java.lang.instrument.Instrumentation

[Peter Levart]

Hi Sven,

Just an idea...

What NetBeans could probably do is to create a special sub-interface of 
java.lang.instrument.Instrumentation in its bootstrap jar file (the jar 
passed to class-path) and make that jar file MR jar with two versions of 
say org.netbeans.core.Instrumentation interfaces extending 
java.lang.instrument.Instrumentation. The one for pre-9 JDK would have 
an empty body while the one for JDK 9 would override the newly 
introduced abstract methods with default implementations. NetBeans 
implementation classes would then implement 
org.netbeans.core.Instrumentation instead of 
java.lang.instrument.Instrumentation.

Regards, Peter

On 06/16/2017 09:40 AM, Jaroslav Tulach wrote:
> On pátek 16. června 2017 8:17:51 CEST Sven Reimers wrote:
>> Hi Alan,
>>
>> the code in question I am looking at is in
>>
>>   o.n.bootstrap/src/org/netbeans/NbInstrumentation.java
>>
>> So this looks more like some basic stuff baked deep into NetBeans core...
>>
>> cc'Ing Jaroslav Tulach who wrote this - he should have some more details..
>> else I will try to figure this out.
>>
>> Thanks for looking into this
>>
>> Sven
>>
>>
>> On Fri, Jun 16, 2017 at 8:11 AM, Alan Bateman <Alan.Bateman at oracle.com>
>>
>> wrote:
>>> On 16/06/2017 06:54, Sven Reimers wrote:
>>>> Hi all,
>>>>
>>>> as part of the process of the code donation from Oracle to Apache for
>>>> NetBeans I tried a compilation of the source code using idk 9-ea+173. The
>>>> compilation fails due to an added method boolean
>>>> isModifiableModule(Module)
>>>> in java.lang.instrument.Instrumentation.
>>>>
>>>> Should the newly added method on the interface Instrumentation have a
>>>> default implementation to make this change source code compatible from 8
>>>> to
>>>> 9, e.g.
>>>>
>>>> default boolean isModifiableModule(Module module) {
>>>>
>>>>       return false;
>>>>
>>>> }
>>>>
>>>>
>>>> Is it already to late for changing this before JDK 9 release?
>>>>
>>>> You are correct that adding abstract methods to Instrumentation is an
>>> incompatible change but the long term assumption in this area has always
>>> been it wouldn't be implemented outside of the java.instrument module.
>>> There were 4 abstract methods added to it in Java SE 6 and I don't recall
>>> anyone screaming (pre-dates default methods of course).
> Looks like I have implemented the code when compiling against JDK7.
>
>>> So can you say what NetBeans is doing? Is this mocking, maybe
>>> forwarding/intercepting?
> See https://netbeans.org/bugzilla/show_bug.cgi?id=237919
>
>>> If there is a compelling reasons then we could
>>> try
>>> to see about changing redefineModule and the other new methods to be
>>> default methods but it is late and there is more to this that changing
>>> them
>>> to be default methods.
> -jt
>