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…
Which version of JDK should I use?
101–110 of 258 posts
Re: Which version of JDK should I use?
#102Earlier 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…
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?
#103The 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…
Re: Which version of JDK should I use?
#104I 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.
Re: Which version of JDK should I use?
#105Re: Which version of JDK should I use?
#106Earlier 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.
Re: Which version of JDK should I use?
#107I 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.
Here are some pages that list some of the reasons:
Re: Which version of JDK should I use?
#108Earlier 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.
Re: Which version of JDK should I use?
#109The 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…
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.