+1 I think there is not any good reason to use Java 8 anymore it is just laziness to upgrade. They will still need to upgrade soon or later because the whole Java ecosystem already started moving to Jakarta and Java 17 (see the Spring). Lets resolve javax dependency hell once and for all. It will be harder and harder to find a supported solution for Java 8.
Best regards Tomas On Thu, Apr 6, 2023 at 3:32 AM Chuck Davis <cjgun...@gmail.com> wrote: > Niel's proposal is at least 3 years over due. What needs to be remembered > is that Netbeans does not time-out....the license does not expire, etc. > People who need to work with JDK8 can do so into eternity by keeping a JDK8 > version of netbeans. This machine I am writing on has 11 versions of > Netbeans only a desktop icon click away (12.1, 12.2, 12.3, 12.4, 12.5, > 12.6, 13, 14, 15, 16 and 17). Sometimes I use more than 1 at a time too. > Of course, I don't know what the "installers" do to destroy other > installations but the best installer is and always will be a *.zip file. > Consequently, there is absolutely no reason to burden developers with > continued backward compatibility into antiquity. And Android compatibility > is a dead issue anyway. You'd be hard pressed to find any Java support at > Google for Android. They're using anything BUT Java these days (political > decisions not technological) so Android is a dead issue with respect to > Java. If you have to use Android, learn Dart (or JetBrains stuff). If > you're smart enough to learn Java you can certainly learn Dart and have a > much more satisfactory Android experience. The development environment > sucks but it is what Google has chosen to support (somewhat). > > My $.02 and ++1 > > On Wed, Apr 5, 2023 at 3:49 PM Stephen Parry > <parry-webmas...@blueyonder.co.uk.invalid> wrote: > > > Sorry to be the noob here - I am mostly just a Netbeans IDE user; I have > > only tinkered a little with the Netbeans build when I was seeking to > > extend ANTLR support and add additional languages. I have never used the > > Netbeans Platform for development. > > > > Question: If I wanted to develop an application that would run on JRE 8, > > with Netbeans as proposed by Neil, what potentially would break? Am I > > not still able to code to the JRE 8 API, use only Java 8 language > > features and compile to JRE 8 bytecode? > > > > If Neil's proposal helps get us out of EE javax vs. jakarta / JPMS hell > > sooner, I am +1. > > > > On 05/04/2023 23:17, László Kishalmi wrote: > > > Well this is about the Lazy Consensus then. > > > > > > I think Neil summarized a plan with a soft, but defined step away > option > > > from JDK 8. It offers more compromise than some of us would like on > this > > > front. > > > > > > Also no one of the naysayers provided a sane use case why that offer > > should > > > not work for them. It's easy to say no, in the name of a holy idea, but > > > would some of you present a case: > > > 1. I have this platform application built on top of NetBeans 17 (or > 18), > > > that needs to run on JDK 8, if NetBeans 19 would only run on JDK 11, I > > > would face issues, as I depend on this and that modules, that I *must* > > > upgrade to. > > > 2. I have an android application that uses some NetBeans Core modules. > My > > > life would be ruined if I can get the apidoc changes > > > org.netbeans.swing.outline from the next release > > > > > > Something like this. > > > > > > On Wed, Apr 5, 2023 at 1:33 PM John Kostaras <jkosta...@gmail.com> > > wrote: > > > > > >> -1 > > >> > > >> Java 8 is also LTS and many out there are still stuck to it. I support > > >> Jarda, too. > > >> > > >> On Wed, Apr 5, 2023 at 6:25 PM toni.ep...@eppleton.de < > > >> toni.ep...@eppleton.de> wrote: > > >> > > >>> -1 > > >>> > > >>> I agree with Jarda. Having the portability for platforms like Android > > is > > >>> important, and I support the proposed alternative. > > >>> > > >>> > > >>> > > >>> Von: Jaroslav Tulach <jaroslav.tul...@gmail.com> > > >>> Datum: Mittwoch, 5. April 2023 um 17:13 > > >>> An: dev <dev@netbeans.apache.org> > > >>> Betreff: Re: [Lazy Consensus] Minimum JDK build and run policy > > (dropping > > >>> JDK 8) > > >>> -1 > > >>> > > >>> Background: http://wiki.apidesign.org/wiki/Portability > > >>> > > >>> > > >>> Alternative: > > >>> > > >>> - I will maintain what ever needs to be maintained to keep JDK 8 CI > > tests > > >>> running > > >>> > > >>> - From Apache NetBeans 19, the minimum JDK required to build and run > > >>> the IDE will be JDK 11. > > >>> > > >>> - The minimum JDK to run and test the NetBeans Platform and modules > up > > to > > >>> VSCode & Jackpot remains JDK 8. > > >>> > > >>> - Usage of JDK11, JDK17, etc. API is possible in dedicated modules > via > > >>> http:// > > >>> wiki.apidesign.org/wiki/AlternativeImplementation > > >>> > > >>> > > >>> Justification: > > >>> > > >>> Writing in Java (a language designed to write once and run > everywhere) > > >>> greatly > > >>> increases portability. However there is another axis hurting > > portability > > >> - > > >>> the > > >>> supported JDK version. Of course, should a library be widely used, it > > has > > >>> to > > >>> support as oldest JDK as possible. These days it is JDK8 - the > primary > > >>> reason > > >>> being that Android supports JDK8 - as such, should a library aspire > to > > be > > >>> used > > >>> on Android (as well as regular Java), it needs to stick to version > > eight. > > >>> > > >>> There's transitivity of non-portability - the portability of the > final > > >>> application cannot be bigger than portability of the least portable > > >> library > > >>> used. This applies also to 3rd party dependencies a framework or > > library > > >>> has: > > >>> again their non-portability may negatively affect portability of such > > >>> framework > > >>> or library. > > >>> > > >>> Of course, writing portable libraries is harder. It requires more > work > > >> from > > >>> the API author, more self-control, more suffering. However such > > suffering > > >>> is > > >>> justifiable. There is usually a single API writer, but there are many > > >>> users to > > >>> it. What matters is to simplify and improve experience of those API > > >> users - > > >>> own author suffering doesn't matter that much. > > >>> > > >>>> # Proposed policy > > >>>> > > >>>> * Apache NetBeans 18 will be the last release to support running the > > >>>> platform on JDK 8. > > >>>> > > >>>> * From Apache NetBeans 19, the minimum JDK required to build and run > > >>>> the IDE or platform will be JDK 11. > > >>>> > > >>>> * Future releases will take an "LTS-1" strategy for building and > > >>>> running (and CI testing) of the IDE and platform. Three JDKs will be > > >>>> supported at any one time - the current JDK, plus the previous two > LTS > > >>>> releases. eg. NetBeans 20 and 21 (Nov 2023 / Feb 2024) will support > > >>>> JDK 11, 17 and 21. NetBeans 22 (May 2024) will support JDK 17, 21 > and > > >>>> 22. > > >>>> > > >>>> ## Background > > >>>> > > >>>> The Apache NetBeans IDE has officially required JDK 11 to build and > > >>>> run since NetBeans 13 in March 2022. The platform (and unofficially > > >>>> the IDE) have continued to support running on JDK 8 - all modules > > >>>> requiring a higher JDK must currently be optional. Various tests > have > > >>>> continued on JDK 8. > > >>>> > > >>>> This situation is causing issues as workarounds must be found for > > >>>> currently non-optional features that have dependencies or other > > >>>> requirements for running on a higher JDK (eg. Maven indexing / > Lucene > > >>>> [1]). It's causing delays, complications and missed testing time in > > >>>> integration of new features (eg. problems merging support for EE 10 > > >>>> [2]). Supporting an increasing range of JDKs is causing increasing > > >>>> workload, both for people and CI. Meeting the challenges of > deprecated > > >>>> (for removal) features in the JDK is also complicated by the > > >>>> additional JDK requirements. > > >>>> > > >>>> ## Notes > > >>>> > > >>>> * Apache NetBeans users will continue to be recommended to use the > > >>>> current or latest LTS JDK to run the IDE. The IDE will continue to > > >>>> support users developing projects for/with JDK 8, for as long as > > >>>> nb-javac and other dependencies allow. > > >>>> > > >>>> * This proposal specifically doesn't address when the default > bytecode > > >>>> level across the codebase is increased. This can happen when > required, > > >>>> but non-optional modules would be free to adopt the minimum JDK as > > >>>> they need to. > > >>>> > > >>>> * Optional modules may continue to require a runtime JDK higher than > > >>>> the minimum. Should it become necessary, build time optional > modules > > >>>> might be considered - eg. a build on the minimum JDK may exclude > > >>>> modules that will not run on that JDK at runtime. > > >>>> > > >>>> * Some modules that are of independent use (eg. lookup, utilities, > > >>>> etc.) might be nominated and advertised to continue JDK 8 support > for > > >>>> the time being. This is not expected to cover the runtime container > as > > >>>> a whole - > > >>> https://netbeans.apache.org/tutorials/nbm-runtime-container.html > > >>>> * Once NetBeans 19 is released, the NetBeans 18 release branch could > > >>>> be used to backport and release JDK 8 supporting fixes, subject to > any > > >>>> PMC members wanting to manage those releases. > > >>>> > > >>>> * The term "platform" is used in reference to the whole framework of > > >>>> modules that we release (eg. via Maven), not just the platform > > >>>> cluster. > > >>>> > > >>>> [1] https://github.com/apache/netbeans/pull/4999 > > >>>> [2] https://github.com/apache/netbeans/pull/4692 > > >>>> > > >>>> > --------------------------------------------------------------------- > > >>>> 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 > > > > > > > > >
