> On Oct 12, 2021, at 3:15 AM, Jaroslav Tulach <[email protected]> > wrote: > > Hello Matthias. > > so 9. 10. 2021 v 17:56 odesílatel Matthias Bläsing < > [email protected]> napsal: > >> Am Samstag, dem 09.10.2021 um 10:38 -0500 schrieb Eric Bresie: >>> Frgaal (1) does seem an interesting beast. > > >> IMHO2: we only gain syntactic sugar. > > No, not at all. We'd get the ability to code against JDK11, 12, 13, 14, ... > APIs while running the build on JDK8.
You get to code with language features of JDK 11,12,13,… You can’t use new APIs without running on the JDK that has them, at least that’s how I understand what the Frgaal web site says. I would vote against adding it as it just starts to muddy the waters… if the code looks like JDK 11+ code, then people are going to expect to call JDK 11+ APIs. We don’t need “imposter” JDK 11 code. I personally would vote to go straight to JDK 17 and enable use of all language features and APIs that are not “preview”. Stepping only to JDK 11 at this point is a missed opportunity. Breaking compatibility in any code with JDK 8 is enough that you might as well go to JDK 17. Get as far ahead as possible. What is special about JDK 11? This drawn out process of pretending to support later versions while requiring compatibility with JDK 8, in other words - NB is still held back by the JDK 8 requirement, so no significant progress is made, but now time is split dealing with multiple implementations. Seems like a waste of effort. There are options that you’ve pointed out to have a fall-back to Java 8, but if you must have that fallback, do we really have the development resources to maintaining two separate versions of that code. Why add that complexity? What is it about requiring JDK 8 compatibility, that prevents you from just sticking with the NB 12.5 code base? (Honest question) To do this cleanly, if the NB platform must have JDK 8 compatibility, the cutoff should be at the NB module level. Decide which modules must still run on JDK 8 and compile those modules with JDK 8. New modules and existing modules that don’t have the JDK 8 requirement, should use JDK 17 and compile to JDK 17 byte code. That way the limited resources aren’t spent maintaining two different implementations. Other mixed approaches seem like complications that will only hurt in the long run. Cheers, Scott
