Live data from Hacker News

Which version of JDK should I use?

whichjdk.com

101–110 of 258 posts

Re: Which version of JDK should I use?

#101

The general guidance is always use the last LTS release unless there is a specific feature in the non LTS releases that you can’t wait for. So any new development should target 17 at this point. Unless you want serious long term pain then you shouldn’t be more than one LTS release behind. So if you are not running on JDK 11 or later you should be strongly thinking about upgrading.

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.

Re: Which version of JDK should I use?

#102
post #23

Earlier quoted context omitted.

Why should I stick to LTS? All other versions aren't in any way less tested, you should always stick to the newest released JDK version, be it LTS or not, this way you get all the benefits (language features, performance gains) and security ones (security fixes always first land in the newest version, and are backported to the older ones). Upgrades now are pretty straightforward if you are past JKD 9 - with JDK 16-17…

> (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…

These discussions inevitably end up as a flame war sooner or later.

Regardless, i actually compared Java with .NET and their web frameworks as a part of my bachelors', everything from synthetic benchmarks for encryption and data processing and transformations, to things like shuffling JSON around. Now, it's all in Latvian and was a number of years ago, so it's not entirely relevant at this point, but i did have some tangible findings.

In short:

  - both Java and .NET (then Core) are inconsistent in their performance - there are certain things which are slower in one technology than other by not using external optimized libraries. For example, Java had problems with writing deeply nested dynamically generated JSON with JavaEE libraries (now Jakarta), whereas .NET Core had problems with handling large amounts of text
  - their performance was largely comparable in most other tests, neither was faster by a factor of 10, like you'd see with Python and Ruby compared to either
  - thus, it's largely a matter of choosing the actual frameworks that you'll want to utilize properly and consider both the job market and business factors (familiarity with the tech stack, job market etc.)
  - in summary, they're close enough for it to not be a technical decision most of the time in real world circumstances (save for a few exceptions), but rather is a decision that depends on social elements
Since then:

  - i don't believe that the observation of them being "close enough" has changed much, both in legacy code and otherwise
  - .NET Core and now .NET 6 has improved bunches with its runtime; Core was so successful it's essentially the future of the platform (i feel bad for developers who'll be tricked into working on legacy code with the old .NET and IIS, versus the new one and Kestrel)
  - JDK has improved bunches with its runtime and GC; the runtime situation is a bit complicated and cumbersome, considering the OP's article, but overall it's pretty usable, especially with frameworks like Quarkus
If you care about benchmarks and vaguely realistic performance comparisons in the current year, simply have a look at the TechEmpower benchmarks: https://www.techempower.com/benchmarks/#section=data-r20&hw=...

If you jump around the different tabs that compare which frameworks do what better, on average:

  - .NET is better for plain text
  - .NET is noticeably better for data updates
  - Java is noticeably better for JSON serialization
  - Java is noticeably better for single DB queries
  - Java is noticeably better for multiple DB queries
  - as for cached queries and other use cases, there's more variance
  - neither is better than the other for it to matter a lot
These are probably better than me linking the bachelors' because it's done in a better controlled environment, with more resources, and a lot of people contributing to the source code of the benchmarks: https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...

In short, you're not necessarily wrong - there have indeed been great improvements to the .NET platform and it's good to see it finally being a capable and performant tech stack that you can use on *nix. But you're also not right: Java is getting similar attention, even though it's still lagging behind a few years in regards to "having its stuff together" (e.g. going from Oracle JDK to a more stable model + the JDK 8 to newer version shift, which is similarly painful with old .NET versions).

To lighten the mood, i'd consider suggesting that anyone also have a look at Go, which is similarly performant and allows you to build runtime independent executables by default, which is easier than in either .NET or Java. It's also pretty easy to write and has seen good use for the development of tools, since its startup time is a tad better than either that of Java or .NET as well. Here's the three compared: https://www.techempower.com/benchmarks/#section=data-r20&hw=...

Re: Which version of JDK should I use?

#103

The general guidance is always use the last LTS release unless there is a specific feature in the non LTS releases that you can’t wait for. So any new development should target 17 at this point. Unless you want serious long term pain then you shouldn’t be more than one LTS release behind. So if you are not running on JDK 11 or later you should be strongly thinking about upgrading.

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…

JDK 8 -> 9 migration was painful, but all other upgrades should be painless (well, maybe the 16-17, but I assume that most libraries will be fixed by the time you upgrade - either add `add-opens` instructions or use appropriate new classes from JDK).

Re: Which version of JDK should I use?

#104

I think this advice only applies to the end users of the JDK and libs, e.g. people who develop webapps. We maintain an OSS library and plan to support JDK 8 for as long as possible (though some of our dependencies made a move to JDK 11 and most likely we'll have to follow suit). With this approach, our libraries can be used by developers under JVM 8, 11, or 17.

Thank you; it is so appreciated when libraries don't abandon old versions.

Re: Which version of JDK should I use?

#105

Earlier quoted context omitted.

I’m confused why you’re suddenly talking about .NET.

There's no real reason to use java for new development in 2021.

Java has a better technology stack. The JVM is light-years ahead of the .NET runtime.

Re: Which version of JDK should I use?

#106
post #44

Earlier quoted context omitted.

The safest, cheapest choice for applications that are heavily maintained is to use the most recent version. LTS is designed for legacy applications that are no longer heavily developed, and might benefit from security and bug fixes only (note that this model is new; in the past, back when there were major versions, minor updates included both patches and big features).

'heavily developed' is the operative consideration as this means upgrading (not merely updating) your Java installations every 6 months.

Which is quite painless, I do it since JDK 10, upgrade up to 1 week after JDK release and it was painless (with one exception around JDK 12 or 13 where spring have some issue for 1 month until I could upgrade).

Re: Which version of JDK should I use?

#107

I wonder why this site doesn't enforce HTTPS, which it clearly supports. https://whichjdk.com/

What reason is there to force https on a stateless static page? The content is always the same. You're just ruining caching and wasting CPU cycles.

That's a very old fashioned way to think about it.

Here are some pages that list some of the reasons:

- https://whynohttps.com/

- https://www.cloudflare.com/learning/ssl/why-use-https/

Re: Which version of JDK should I use?

#108
post #72

Earlier quoted context omitted.

I was using adopt jdk since that's much easier to download the jdk (especially jre) for Windows and Linux. The new Adoptium didn't git a jre build, which is sad :(

Honestly if you are using Linux you should be using the distros Java.

Why? Distros javas are usually way too old to use.

Re: Which version of JDK should I use?

#109

The general guidance is always use the last LTS release unless there is a specific feature in the non LTS releases that you can’t wait for. So any new development should target 17 at this point. Unless you want serious long term pain then you shouldn’t be more than one LTS release behind. So if you are not running on JDK 11 or later you should be strongly thinking about upgrading.

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…

I got stuck in this conundrum at my previous gig as well, and think reached a very different conclusion than you. In short, while I’m skeptical of some of the degree of churn across modern software development as a whole, I’m not sure that this is actually an issue with the Java ecosystem, which has been, and I think continues to be, way more sensitive to backwards compatibility than almost any other ecosystem.

In some ways, this is just a consequence of a kind of evolutionary leap forward for many applications. We don’t deploy our WARs into application servers anymore, we try to pack a fat JAR, or maybe even a statically linked runtime, into a container. We rebuild the whole world on CI all the time. I mean, Java 8 has issues just respecting cgroup limits, which many a despondent ops engineer has discovered.

I think there’s still room for the 1M SLoC monolith even in this new world, but there are real benefits on the horizon for upgrading to Java 17 and beyond. We’ve reached a point where it’s just more expensive not to make upgrades a regular part of you development cycle. And, no one is stopping you from just staying on 1.8. I mean, I’m sure there are still decaying enterprises stranded on 1.3.

Post reply on HN