4 ms·

To be fair, JDK8 represents a stable version of Java features and API that is most of what is needed for enterprise Java development. It is basically the stable

To be fair, JDK8 represents a stable version of Java features and API that is most of what is needed for enterprise Java development. It is basically the stable inflection point of Java's evolution in terms of why Java took over enterprise development. There was a core development intelligence level that JDK8 represented a sweet spot for (ahem, offshoring development). Which is really the core of the hate for Java these days although ... isn't Go the same trap? Most of the post-JDK8 features are moving the language to what Groovy is, but closures, magic string templates, etc, but the IQ level of the programmers for that is a different market availability. Combined with the inherent deployment churn needed for modern JVM version turnover, which most enterprises simply don't have the organizational ability to do, means that JDK8 is going to stick around a LONG time.

lmm 3y ago
Nonsense. For that kind of lowest-common-denominator development JDK8 has nothing that JDK6 doesn't; it has some minor quality-of-life improvements to the language, and some performance improvements to the VM, but nothing truly fundamental. If enterprises were trying to stick with a dumb Go-like language they would stay on JDK6. The real reason is simply that JDK9 was a much bigger compatibility break (in practice if not in theory) than any release before or since, and came after a long time of relatively little development. A lot of frameworks weren't compatible with JDK9 until years after release; some older ones may never be. So especially for enterprises that may have their own large internal frameworks, it takes a while.
- mdaniel 3y ago
  > For that kind of lowest-common-denominator development JDK8 has nothing that JDK6 doesn't I see you are also one of the folks who ignores try-with-resources. And, say what you will about lambdas, it is night and day different between pre-8 and post-8 implementations of those various one-method interfaces such as InvocationHandler Connection fakeConn = (Connection)Proxy.newInstance(cl, new Class[]{Connection.class}, (proxy, method, args) -> { /*something awesome*/ })
  - lmm 3y ago
    I like both those things but they're just syntax sugar, they increase expressiveness at the cost of a more complex language. If the goal was a dumb language for dumb offshore developers (I don't think it is, but that's what the post I was responding to was saying), JDK6 is an even better choice than JDK8. Putting it another way, the changes going 6 -> 8 are the same kind of things as the changes going 9 -> 10, or even 9 -> 17.

lmm 3y ago

Nonsense. For that kind of lowest-common-denominator development JDK8 has nothing that JDK6 doesn't; it has some minor quality-of-life improvements to the language, and some performance improvements to the VM, but nothing truly fundamental. If enterprises were trying to stick with a dumb Go-like language they would stay on JDK6. The real reason is simply that JDK9 was a much bigger compatibility break (in practice if not in theory) than any release before or since, and came after a long time of relatively little development. A lot of frameworks weren't compatible with JDK9 until years after release; some older ones may never be. So especially for enterprises that may have their own large internal frameworks, it takes a while.

mdaniel 3y ago
> For that kind of lowest-common-denominator development JDK8 has nothing that JDK6 doesn't I see you are also one of the folks who ignores try-with-resources. And, say what you will about lambdas, it is night and day different between pre-8 and post-8 implementations of those various one-method interfaces such as InvocationHandler Connection fakeConn = (Connection)Proxy.newInstance(cl, new Class[]{Connection.class}, (proxy, method, args) -> { /*something awesome*/ })
- lmm 3y ago
  I like both those things but they're just syntax sugar, they increase expressiveness at the cost of a more complex language. If the goal was a dumb language for dumb offshore developers (I don't think it is, but that's what the post I was responding to was saying), JDK6 is an even better choice than JDK8. Putting it another way, the changes going 6 -> 8 are the same kind of things as the changes going 9 -> 10, or even 9 -> 17.