Live data from Hacker News

Which version of JDK should I use?

whichjdk.com

151–160 of 258 posts

Re: Which version of JDK should I use?

#151

Earlier quoted context omitted.

Last time I checked, at least in Ubuntu 20.04, there was already a package for OpenJDK 17, so I think that's the straightforward and recommended way to get Java 17 in Ubuntu.

Wow, you're actually right — I wasn't able to find it before (maybe Java 17 was too new back then). If anybody's interested: sudo add-apt-repository ppa:linuxuprising/java sudo apt-get update sudo apt-get install oracle-java17-installer oracle-java17-set-default

Yes, I checked some weeks ago and v.16 was the last one, so I guess it was too soon.

However, you don't need a special repo for getting OpenJDK 17. Yours is for getting Oracle JDK 17, right?

Re: Which version of JDK should I use?

#152
post #111

Earlier quoted context omitted.

> When Oracle acquired Sun in 2010-11, Sun had not shipped a new release of Java in more than four years.[0] That's hardly a "stability" worth treasuring. Sun went several years without releasing a new major version, but that same page lists frequent minor updates. So yes, I would call that exactly a stability to treasure.

More like stagnation.

I mean, yes, there were fewer major features, but there were feature releases in those minor updates; there's nothing wrong with having stable software. Are you also one of those people who complain that stable Debian and RHEL releases include old software? Not everyone wants to live on the bleeding edge, and Java was a heavily enterprise ecosystem (for better and worse:]).

Re: Which version of JDK should I use?

#153
post #131

Earlier quoted context omitted.

Then use Kotlin, and take advantage of the jvm and the ecosystem, and avoid basically all the stuff you listed about the java language. "no real reason" is a stupid take. I could list multiple, but a big one is that there are hundred java developers for each dotnet developer in my city. The java env is well tested and well understood, if anything one should argue why not use it instead of a hip and trendy alternative…

Their point about using .NET were not really valid since one of the big and best reason to use Java is that you already have a Java codebase, but things like value types and generics without type erasure aren't solved in Kotlin, so Kotlin isn't really a good answer to his not really valid point.

> things like value types and generics without type erasure aren't solved in Kotlin

Perhaps not solved, but at least partially addressed with value classes[1] and reified type parameters[2].

[1] https://kotlinlang.org/docs/inline-classes.html

[2] https://kotlinlang.org/docs/inline-functions.html#reified-ty...

Re: Which version of JDK should I use?

#154
post #127
post #7

Earlier quoted context omitted.

Adoption is the project umbrella under the Eclipse Foundation. Temurin is the project. OpenJDK is the artifact. https://projects.eclipse.org/projects/adoptium > The mission of the Eclipse Adoptium Top-Level Project is to produce high-quality runtimes and associated technology for use within the Java ecosystem. We achieve this through a set of Projects under the Adoptium PMC and a close working partnership with extern…

It sounds like something Microsoft would come up with. Well, it's missing a "NT Azure Client Access License". Why didn't they just keep AdoptOpenJDK? That was a good name IMO.

From https://developer.ibm.com/announcements/adoptopenjdk-has-a-n... (Eclipse is sponsored by IBM)...

> Along with the move to the Eclipse Foundation, the project has a new name: Eclipse Adoptium. The move and name change are being made to ensure vendor independence and long-term viability of the project. As you know, the Eclipse Foundation has a number of key projects, such as Jakarta EE, under its umbrella, with the foundation providing the necessary legal and operational support for its projects.

I suspect that part of this is that it has more to it than just the JDK.

Re: Which version of JDK should I use?

#156
post #129

Earlier quoted context omitted.

> (language features, performance gains) There haven't been any notable language features added since java 9 besides some basic syntax sugar (which is already covered by stuff like lombok anyway). For features and performance you might as well just target .NET 6. It has things that have been perpetually 'too hard to implement' (read: oracle doesn't want to pay their engineers to impl it and will sue you if you do it…

> read: oracle doesn't want to pay their engineers to impl it and will sue you if you do it yourself) like value types, generics without type erasure, no checked exceptions, etc. All of this is currently being implemented in project Valhalla...

I never buy into the tech stack argument that things are being worked on (e.g you mention Project Vahalla but I see this across many languages and tools). Seen this argument used on a number of different technologies. It compares a future state to a current state to put the favored tech (the future state) in an equal or better position. It usually punishes innovative platforms as well; because it dismisses any reason to take them up.

It's comparing apples to oranges - in this case .NET is also being actively worked on so may have other things by then. Compare current state only.

The truth is each platform has prioritized features relevant to its context. For what its worth in my experience while the JVM has many more JIT optimisations and the like it tends to need them more of them given the lack of some of those features you mention (e.g. value types). Whereas .NET code allows value types, better management of memory (i.e. Span), reified generics etc so the focus has been to allow the user to optimise themselves where required where still allowing for a decent performance default. Many of the optimisations in the JVM wouldn't have the same bang for buck in .NET and vice versa.

On a personal note I'm more of a fan of the .NET philosophy because the code is usually fast enough, and when I need to tune memory, avoid allocations, and do fast code it seems to offer more tools not in an unsafe context to do so. It allows a better "upper bound" of performance for core things IMO while keeping to bytecode/IL. Many benchmarks where the same level of application optimisation has occured from what I seen have confirmed this bias for me. YMMV

Re: Which version of JDK should I use?

#157

These recommendations are pretty arbitrary and don't even attempt to scratch the surface of what is actually materially different between the JDKs. Don't use Corretto outside of Amazon... why? Don't use Dragonwell because... China bad? Use Red Hat OpenJDK if you're running on Red Hat servers, Microsoft OpenJDK if you're on Azure, SapMachine if you're on SAP, because... the name matches so that's nice? At least they'r…

> Use Red Hat OpenJDK if you're running on Red Hat servers, Microsoft OpenJDK if you're on Azure, SapMachine if you're on SAP, because... the name matches so that's nice?

Presumably this has to do with support and possible testing. People buy RedHat EL for the longterm support, if they use a different vendor for the JDK they have to set up a whole new contract for that with a different company. By contrast, people using a free Linux distro may not have any benefit to using RedHat's JDK.

Re: Which version of JDK should I use?

#158
post #61

Earlier quoted context omitted.

> any references/benchmarks for some realworld apps/services? .NET 6 is vastly more performant than .NET 5, which was already faster than openjdk and openj9 ( https://devblogs.microsoft.com/dotnet/performance-improvemen... ) > and also what do you mean by oracle suing if you implement value types? this one shouldn't need an explanation, oracle very commonly pursues frivolous lawsuits as a way of bullying money out of…

where does it say .net 5 was faster than openjdk? hotspot is a very sophisticated jit compiler that has probably 100 manyears put into it just in optimizations. given that .net added monomorphic/bimorphic call site devirtualization recently which is considered quite basic in the hotspot, it would be good to see real world usage comparison.

Where required there are ways to force it to inline/devirtualise yourself. For example using refied generics is one way I've seen - i.e. there is no interface/virtual casting since it takes a type that implements interface, rather than the interface itself. It allows you to make polymorphism compile time rather than runtime. Seem comparison libraries to Java (closed source) that have run much faster as a result.

I do find people comparing Java and .NET Core often are compare apples to oranges however. Working on both languages it is just my opinion but the .NET platform is newer - it has a better "base" even without the same man hours. Much of the engineering time in both ecosystems is spent optimising for code typical to that ecosystem which is affected by history/legacy like any other software system.

Re: Which version of JDK should I use?

#159

Earlier quoted context omitted.

Currently upgrading a ~1M SLoC Java enterprise app (with regular Spring, Jetty in there, scheduled processes, PrimeFaces for web UI, REST API services, SOAP services, the whole shebang) from Java 8 to Java 11 (since 17 wasn't out when that change was approved) and it's largely proving to be a pain. Since the version of Spring is ancient and changes over to Spring Boot were also approved, now have to rewrite parts of…

Can you give a specific technical problem with updating from 8 to 11? Everyone says it's hard - nobody's ever able to give a practical example of a problem.

Oh, I have a fun one. The company I work at leverages Nashorn for running some user-customizable scripts and when upgrading from 8 to 11 we found out that Nashorn changed the way they express numbers under the hood. Basically, every number is either an integer or a float and it used to be that every number was a long or a float.

This silently broke a bunch of scripts and callbacks because of class cast exceptions and such. The solution was to rewrite the scripts in such a way to import the Java Long class and use that directly to express large integers.

The most important breaking issues I've found were not necessarily in our code base, but in dependencies. Libraries that include libraries that include libraries, all doing their own thing, a lot of the time involving some pretty scary reflection stuff for some unexplained reason. Blindly upgrading libraries only gets you so far, sometimes a dependency gets abandoned and you need to find a replacement and rewrite your code to call the APIs in the right manner to be backwards compatible enough.

Re: Which version of JDK should I use?

#160

Earlier quoted context omitted.

Can you give a specific technical problem with updating from 8 to 11? Everyone says it's hard - nobody's ever able to give a practical example of a problem.

Oh, I have a fun one. The company I work at leverages Nashorn for running some user-customizable scripts and when upgrading from 8 to 11 we found out that Nashorn changed the way they express numbers under the hood. Basically, every number is either an integer or a float and it used to be that every number was a long or a float. This silently broke a bunch of scripts and callbacks because of class cast exceptions and…

> involving some pretty scary reflection stuff for some unexplained reason

This is where it always seems to end up. Why do people bend over so far backwards doing reflection that isn't specified?

Post reply on HN