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

221–230 of 251 posts

Re: Java 17 / JDK 17: General Availability

#221

Post by grishka »

syncsynchalt wrote: post #220
grishka wrote: post #58

Earlier quoted context omitted.

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…

Java could adopt swift-like `Object!` typing for non-nullable variables and spread that guarantee through the compiler and JVM runtime. I don't think it's a technical impossibility, but it's more likely to be solved by a JVM-based language like Kotlin than it is to get it adopted into the Java mothership.

Compile-time checks definitely can't guarantee anything. You could still end up with null pointers from, for example, a library like gson using reflection to set fields. If you add "non-null" to the type descriptors inside class files (something like Kjava/lang/Object; instead of the usual Ljava/lang/Object;) and have the JVM enforce non-null-ness at runtime, you'll still have crashes caused by null pointers but earlier. Oh and you'll have to make an exception to allow these to be null during a constructor or static initializer invocation so it could actually initialize everything. It gets messy.

IIRC that proposition for value types makes them more akin to structs, without inheritance and dynamic methods. And I don't remember whether the fields are final, but given the current trend towards making everything as immutable as possible, they probably are.

Re: Java 17 / JDK 17: General Availability

#222

Post by sideeffffect »

igouy wrote: post #195
exabrial wrote: post #34

Java5 and Java8 were monumental changes to the language… this update probably will have the same legacy. Can’t wait to see the benchmarks out of this bad boy once they get the compilers tuned in.

Don't new programs have to be written to use the new features? elapsed secs binarytrees,java16,7 2.478 binarytrees,java17,7 2.475 binarytrees,java16,3 4.644 binarytrees,java17,3 4.574 binarytrees,java16,2 4.765 binarytrees,java17,2 4.772 binarytrees,java16,6 4.608 binarytrees,java17,6 4.594 binarytrees,java16,4 4.733 binarytrees,java17,4 4.808 fannkuchredux,java16,2 45.438 fannkuchredux,java17,2 43.921 fannkuchredux,…

Can you please compare to 11 or even 8?

Re: Java 17 / JDK 17: General Availability

#223

Post by stickfigure »

ivan_gammel wrote: post #216
stickfigure wrote: post #209

Earlier quoted context omitted.

Eh? This is pretty good: Colour changed = colour.withRed(5);

Every method of your API must serve some business purpose. "With" methods and setters generated or written "just in case" often do not have one or they are being used only in tests, which would be insufficient justification for having them. Does your code really need to change individual components of the color? If it is not a graphic editor, probably not and those methods will be redundant.

That sounds unpleasantly pedantic.

Re: Java 17 / JDK 17: General Availability

#225

Post by paulddraper »

hashmash wrote: post #64
mabbo wrote: 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.

Probably 1/2 of all Java classes written should be records.

Re: Java 17 / JDK 17: General Availability

#226

Post by paulddraper »

dzonga wrote: post #140

as a node dev, I see people using typescript with node. I wonder why don't those people just use java ? and let us clay potters shape plain js to our will. rather than pollute the node ecosystem with typescript

> pollute the node ecosystem with typescript

And there's the beauty of TypeScript....you can still use JavaScript as if TypeScript never existed.

Of course, many teams will fall in love with TS.

But you the library user don't have to give two farts.

Re: Java 17 / JDK 17: General Availability

#227

Post by tcmart14 »

brunoborges wrote: post #147
jlengrand wrote: post #75

Earlier quoted context omitted.

Do you know of any vendor for which 17 isn't considered an LTS? Genuinely curious

Ubuntu's, Alpine's, Debian's, and any Linux distribution that builds and ships OpenJDK from the source (except Red Hat's, of course). Yes, these are "distributions" (binaries) of OpenJDK that do not provide any sort of support, and clearly no LTS flag to them.

Yes and no. Debian's repos provide binaries for multiple version though. Since 11 has been about, Debian testing has always had OpenJDK11 and then of course binaries for newer versions. So they do ship the LTS, you just need to specify the version number, openjdk-11-jdk. They don't tag it as LTS in the package name, but someone who is using java professionally probably knows openjdk-11 is the LTS implementation.

Re: Java 17 / JDK 17: General Availability

#228

Post by zaphirplane »

cogman10 wrote: post #172
the8472 wrote: post #133

Earlier quoted context omitted.

I guess records will make valhalla (value types) easier which enables more efficient data structures and will probably make passing data over FFI (valhalla) easier too. They reduce a lot of boilerplate, e.g. when passing multiple return values.

Records are orthogonal to value types (now called primitive types).

I thought they are light weight ways of declaring a structure. From there they take different paths for immutability extensibility allocation … etc

Re: Java 17 / JDK 17: General Availability

#229

Post by cema »

smarks wrote: post #114
geodel wrote: post #87

Earlier quoted context omitted.

So one thing peculiar in Java is public records have to be in their own files. Now I wanted to treat records as less ceremonial than classes to organize code. I'd have liked to have a dozen or so records in a file along with some basic operations on them but it is not possible have multiple records without that many files. I know the answer is always use IDE and all but it causes more context switches than scrolling…

If you have a bunch of related records you can make them public and nested within a top-level public class. You could also throw some static utility or factory methods in there too.

Sure, but that's still ceremony.

Re: Java 17 / JDK 17: General Availability

#230

Post by jamesfinlayson »

filereaper wrote: post #102

I've been out of the loop with the Java ecosystem, but has the transition from Java 8 to 11 completed where most of folks here work? I was also curious about large ecosystems like Hadoop and their moves from 8 to 11.

I recently finished migrating a bunch (100+) AWS Lambdas from JDK 8 to JDK 11 and it was pretty painless - unit testing was spotty at best but there were no issues. This was hastened by AWS changing the underlying Java 8 runtime to Amazon Linux - it probably would have been fine but I decided that if we were going to test a change, we might as well move to Java 11 and make the full regression test worthwhile.
Post reply on HN