netbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Reimers <sven.reim...@gmail.com>
Subject Re: Optional modules with GPL dependencies (was: What to include/exclude in code donation to Apache)
Date Sun, 06 Nov 2016 10:31:21 GMT
Hi all,

for me it seems there are two parts of this discussion:

1. The legal part about GPL+CPE
2. The technical problem of maintaining a javac fork

I think 2 is already a problem (a BIG thanks to Jan Lahoda who still keeps
this working and even provides branches working with Valhalla...) that not
crashed up to now and would be good to be solved without especially looking
at the current transition.

I will not comment on 1 - I think all is said..

Just my 2c€

-Sven



On Sun, Nov 6, 2016 at 11:26 AM, Neil C Smith <neilcsmith.net@googlemail.com
> wrote:

> Hi,
>
> On 5 November 2016 at 19:20, Wade Chandler <wadechandler@apache.org>
> wrote:
> > On Nov 5, 2016 2:00 PM, "Neil C Smith" <neilcsmith.net@googlemail.com>
> > 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
>
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>



-- 
Sven Reimers

* Senior Expert Software Architect
* Java Champion
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* Community Leader  NetBeans: http://community.java.net/netbeans
                              Desktop Java:
http://community.java.net/javadesktop
* JUG Leader JUG Bodensee: http://www.jug-bodensee.de
* Duke's Choice Award Winner 2009

* XING: https://www.xing.com/profile/Sven_Reimers8
* LinkedIn: http://www.linkedin.com/in/svenreimers

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message