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.bate...@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
