18 ms·

Considering tons of folks are still on Java 8, I would have liked to also see comparison between that and Java 17. Based on the improvements shown from Java 11

Considering tons of folks are still on Java 8, I would have liked to also see comparison between that and Java 17. Based on the improvements shown from Java 11 to 17, one could expect even larger improvements from Java 8.

pantalaimon 5y ago
I'm surprised that it's now common for software to require a certain (old) Java version. Wasn't the whole "write once run anywhere" promise about backwards compatibility too?
- the8472 5y ago
  That generally holds when you stick to public APIs. But there are many libraries that used reflection to access unstable internals. And that broke with modules.
  - native_samples 5y ago
    No, it was more than that. Java has broken a ton of backwards compatibility in recent years. They stopped shipping a lot of stuff (like JavaFX), JavaEE stuff was removed from the JDK and then re-namespaced, they changed the formatting of the version number, they removed Web Start, they moved some stuff out of Unsafe, they changed how you access class files inside the JDK and so on. The idea that the only thing that changed was access to internals isn't really the case, but a lot of these changes were "allowed" because Java cares about compatibility with its own spec rather than specific popular apps.
    - josefx 5y ago
      > They stopped shipping a lot of stuff (like JavaFX), I thought they just split up the JDK into modules, making some libraries optional for a smaller footprint if you decided to ship your program with the JDK included. I am quite sure swing was also split of and all my toy programs still run despite that. > JavaEE stuff was removed from the JDK and then re-namespaced, JavaEE was never part of the standard JDK. Never used it, but you can probably still find the old java package somewhere. > they moved some stuff out of Unsafe out of sun.misc.Unsafe, an internal API of the Sun JDK that wasn't in the java namespace, wasn't documented and had nearly every IDE scream at you.
      - brabel 5y ago
        > I am quite sure swing was also split of and all my toy programs still run despite that. Swing is still distributed with the JDK, but JavaFX isn't. If you use JavaFX, you need to either add Maven dependencies on the JavaFX modules or compile with a JDK distribution which still includes JavaFX (e.g. jdk-fx from Azul: https://www.azul.com/downloads/?package=jdk-fx https://www.azul.com/downloads/?package=jdk-fx).
- pram 5y ago
  Tried running a Java applet recently? ;P
  - msgilligan 5y ago
    The answer to this question is almost certainly "no". It is ironic that what was originally the most hyped feature of Java has now been removed. But nobody is going to miss it.
    - lucumo 5y ago
      I worked on one this year. You need Java 8 for it and an insanely old browser. They didn't mention the applet part in the job description. That was my shortest tenure ever, including Summer jobs and internships...
      - msgilligan 5y ago
        Ugh. Sounds horrible.
      - vbezhenar 5y ago
        Some applets could be launched with javaws, but it would require some tinkering to extract proper jnlp file from HTML or JavaScript. I managed to do so with HP iLO remote KVM app.
        marwis 5y ago
        javaws was also removed =)
        vbezhenar 5y ago
        Need to use old Java, yep. Not as painful as using old browser.
    - tablespoon 5y ago
      >> Tried running a Java applet recently? ;P > The answer to this question is almost certainly "no". For me, it's a yes. My employer uses some ancient monitoring application called SiteScope. They recently "upgraded" from an ancient version to a newer one (I think the latest), and nearly the whole frontend appears to be implemented as a Java Applet. Since no browser on the Mac supports Applets anymore, their workaround was to download some Java App that ran the UI. The older version we had used HTML.
- NovemberWhiskey 5y ago
  At the byte code level, maybe - but any language as large as Java is (over the course of 20+ years) going to have changes to its libraries, including deprecations / removals.
- msgilligan 5y ago
  It's common to require a certain old Java version or newer. In general Java is extremely backward compatible. There have been a few minor breaking changes from JDK 8 to JDK 17, but the worst ones have had command-line options to disable them. Maybe you're referring to JEE and/or specific "enterprise" software which does tend to move much more slowly.
  - colechristensen 5y ago
    I’ve run into several performance regressions from 8 -> 11 -> beyond Code still worked but services would easily get overloaded, there would be one piece of code which ran crazy slow, or new memory issues would come up. It absolutely is not just safe to jump versions in production, usually it’s been weeks of testing finding and fixing perf bugs.
    - msgilligan 5y ago
      Yes, what you describe is entirely believable. And one of the legitimate reasons why enterprise software is slow to upgrade.
  - technion 5y ago
    This really hasn't been consistent with my experience as an end user. I have POS software that will blow up if any POS terminal applies a minor point release update on any terminal. I have current PMS software from Oracle that will infinitely NullPointerException if upgrade to a currently supported version of Oracle's JRE. It's going back a few years but I remember backups being unreadable if you upgraded JRE on a Backup Exec server.
- pabl0rg 5y ago
  Yes. But in the move to java 9 they broke java’s customary backward compatibility and left behind a lot of users. It doesn’t help that there is no good, clear and complete guide on how to upgrade SOAP clients. I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem. I’m not surprised that people seem to be leaving the ecosystem.
  - oauea 5y ago
    > It doesn’t help that there is no good, clear and complete guide on how to upgrade SOAP clients. > I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem. Could you clarify what you ran into? Why docker? I'll have to do this soon.
    - Alupis 5y ago
      Specifically, a ton of used-to-be-included in the standard JDK things like nearly all XML processing are now broken out into modules or require maven dependencies, etc. So it's not "turn-key" to upgrade to jdk 9 or above, like say, 6 -> 7 -> 8 was. Sounds simple... "just add it to your maven deps!" - but in practice it's more complicated than that and requires careful planning and testing. Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. Java 9 created quite a mess. Once you finish that upgrade though, moving into Java 11 or anything newer is basically turn-key like it was before. But, this had the effect of many companies staying with Java 8 until forced to upgrade.
      - _hilro 5y ago
        from OP > Could you clarify what you ran into? Why docker? Not sure I follow why you had to turn to docker > Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. The JVM is deterministic - I don't follow this statement?
- osrec 5y ago
  I know it does happen, but I wouldn't say it's common. Generally speaking, most of the software I use runs without issues on newer JVMs, despite being built for an old one.
- _pmf_ 5y ago
  All desktop software I knew around 2009 already used a bundled JRE.
- paulmd 5y ago
  Oracle moved away from their "free" license to requiring a $100 or $200 per seat license for home users (and I think even more for business users), so the clock stopped ticking at Java 8u202 for a lot of people who refused to (or couldn't) move to OpenJDK. edit: although this appears to have recently changed! https://blogs.oracle.com/java/post/free-java-license https://blogs.oracle.com/java/post/free-java-license It was really a terrible idea from a security perspective - and unfortunately there are organizations that won't consider software without a support contract.
- gdsdfe 5y ago
  Java 8 was out 7 years ago ... That's like century in the software world
- EdwardDiego 5y ago
  The big issue is around four things: 1) Certain libraries that were part of the JDK being moved out of the JDK, which usually required adding them as a module or dependency in $BUILD_TOOL_INSTRUCTIONS_FILE 2) Internal JVM APIs that weren't public being used via reflection by clever libraries, and then when they change, those libraries break 3) Bytecode emitting libraries - various frameworks love these, but bytecode that worked for Java 8 can fail on Java 9. Hence Spring 4 only supports JDKs 6 - 8. So to move to JDK 9+, you had to upgrade Spring to 5.x, and things that were tied to your version of Spring... and this process can very often suck. 4) New versions of library X only being available in class formats that Java 8 can't run. I encountered this with Jetty - version 10+ only support Java 11+, so if you're stuck on Java 8, you're limited to bug fix releases on the last version that supported Java 8. Since Java 9, the JVM has been warning if you use internal APIs. As of Java 17, they have started enforcing strong encapsulation of those APIs ("private means private yo"), to give the JDK freedom to evolve without worrying about every library that got clever with the internals of the JVM. But given the very long lead time and ample messaging on this, I don't expect Java 17 breaking too many things. At my last job, we had a rather large monolithic build that was tied to Java 8 because some modules would die a horrible death when compiled with or for a higher version Java. So I introduced Maven and Gradle toolchains[1] so that individual modules could compile using their preferred Java version, which freed up new modules/apps to use Java >8 as they saw fit. All the legacy apps that broke on Java 9+ could stay on 8, but the rest of the project was freed from their legacy crap. [1]: https://docs.gradle.org/current/userguide/toolchains.html https://docs.gradle.org/current/userguide/toolchains.html
- magpi3 5y ago
  Write once test everywhere was the problem. If you wanted a fully tested app, you have to bundle a JRE, and if you are bundling a JRE then backward compatibility is not as important.
- stockerta 5y ago
  Taht never worked. I had to use a goverment java web applet that run on only one exact java version, down to the patch level. Anything else, it didn't work. And also that java version was already out of date, so every browser was crying about it. fsck java.
spullara 5y ago
Anyone still on Java 8 can just stay there. If they cared about whatever it is they would have upgraded years ago.
- brokenmachine 5y ago
  Complete Anathema to the upgrade-addicted architecture astronauts round here. Nothing can ever be finished, there must be "upgrades"!
DarkmSparks 5y ago
Im more skeptical. one of the reasons we're still on jre8 is any of the newer jres I tested throw crash panics on several tasks and the ones that dont take 40 or 50 hours to finish instead of instead of 4 or 5. (mostly changes in the garbage collection as far as i could tell, several command line options we rely on for performance were depreciated with no way to turn them back on) That left me with the impression that stability and performance had been abandoned over throwing everything including the kitchen sink at it to try and attract people who like rust and go. Could be wrong, but the hand waving away the implication that 17 is slower than 15 at the end and not even trying to compare with 8 which is rock solid and crazy performant leaves me thinking nothing actually changed.
- vips7L 5y ago
  Here is a blog that compares garbage collection across several versions and GC's: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 They concluded: "JDK 8 is an antiquated runtime. The default Parallel collector enters huge Full GC pauses and the G1, although having less frequent Full GCs, is stuck in an old version that uses just one thread to perform it, resulting in even longer pauses. Even on a moderate heap of 12 GB, the pauses were exceeding 20 seconds for Parallel and a full minute for G1. The ConcurrentMarkSweep collector is strictly worse than G1 in all scenarios, and its failure mode are multi-minute Full GC pauses."
  - DarkmSparks 5y ago
    I forget, bit iirc it uses one by default, but you can specify the number of threads to use with XX:ParallelGCThreads=<N> which is what got depreciated later. its target is throughput rather than response so yep "pauses", but the entire job takes 4 hours instead of 40. In production those pauses vanish with load balancing. checking for jdk8 vs jdk17 turns up https://www.google.com/amp/s/www.infoworld.com/article/3606833/jdk-17-the-new-features-in-java-17.amp.html https://www.google.com/amp/s/www.infoworld.com/article/36068... "New Relic found that nearly 100 percent of users are running either JDK 11 or JDK 8, the two most recent LTS releases." so 17 being 8% faster than 11 apart from when its 10% slower, "maybe" slower or faster than 15 but they chose not to do a like for like comparison.... but 11 being catastrophically lower throughput than 8.... I may get some time soon to do some benching, I dont want to be back on 8, but the benching I did for at least 10 and 11 just made them a no go, completely crashing the jvm was an even bigger issue than the time.
surfsvammel 5y ago
We are still on Java 8 in many applications and there is no real reason for it. Very much looking forward to get our hands on some new GC implementations. We will definitely move to 17 already next year.
yellowapple 5y ago
I legitimately didn't know there were newer versions than 8. I haven't been following the Java space very closely, so I kinda did a double-take when I saw "Java 17" lol.
- hallway_monitor 5y ago
  Same here. I've been in Microsoft land for the past decade and doing some Android work in xamarin which is I believe still on Java 8.
  - brunoborges 5y ago
    Then you will be shocked to learn that Microsoft now builds and ships its own Build of OpenJDK. https://microsoft.com/openjdk https://microsoft.com/openjdk
ge0ffrey 5y ago
> Considering tons of folks are still on Java 8, I would have liked to also see comparison between that and Java 17. We did a comparison of Java 8 and Java 11. And that was a good jump too: https://www.optaplanner.org/blog/2019/01/17/HowMuchFasterIsJava11.html https://www.optaplanner.org/blog/2019/01/17/HowMuchFasterIsJ... Now, you can't just sum op those percentages (different code base), but that sum would be a starting estimate I think.

pantalaimon 5y ago

I'm surprised that it's now common for software to require a certain (old) Java version. Wasn't the whole "write once run anywhere" promise about backwards compatibility too?

the8472 5y ago
That generally holds when you stick to public APIs. But there are many libraries that used reflection to access unstable internals. And that broke with modules.
- native_samples 5y ago
  No, it was more than that. Java has broken a ton of backwards compatibility in recent years. They stopped shipping a lot of stuff (like JavaFX), JavaEE stuff was removed from the JDK and then re-namespaced, they changed the formatting of the version number, they removed Web Start, they moved some stuff out of Unsafe, they changed how you access class files inside the JDK and so on. The idea that the only thing that changed was access to internals isn't really the case, but a lot of these changes were "allowed" because Java cares about compatibility with its own spec rather than specific popular apps.
  - josefx 5y ago
    > They stopped shipping a lot of stuff (like JavaFX), I thought they just split up the JDK into modules, making some libraries optional for a smaller footprint if you decided to ship your program with the JDK included. I am quite sure swing was also split of and all my toy programs still run despite that. > JavaEE stuff was removed from the JDK and then re-namespaced, JavaEE was never part of the standard JDK. Never used it, but you can probably still find the old java package somewhere. > they moved some stuff out of Unsafe out of sun.misc.Unsafe, an internal API of the Sun JDK that wasn't in the java namespace, wasn't documented and had nearly every IDE scream at you.
    - brabel 5y ago
      > I am quite sure swing was also split of and all my toy programs still run despite that. Swing is still distributed with the JDK, but JavaFX isn't. If you use JavaFX, you need to either add Maven dependencies on the JavaFX modules or compile with a JDK distribution which still includes JavaFX (e.g. jdk-fx from Azul: https://www.azul.com/downloads/?package=jdk-fx https://www.azul.com/downloads/?package=jdk-fx).
pram 5y ago
Tried running a Java applet recently? ;P
- msgilligan 5y ago
  The answer to this question is almost certainly "no". It is ironic that what was originally the most hyped feature of Java has now been removed. But nobody is going to miss it.
  - lucumo 5y ago
    I worked on one this year. You need Java 8 for it and an insanely old browser. They didn't mention the applet part in the job description. That was my shortest tenure ever, including Summer jobs and internships...
    - msgilligan 5y ago
      Ugh. Sounds horrible.
    - vbezhenar 5y ago
      Some applets could be launched with javaws, but it would require some tinkering to extract proper jnlp file from HTML or JavaScript. I managed to do so with HP iLO remote KVM app.
      - marwis 5y ago
        javaws was also removed =)
        vbezhenar 5y ago
        Need to use old Java, yep. Not as painful as using old browser.
  - tablespoon 5y ago
    >> Tried running a Java applet recently? ;P > The answer to this question is almost certainly "no". For me, it's a yes. My employer uses some ancient monitoring application called SiteScope. They recently "upgraded" from an ancient version to a newer one (I think the latest), and nearly the whole frontend appears to be implemented as a Java Applet. Since no browser on the Mac supports Applets anymore, their workaround was to download some Java App that ran the UI. The older version we had used HTML.
NovemberWhiskey 5y ago
At the byte code level, maybe - but any language as large as Java is (over the course of 20+ years) going to have changes to its libraries, including deprecations / removals.
msgilligan 5y ago
It's common to require a certain old Java version or newer. In general Java is extremely backward compatible. There have been a few minor breaking changes from JDK 8 to JDK 17, but the worst ones have had command-line options to disable them. Maybe you're referring to JEE and/or specific "enterprise" software which does tend to move much more slowly.
- colechristensen 5y ago
  I’ve run into several performance regressions from 8 -> 11 -> beyond Code still worked but services would easily get overloaded, there would be one piece of code which ran crazy slow, or new memory issues would come up. It absolutely is not just safe to jump versions in production, usually it’s been weeks of testing finding and fixing perf bugs.
  - msgilligan 5y ago
    Yes, what you describe is entirely believable. And one of the legitimate reasons why enterprise software is slow to upgrade.
- technion 5y ago
  This really hasn't been consistent with my experience as an end user. I have POS software that will blow up if any POS terminal applies a minor point release update on any terminal. I have current PMS software from Oracle that will infinitely NullPointerException if upgrade to a currently supported version of Oracle's JRE. It's going back a few years but I remember backups being unreadable if you upgraded JRE on a Backup Exec server.
pabl0rg 5y ago
Yes. But in the move to java 9 they broke java’s customary backward compatibility and left behind a lot of users. It doesn’t help that there is no good, clear and complete guide on how to upgrade SOAP clients. I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem. I’m not surprised that people seem to be leaving the ecosystem.
- oauea 5y ago
  > It doesn’t help that there is no good, clear and complete guide on how to upgrade SOAP clients. > I went through this recently and learned that because jakarta uses multi-release jars, we have to do the regular dependency changes and also change our fat-jar based build/release to Docker images. In other words, they decided to throw out decades of users’ investment in learning the ecosystem. Could you clarify what you ran into? Why docker? I'll have to do this soon.
  - Alupis 5y ago
    Specifically, a ton of used-to-be-included in the standard JDK things like nearly all XML processing are now broken out into modules or require maven dependencies, etc. So it's not "turn-key" to upgrade to jdk 9 or above, like say, 6 -> 7 -> 8 was. Sounds simple... "just add it to your maven deps!" - but in practice it's more complicated than that and requires careful planning and testing. Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. Java 9 created quite a mess. Once you finish that upgrade though, moving into Java 11 or anything newer is basically turn-key like it was before. But, this had the effect of many companies staying with Java 8 until forced to upgrade.
    - _hilro 5y ago
      from OP > Could you clarify what you ran into? Why docker? Not sure I follow why you had to turn to docker > Some things might even surprise you and run for a while before a classloader can't find something and explodes in runtime. The JVM is deterministic - I don't follow this statement?
osrec 5y ago
I know it does happen, but I wouldn't say it's common. Generally speaking, most of the software I use runs without issues on newer JVMs, despite being built for an old one.
_pmf_ 5y ago
All desktop software I knew around 2009 already used a bundled JRE.
paulmd 5y ago
Oracle moved away from their "free" license to requiring a $100 or $200 per seat license for home users (and I think even more for business users), so the clock stopped ticking at Java 8u202 for a lot of people who refused to (or couldn't) move to OpenJDK. edit: although this appears to have recently changed! https://blogs.oracle.com/java/post/free-java-license https://blogs.oracle.com/java/post/free-java-license It was really a terrible idea from a security perspective - and unfortunately there are organizations that won't consider software without a support contract.
gdsdfe 5y ago
Java 8 was out 7 years ago ... That's like century in the software world
EdwardDiego 5y ago
The big issue is around four things: 1) Certain libraries that were part of the JDK being moved out of the JDK, which usually required adding them as a module or dependency in $BUILD_TOOL_INSTRUCTIONS_FILE 2) Internal JVM APIs that weren't public being used via reflection by clever libraries, and then when they change, those libraries break 3) Bytecode emitting libraries - various frameworks love these, but bytecode that worked for Java 8 can fail on Java 9. Hence Spring 4 only supports JDKs 6 - 8. So to move to JDK 9+, you had to upgrade Spring to 5.x, and things that were tied to your version of Spring... and this process can very often suck. 4) New versions of library X only being available in class formats that Java 8 can't run. I encountered this with Jetty - version 10+ only support Java 11+, so if you're stuck on Java 8, you're limited to bug fix releases on the last version that supported Java 8. Since Java 9, the JVM has been warning if you use internal APIs. As of Java 17, they have started enforcing strong encapsulation of those APIs ("private means private yo"), to give the JDK freedom to evolve without worrying about every library that got clever with the internals of the JVM. But given the very long lead time and ample messaging on this, I don't expect Java 17 breaking too many things. At my last job, we had a rather large monolithic build that was tied to Java 8 because some modules would die a horrible death when compiled with or for a higher version Java. So I introduced Maven and Gradle toolchains[1] so that individual modules could compile using their preferred Java version, which freed up new modules/apps to use Java >8 as they saw fit. All the legacy apps that broke on Java 9+ could stay on 8, but the rest of the project was freed from their legacy crap. [1]: https://docs.gradle.org/current/userguide/toolchains.html https://docs.gradle.org/current/userguide/toolchains.html
magpi3 5y ago
Write once test everywhere was the problem. If you wanted a fully tested app, you have to bundle a JRE, and if you are bundling a JRE then backward compatibility is not as important.
stockerta 5y ago
Taht never worked. I had to use a goverment java web applet that run on only one exact java version, down to the patch level. Anything else, it didn't work. And also that java version was already out of date, so every browser was crying about it. fsck java.

spullara 5y ago

Anyone still on Java 8 can just stay there. If they cared about whatever it is they would have upgraded years ago.

brokenmachine 5y ago
Complete Anathema to the upgrade-addicted architecture astronauts round here. Nothing can ever be finished, there must be "upgrades"!

DarkmSparks 5y ago

Im more skeptical. one of the reasons we're still on jre8 is any of the newer jres I tested throw crash panics on several tasks and the ones that dont take 40 or 50 hours to finish instead of instead of 4 or 5. (mostly changes in the garbage collection as far as i could tell, several command line options we rely on for performance were depreciated with no way to turn them back on) That left me with the impression that stability and performance had been abandoned over throwing everything including the kitchen sink at it to try and attract people who like rust and go. Could be wrong, but the hand waving away the implication that 17 is slower than 15 at the end and not even trying to compare with 8 which is rock solid and crazy performant leaves me thinking nothing actually changed.

vips7L 5y ago
Here is a blog that compares garbage collection across several versions and GC's: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 They concluded: "JDK 8 is an antiquated runtime. The default Parallel collector enters huge Full GC pauses and the G1, although having less frequent Full GCs, is stuck in an old version that uses just one thread to perform it, resulting in even longer pauses. Even on a moderate heap of 12 GB, the pauses were exceeding 20 seconds for Parallel and a full minute for G1. The ConcurrentMarkSweep collector is strictly worse than G1 in all scenarios, and its failure mode are multi-minute Full GC pauses."
- DarkmSparks 5y ago
  I forget, bit iirc it uses one by default, but you can specify the number of threads to use with XX:ParallelGCThreads=<N> which is what got depreciated later. its target is throughput rather than response so yep "pauses", but the entire job takes 4 hours instead of 40. In production those pauses vanish with load balancing. checking for jdk8 vs jdk17 turns up https://www.google.com/amp/s/www.infoworld.com/article/3606833/jdk-17-the-new-features-in-java-17.amp.html https://www.google.com/amp/s/www.infoworld.com/article/36068... "New Relic found that nearly 100 percent of users are running either JDK 11 or JDK 8, the two most recent LTS releases." so 17 being 8% faster than 11 apart from when its 10% slower, "maybe" slower or faster than 15 but they chose not to do a like for like comparison.... but 11 being catastrophically lower throughput than 8.... I may get some time soon to do some benching, I dont want to be back on 8, but the benching I did for at least 10 and 11 just made them a no go, completely crashing the jvm was an even bigger issue than the time.

surfsvammel 5y ago

We are still on Java 8 in many applications and there is no real reason for it. Very much looking forward to get our hands on some new GC implementations. We will definitely move to 17 already next year.

yellowapple 5y ago

I legitimately didn't know there were newer versions than 8. I haven't been following the Java space very closely, so I kinda did a double-take when I saw "Java 17" lol.

hallway_monitor 5y ago
Same here. I've been in Microsoft land for the past decade and doing some Android work in xamarin which is I believe still on Java 8.
- brunoborges 5y ago
  Then you will be shocked to learn that Microsoft now builds and ships its own Build of OpenJDK. https://microsoft.com/openjdk https://microsoft.com/openjdk

ge0ffrey 5y ago

> Considering tons of folks are still on Java 8, I would have liked to also see comparison between that and Java 17. We did a comparison of Java 8 and Java 11. And that was a good jump too: https://www.optaplanner.org/blog/2019/01/17/HowMuchFasterIsJava11.html https://www.optaplanner.org/blog/2019/01/17/HowMuchFasterIsJ... Now, you can't just sum op those percentages (different code base), but that sum would be a starting estimate I think.