JDK `javac` drops support for old `-target` versions. E.g. version 11 can no longer target 1.5 bytecode:
``` $ /jdk-11/bin/javac -source 1.5 -target 1.5 Hello.java error: Source option 5 is no longer supported. Use 6 or later. error: Target option 1.5 is no longer supported. Use 1.6 or later. ``` and such "dropping" constantly continues and happens all the time. For example JDK-17 cannot target 1.6 anymore: ``` $ /jdk-17/bin/javac -source 1.6 -target 1.6 Hello.java error: Source option 6 is no longer supported. Use 7 or later. error: Target option 6 is no longer supported. Use 7 or later. ``` as a consequence one cannot use the latest JDK to build (not so old) versions of NetBeans. This decay bugs me a lot. I want to use JDK/JRE as a runtime (newest JDK can still run the 1.0 bytecode format) and separate compiler from such runtime. Then the world is going to be a better place. -jt Sidenote: > I think Michael Bien answered this: "btw javac has actually a public API, it > won't simply disappear from one release to the other without warning" NetBeans use of `javac` goes far beyond its public API. I believe there is a little relevance concluding the important aspects of javac remain based on existence of some public API. Dne úterý 25. října 2022 3:16:38 CEST, Eirik Bakke napsal(a): > > Right now, when we build NetBeans, we’re using the javac from the JDK that > > we’re using to do the build — so that we’re dependent on the JDK team, > > which can decide to drop features. > > Does the JDK ever drop features? Are we currently dependent on unofficial or > experimental JDK features relating to the official javac? > I think Michael Bien answered this: "btw javac has actually a public API, it > won't simply disappear from one release to the other without warning" > I agree with Michael Bien here: > > > I would approach this from a different POV and ask why NB requires > > nb-javac in the first place, instead of trying to find more stages in the > > NB life cycle where we can add it. > > Much better to keep NetBeans building with the standard JDK. > > -- Eirik > > -----Original Message----- > From: Michael Bien <mbie...@gmail.com> > Sent: Monday, October 24, 2022 4:27 PM > To: dev@netbeans.apache.org; Ernie Rael <err...@raelity.com> > Subject: Re: nb-javac for building NetBeans itself > > On 24.10.22 22:15, Ernie Rael wrote: > > > On 22/10/24 8:58 AM, Michael Bien wrote: > > > >> On 24.10.22 17:27, Ernie Rael wrote: > >> > >>> The link to apache's guidelines for voting was clarifying for me. > >>> I'd like to see a more technical discussion. > >> > >> > >> > >> for me too, I withdrew the -1 vote the moment I realized that this > >> could qualify as veto since this discussion would fall into the > >> code-change category. > >> > >> > >> > >> Luckily withdrawing vetos is legal, which is useful since I didn't > >> even intend to veto anything :) > >> > >> > >> > >> > >>> And I have to mention one thing that really bugged me: a lot of the > >>> discussion seemed to have the assumption that it's easy for users to > >>> use the latest JDK; I think that's just not accurate (but again > >>> don't have hard data). For me, I have to use Gradle 6.8.x so I can > >>> not use the latest JDK. If it's true in general that many/most users > >>> can not use the latest JDK, that seems like an extremely important > >>> data point. > >> > >> > >> > >> Yes I heard about this issue. We should take a look if this can be > >> somehow solved. Its certainly not optimal to be required to change > >> the runtime JDK of the IDE when switching between projects which use > >> different gradle versions. > >> > >> > >> > >> lets try to solve this without nb-gradle if possible. > > > > I only brought that up as an example of a situation where can't use > > the latest JDK. I wouldn't be surprised if most users have > > restrictions on which JDK can be used and/or targeted. > > > This doesn't influence the target JDK at all. Java 8 shops don't swap out > the build-in JDK 11 of android studio if they write an app. It is just the > runtime of android studio, it has no other viral effects or influences your > support contracts with specific vendors. > -mbien > > > > >> > >> > >> best regards, > >> > >> > >> > >> michael > >> > >> > >> > >> > >>> > >>> > >>> -ernie > >>> > >>> > >>> > >>> > >>>> > >>>> > >>>> Maybe a straight vote on this is the way forward, and we live with > >>>> the consequences either way?! > >>>> > >>>> > >>>> > >>>> Best wishes, > >>>> > >>>> > >>>> > >>>> Neil > >>>> > >>>> > >>>> > >>>> ------------------------------------------------------------------- > >>>> -- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > >>>> For additional commands, e-mail: dev-h...@netbeans.apache.org > >>>> > >>>> > >>>> > >>>> For further information about the NetBeans mailing lists, visit: > >>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> -------------------------------------------------------------------- > >>> - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > >>> For additional commands, e-mail: dev-h...@netbeans.apache.org > >>> > >>> > >>> > >>> For further information about the NetBeans mailing lists, visit: > >>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > >>> > >>> > >>> > >>> > >> > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > >> For additional commands, e-mail: dev-h...@netbeans.apache.org > >> > >> > >> > >> For further information about the NetBeans mailing lists, visit: > >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > >> > >> > >> > >> > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
