I think we should divide JDK that NetBeans developed uder and run on, with the JDKs under which projects are developed. As example NB itself run on JDK 17, but i want use JDK from 8 to 17 for my projects.
Is it possible, to do it like in Idea, which runs on jdk distributed with, and each project in idea can be built and run on diferrent JDK? If it is possible, do we need nb-javac for it, or don't? If nb-javac is not needed for this, what other reasons to support it? On Thu, Oct 27, 2022 at 3:53 AM Michael Bien <mbie...@gmail.com> wrote: > > just to clarify: > > I don't think anybody suggested to drop Java 8 support in the NetBeans > editor. > > Imagine nb-javac as a dependency like any other artifact. If NB wants to > support Java X, it would have to get a javac which supports java X from > somewhere. If nb-javac would be gone, NB 16 would have to run on JDK 19 > and use it's javac to get support for JDK 19. > > Since JDK 19 supports Java 8 perfectly fine - nobody has to worry. There > are also no indications that Java 8 support will be dropped from javac > during the LTS lifespan of Java 8. nb-javac does not influence what java > version the editor can support, it adds the capability to run NB on > older JDKs. Since nb-javac is generated from the JDK repository, it > would also not magically provide JDK 8 support forever in the very > unlikely event of OpenJDK dropping support for the java 1.8 target. > > > The discussion is roughly about this: > > should NetBeans add nb-javac to more stages of its project lifecycle > (for example build), or should NB strive to minimize the dependency on > nb-javac. So that maybe, one day in the future, it could be removed. > This would mean that NB_the_IDE (not the platform) would not be able to > _run_ on JDK 8 anymore (thunder in the background), it would be locked > to the current JDK release which is already conveniently synced with > NB's release cycle. > > I am not going to repeat all the advantages of this setup, but it would > reach from simplified CI, to being actually able to use recent APIs in > NetBeans_the_project. If this turns out to be unrealistic (there are > risks and potential problems), it could still turn out to be better to > only backport nb-javac to the latest LTS release, instead of all the way > down to 8 once NB can bootstrap its own JDK runtime. > > Even if this doesn't happen I don't quite see the benefit in compiling > NetBeans with nb-javac outside from the fact that it is theoretically > possible. > > (I am in the minimize the dependency camp in case someone is wondering ;)) > > best regards, > -mbien > > > On 27.10.22 01:08, Scott Palmer wrote: > > JDK 8 is still supported by Oracle. Dropping it should happen when it > makes sense, after support has ended. If you need to work on Java > versions prior to 8, first, I’m sorry, you have my sympathy, second, > download an older version of NetBeans that supports it - if you are living > in the past go all-in. :-) > > > > I still have to make Java 8 compatible output for some projects. If > that means I have to use NB 16 or 15 instead of 17, so be it. I would > absolutely not want NB to be held back by a need to support ancient tech. > Microsoft does that with Windows and we are still living with the insanity > of DOS drive letters and path limits because of it! > > > > From the sounds of it, nb-javac is a relic that shouldn’t be needed… > cut it out. Tooling (Maven/Gradle) can support alternative compilers in > some cases… maybe if those compilers are compatible with the javac API they > can integrate with NB for better editor feedback or whatever. If someone > wants to support nb-javac as an optional plugin fine, but overall the > platform needs to move forward, not hold on to the past. Apache shouldn’t > directly concern itself with nb-javac anymore. > > > > Changes is inevitable, resistance is futile, etc… I’m much more > interested in top-notch Java 20+ support. I think it is reasonable to say > that NB supports the oldest LTS JDK and no earlier. > > > > Just my opinion, > > > > Scott > > > >> On Oct 26, 2022, at 6:57 PM, Geertjan Wielenga > <geertjan.wiele...@googlemail.com.INVALID> wrote: > >> > >> Just been looking into open source work done in the context of the > >> European Union and one of the key applications there requires JDK 8: > >> > >> https://github.com/l-e-x/leos > >> > >> I.e., we need to stop thinking that Java 8 is somehow dead or > >> ethically or otherwise problematic -- it's simply what a great deal of > >> applications use and any strategy we come up with needs to cater to > >> Java 8. > >> > >> Gj > >> > >> On Wed, Oct 26, 2022 at 10:57 PM Glenn Holmer > >> <ce...@protonmail.com.invalid> wrote: > >>> On 10/25/22 22:48, Laszlo Kishalmi wrote: > >>>> I'm confused as well. Still not clear, what are we about to solve > here. > >>>> Use new lang spec with old runtimes? I do not have granny issues... > >>> Also confused. If this is all so people can still code for Java 8 in > >>> this day and age, I say drop support for JDK8 ("Nuke the site from > >>> orbit, it's the only way to be sure"). I may be out of touch, being > >>> retired for eight years now, but IMHO anyone still using Java 8 would > be > >>> better off to stay in his parents' basement with his VAX-11 coding > >>> assembly language. It's getting as bad as the Python 2/3 thing was. > >>> > >>> And if it's so you can code using new features not available in the JDK > >>> you're using... use the newer JDK! I just don't understand any of this, > >>> but I do remember a time when NetBeans was the leader in out-of-box > >>> support for new language features. > >>> > >>>> The examples of Java 17 has no support for Java 6 target, makes this > >>>> discussion ridiculous. > >>> +1, what are we even talking about here? Java 6? seriously? > >>> > >>> -- > >>> Glenn Holmer (Linux registered user #16682) > >>> "After the vintage season came the aftermath -- and Cenbe." > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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 > > > > -- Best regards, Anton V. Kirilchik E-mail: kosmonaf...@gmail.com Skype: kosmonaFFFt.kav
