Live data from Hacker News

Java 18 / JDK 18: General Availability

mail.openjdk.java.net

111–120 of 304 posts

Re: Java 18 / JDK 18: General Availability

#111
post #6

Is there a reason to use Oracle's closed-source Java implementation instead of the opensource implementations? Asking as someone who's ignorant about Java. edit: per comments below, Oracle's Java is open-source too these days.

Oracle OpenJDK is an open-source Java release:

https://jdk.java.net/18/

Re: Java 18 / JDK 18: General Availability

#112
post #6

Is there a reason to use Oracle's closed-source Java implementation instead of the opensource implementations? Asking as someone who's ignorant about Java. edit: per comments below, Oracle's Java is open-source too these days.

For some purposes a tested validated binary may be appropriate vs mystery meat someone threw through a compiler then shipped without testing.

That's actually why I prefer Azul's openjdk builds over adoptopenjdk or other distros: it's sane but not in contact with the Oracle swamp

https://www.azul.com/downloads/?package=jdk#download-openjdk

https://hub.docker.com/r/azul/zulu-openjdk

Re: Java 18 / JDK 18: General Availability

#113
post #96

Earlier quoted context omitted.

Anyone not seriously considering option 3 as the default, with options 1 and 2 being the exception that one must have good reason to take, automatically disqualifies himself as ignorant of proper error handling. Of course you catch and handle errors. Or at the very least you must think about whether it makes sense to handle an error on the current abstraction level that you are on, which means you must always conside…

By your opinion 90%+ of Java ecosystem is ignorant of proper error handling, which in itself is a statement on how poorly this method of error handling is looked at.

I have seen quite a bit of code in the Java ecosystem over more than 15 years, but far less than 90% of it. And even in the small slice that I've seen, I'd say the quota of ignorant error handling is way lower than 90%. Especially the higher-quality Java libraries that people reuse over and over usually behave okay with regard to exception handling nowadays.

Re: Java 18 / JDK 18: General Availability

#116

Earlier quoted context omitted.

Maybe I'm wrong, but I don't see that called out anywhere. I don't believe that's true anymore, but correct me if I'm wrong. For reference I double checked here: https://www.oracle.com/java/technologies/downloads/

There used to be really prominent banners telling you about it. I don't see them now, but I'm also not sure they switched back. Here's an article I found explaining the switch to requiring paid usage. https://blog.netwrix.com/2021/12/02/oracle-java-license-chan...

I think that’s the switch (somewhat) _away_ from paid usage.

https://itassetalliance.com/blog-posts/what-do-oracles-2021-... says there was a change in 2019 that made critical security updates a paid feature.

The 2021 license change reverted this somewhat, by giving you one year of security fixes for free in the long term support versions (I’m sure I’m missing some detail, if not completely misinterpreting things, here)

Re: Java 18 / JDK 18: General Availability

#118

This is tangential and possibly too open ended to be productive but worth a shot anyway. Why is Java so popular? I know of a major Silicon Valley company that's migrating their backend to it. Why Java over other languages? Or maybe there's not really other viable options? I'm speaking as someone who spent the last 6 years focused on frontend web technology.

What else would you use? Java is the shark that ate everyone else's lunch. At this point all you have as alternatives in the category of "easy to use for backend type stuff" is C#, and go. Both of which have their pros and cons but on the whole aren't bad choices. I guess like bellbottoms, Java is making a fashionable comeback.

This is my default answer. What else would you use? C# is the only realistic alternative in my opinion, and I could respect that choice.

I work in Go currently and although I see the positives, I'd be less inclined to unleash a bunch of mid-level devs using Go to create a huge codebase.

If I could have my way, personally, I'd go for one of the other fun JVM langs out there... but that's just me having fun.

Re: Java 18 / JDK 18: General Availability

#119
post #16
post #8

Earlier quoted context omitted.

I'll try: Java is a proven, boring and "easy" language without much surprise, with a big standard library and ecosystem.

Java is great, but here's a surprise: if (str1 == str2) { // oops }

For what it’s worth any decent IDE will warn you about that. But as a Java developer you know it’s wrong, Strings are objects and that’s not how you compare objects.

The tricky one is numbers.

Integer == int // fine

int == int // fine

numVarOne == numVarTwo // Uh-oh

In that third example you better make sure they aren’t both boxed objects or BigDecimals.

I’ve almost never seen the string one for some reason. It’s always boxed numbers.

Again, a good IDE is worth a ton.

Re: Java 18 / JDK 18: General Availability

#120
post #16
post #8

Earlier quoted context omitted.

I'll try: Java is a proven, boring and "easy" language without much surprise, with a big standard library and ecosystem.

Java is great, but here's a surprise: if (str1 == str2) { // oops }

Eh, I'll take that over https://dorey.github.io/JavaScript-Equality-Table/> any day.

Boolean.getBoolean, however, now that is a proper Java land mine.

Post reply on HN