Live data from Hacker News

Java 17 / JDK 17: General Availability

mail.openjdk.java.net

61–70 of 251 posts

Re: Java 17 / JDK 17: General Availability

#61
post #58

I'm curious if it would be possible to remove null from Java. There's already support for Optional. I mean I guess a lot of code would stop compiling, or could it be deprecated somehow.

Not without changing everything in significant ways. There are two distinct kinds of types in Java: objects, including arrays, and primitives. Objects are represented as pointers, and those can be null — that's their default value. And multiple pointers can point to the same object. Primitives (int, long, boolean, char, byte, short, float, double) are "value types", they can't be null, are copied on assignment, and h…

Who said anything about non-primitive value types? Java just needs a second kind of reference type: non-nullable reference types that are always initialized, where a direct assignment from a nullable-reference-typed value to a non-nullable-reference-typed slot fails to compile (but the opposite succeeds.) You’d instead have to go through Optional.ofNullable or somesuch, where that proxy type would then be modified to have variants of .get et al that return a non-nullable-reference return type.

Re: Java 17 / JDK 17: General Availability

#62
post #54

Earlier quoted context omitted.

You get null for free.

Can’t tell if this meant to be a statement of fact, opinion or sarcasm. Over the course of 20 years have I have probably spent days of time tracking down NPEs in code being developed and after the fact in production releases. The amount of extra code and time spent to determine if variable is null certainly isn’t free. Optional at least states the variable may not be referencing anything and provides helpful methods…

I really like the Kotlin approach, where they just embraced null being a fact of life on the JVM/JS and instead integrated nullability into the type-system [1]. C# and Typescript do something similar.

So then you get the best of both world, the safety of Optional without the boxing overhead.

[1] https://kotlinlang.org/docs/null-safety.html

Re: Java 17 / JDK 17: General Availability

#63

Some other news in relation to the release: - (Proposal) Moving JDK LTS versions to a two year cadence [1]. Java 21 will be next LTS instead of Java 23. - Oracle JDK is now free for commercial and production use [2]. - A new Java developer site [3]. [1] https://mreinhold.org/blog/forward-even-faster [2] https://blogs.oracle.com/java/post/free-java-license [3] https://dev.java/

Another license change for the official oracle jdk? What's the trap this time? :-O

Re: Java 17 / JDK 17: General Availability

#64
post #51

Earlier quoted context omitted.

Comprehensive list of all JEPs integrated since JDK 11: https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11

> Language > Pattern Matching for instanceof (16) > Records (16) > Restore Always-Strict Floating-Point Semantics (17) > Sealed Classes (17) > Switch Expressions (14) > Text Blocks (15) This is what excites me. Records, switch expressions and sealed classes are all excellent and even better together. Along with pattern matching switch statements, Java is finally losing a lot of cruft people complain about.

I'm trying to find a good use case for records, but the best I can come up with is using it for composite hashmap keys. I suppose when combined with sealed classes and pattern matching features at some point it might be more useful, but what is the main use for records right now? Given that they're immutable and have no convenient way to be copied when modified, I find them quite tedious to use.

Re: Java 17 / JDK 17: General Availability

#65

On its own, the features specifically for Java 17 aren't obviously that compelling, but the important thing is that Java 17 is an LTS, the last one of which was Java 11, 3 years ago. Since many organizations, including mine, stick to LTS releases, that means a lot of developers will get a big change in what they can do sometime in the next few months as they upgrade to the LTS. Among other things, this means that we…

This also brings some big gotchas, such as the closing of encapsulation loopholes. Unsafe code and various hacks calling into the JDK will break a lot of programs; so you might be stuck on 11 if you use HBase, Spark, etc.

Re: Java 17 / JDK 17: General Availability

#66
post #51

Earlier quoted context omitted.

Comprehensive list of all JEPs integrated since JDK 11: https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11

> Language > Pattern Matching for instanceof (16) > Records (16) > Restore Always-Strict Floating-Point Semantics (17) > Sealed Classes (17) > Switch Expressions (14) > Text Blocks (15) This is what excites me. Records, switch expressions and sealed classes are all excellent and even better together. Along with pattern matching switch statements, Java is finally losing a lot of cruft people complain about.

a lot of these were the killer feature of scala that separated it from other languages

Re: Java 17 / JDK 17: General Availability

#67
post #51

Earlier quoted context omitted.

> Language > Pattern Matching for instanceof (16) > Records (16) > Restore Always-Strict Floating-Point Semantics (17) > Sealed Classes (17) > Switch Expressions (14) > Text Blocks (15) This is what excites me. Records, switch expressions and sealed classes are all excellent and even better together. Along with pattern matching switch statements, Java is finally losing a lot of cruft people complain about.

I'm trying to find a good use case for records, but the best I can come up with is using it for composite hashmap keys. I suppose when combined with sealed classes and pattern matching features at some point it might be more useful, but what is the main use for records right now? Given that they're immutable and have no convenient way to be copied when modified, I find them quite tedious to use.

I work as a systems developer for a bank and records is an easy replacement for a very popular dependency called lombok. Now, records doesn't necessarily do everything that lombok does, but for us it replaces what we actually need. One less dependency and I'm a happy camper.

Re: Java 17 / JDK 17: General Availability

#68
post #63

Some other news in relation to the release: - (Proposal) Moving JDK LTS versions to a two year cadence [1]. Java 21 will be next LTS instead of Java 23. - Oracle JDK is now free for commercial and production use [2]. - A new Java developer site [3]. [1] https://mreinhold.org/blog/forward-even-faster [2] https://blogs.oracle.com/java/post/free-java-license [3] https://dev.java/

Another license change for the official oracle jdk? What's the trap this time? :-O

Probably they got too much flak and a drop in market share (aka companies uninstalling Java, which they probably track in the uninstaller)...

Re: Java 17 / JDK 17: General Availability

#69

Great to see there is support for M1: https://openjdk.java.net/jeps/391

It's worth noting that you may not always want to use the ARM JVM on M1 even if it's available, because then anything linked by JNI needs to be running on ARM also.

I'm on an M1 Mac and have spent more time using the x86 JVM because the ARM JVM is less likely to have applications Just Work.

Re: Java 17 / JDK 17: General Availability

#70
post #63

Some other news in relation to the release: - (Proposal) Moving JDK LTS versions to a two year cadence [1]. Java 21 will be next LTS instead of Java 23. - Oracle JDK is now free for commercial and production use [2]. - A new Java developer site [3]. [1] https://mreinhold.org/blog/forward-even-faster [2] https://blogs.oracle.com/java/post/free-java-license [3] https://dev.java/

Another license change for the official oracle jdk? What's the trap this time? :-O

I am confused by the license. The way I read it, a "bundling" with commercially licensed Software is forbidden, that is, you can't ship the JRE along with a product that you are selling. So your users will face rxtra installation steps
Post reply on HN