16 ms·

JDK 20 and JDK 21: What we know so far

143 points by mikece 4y ago

PaulHoule 4y ago
When I saw sequenced collections earlier I didn’t like the design but I completely approve of the latest revision. One nice thing about the process they use to develop Java is that they really do work and rework new features to make them great. I just wish that instead of Streams they’d made something more like https://github.com/paulhoule/pidove https://github.com/paulhoule/pidove With the possibility of making something more fluent and less lispy.
- mindcrime 4y ago
  Pidove sounds really awesome. I'm totally going to give that a try!
  - PaulHoule 4y ago
    It has a sibling project which is still half-baked https://github.com/paulhoule/ferocity https://github.com/paulhoule/ferocity which is about developing a lispy DSL in which it is possible to write Java-in-Java to transform it to make syntactic macros. It's kinda crazy https://github.com/paulhoule/ferocity/blob/main/ferocity0/src/test/java/com/ontology2/ferocity/TestUrFierce.java https://github.com/paulhoule/ferocity/blob/main/ferocity0/sr... and somebody might think it combines the worst of Java and Common LISP but I did enough work on it to be sure there were no major barriers. ferocity0 is a bootstrap implementation that it's possible to write a code generator that can generate code to make stubs for the standard library and write ferocity1 in ferocity0 and write ferocity2 in ferocity1 with the full power of code generation to hide the accidental complexity of Java... But other projects got in the way.
    - brabel 4y ago
      Looking at your examples, this looks like https://github.com/square/javapoet https://github.com/square/javapoet
      - PaulHoule 4y ago
        Yeah, that’s very similar. Thanks for the link. It’s got the difference though that they are using (mostly) strings to write the method bodies and my approach builds those up with the lispy DSL. The class/method/field definitions are basically the same. (ferocity contains three languages, one of expression trees, one of class definitions, another of compound statements that doesn't exist yet) Mine can also run ‘lispy Java’ in an interpreted mode (as well as writing code that goes through javac) and I discovered the interpreter has a type system which is a little richer than the Java type system, namely I discovered (not invented) ‘quote’ and ‘eval’ so that expressions are a first class data type that can be manipulated…. I have to define some set of operators to make it easy to traverse and work on expressions which would make it easy to metaprogramming, probably taking back some of the verbosity that comes with the lispy java-in-java embedding.
- pjmlp 4y ago
  I would already be happy if they provided some adapters for exceptions in lambdas, instead of us having to create our own, or use one of the several libraries that provide them.
bcrosby95 4y ago
I was wondering this morning, with regards to the pattern matching for switch: Is there a performance consideration here? When using sealed classes, can the JVM do a better job optimizing pattern matches for switch? Are there also considerations with how it interacts with Project Valhalla? The team evolving Java seem pretty good at evolving the language with higher level goals in mind, so I wasn't sure if there were interrelated factors here.
- tadfisher 4y ago
  > When using sealed classes, can the JVM do a better job optimizing pattern matches for switch? Yes! In the Pair<I> example from the JEP, if the number of subclasses of I is large enough, it may be worth generating a perfect hash function [0] to match the pattern in O(1) time instead of the naive O(n^2). This is only possible in the general case for exhaustive switch statements, which sealed classes allow for with instanceof-style patterns. [0]: https://en.wikipedia.org/wiki/Perfect_hash_function https://en.wikipedia.org/wiki/Perfect_hash_function
  - debug-desperado 4y ago
    So, has perfect hashing dispatch like you're describing here actually been added (or planned) in the JIT?
foolfoolz 4y ago
modern java is a huge improvement over old java. switch pattern matching will be huge, this has been in preview for a long time
- papito 4y ago
  Look, I haven't done Java in more than 10 years, but I have done Scala. Honest question - isn't Java just trying to "steal" Scala's concepts and catch up to the "cool" languages?
  - mayank 4y ago
    All modern languages heavily borrow from each other’s latest iterations. In the case of Java though, playing catch up is by design since it’s intended to be a conservative/stable language.
  - sfritz 4y ago
    Their philosophy is to "adopt" language features once they're well worn by other languages so they can learn from their mistakes / successes.
    - NwpierratorR 4y ago
      While philosophy is good, Java makes a very questionable syntactic choices when adopts that said features. Pure slowness in how java develop feels like you have to wait 5 years to get something that other languages have, only to get it in the most aesthetically unpleasant way. It seems like devs add unnecessary verbosity whenever they can. Java adopted lambdas after many other languages, yet still decided that allowing to move last parameter closure {} outside of () is too radical, even though it is much more visually pleasant choice and quite common in other languages. default methods in interfaces instead of static extensions. This one is controversial as static extension methods were not really common when java came up with this, but end result does not look impressive. Same with their new sealed classes. They just chose the most verbose version they came up with. Some inconsistency of choices also kinda baffles me. First they added support for skipping necessity of mentioning generic type inside <> during instantiation, only to introduce local vars later that require you to mention generic types within the same <>. Now you either mention generics by their full type always, or embrace the inconsistency and have it skipped when type mentioned in prefix and type it when using local vars. Or do not use local vars and have consistent codestyle with increased verbosity. Java is still a good language, but it feels dated in syntax. TBH I have no idea why would anyone chose java in 2023 when there's kotlin, which not only fully covers the same functionality(okay, no pattern matching and no loom/valhalla until java merges it), but does it while being much more concise and readable.
Phelinofist 4y ago
Structured concurrency sounds amazing, but it will probably take some time till it is widely usable :(
marginalia_nu 4y ago
Foreign Memory API can't come soon enough. The weird hoops you have to jump through to allocate large buffers of memory in Java are perhaps my least favorite aspect of the language right now.
- marcosscriven 4y ago
  What I’d really love to do is limit memory by Java thread, rather than per process. Allowing things like job runners to not crowd out others.
endisneigh 4y ago
It's been a while since I've programmed in Java. I wonder how good the concurrency stuff is these days. On a somewhat related note I was talking to a team from a random bay area company on how they switched from Java/Spring to Node and that Node is slower but since it's single threaded they load balance a bunch of servers and in practice it's just as fast when considering the developer productivity. Compute is really cheap these days, so I wonder how much it's worth it to squeeze every drop of performance out now.
- marginalia_nu 4y ago
  Compute is cheap if you're doing trivial things that doesn't require much compute. Flip side is that this is true for everyone. If you're only doing trivial things that could have been done 20 years ago, you really don't have much competitive advantage. It's difficult to be competitive in the area of solving easy problems.
  - CharlieDigital 4y ago
    > Compute is cheap if you're doing trivial things that doesn't require much compute. A lot of the work on the web/API side is I/O bound (e.g. waiting for network I/O to database) so unless throughput is your game (e.g. Stackoverflow), it seems that Node is "good enough" for most web/API work.
    - marginalia_nu 4y ago
      It is I/O bound because you aren't using the available compute as much as you could. Modern hardware is insanely powerful. Like it's absolutely bonkers how much you can do on a modern computer. Although most modern applications have capabilities on par with a 2006 flash game.
      - CharlieDigital 4y ago
        All true, but there's a point of nuance: because cloud is all virtualized, you are taking advantage of the underlying high performance modern hardware because a serverless Node function is one of who know how many on the physical hardware.
clumsysmurf 4y ago
The only reason why I am looking at Golang is because of its fast startup and low memory usage. I prefer the Java ecosystem and Kotlin specifically; how is the JVM's progress in this area for serverless, etc?
- threeseed 4y ago
  There is GraalVM native image [1] which works well. And libraries like Quarkus [2] that leverage it that can launch in < 0.016s with < 12MB of RAM. [1] https://www.graalvm.org/22.0/reference-manual/native-image/ https://www.graalvm.org/22.0/reference-manual/native-image/ [2] https://quarkus.io https://quarkus.io
  - dschulz 4y ago
    unfortunately, compilation times are not so good.
    - msgilligan 4y ago
      Well, you do most of your compilation, test, and debug under the JVM and only do final test (and possibly debug) with native compilation.
- FlyingSnake 4y ago
  How is the generics story going in golang? I wonder if it brought a major paradigm shift in the way Go is written.
  - dgunay 4y ago
    It is definitely better than before, but doesn't really change the game much. It has severe limitations. My biggest hope when generics were announced was that we'd finally get an alternative to writing `if err != nil` 10+ times per function, but it doesn't support generic method type parameters. That alone kneecaps it severely by making type-safe method chaining useless in most scenarios (unless you never need to map to another type, ever, I guess. Lucky you.)
nickpeterson 4y ago
Oh great more shit to learn! I’m moving my entire bowling alley codebase to forth.
- lolive 4y ago
  Bash FTW!
xg15 4y ago
Pet peeve warning. I'd like to propose a very simple JEP for JDK22: Let me omit the useless {} at the end of a record declaration. I get that records are technically classes and that sometimes, you want to add helper methods, additional constructors, etc. But the canonical - and most common - usecase for records is a dumb immutable data structure, and for that you shouldn't need anything except the fields and generated methods. That's the whole idea behind them. I always found it strange that Java has you write an awkward empty class block for the standard usecase here, while reserving the more natural syntax for exotic uses.
- krzyk 4y ago
  Do you really think they just forget about it? It has a purpose: https://mail.openjdk.org/pipermail/amber-dev/2020-April/005899.html https://mail.openjdk.org/pipermail/amber-dev/2020-April/0058...
  - imoverclocked 4y ago
    That’s the fun thing about backward compatibility. You can never clean up technically supported things that were never intended. It would be cool if we could have some kind of pragma or alternate syntax (file extension?) that gets rid of these unwanted ambiguities every decade or so. How to do that while avoiding the whole “Perl 6” can of worms might be the hard part though.
    - KptMarchewa 4y ago
      Rust editions? They work on per crate, rather than per file level though.
      - pron 4y ago
        In Java you set the language version per source file, and there are occasional and uncommon source incompatibilities, but it's still not worth it to introduce a common incompatibility (which isn't really the case here, anyway).
emodendroket 4y ago
Tantalizing to know how many useful features are being added all the time and yet so many apps are stuck on JDK8.
- lolive 4y ago
  I see more and more the JDK11 to be an absolute minimum. (which leads to issues because of that [still mysterious to me] move to modules management)
VagueMag 4y ago
I've been playing around a lot with the pattern matching preview features in a small personal greenfield project, and the requirement to explicitly spell out the generic type params every time always catches me off guard and sorta craps up the code a bit. Looking forward to just using diamond operators there. I also can't do nested record destructuring because it causes an ArrayIndexOutOfBoundsException in the Eclipse Neovim LSP. The "bleeding" part of bleeding edge!
- zumu 4y ago
  > the requirement to explicitly spell out the generic type params every time always catches me off guard and sorta craps up the code a bit I'm glad it's not just me! I was implementing Either<T, U> the other day, and found writing Left<T, U> and Right<T, U> a little dirty. Progress is progress though.
ActorNightly 4y ago
Its kinda funny reading these. Kotlin and Groovy exist, which fixed a lot of the issues with core java (like for example requiring a class around a main function), but yet Java developers are completely oblivious to this. This kind of stuff should be in the core language. Im convinced that Java exists solely to create positions within Software Engineering industry. It requires you to write more code than necessary by design.
- re-thc 4y ago
  It's not a 1:1 replacement. Some things are better and some are worse with Groovy and Kotlin. Not everything is "fixed".
  - ActorNightly 4y ago
    If google moves their entire app development workflow for Android to Kotlin, its pretty much a 1:1 replacement.
    - re-thc 4y ago
      That's like saying if Java can adopt more features we don't need Kotlin? Doesn't help either way. It doesn't help either way. Kotlin definitely has its quirks and issues. Multiplatform means they're trying to re-invent everything and yet don't have all the resources to. With Kotlin moving to KSP for annotation processing this has been another source of pain with library developers having to maintain 2 variants. Not everything is KSP supported either. It's not quite so straight forward.
    - pjmlp 4y ago
      Yet they caved in, added Java 11 LTS to Android 12/13 and Java 17 LTS is coming this year. It turns out that being unable to use Java libraries is a big issue when one doesn't want to re-create the Java world in Kotlin.
- kaba0 4y ago
  For some reason people really can’t step over that 2 lines of boilerplate for Hello World, but here you are, it is being worked on: https://openjdk.org/jeps/8302326 https://openjdk.org/jeps/8302326
cutler 4y ago
I'm really looking forward to JDK 50 with its revolutionary Pattern.quotemeta() method which will be able to do what Perl has been doing for nearly 30 years.

143 points by mikece 4y ago

When I saw sequenced collections earlier I didn’t like the design but I completely approve of the latest revision. One nice thing about the process they use to develop Java is that they really do work and rework new features to make them great. I just wish that instead of Streams they’d made something more like https://github.com/paulhoule/pidove https://github.com/paulhoule/pidove With the possibility of making something more fluent and less lispy.

mindcrime 4y ago
Pidove sounds really awesome. I'm totally going to give that a try!
- PaulHoule 4y ago
  It has a sibling project which is still half-baked https://github.com/paulhoule/ferocity https://github.com/paulhoule/ferocity which is about developing a lispy DSL in which it is possible to write Java-in-Java to transform it to make syntactic macros. It's kinda crazy https://github.com/paulhoule/ferocity/blob/main/ferocity0/src/test/java/com/ontology2/ferocity/TestUrFierce.java https://github.com/paulhoule/ferocity/blob/main/ferocity0/sr... and somebody might think it combines the worst of Java and Common LISP but I did enough work on it to be sure there were no major barriers. ferocity0 is a bootstrap implementation that it's possible to write a code generator that can generate code to make stubs for the standard library and write ferocity1 in ferocity0 and write ferocity2 in ferocity1 with the full power of code generation to hide the accidental complexity of Java... But other projects got in the way.
  - brabel 4y ago
    Looking at your examples, this looks like https://github.com/square/javapoet https://github.com/square/javapoet
    - PaulHoule 4y ago
      Yeah, that’s very similar. Thanks for the link. It’s got the difference though that they are using (mostly) strings to write the method bodies and my approach builds those up with the lispy DSL. The class/method/field definitions are basically the same. (ferocity contains three languages, one of expression trees, one of class definitions, another of compound statements that doesn't exist yet) Mine can also run ‘lispy Java’ in an interpreted mode (as well as writing code that goes through javac) and I discovered the interpreter has a type system which is a little richer than the Java type system, namely I discovered (not invented) ‘quote’ and ‘eval’ so that expressions are a first class data type that can be manipulated…. I have to define some set of operators to make it easy to traverse and work on expressions which would make it easy to metaprogramming, probably taking back some of the verbosity that comes with the lispy java-in-java embedding.
pjmlp 4y ago
I would already be happy if they provided some adapters for exceptions in lambdas, instead of us having to create our own, or use one of the several libraries that provide them.

bcrosby95 4y ago

I was wondering this morning, with regards to the pattern matching for switch: Is there a performance consideration here? When using sealed classes, can the JVM do a better job optimizing pattern matches for switch? Are there also considerations with how it interacts with Project Valhalla? The team evolving Java seem pretty good at evolving the language with higher level goals in mind, so I wasn't sure if there were interrelated factors here.

tadfisher 4y ago
> When using sealed classes, can the JVM do a better job optimizing pattern matches for switch? Yes! In the Pair<I> example from the JEP, if the number of subclasses of I is large enough, it may be worth generating a perfect hash function [0] to match the pattern in O(1) time instead of the naive O(n^2). This is only possible in the general case for exhaustive switch statements, which sealed classes allow for with instanceof-style patterns. [0]: https://en.wikipedia.org/wiki/Perfect_hash_function https://en.wikipedia.org/wiki/Perfect_hash_function
- debug-desperado 4y ago
  So, has perfect hashing dispatch like you're describing here actually been added (or planned) in the JIT?

foolfoolz 4y ago

modern java is a huge improvement over old java. switch pattern matching will be huge, this has been in preview for a long time

papito 4y ago
Look, I haven't done Java in more than 10 years, but I have done Scala. Honest question - isn't Java just trying to "steal" Scala's concepts and catch up to the "cool" languages?
- mayank 4y ago
  All modern languages heavily borrow from each other’s latest iterations. In the case of Java though, playing catch up is by design since it’s intended to be a conservative/stable language.
- sfritz 4y ago
  Their philosophy is to "adopt" language features once they're well worn by other languages so they can learn from their mistakes / successes.
  - NwpierratorR 4y ago
    While philosophy is good, Java makes a very questionable syntactic choices when adopts that said features. Pure slowness in how java develop feels like you have to wait 5 years to get something that other languages have, only to get it in the most aesthetically unpleasant way. It seems like devs add unnecessary verbosity whenever they can. Java adopted lambdas after many other languages, yet still decided that allowing to move last parameter closure {} outside of () is too radical, even though it is much more visually pleasant choice and quite common in other languages. default methods in interfaces instead of static extensions. This one is controversial as static extension methods were not really common when java came up with this, but end result does not look impressive. Same with their new sealed classes. They just chose the most verbose version they came up with. Some inconsistency of choices also kinda baffles me. First they added support for skipping necessity of mentioning generic type inside <> during instantiation, only to introduce local vars later that require you to mention generic types within the same <>. Now you either mention generics by their full type always, or embrace the inconsistency and have it skipped when type mentioned in prefix and type it when using local vars. Or do not use local vars and have consistent codestyle with increased verbosity. Java is still a good language, but it feels dated in syntax. TBH I have no idea why would anyone chose java in 2023 when there's kotlin, which not only fully covers the same functionality(okay, no pattern matching and no loom/valhalla until java merges it), but does it while being much more concise and readable.

Phelinofist 4y ago

Structured concurrency sounds amazing, but it will probably take some time till it is widely usable :(

marginalia_nu 4y ago

Foreign Memory API can't come soon enough. The weird hoops you have to jump through to allocate large buffers of memory in Java are perhaps my least favorite aspect of the language right now.

marcosscriven 4y ago
What I’d really love to do is limit memory by Java thread, rather than per process. Allowing things like job runners to not crowd out others.

endisneigh 4y ago

It's been a while since I've programmed in Java. I wonder how good the concurrency stuff is these days. On a somewhat related note I was talking to a team from a random bay area company on how they switched from Java/Spring to Node and that Node is slower but since it's single threaded they load balance a bunch of servers and in practice it's just as fast when considering the developer productivity. Compute is really cheap these days, so I wonder how much it's worth it to squeeze every drop of performance out now.

marginalia_nu 4y ago
Compute is cheap if you're doing trivial things that doesn't require much compute. Flip side is that this is true for everyone. If you're only doing trivial things that could have been done 20 years ago, you really don't have much competitive advantage. It's difficult to be competitive in the area of solving easy problems.
- CharlieDigital 4y ago
  > Compute is cheap if you're doing trivial things that doesn't require much compute. A lot of the work on the web/API side is I/O bound (e.g. waiting for network I/O to database) so unless throughput is your game (e.g. Stackoverflow), it seems that Node is "good enough" for most web/API work.
  - marginalia_nu 4y ago
    It is I/O bound because you aren't using the available compute as much as you could. Modern hardware is insanely powerful. Like it's absolutely bonkers how much you can do on a modern computer. Although most modern applications have capabilities on par with a 2006 flash game.
    - CharlieDigital 4y ago
      All true, but there's a point of nuance: because cloud is all virtualized, you are taking advantage of the underlying high performance modern hardware because a serverless Node function is one of who know how many on the physical hardware.

clumsysmurf 4y ago

The only reason why I am looking at Golang is because of its fast startup and low memory usage. I prefer the Java ecosystem and Kotlin specifically; how is the JVM's progress in this area for serverless, etc?

threeseed 4y ago
There is GraalVM native image [1] which works well. And libraries like Quarkus [2] that leverage it that can launch in < 0.016s with < 12MB of RAM. [1] https://www.graalvm.org/22.0/reference-manual/native-image/ https://www.graalvm.org/22.0/reference-manual/native-image/ [2] https://quarkus.io https://quarkus.io
- dschulz 4y ago
  unfortunately, compilation times are not so good.
  - msgilligan 4y ago
    Well, you do most of your compilation, test, and debug under the JVM and only do final test (and possibly debug) with native compilation.
FlyingSnake 4y ago
How is the generics story going in golang? I wonder if it brought a major paradigm shift in the way Go is written.
- dgunay 4y ago
  It is definitely better than before, but doesn't really change the game much. It has severe limitations. My biggest hope when generics were announced was that we'd finally get an alternative to writing `if err != nil` 10+ times per function, but it doesn't support generic method type parameters. That alone kneecaps it severely by making type-safe method chaining useless in most scenarios (unless you never need to map to another type, ever, I guess. Lucky you.)

nickpeterson 4y ago

Oh great more shit to learn! I’m moving my entire bowling alley codebase to forth.

lolive 4y ago
Bash FTW!

xg15 4y ago

Pet peeve warning. I'd like to propose a very simple JEP for JDK22: Let me omit the useless {} at the end of a record declaration. I get that records are technically classes and that sometimes, you want to add helper methods, additional constructors, etc. But the canonical - and most common - usecase for records is a dumb immutable data structure, and for that you shouldn't need anything except the fields and generated methods. That's the whole idea behind them. I always found it strange that Java has you write an awkward empty class block for the standard usecase here, while reserving the more natural syntax for exotic uses.

krzyk 4y ago
Do you really think they just forget about it? It has a purpose: https://mail.openjdk.org/pipermail/amber-dev/2020-April/005899.html https://mail.openjdk.org/pipermail/amber-dev/2020-April/0058...
- imoverclocked 4y ago
  That’s the fun thing about backward compatibility. You can never clean up technically supported things that were never intended. It would be cool if we could have some kind of pragma or alternate syntax (file extension?) that gets rid of these unwanted ambiguities every decade or so. How to do that while avoiding the whole “Perl 6” can of worms might be the hard part though.
  - KptMarchewa 4y ago
    Rust editions? They work on per crate, rather than per file level though.
    - pron 4y ago
      In Java you set the language version per source file, and there are occasional and uncommon source incompatibilities, but it's still not worth it to introduce a common incompatibility (which isn't really the case here, anyway).

emodendroket 4y ago

Tantalizing to know how many useful features are being added all the time and yet so many apps are stuck on JDK8.

lolive 4y ago
I see more and more the JDK11 to be an absolute minimum. (which leads to issues because of that [still mysterious to me] move to modules management)

VagueMag 4y ago

I've been playing around a lot with the pattern matching preview features in a small personal greenfield project, and the requirement to explicitly spell out the generic type params every time always catches me off guard and sorta craps up the code a bit. Looking forward to just using diamond operators there. I also can't do nested record destructuring because it causes an ArrayIndexOutOfBoundsException in the Eclipse Neovim LSP. The "bleeding" part of bleeding edge!

zumu 4y ago
> the requirement to explicitly spell out the generic type params every time always catches me off guard and sorta craps up the code a bit I'm glad it's not just me! I was implementing Either<T, U> the other day, and found writing Left<T, U> and Right<T, U> a little dirty. Progress is progress though.

ActorNightly 4y ago

Its kinda funny reading these. Kotlin and Groovy exist, which fixed a lot of the issues with core java (like for example requiring a class around a main function), but yet Java developers are completely oblivious to this. This kind of stuff should be in the core language. Im convinced that Java exists solely to create positions within Software Engineering industry. It requires you to write more code than necessary by design.

re-thc 4y ago
It's not a 1:1 replacement. Some things are better and some are worse with Groovy and Kotlin. Not everything is "fixed".
- ActorNightly 4y ago
  If google moves their entire app development workflow for Android to Kotlin, its pretty much a 1:1 replacement.
  - re-thc 4y ago
    That's like saying if Java can adopt more features we don't need Kotlin? Doesn't help either way. It doesn't help either way. Kotlin definitely has its quirks and issues. Multiplatform means they're trying to re-invent everything and yet don't have all the resources to. With Kotlin moving to KSP for annotation processing this has been another source of pain with library developers having to maintain 2 variants. Not everything is KSP supported either. It's not quite so straight forward.
  - pjmlp 4y ago
    Yet they caved in, added Java 11 LTS to Android 12/13 and Java 17 LTS is coming this year. It turns out that being unable to use Java libraries is a big issue when one doesn't want to re-create the Java world in Kotlin.
kaba0 4y ago
For some reason people really can’t step over that 2 lines of boilerplate for Hello World, but here you are, it is being worked on: https://openjdk.org/jeps/8302326 https://openjdk.org/jeps/8302326

cutler 4y ago

I'm really looking forward to JDK 50 with its revolutionary Pattern.quotemeta() method which will be able to do what Perl has been doing for nearly 30 years.