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

121–130 of 251 posts

Re: Java 17 / JDK 17: General Availability

#121

Post by bdamm »

dtech wrote: post #62
mleo wrote: post #54

Earlier quoted context omitted.

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

This really sounds like the way to go, although of course it is too late for Java. Optional feels awkward, and there's no more safety than we already have since the JVM null-checks anyway.

   if( arg.isPresent() ) ...
vs

   if( arg != null ) ...
How is this better?

Re: Java 17 / JDK 17: General Availability

#122

Post by native_samples »

geophile wrote: post #18
vips7L wrote: post #12

Earlier quoted context omitted.

Primitive classes are being worked on in Project Valhalla.

I think this statement has been true since about 2014. Structs are nice, as they allow for control over locality, to a degree that is simply not possible in Java currently. But there is a second effect, which is possibly more important: If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to…

It's mostly implemented in a branch. You can download a version of Java that can do this today. There's more work to do before it can be merged though, and will probably ship in incremental pieces.

Re: Java 17 / JDK 17: General Availability

#125

Post by titovodka »

stickfigure wrote: post #107
carimura wrote: post #91

Earlier quoted context omitted.

Part of the vision of pattern matching is aggregation and destructuring [1]. This is just exploratory but may be what you're thinking about? [1] https://github.com/openjdk/amber-docs/blob/master/site/desig...

Interesting but the "Isn't this just multiple return?" section seems to completely miss the point. I don't see any examples of what multiple-return would look like. And multiple-return is what I want. At first glance, it looks like this (sure, more powerful) pattern matching system is not going to satisfy my desire for a compact syntax that lets me do the equivalent of this typescript: const [foo, bar] = getMeTwoThin…

I might not be aware of best practices.

What are the benefits of having a multiple return type function?

I just assume that one can use an object if this is needed throughout the whole code..

Or maybe create an arraylist if possible and return that?

Re: Java 17 / JDK 17: General Availability

#126

Post by pgwhalen »

cmckn wrote: post #65
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…

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.

You won’t be stuck, you just need to add some command line flags when running your application, as a way of acknowledging these packages are breaking encapsulation.

Re: Java 17 / JDK 17: General Availability

#128

Post by jollybean »

native_samples wrote: post #119
gmueckl wrote: post #70

Earlier quoted context omitted.

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

JRE stopped existing in Java 8. The idea now is you "link" a JVM for your app, which customizes and optimizes it. Then you ship both together. It's the fully supported way and has no license implications. Seems like the new Oracle JDK license is a lot more flexible than before. In reality it's kind of cosmetic because lots of people were using the (100% compatible) Amazon or Azul spins, or just regular OpenJDKs.

So the comments above seem to indicate that bundling 'JRE' with an app requires a license. Are you indicating that post-java8 model which builds a 'Custom JRE', and distributing that with your app does not require a license?

Re: Java 17 / JDK 17: General Availability

#129

Post by orthoxerox »

0x0 wrote: post #63
kasperni wrote: post #39

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

Only JDK 17 is free. Earlier versions are not.

Re: Java 17 / JDK 17: General Availability

#130

Post by mabbo »

pulse7 wrote: post #106
hashmash wrote: post #64

Earlier quoted context omitted.

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.

No more Lombok @Data annotations needed...

Actually, I think it would be the lombok @Value. Record classes are immutable, while @Data adds set methods.
Post reply on HN