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

111–120 of 251 posts

Re: Java 17 / JDK 17: General Availability

#111

Post by suyash »

MarkMarine wrote: post #57
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

yes and most java developers have come to terms with null and NPE, it's just part of programming in Java so honestly I'm fine with it being here.

Re: Java 17 / JDK 17: General Availability

#112

Post by thinkharderdev »

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.

I think it is certainly possible. In Scala you enable "explicit nulls" and it will not compile if you try to set a value to null (https://dotty.epfl.ch/docs/reference/other-new-features/expl...) without making the type a union with Null.

Re: Java 17 / JDK 17: General Availability

#113

Post by macspoofing »

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…

>the last one of which was Java 11, 3 years ago.

Extended support still behind Java 8 =)

I suspect Java 8 will be with us for a long long time.

Re: Java 17 / JDK 17: General Availability

#114

Post by smarks »

geodel wrote: post #87
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.

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.

Re: Java 17 / JDK 17: General Availability

#115

Post by Tainnor »

tathisit wrote: post #84
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.

Kotlin does it, but it's next to useless because the ecosystem makes heavy use of null.

what? I don't feel it's "pointless" at all. Many popular Java libraries and frameworks (including Spring) use nullability annotations which can be interpreted correctly by Kotlin. It's true that I can't be 100% sure not to get NPEs, but I think it's close enough and I've rarely seen NPEs in Kotlin codebases.

Re: Java 17 / JDK 17: General Availability

#116

Post by suyash »

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

if you're coming from Java 8, here is a comprehensive list of new features since then https://ondro.inginea.eu/index.php/new-features-in-java-vers...

Re: Java 17 / JDK 17: General Availability

#117

Post by geodel »

Lately I have insight similar to 'what hardware improvements give, software bloat take it away', 'what JDK platforms give third party Java frameworks take it away.

I have this misfortune of dealing daily with a nasty Java framework which converts compile time errors into runtime errors, single error trace with multiple stack traces , most of them being from framework itself.

One thing that might improve situation is server side libraries instead of framework. However AFAIK there is nothing like that in Java world. Everything is bound to Servlet API at lowest level and app server/frameworks on top of it.

Re: Java 17 / JDK 17: General Availability

#118

Post by Sindisil »

gmueckl wrote: post #70
0x0 wrote: post #63

Earlier quoted context omitted.

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

They are, however, making a commitment to scripting friendly URLs for the JDK downloads, making it feasible to automate the install.

Still, it is pretty lame, since they've been advocating bundling of the JDK since they deprecated the WebStart.

OTOH, since Oracle JDK and OpenJDK are identical save for branding and licensing, not sure why you wouldn't just bundle an OpenJDK build in that case.

This new license seems to be targeted to two main groups: those who depend upon a "system" install of Oracle Java for running third party apps, and those who are for some reason unwilling to use OpenJDK.

Re: Java 17 / JDK 17: General Availability

#119

Post by native_samples »

gmueckl wrote: post #70
0x0 wrote: post #63

Earlier quoted context omitted.

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

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.

Re: Java 17 / JDK 17: General Availability

#120

Post by BossingAround »

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/

> Oracle JDK is now free for commercial and production use.

Hopefully, developers have learned to avoid Oracle like a plague after the last absolute licensing failure with JDK that caused all the FUD.

Post reply on HN