netbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil C Smith <>
Subject Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)
Date Sun, 06 Nov 2016 10:26:17 GMT

On 5 November 2016 at 19:20, Wade Chandler <> wrote:
> On Nov 5, 2016 2:00 PM, "Neil C Smith" <>
> wrote:
>>Why I think this
>> is different to reliance on almost any other library is the way javac
>> uses the internals of the JRE.  eg. the last time I looked, javac had
>> specific exceptions in place to bypass module restrictions in Java 9.
>> It just feels like shakier ground to rely on than it could be.
> The same would
> be the case with any OpenJDK API ATM.

I think you're missing the point I'm trying to make, or I'm not
explaining very well - what javac relies on is not part of the OpenJDK
API, or any public and stable one - hence shakier ground!

>> Assuming the answer to my licensing question is no, then I'm
>> interested in exactly how much nb-javac forks from javac and how
>> maintainable it is from outside?
> That could be done any way needed IMO. It could be forked and put on GitHub
> directly by the NB community once NB is at Apache. So, it would just be an
> OSS standalone component managed by the NB community; not Apache nor
> Oracle. Other options are clearly open to discussion. I would like to hear
> Oracle's POV on this.

So would I!

Yes, the community could (not ideal but could) work on it on GitHub,
but this is not my concern about maintainability.  javac relies on
access to internals of the JRE.  I'm assuming the nb-javac fork still
does?  Jigsaw may have implications here - javac has specific
exceptions.  I know other javac forks have had issues.

What I'm saying about maintainability is that changes in the internals
of OpenJDK have the potential to stop nb-javac from functioning.  So,
while we, the NetBeans community, may be able to manage the code on
our side, it may also require commitment from Oracle / OpenJDK to not
break access to internal features that the nb-javac library relies on.

As I said earlier, this is tangentially related to the license
argument IMO, because a fudge now to meet the immediate needs of that
without the agreement of how this plays out into the future to meet
technical and maintenance concerns feels wrong.

> Either way, that doesn't make NB less viable. You use
> it now...

Yes, but that is not a guarantee this keeps working?!

Best wishes,


Neil C Smith
Artist & Technologist

Praxis LIVE - hybrid visual IDE for creative coding -

View raw message