I could be wrong but I think there's a lot of confusion about what JDK support means in relation to Apache NetBeans.
Here's the tentative release cycle: https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+Release+Roadmap In the upcoming release of Apache NetBeans, scheduled for November, Apache NetBeans is scheduled to run on JDK 11 and provide features that relate to JDK 11. With each quarterly release, the tentative plan is to ensure that any new releases of the JDK will be supported by the release that is released during the same time period, i.e., if/when JDK 12 is released in time for the February 2019 release of Apache NetBeans, then Apache NetBeans will support you by being able to run on JDK 12 and by providing enhancements, e.g., Java editor enhancements, for example, to support the JDK 12 release. The question of release numbering of Apache NetBeans is a separate question. The question of which JDK is used to build Apache NetBeans, currently JDK 8, is also a separate question. Thanks, Gj On Wed, Aug 22, 2018 at 12:45 AM, Will Hartung <[email protected]> wrote: > On Tue, Aug 21, 2018 at 12:48 PM, Matthias Bläsing < > [email protected]> wrote: > > > Matthias, being happy, that his employer finally got Java 8 into > > production... > > > > Seriously, welcome to my world. And we're still not 100%, we still have > stuff running on Glassfish 3, for example. > > With a new JDK coming out every 6 months, I think it will be resource > intensive enough to get the IDE to support the prevailing JDK features, > much less having to update the platform to build and run on it. Tying the > platform to the LTS releases (whatever "LTS release" ends up truly meaning, > if anything) should lessen that burden on the NB team, simply due to lower > frequency. > > With JDK 11 on the horizon, and being flagged as ostensibly an LTS, it > would make sense to jump up, try to catch up, and strive that NB 9+ > (whatever THAT turns out to be) meets and greets JDK 11 as a first class > citizen. > > If someone wants to track the 6 month JDK cycle, that's all well and good, > but if bugs to the platform aren't being back ported, and only available on > JDKs that users aren't using, its a disincentive for them to adopt it in > the first place. You can see a company trying to adopt the NB platform and > barely even getting a real project off the ground in 6 months, much less > then having to catch up and change the JDK to keep up in the middle of > their project. That time to catch up, retest, fix new issues, etc. is a > drag on the overall project. That's why that stuff doesn't get done today, > now. Would you rather spend the time on New Feature, or adopting a new > underlying runtime that offers no visible New Features. All that time for > the same CRUD screens. > > The entire point of the LTS is that they're something that companies can > rely and plan around. I don't want to call the interim release "stable > betas", but rather previews of things to come in the next LTS. > > Obviously, JDK adoption should not be arduous. But the JDK is moving REALLY > fast right now, with engine changes, the divestiture of capabilities, etc. > > All that logic "they can just use the previous versions" applies to this > team too. We can just "use the previous version" as it can have less of a > ripple affect. Everything this team does affects the many users, which can > make decisions such as these even more important. > > Regards, > > Will Hartung >
