Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 17 / JDK 17: General Availability

mail.openjdk.java.net

Post reply on HN
Print view View original

51–60 of 251 posts

Re: Java 17 / JDK 17: General Availability

#51

Post by mabbo »

mreinhold wrote: post #32
hyperpape wrote: post #20

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…

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.

Re: Java 17 / JDK 17: General Availability

#54

Post by mleo »

throwaway4good wrote: post #38
deepsun wrote: post #7

Are they going to introduce zero-cost structs? Kinda like Rust guarantees that Option has the same size as T (aka free like in free beer).

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 to chain mapping and conditionals to more easily deal with null values.

Re: Java 17 / JDK 17: General Availability

#55

Post by deepsun »

zokier wrote: post #25
deepsun wrote: post #7

Are they going to introduce zero-cost structs? Kinda like Rust guarantees that Option has the same size as T (aka free like in free beer).

> Kinda like Rust guarantees that Option has the same size as T (aka free like in free beer). That is not correct. Trivial counterexample: https://play.rust-lang.org/?version=stable&mode=debug&editio... prints 4 8 i.e. Option is 4 bytes larger than plain T

Sure, I meant:

Rust guarantees to optimize the following types T such that Option has the same size as T:

    Box
    &U
    &mut U
    fn, extern "C" fn
    num::NonZero*
    ptr::NonNull
    #[repr(transparent)] struct around one of the types in this list.
UPDATE: Or, better per your example: struct T {i: i32} takes the same size as i32: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: Java 17 / JDK 17: General Availability

#57

Post by MarkMarine »

ianpurton wrote: post #53

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.

Java tries so hard to be backwards compatible, I think null is here to stay. There is always Kotlin if you want better null safety, or compile time checks like null-away, but they are still null adjacent. Disappointing but that’s what we’re stuck with in service of backwards compatibility, but I’m not sure making these breaking changes is an improvement… look at Python 2->3 for an example

Re: Java 17 / JDK 17: General Availability

#58

Post by grishka »

ianpurton wrote: post #53

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 have meaningful default values (0 for numbers, false for booleans). Adding non-primitive value types would mean having to solve many new problems that C++ had and still has. That said, they are exploring this idea, iirc they call it "project valhalla".

Re: Java 17 / JDK 17: General Availability

#60

Post by vbezhenar »

avodonosov wrote: post #23

I am skeptical about the "strong encapsulation" and in general, of all cases whey people tell me about something: "you don't need it, it's better for you to do it other way". Usually I know better what I need. There were cases when I needed to access the internals, e.g. fixing a prod issue. A quote from Thinking Forth comes to mind: > The newest traditional languages (such as Modula 2) bend over backwards to ensure t…

Library developers start depending on Java internals.

Developer change internals, because they want to improve something.

Library breaks.

Users don't want to update to new Java because their code does not work.

They want to break that chain, I guess.

Also I think that you still can allow access to any internal class using --add-opens

Post reply on HN