Java 20 / JDK 20: General Availability

https://mail.openjdk.org/pipermail/jdk-dev/2023-March/007517.html

by mfiguiere • 3 years ago

311 323 3 years ago

mail.openjdk.org

ar9av• 3 years ago

Gist: ``` JDK 20 introduces six features: - Scoped values for safe sharing of data across threads - Record patterns for declarative data navigation and processing - Foreign function and memory API for interoperation with code and data outside the Java runtime - Virtual threads for lightweight concurrent programming - Structured concurrency for simplified multithreaded programming - Pattern matching for switch statements and expressions for concise and safe complex data-oriented queries ```

carimura6• 3 years ago

...but also thousands of other stability, performance, and security updates.

ActorNightly3• 3 years ago

Don't worry, someone will still manage put in a bug that results in a zero day in the next 2 years.

mfiguiere• 3 years ago

A good coverage of all the JEPs included in JDK 20: https://foojay.io/today/its-java-20-release-day-heres-whats-...

PaulHoule• 3 years ago

Note all the new cool stuff is incubator and preview status and I'm a little worried that this will still be the case for the JDK 21 stable release.

ludovicianul• 3 years ago

I have hopes to see Virtual Threads in Java 21, also being the next LTS.

grishka• 3 years ago

IIRC they are going to release pattern matching for switch and record deconstruction as stable in JDK 21.

rfrec0n• 3 years ago

I think this is supposed to be the last preview version of FFI and the other JEPs from Project Panama, so hopefully we will have them at least but I definitely share a bit of that concern.

carimura6• 3 years ago

Probably not this go-around: https://openjdk.org/jeps/442

Better to be right then rushed though.

zjaffee2• 3 years ago

I really hope to see the SIMD vector related improvements come through, I know there are some independent JDK code bases that have more evolved SIMD support, but for a lot of big data processing tools, switching away from jdk based languages appears to be the way SIMD related performance improvements have been realized because of this missing crucial feature set. JDK 11 was when this stuff was first in development, and it's truthfully insane that it hasn't fully been released yet.

kaba015• 3 years ago

Most of these low-level APIs simply just wait for value types - they don’t want to hardcode something into the language, that might not be a perfect fit for those. Which makes sense, frankly.

carimura6• 3 years ago

More details on 20:

Announcement: https://inside.java/2023/03/21/the-arrival-of-java-20/

VM improvements: https://tschatzl.github.io/2023/03/14/jdk20-g1-parallel-gc-c...

Non-JEP Improvements: https://nipafx.dev/java-20-guide/

Idiot_in_Vain• 3 years ago

Damn, time flies.

I remember the excitement from the different alpha/beta versions that were coming out in 1994/1995.

jvolkman• 3 years ago

Time only started flying with the release of Java 9. Prior to that versions stuck around for years.

jwr2• 3 years ago

I still remember the Java launch party that was done by Sun Microsystems (regional office).

garblegarble3• 3 years ago

This is exciting, can't wait for the LTS release next year... that said, I don't much care for the "case SomeType t when ..." pattern matching syntax, I don't see the benefit of introducing a new keyword over using "if"... or even just "&&". To pinch the example used in[1]:

    case Tuner t && guitar.isInTune() -> ...;

and

    case Tuner t if guitar.isInTune() -> ...;

both seem as clear as

    case Tuner t when guitar.isInTune() -> ...;

...am I misunderstanding the reasoning here? Is it being introduced to keep the grammar definition simpler?

1: https://foojay.io/today/its-java-20-release-day-heres-whats-...

mason55• 3 years ago

In the case of &&, the left hand side of the expression (Tuner t) isn't a boolean expression.

In the case of "if", you're right, the grammar doesn't work, both because the syntax of Java already says that the if condition must be enclosed in parentheses and also because an if block is a statement and you need an expression here.

To make either of those work, you'd have to make the rest of the pattern matching syntax much worse.

anyfoo4• 3 years ago

The “&&” one is super confusing indeed, but the “if” one is just a question of style. It would be possible to reuse the “if” keyword for different grammar. python does it for its trinary operator, where there is an expression instead of a statement after “then” (e.g. “foo = if bar then 1 else 2”), but if Java does not have the same habit of reusing keywords already (not sure), it might not want to start now for consistency.

papruapap• 3 years ago

they want it to be as ugly as cpp

dang• 3 years ago

Maybe so, but please don't post unsubstantive and/or flamebait comments to Hacker News. We're trying for something different here: https://news.ycombinator.com/newsguidelines.html.

bcrosby953• 3 years ago

In 2nd preview, they used &&: https://openjdk.org/jeps/420

At 3rd preview, they switched to when: https://openjdk.org/jeps/427

In that JEP they state:

Based upon experience and feedback we propose instead to allow when clauses in switch blocks to specify guards to pattern labels

So I assume people thought && was confusing.

anyfoo4• 3 years ago

The “&&” one is bizarre, it makes it look like the whole thing is a Boolean expression, which it absolutely is not. That gets even weirder because the part right of it actually is a Boolean expression, so on top of very confusing reading you now make it look like there are strange interactions with operator precedence. Using && is one of the worst choices.

The “if” one does not suffer from any such problem and reads okay to me. I guess one argument against it could be that since the whole thing is a distinct grammatical construct, why not just introduce a distinct keyword instead of making an existing keyword depending on context? That’s mostly a question of style though (e.g. I don’t know right now if Java already has an habit of reusing keywords like that).

mikepurvis• 3 years ago

I'm not a Java user, but I really don't love the overloading of `if` in Python (statement, ternary, comprehensions), so introducing a new keyword here seems pretty reasonable to me.

And don't even get me started on `static` in C++.

garblegarble3• 3 years ago

The "&&" approach is how you express that same logic in an if statement in Java today.

Given this pattern matching syntax change, you'd write:

    switch(obj) {
        case Tuner t when guitar.isInTune() -> ...;
        ...
    }

For a switch, but for an if statement it's written as:

    if (obj instanceof Tuner t && guitar.isInTune()) {
        ...
    }

Edit: I do wonder, actually, if avoiding "&&" is to allow the "when" case execution to be reordered (e.g. to allow JIT to extract common "when" conditions prior to the switch expression), which would be wrong to do given the short-circuiting rule implications of "&&"

hn_throwaway_994• 3 years ago

As another comment mention, they did use && in the 2nd preview, but then switched it, so you're right, it must have been confusing.

FWIW, though, I don't find it "bizarre". While it's not a boolean expression per Java, at least in my mind it serves the same purpose: "in the case that thing x is of type SomeType and ...some other thing about ((SomeType)x) is true...".

I think it's a tough choice, I'm sure they were probably not wanting to add a new keyword, but at the end of the day "when" is so familiar to anyone who's ever written SQL (which I'm guessing is most Java devs) so seems like a good choice.

pkulak• 3 years ago

I think Rust uses "if" for its match guards too and I don't recall it upsetting anyone. I'm all for keeping things consistent between languages if only to prevent too much bike shedding.

pron2• 3 years ago

This year. Six months from today.

shagie• 3 years ago

(just on the following up on this)

https://en.wikipedia.org/wiki/Java_version_history

The non-LTS releases are every 6 months and have support for one year.

LTS releases are every 4th release which falls on odd numbered years in September.

MBCook• 3 years ago

Oh really? Sweet. It’s only relatively recently I’ve been able to use Java 17 everywhere (there were straggler codebases).

And now I’ll get 21 soon? Awesome.

lifewallet_dev• 3 years ago

I think the only reason is that they're very different, if you define them:

    type when expression -> block

    if expression -> block

For parsing works better, for programmers is better since they don't confuse both concepts, and in general pattern matching isn't the same as a if condition or a switch.

https://stackoverflow.com/questions/199918/explaining-patter...

I think the difference is when you start pattern matching on tuples and other types that you cannot do a simple `if ident.isinstanceof(type) ->`.

For example in Elixir you can do:

    def ident(param = {:key => true}):

This will only match when the param type is not only `map`, but also contains a key named `:key` and its value is `true`.

In the end though, it's syntax sugar (but everything is if you put it that way classes are syntax sugar).

munificent6• 3 years ago

I work on Dart which is also adding pattern matching [1]. When we designed the syntax for guards, we also considered exactly these three choices before ultimately landing on "when" too.

Our main reasoning was:

"&&" is intuitive but it means that you can have a pattern that is immediately followed by an infix operator. That can be problematic if you ever want to make "&&" a valid pattern infix operator. And, in our case, we ended up doing exactly that, so "&&" would have been ambiguous. If you were to write:

    case foo && true:

Then it could be parsed as either a pattern that matches when the value is equal to the constant "foo" and is equal to the constant "true". Or it could be parsed as a pattern that matches when the value is equal to the constant "foo" followed by a pointless guard that always succeeds.

"if" is nice because it's already a reserved word and the semantics are pretty obvious. But in Dart, an if statement always has the condition in parentheses. Those are pointless in a pattern since we already have another explicit delimiter separating the guard from the case body:

    case foo if (condition):
    //                     ^

We could say that the if condition in a guard doesn't need parentheses but if conditions elsewhere do. But that's likely just an annoying footgun where users will write them unnecessarily (but harmelessly at least) in guards and forget them in if statements and get compile errors.

If Dart didn't require parentheses around if conditions, we probably would have used "if" for guard clauses to (like Scala and Rust do).

So we tried "when" and most users and team members seem to like it. Syntax design is a human-centered process so often the right answer is just what feels right to the most people.

[1] https://github.com/dart-lang/language/blob/master/accepted/f...

Pet_Ant• 3 years ago

Gotta say I'd've taken the if with parentheses myself. Feels like it's reusing something familiar even if they are extraneous at times.

garblegarble3• 3 years ago

Thank you, that's excellent insight into the thought process for the same feature at about the same time.

You mention about the human-centred nature of syntax design... do you have any instinct for why one route vs another felt right to users? Do you feel like you've developed a better instinct for this over time, or is it still hard to predict what will feel natural to users?

dart_fan• 3 years ago

Very excited to hear this, if true, I will pick up Dart & Flutter again after this is released.

DeathArrow• 3 years ago

Maybe they got inspired by C#?

var favoriteTask = obj switch

{

  Developer dev when dev.YearOfBirth == 1980 => $"{dev.FirstName} listens to metal",

  Developer dev => $"{dev.FirstName} writes code",

  Manager _ => "Create meetings",

  _ => "Do what objects do",

};

morph123• 3 years ago

This feels a bit like discussing the new fancy garden hoe as a farm hand as they are making the tractor.

philipwhiuk• 3 years ago

Only if you build your tractors out of garden hoes ;)

unixhero• 3 years ago

Are these hoes somehow related to lemon stealing hoes?

mrkeen2• 3 years ago

Java is a conservative language, which means that it waits and sees which features work well for the tractor, and then retrofits them to the hoe.

pron2• 3 years ago

except no one's making the tractor

znpy3• 3 years ago

Does anybody know if there are significant improvement fir java on arm in this release?

exabrial• 3 years ago

Java on my ARM MBP is _very_ fast, by a large margin; faster than my x86 cloud servers by 1.5x-2.5x

znpy3• 3 years ago

Nice, I’ll put your arm laptop in production then

carimura6• 3 years ago

More info on 20:

Announcement: https://inside.java/2023/03/21/the-arrival-of-java-20/

VM improvements: https://tschatzl.github.io/2023/03/14/jdk20-g1-parallel-gc-c...

Non-JEP Improvements: https://nipafx.dev/java-20-guide/

pshirshov5• 3 years ago

structured concurrency

That's another huge effort which delivered us an imperfect abstraction.

I would prefer to have HKTs and typeclasses, so I may implement my own IO monad.

quectophoton• 3 years ago

I would prefer to have HKTs and typeclasses, so I may implement my own IO monad.

I'm not a Java developer, and I haven't even read about higher kinded types or typeclasses (the theory side of programming is my weakness); but you picked my curiosity with this.

Can you elaborate how concurrency done this way would look in Java?

pshirshov5• 3 years ago

Ideally like this: https://zio.dev/reference/#concurrency

Or this: https://hoogle.haskell.org/?hoogle=fork

roschdal2• 3 years ago

Java 8 is the best Java.

oweiler• 3 years ago

Why? Java 11 is already leaps and bounds better than Java 8.

roschdal2• 3 years ago

Java 8 was before Oracle started with evil licensing terms and crazy language changes which allowed all kinds of alternative syntaxes.

cesarb5• 3 years ago

Not the parent poster, but I can see why: IMHO, the best new feature for Java was try-with-resources (Java 7), and the second best new feature was all the functional stuff in Java 8. On the other hand, Java 9 started the introduction of several breaking changes (it took years before I stopped seeing updates to Java libraries to fix their compatibility with Java 9 and Java 11), so it can be seen why someone would think of Java 8 as the highest point of that language.

(For Java 9/10/11 in particular, there are several small enhancements, but nothing as earth-shaking as the changes we got with Java 7/8.)

jabroni_salad• 3 years ago

I'm in Security and 8 generates a lot of revenue for me :)

I'm not sure that it's inherently insecure, there is just a ton of old stuff in the ecosystem still chugging away.

vips7L4• 3 years ago

Java 8 is an antiquated runtime. You're doing a disservice to your customers and developers by continuing to use it.

deely3• 3 years ago

Java 8 is working runtime. Whats wrong in using runtime that works?

pmontra• 3 years ago

Maybe that's why the two Java based products used by a customer of mine both have been using Java 8 since forever. One eventually switched to Java 11 last year.

Or licensing, or having to rewrite too much of those apps for no perceived value. Who knows.

629514132• 3 years ago

In locations which JDK Release Notes reach in eight light-years.

akavi2• 3 years ago

Now even Java has pattern matching, what's Javascript's excuse?

Literally the only feature preventing Typescript from being my perfect language.

Waterluvian2• 3 years ago

https://github.com/tc39/proposal-pattern-matching

I'm not sure if it's stalled or not. But it's being discussed.

jackworks• 3 years ago

We're still developing this proposal. be patient LOL

BiteCode_dev2• 3 years ago

Given the terrible result we came up with in the Python community, I understand the JS wants to take their time. It's a great feature, but it's hard to get right, especially on an existing language.

Not to mention JS is not typed, but pattern matching that can't match typescript types would be terrible.

sgt• 3 years ago

What's wrong with match? I've used it quite a bit and it is quite powerful.

Yahivin• 3 years ago

Check out Civet https://civet.dev/#pattern-matching

dgb233• 3 years ago

I don't see a huge benefit for pattern matching in JS outside of it being expression based rather than statement based.

Either way, the benefit has to be enormous. It's a feature that can easily break existing code.

int_19h2• 3 years ago

How would it break existing code?

baq• 3 years ago

In a world where upgrading node versions without language changes breaks existing code I wouldn’t be too worried.

Alifatisk5• 3 years ago

What’ the hype with pattern matching? What does it solve?

dcminter• 3 years ago

It's really nice syntactic sugar. Complicated conditional logic cluttered with redundant types turns into a series of simple patterns. "Just" makes it easier to not make stupid bugs (I'm all for it).

brabel• 3 years ago

Hype with pattern matching? That sounds quite funny to me considering certain languages (Haskell, Erlang, OCaml...) have had that for decades.

What convinced me of the power of pattern matching was seeing a red-black binary tree being implemented effortlessly in Ocaml (I think), while in C++ and Java it was a really difficult algorithm to implement.

When you have provably exhaustive pattern matching (i.e. the compiler forces you to handle every possible case), certain things that are very difficult to write otherwise become very easy.

munificent6• 3 years ago

If you've ever done any assembly programming or worked with other old or low level languages, you may have encountered an environment where you can write simple operator expressions, but you can't compose them. So this is OK:

    a = b + c
    d = e - f
    g = a * d

But the compiler doesn't allow:

    g = (b + c) * (e - f)

You have expressions that produce, but they don't compose. You can't produce a value from a more complex, nested expression. We, rightly, no longer use languages like that.

Pattern matching parallels that, except for assignment and decomposing values. Many languages today let you write:

    topLeft = rect.topLeft.x;
    left = topLeft.x;
    top = topLeft.y;
    bottomRight = rect.bottomRight;
    right = bottomRight.x;
    bottom = bottomRight.y;

Or even:

    left = rect.topLeft.x;
    top = rect.topLeft.y;
    right = rect.bottomRight.x;
    bottom = rect.bottomRight.y;

(Because at least you can compose expressions on the RHS.) But they don't let you write:

    (topLeft, bottomRight) = rect;
    (left, top) = topLeft;
    (right, bottom) = bottomRight;

Or even:

    ((left, top), (right, bottom)) = rect;

Pattern matching gives you that. It is freely composable destructuring.

Also, the "matching" part means that in many languages you can also ask questions about values as you destructure them, which enables a particularly nice style of programming.

nvarsj• 3 years ago

It makes it very easy to deal with nested data structures. Imagine creating a nested map/struct literal, and then extract the values out using a very similar syntax on a single line.

It's one of those things that when you get used to, you wonder why other languages don't implement it.

leros• 3 years ago

This seems like an appropriate place to post the official Java rap: https://youtu.be/b-Cr0EWwaTk

BenoitP• 3 years ago

I prefer this one: Java Forever And Ever Movie (Java vs Windows .Net)

https://www.youtube.com/watch?v=RnqAXuLZlaE

oaiey5• 3 years ago

Awesome but today this would be a different story line ... maybe: two old conservatives (Java and C#) re-inventing themselves to fight against the hipsters (Go, Swift, JS, ...) ;)

elygre• 3 years ago

All the JavaZone videos are amazing. Like this one: https://www.youtube.com/watch?v=1JZnj4eNHXE

Traubenfuchs• 3 years ago

I still don't understand what's the correct way to replace thread locals holding initialization heavy & non thread-safe instances besides using a pool which produces a lot of overhead when using loom/virtual threads. In the past, with ThreadLocal, you'd have one instance per thread, making sure that those instances could only be used once and would only be instantiated for all threads of your (acceptor) thread pool

Does anyone know the solution?

Holo3143• 3 years ago

Virtual threads are designed for light, IO-bound, tasks, if your task is heavy/CPU-bound tasks then you won't necessarily want to switch to virtual threads with ScopedValue.

rjzzleep• 3 years ago

Here's me wondering how many more years will pass before the Wayland support is going GA.

erik_seaberg2• 3 years ago

If applets and web start are dead, and Wayland doesn’t render remotely, how would this work? Would a Java app server have to ask the user to run something on the desktop?

drdec• 3 years ago

There are java desktop applications, e.g. IntelliJ, SQLDeveloper, etc.

foolfoolz• 3 years ago

its amazing how much the world hasn’t been able to keep up with java. github PRs still have no syntax highlighting support for record and var

jayd166• 3 years ago

Why do you think that is? I thought things like the language server protocol made this a self service kind of problem. Who needs to be catching up?

oaiey5• 3 years ago

Because syntax highlighting in JavaScript is (presumingly) not covered by LSP but by a generic syntax parser. And these updates take endless through the supply chain pipeline.

And as a side note: LSPs are not exactly free these days anymore. Java is not considering it core project (I guess outsourced to RedHat and Eclipse) and Microsoft has a very erratic behavior towards what is in and out the LSP or DAP.

TheAceOfHearts• 3 years ago

Github uses Linguist for syntax highlighting and has a section in their CONTRIBUTING document for fixing bad syntax highlighting [0].

Admittedly I couldn't figure out exactly what repo is being used for Java's syntax highlighting since vendor/README.md says Java is using tree-sitter/tree-sitter-java and grammar.js in that repo appeears to already include references to record.

languages.yml [1] shows ace_mode java, and ace editor's java_highlight_rules.js doesn't mention record anywhere. I'm not clear if github is using ace editor or code mirror, since both are mentioned there.

Hopefully this helps get started on improving the poor syntax highlighting experience.

[0] https://github.com/github/linguist/blob/master/CONTRIBUTING....

[1] https://github.com/github/linguist/blob/c34f887f48d81e2ed42b...

[2] https://github.com/ajaxorg/ace/blob/a2e89b94b4dcdff28bf3c8f4...

mrkeen2• 3 years ago

With Java it's always win/win. If external software works with it, "Java has great tooling", if it doesn't, the rest of the world is slow.

DannyBee2• 3 years ago

It's highly amusing to watch java folks frame this as the rest of the world not "keeping up" when it's pretty obvious it's the rest of the world not caring enough to do anything about it.

I wonder how long it will be before they realize they are in the slow, sad, decline regardless of how many features get added.

xyzzy4747• 3 years ago

I think this is true for young companies - for example every crypto startup I’ve interacted with makes their backend in either Node.js, Golang, or Rust.

There is quite a lot of legacy software that uses Java though.

miffy900• 3 years ago

'The world' in this case also includes a large portion of java programmers; it takes years for Java programmers to adopt new language features, if they do so at all. They're almost as bad as C++ devs.

And if you consider the history of Java as a language since the 1990's, it has historically had very slow feature releases. If you review the release history of Java, almost half of major relases and changes to the language came after 2014+. var in Java came out in 2018, record was introduced out in 2020 - feaures that were copied from other languages that already had them for years. Java as a language is still is playing catchup here.

guru4consulting• 3 years ago

>Java as a language is still is playing catchup here.

It's a feature, not a bug.

tiffanyh• 3 years ago

What's the relationship between the Java releases and GraalVM releases?

mike_hearn7• 3 years ago

They're being synchronized at the moment.

jwr2• 3 years ago

As a Clojure programmer, I don't care about any of the Java language features or improvements, but I'm super happy that I'm getting a state of the art JVM that is continuously developed, maintained, extended and optimized, over a time scale of decades.

This is incredibly useful: having a good VM to run your code in, with good modern garbage collectors, is not an obvious thing (as many other languages have learned).

This is not the LTS release, so I won't be switching to it, but I'm looking forward to the next LTS.

zerr• 3 years ago

The same applies to Clojure CLR, right?

herculity275• 3 years ago

I haven't looked into CLR in a long time, but it feels like it has a fraction of JVM's adoption and community size. Microsoft also seems to be prioritizing Typescript and Node internally with its recent moves.

logistark2• 3 years ago

As Clojure programmer, i tell you that you should, because any moment Java introduce new features libraries will start using and most Clojure libraries are Java libraries wrappers.

In addition if you want to use these new Java libraries in case and Clojure does not catch up with new Java features the ergonomics of using Java libraries with clojure decrease.

And still they are trying to figure out how Ifn Clojure interface with Java functional interfaces.

Also when Project Loom lands on JVM it will benefit Clojure too, allowing to remove code for instance of Clojure futures.

If Clojure catch up with Value classes can increase performance of Clojure too.

But this disregard of Java features or improvements is the kind of Clojure developer so content of what he have that forgots that can get better things.

Alifatisk5• 3 years ago

I second this, using jRuby

koito172• 3 years ago

As another Clojure programmer, I say you should care about developments in Java. After all, the Java module system is precisely why classes became minefields with clojure.core/bean -- illegal reflective accesses and what not.

As someone else noted in this comment section, a lot of useful Clojure libraries are wrappers over Java libraries. So improvements to Java used in these libraries are good for you, too.

tadfisher• 3 years ago

The Java module system is a problem on Java as well. They defined "module" in the narrowest terms possible (API visibility) without addressing any of the modularization problems Java developers have to deal with every day, so we end up with another layer on top of the layers of third-party dependency management systems, package repositories, and runtime class loaders that we are forced to use to have a semblance of a working build and deployment toolchain. They could have expanded upon this foundation and came up with the equivalent of Cargo or go modules, but instead they created this n+1 standard that 90% of developers either ignore or disable.

I'm sure it works for OpenJDK though.

pjmlp5• 3 years ago

Any user of a guest language should care about what the "systems" language of the platform offers, if nothing else, to understand those stack traces, and FFI to platform libraries.

FalconSensei2• 3 years ago

And here I am still on Java 8 :/

rafaelturk• 3 years ago

Impressive how many companies are stuck on quite old java versions. We are a core API for payments services, and we need to force our customers to upgrade to newer Java versions as most of them don't support newer encriptyion protocols

oaiey5• 3 years ago

Thank You for your service.

taftster9• 3 years ago

I mean, that's OK though. Not sure why this is considered such a bad thing. You're missing out on some new language features, sure, but Java 8 is still reliable and rock solid. There's lots of companies that have hesitation or even inability to upgrade, hopefully there's at least some initiative and/or direction to do so.

A company that is head-in-sand deliberately not upgrading from Java 8 is one thing. A company that is just being conservative and intentional about the upgrade path, that's another entirely different thing.

I don't mind a company that has been using Java so much that it's just a slow process for them to get on the next thing. Old libraries that need to be recompiled for Java modules, etc. Hopefully it happens for you soon.

logistark2• 3 years ago

I think that the main problem upgrading beyond Java 8 is Java 9 and module system and a lot of javax package classes that were removed. It will be very helpful a tool that can detect what modules or classes that are being used by your codebase and add them as maven or gradle dependencies and add them to the classpath.

FalconSensei2• 3 years ago

I mean, that's OK though. Not sure why this is considered such a bad thing

For existing software, sure. But the problem I guess is when there are a lot of newer projects starting and everyone is stuck on the older version

paulmd• 3 years ago

There's very little reason not to upgrade from Java 8 at this point. Everything should be a drop-in replacement and there are significant performance benefits (garbage collection is leagues better) to doing so.

The bigger problem is that a lot of places are stuck on Oracle JDK - 8u252 is the last free version so a lot of places just decided they'd never upgrade, nor do they want to look at whether Temurin or Coretto would work for them (the answer is usually yes).

0xDEF• 3 years ago

It's interesting how the introduction of "modules" has forced so many to stick with C++17 and Java 8.

Longhanks• 3 years ago

C++ has barely any feature complete compiler implementations and build systems aren’t ready for all of its additions, either (CMake and modules in particular). libstdc++ and libc++, gcc and clang are all not ready for production use or rather untested and/or buggy.

Unless you’re targeting MSBuild Visual Studio Solutions and Windows only, C++17 is currently the most up to date, stable, and battle-proven version.

TheRealPomax2• 3 years ago

Perfectly fine for already written codebases or codebases that need to target hardware that's stuck in the past?

Just don't use it for new projects on modern hardware. Be on at least the current LTS version for that and enjoy a much more expressive language on a much better JVM.

SPBS• 3 years ago

My codebase at work is written in Java 8, I honestly don't see what other benefits upgrading the language would bring. There's already so much business code written in the old Java 8 style (which works), don't go trying to change how the code is written now. To me Java 8 is simple and boring like Go, with some imperfections like the lack of a native map data type.

I'd still upgrade for the new VM's better performance/security patches or whatever, but I don't need any language changes.

spacephysics• 3 years ago

Big reason is security patches. But if the services are running in a VPN and don’t interact with outside world, it’s fine

riku_iki• 3 years ago

We migrated our codebase because multi line string literals somewhere in jdk14 made writing large SQL queries in java code so much easier.

dtech2• 3 years ago

I unfortunately encounter this mindset so much in Java programmers, and the similar "we don't need no feature X" even if the feature has proven themselves for a long time in a large amount of languages. I'm hesitant to bring it up, but I see a lot of Blub Paradox [1] among Java programmers. Heck, a lot of places disallow `var`, while over here in Kotlin-Python-Rust-C#-Typescript-Go-etc-land that's been the default since forever.

Taking this comment in good faith, the following language features from 9+ are incredibly useful for everyday programmers, you should give them a serious try before dismissing them:

- `var` local type inference

- record classes

- text blocks

- switch expressions

- sealed classes and interfaces

[1] http://paulgraham.com/avg.html

therealdrag02• 3 years ago

People think boring is good but it’s not. Simplicity is good. Boring is just what you’re familiar with.

New features done right improve simplicity by abstracting away complexity or need to reinvent the wheel. For example Go devs having wrote their own list .map() functions is absurd.

barkingcat2• 3 years ago

Minor typo in the linked site:

"JDK 20 reached General Availability on 21 March 2022"

Should be 21 March 2023

Not sure who can edit that page but putting here.

spicybright• 3 years ago

Just adding too, I think some of the switch statement example code is wrong:

    Object obj = 123L;
    String formatted = switch (obj) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };

Unless I'm not understanding something, the default statement should be `obj.toString()` as `o` isn't defined.

mdaniel• 3 years ago

JFC, I was going to say they should have used `String.valueOf(obj)` since I expected `Object obj = null; switch (obj) { default ->` to do something sane but no, the stupid PoS NPEs because `switch` itself evidently calls `Objects.requireNonNull`

The Billion Dollar Mistake meets the Power of Compounding Interest to produce an inflation adjusted number that just keeps on giving

barkingcat2• 3 years ago

This was fixed by Mark Reinhold

philonoist• 3 years ago

Could the pundits of HN please compare this release with Kotlin?

jillesvangurp• 3 years ago

Picking the release notes apart:

- ScopedValue (Incubator). Seems like a replacement for ThreadLocal that is intended to be a bit less dangerous (it is notorious for leaking memory and file handles). The Kotlin equivalent would be CoroutineScope. I'd say the latter is the cleaner solution. And probably ScopedValues came into existence for the same reason (co-routines & structured concurrency kind of breaking ThreadLocal a bit).

- Record Patterns (Second Preview). This looks a bit like Kotlin's smart casts. Useful. I think the Kotlin implementation with contracts is a bit more powerful and broadly applicable in more use cases. But nice of course.

- Pattern Matching for switch (Fourth Preview). That looks to me like an attempt to beef up the Java switch, which is a welcome change. The Kotlin equivalent would be when. Not a whole lot of difference at first glance. But combined with smart casts, Kotlin is quite nice already IMHO. Scala developers might disagree about a thing or two here..

- Foreign Function & Memory API (Second Preview). Looks like a nice JVM level feature for integrating native code that is potentially also of use to the Kotlin language developers.

- Virtual Threads (Second Preview). The second iteration of Loom. The JVM level implementation for this is going to make Kotlin's co-routines potentially even nicer. I don't think it should be that disruptive for Kotlin developers already using co-routines but performance increases are nice.

- Structured Concurrency. Also Loom related. From what I've seen of Loom so far, it should just work with your existing code without too much changes. And co-routines are definitely a nice API to do structured concurrency so not particularly relevant for Kotlin users. But it's going to be a big enabler for Java developers that have lacked this.

- Vector API (Fifth Incubator). Another JVM level optimization that the Kotlin developers should be able to make use of. I imagine projects like the kotlindl framework (a deep learning framework) can make use of this. A bit niche but nice if you use things like that.

So, nice incremental change and a few nice things that Kotlin will benefit from probably. Whether you use Java or Kotlin, it's going to be nicer for everyone once this ships in an LTS jdk.

Holo3143• 3 years ago

- ScopedValue doesn't have a direct equivalent in Kotlin, but CoroutineContext.Element and ThreadContextElement inside of CoroutineContext serve the same purpose. I really think Kotlin overcomplicated this idea.

- Record Patterns are stronger than Kotlins smart cast because of nested patterns

- Kotlin Coroutines works exclusively with Structured Concurrency already. The JEP just adds a way to use Structured Concurrency with threads (it can also be used in Kotlin if you use pure Threads(virtual or not), but I don't see any reason not to use Coroutines

pjmlp5• 3 years ago

Most Kotlin users don't get anything from JVM, as the majority target Android, and Google doesn't care that much about keeping Java up to date, even the latest LTS updates, are partial support.

DonHopkins2• 3 years ago

Why not just use C# instead? It was purposefully designed to address and correct the many mistakes of Java, and much more importantly, it's not owned by Oracle.

Alifatisk5• 3 years ago

Isn’t openjdk disconnected from Oracle?

znpy3• 3 years ago

Not only that, oracle’s jdk is actually a distribution of openjdk.

kaba015• 3 years ago

Disconnected? No. Oracle pays for 95+% of all OpenJDK commits. Their OracleJDK is pretty much just an OpenJDK with a few logos added — they have over time made every proprietary feature open-source and available in OpenJDK.

But as I expanded a bit more here (https://news.ycombinator.com/item?id=35249701 ), Java is probably the safest bet from a code longevity perspective.

oaiey5• 3 years ago

With all my love for .NET, why not continue Java with its new features when it fits to your developer base, existing products etc.

Give it one or two more years and Java is where C# is ... also aesthetically. As did JavaScript.

EVa5I7bHFq9mnYK• 3 years ago

The feature that everyone is excited above - switch statement with pattern matching - has been available in C# for 6 years now.

twobitshifter• 3 years ago

C#, owned by the most ethical company in software.

Java is very different and much improved from when c# branched off, but many people haven’t been following along and still think it’s the same as in 2002.

hota_mazi3• 3 years ago

This is 2023 and you are saying that Microsoft is less ethical than Oracle.

A lot of things have happened since the 90s, you know?

palata• 3 years ago

Or Kotlin? Or Scala?

DonHopkins2• 3 years ago

Why not just use C# instead? It was purposefully designed to address and correct the many mistakes of Java, and much more importantly, it's not owned by Oracle.

taftster9• 3 years ago

All the while, adding its own mistakes to the pile.

As an example, idiomatic Java style is moving away from getters/setters and instead favors builders and immutable types. That whole inheritance vs. composition concept is changing the way Java is being used.

Meanwhile, C# has baked getters/setters so deep into their language (as properties) that there's just no moving off of them. Have you tried making a Builder in C# - ugh. Much harder than it should be.

C# took the best of Java and ran deep into a cave with it. Meanwhile, Joshua Bloch's Effective Java has completely changed the way that "good" Java should be written and likely helped kickstart the whole revolution that is modern Java.

I agree with your sentiment in general. C# / CLR are truly remarkable engineering feats. But Java is starting to break away from its old molds and is seemingly adding agility as it goes.

As far as ownership. Java is not owned by Oracle any more than C# is not owned by Microsoft. They are both open languages with a majority backing supporter that yes, has a lot of influence over the languages. I'd argue Microsoft has more influence over C# / CLR than Oracle does on Java / JVM (but that's too close to call and probably too opinionated to suggest).

desertlounger2• 3 years ago

Yes. And with "records" (record classes, something with the characteristics of a tuple or struct) you can get further away from getter/setter boilerplate code.

gcl09• 3 years ago

Aren't records and init only setters in C# also a way to favor immutable types and fix setters in properties? (Not trying to criticize, I really want to know).

desertlounger2• 3 years ago

AFAIK Java was GPL'd by Sun (before the Oracle purchase). This resulted in the OpenJDK, which is the basis for all distributions of Java. Oracle is a big contributor to the development, but so are many others. You can get a pure OpenJDK or any of a number of branded JDKs like those from Eclipse, BellSoft, etc. You can get non-free distributions with support too. A sticking point for a number of years was the TCK (Technology Compatability Kit) used to validate Java, but that too was GPL'd. Java has evolved quite a bit since being open sourced. IMHO C# has some great features, but Java is great for certain things. For instance, making native apps for Mac, Win, and Linux based on modular libraries from the JDK is now fairly easy (and with a modern UI using the OpenJFX framework).

beezle• 3 years ago

Asking honest question here - did Oracle change the terms back so that one can now develop and distribute applications using their JDK without fees so long as one does not also re-distribute/bundle their jdk with your application(s)? I just read something along those lines having thought that one couldn't use their JDK for anything without fee anymore.

If so, is there a reason to go with OpenJDK over Oracle other than GPL purity?

Again, legit question, no axes to grind.

kaba015• 3 years ago

Designing something with an intent is very different than succeeding in it.

Also, absolutely objectively Microsoft has orders of magnitude more control over C# than Oracle has over Java. Both Java, the language and the JVM has a specification, implemented completely independently by several companies, and the reference implementation is used as a business critical infrastructure of almost all Fortune 500 companies, many of which could single handedly continue to support and develop the platform. Meanwhile C# doesn’t have an open-source debugger..

mbfg2• 3 years ago

I'm curious what is meant by a "preview feature, or second preview feature, or..." in a released product?? I don't suppose they are going to remove it later. So in what way is it a preview? Are they signalling that it might have breaking changes in the future?

somenameforme• 3 years ago

"A preview feature is a new feature whose design, specification, and implementation are complete, but which is not permanent, which means that the feature may exist in a different form or not at all in future JDK releases."

https://docs.oracle.com/en/java/javase/19/language/preview-l...

simonkagedal• 3 years ago

Yes, they reserve the possibilty to completely redo or even remove these preview features. They are not enabled by default, you have to opt in with a compiler flag.

mbfg2• 3 years ago

ok, that makes some sense.

carimura6• 3 years ago

You can read all about it here: https://openjdk.org/jeps/12

with a slight addendum here: https://openjdk.org/jeps/8300604

and podcast that discusses both: https://inside.java/2023/03/21/podcast-030/

digitalsanctum• 3 years ago

As an engineer that last used Java when it was Java 11, I cringe at the thought of diving back in. A trade-off of increased release velocity for any language I suppose.

kaba015• 3 years ago

Why? Only the encapsulation difference was a slightly bigger breaking change since 8, after you are done with that it really is smooth sailing.

Or if you mean addition of new features, then Java is very conservative on that front and it is still a very small language compared to most other mainstream ones.

nprateem• 3 years ago

It's really not as bad as it used to be. I recently picked it up again after playing with Spring boot. I got to say Spring boot seems awesome, and java as a whole it much more ergonomic. Worth another look.

twblalock• 3 years ago

You don’t need to learn or use any of the new features. Most devs seem to still pretend they are writing for Java 8 anyway.

oulu20062• 3 years ago

I use Clojure, which benefits from these consistent JVM improvements; things like pattern matching have been accessible to me for years already, but I like that Java slowly trails along as it helps keep me vested in the Java ecosystem.

cutler• 3 years ago

By contrast I despair of Clojure ever keeping pace with Java updates. Clojure seems to be a functional language which isn't even implemented using the host's functional features which were introduced 9 years ago.

yCombLinks• 3 years ago

Nearly all of the language changes except for the thread changes are minor quality of life things.

jayd166• 3 years ago

Structured concurrency looks a lot like C#'s Task library without the async/await sugar but with the exact same footguns.

Joining into a synchronous function is an anti-pattern in C# because you consume threads. This seems to be the same, except with the assumption that virtual threads are fine.... But that's not an assumption that can be made by the method writer, right?

pjmlp5• 3 years ago

Tasks aren't threads in TPL.

jayd166• 3 years ago

What are you trying to say? They still run on threads and can consume them.

hn_throwaway_994• 3 years ago

Really excited to see how virtual threads are taken up by developers, and if they affect the larger programming language community. They just really seem like "the best of both worlds" to me: the high scalability/low resource usage of async/await, with the ease-of-use experience of threads (e.g. not having to worry about "function coloring").

cesarb5• 3 years ago

I'm personally not so sure. We already had something like that before (M:N threads), and the world moved away from it, towards letting the kernel manage everything (1:1 threads). So I'd expect instead that operating system kernels gain whatever features are missing for scaling to a higher number of threads, and everything once again goes back to each programming language thread corresponding to one kernel thread.

kaba015• 3 years ago

M:N is not the interesting aspect of virtual threads at all, automagically turning blocking operations into non-blocking is - which has not really been tried before (with erlang and go being the first).

mike_hearn7• 3 years ago

The problem of scaling threads up further is fundamental and not really solvable by more kernel features. JVM virtual threads can be efficient because the runtime has complete knowledge of the executing code and stack layouts, how the heap is laid out, how the GC works and it can control how code is compiled. The kernel can't do any of these things - it has to assume a process is a black box that could do anything with its stacks, could be compiled by anything and so on.

Note that this advantage obviously goes away the moment you call into native code. Then the JVM is in the same position as the kernel. It doesn't control the compiler or the stack any more, and so that's why a virtual thread becomes "pinned" at that point and you lose the efficiency (the JVM needs to acquire more kernel threads). Fortunately though the JVM ecosystem doesn't rely on native code all that much, so it should be rare in practice.

This advantage can be brought to other non-Java languages too via Truffle. Truffle languages are reimplemented on top of Java and when programs call into native code they have the option of calling into JIT compiled LLVM bitcode instead of real native code (or indeed any JVM bytecode library). In that situation the JVM remains in control and so things should in theory still be Loom-able. Not sure if that's currently true in practice, but it could be.

pkolaczk2• 3 years ago

low resource usage of async/await

Will calling a coroutine do zero heap allocations like async in Rust?

with the ease-of-use experience of threads

That's highly subjective. Threads usually require locking which is often hard to get performant and correct at the same time. Async/await allows to write concurrent code with no synchronization.

mike_hearn7• 3 years ago

Async/await allows to write concurrent code with no synchronization

Well you still need some sort of synchronization, because an "await" allows arbitrary other actions to occur. If an await is introduced in code you transitively call then you might find that some invariant you were expecting to hold has now changed across a call when it previously didn't. Fundamentally, locks are about making invariants atomic and that's independent of exactly how code is scheduled and when.

matsemann• 3 years ago

Async/await allows to write concurrent code with no synchronization.

Hmm,I don't see how async/awaits makes a difference. Care to explain?

Like, if you have multiple sources that can add or read from a queue, unless there is a single thread running all your async loops (ala python), you still need some synchronization. At least that's my experience using coroutines heavily in kotlin.

rr808• 3 years ago

Anything is better than asynchronous.

tomp2• 3 years ago

The fact that they’re cooperatively scheduled makes them quite problematic.

Basically a leaky abstraction, you have to think whether your code will block or not.

Go went through the same process, before eventually figuring out that they do need to make their lightweight threads (goroutines) preemptive.

cozos2• 3 years ago

Can you expand why its a leaky abstraction? Is it because virtual threads can only yield when its doing blocking operations?

nsm2• 3 years ago

What are some good primers to understand the prominent new Java features? Not just in 20, but since, say, 8. Asking as someone who would like to be cursorily familiar with Java, but does not use it day to day. I'm very familiar with things like auto type inference, pattern matching, multi-line strings and structured concurrency from other languages, so I'm not looking for an introduction to Java. I'm looking for something like "Modern Java for the experienced Rust/Python/C++ programmer". Thanks!

mongol• 3 years ago

Boring answer... but Chat GPT? I asked it what was new in Java 8 and it enumerated a number of features. I could proceed to ask it about more details for each, and then continue Java version by version and I think it would be quite exhaustive.

The other day I did something similar for cell biology. As a layman I wanted to learn more about DNA, mRNA, tRNA, translation, transcription, mitosis, miosis, etc. I think I learned it much better by querying Chat GPT than say reading Wikipedia. Something about the interaction, to ask for more details on what was not clear that helped me understand it.

nsm2• 3 years ago

Thanks! I keep forgetting to reach for this.

copperx• 3 years ago

I've avoided that because of the tedium of having to fact check everything.

illiarian• 3 years ago

Boring answer... but Chat GPT?

Trained on data up to September 2021.

Legion• 3 years ago

The problem with ChatGPT is that, when it should say "I don't know", it will instead confidently spew plausible sounding garbage.

anotherevan• 3 years ago

RP @johl@mastodon.xyz: I wish more people understood that "I want the computer to generate a natural language text that sounds like a plausible answer to a question about x" and "I want the computer to answer a question about x" are two very different problems.

https://aus.social/@johl@mastodon.xyz/110050185180546324

sarchertech• 3 years ago

When I’ve asked chatgpt to explain something to me that I’m very knowledgeable about, distributed systems, it was flat out wrong about many fundamentals in a way that would have seemed completely plausible to a novice. It was making up algorithms, complete with fake but believable names, to solve problems that are provably unsolvable.

My wife, a physician, reported similar errors when I got her to ask it medical questions.

Using chatgpt to learn about something new is flat out dangerous.

aardvark179• 3 years ago

You might find just browsing the JEPs will get you a long way. https://openjdk.org/jeps/0

emdashcomma• 3 years ago

Here are some resources I've found helpful and have read or are on my backlog to catch up with these developments:

- https://github.com/wesleyegberto/java-new-features (terse, includes links to JEPs, good jumping off point)

- https://github.com/winterbe/java8-tutorial (quick tour through features of Java 8)

- https://winterbe.com/posts/2018/09/24/java-11-tutorial/ (same for Java 11)

Books:

- Java 8 in Action / Modern Java in Action (Raoul-Gabriel Urma, Alan Mycroft, Mario Fusco; 2014 and 2018 respectively)

- The Well-Grounded Java Developer (Martijn Verburg, Benjamin Evans, Jason Clark; 2022) - not specifically focused on new features but does cover them in the context of going deeper into Java and the JVM.

cbm-vic-20• 3 years ago

Java Almanac can show the API differences between versions of Java.

https://javaalmanac.io/

629514132• 3 years ago

https://reflectoring.io/java-release-notes/ https://advancedweb.hu/new-language-features-since-java-8-to...

VagueMag• 3 years ago

I've been trying to get caught up while job searching after being laid off, and have found YouTube to be a pretty good source, the Java language advocates are all very keen to show off all the shiny new stuff. Also definitely recommend the JEPs as one of the other sibling comments did. All of the "Data Oriented Programming in Java" stuff is I think especially relevant, Brian Goetz had a good article on InfoQ about it.

carimura6• 3 years ago

also http://dev.java/evolution

cryptos• 3 years ago

- https://www.baeldung.com/java-8-new-features,

- https://www.baeldung.com/new-java-9,

- https://www.baeldung.com/java-10-overview,

- https://www.baeldung.com/java-11-new-features,

- https://www.baeldung.com/java-12-new-features,

- https://www.baeldung.com/java-13-new-features,

- https://www.baeldung.com/java-14-new-features,

- https://www.baeldung.com/java-15-new,

- https://www.baeldung.com/java-16-new-features,

- https://www.baeldung.com/java-17-new-features,

- https://www.developer.com/java/java-18-features/,

- https://www.infoworld.com/article/3676699/jdk-20-the-new-fea...

- https://www.infoworld.com/article/3653331/jdk-19-the-new-fea...,

furtiman• 3 years ago

Coming from the telegram bot of hacker news, where this post has a lot of downvotes (21 down to 6 up, which is quite a lot for how many reactions usually are there), could someone (perhaps even from people who downvoted) explain why this news is met with such negativity?

I kind of assume it's due to the cliché Java-oriented hatred, but curious to hear opinions...

MichaelMoser123• 3 years ago

virtual threads are still in preview. At which stage/release will they be in regular usage? (not preview) Is anyone planning to use virtual threads, at this stage?

i understand that virtual threads are very similar to goroutines in golang

kasajian• 3 years ago

Why is it difficult to determine what those features are 429, 432, 433, etc. How difficult would it have been to put links there so one can click on the link to see what it is. Have these people hard of hyper-text markup?

bcrosby953• 3 years ago

https://openjdk.org/projects/jdk/20/

It's linked in the email.

vbezhenar• 3 years ago

So... exactly zero new features? Well, hopefully JVM got faster and future LTS release will be more interesting.

Java 20 / JDK 20: General Availability

Related Stories