5 ms·

I agree with everything you said except for "Java is still very slow to evolve." New Java versions are cut every six months since 2017 and since then has added

I agree with everything you said except for "Java is still very slow to evolve." New Java versions are cut every six months since 2017 and since then has added a significant amount of new features, syntactical sugar, APIs, et cetera. Not only that, but they've also have been pretty aggressive IMO in deprecating and removing legacy. Very very different than the Java I remember working in years ago.

weego 4y ago
You're correct of course, but to back up the parents comment, they do have a habit of implementing things other than the low hanging fruit that developers are frustrated not having, leading the drive towards other jvm langs
- mbStavola 4y ago
  What are some examples of those low hanging fruits?
  - ohgodplsno 4y ago
    Functional/SAM interfaces (transforming interfaces with a single method into a simple lambda), pleasant usage of lambdas (last lambda parameter can be put outside of the call like(this) { ... }, leading to a language that lends itself really well to building a DSL, coroutines were not a low hanging fruit but absolutely are infinitely more pleasant to use than RxJava, operator overload including invoke(), ranges that are pleasant to use (0 .. 10).forEach { }, or when (floatVariable) { in 0.0f .. 1.0f -> ... }, pattern-ish matching with when (not quite full on functional language powerful, and I believe that Java is not only catching up to it but making their switch quite a bit better), a standard lib that is packed full of extremely useful and consistently named methods, extension functions, delegation (if you inherited a SDK that has a piss poor interface, you can simply make a SDKWrapper(val internalSdk: SDK): SDK by internalSdk, which means that it will automatically implement it, and you can then have your wrapper do whatever around it (logging, better functions, DI, etc.))) Kotlin is truly a pleasant language, both when you don't know it (although it can look a bit symbol soup-y at times for juniors), and when you fully know it.
  - origin_path 4y ago
    Just browse through the Kotlin standard library. It's basically just a set of mappings to the Java standard library with a whole lot of extension functions to make it easier to use.
quantified 4y ago
In HN a while back, an Oracle dev pointed out that the evolution is slow for a reason. Which confirmed slow. New releases every 6 months, but not that much in the way of changes. This isn't criticism of the fact of it or going into why it is or whether it should be that way. It's just a statement of fact.
Alupis 4y ago
> New Java versions are cut every six months since 2017 and since then has added a significant amount of new features And yet, the overwhelming majority of the Java community are still using JRE8 with none of these new features. There are some that love this new pace of language development, but very few are actually using new features in production code.
- yardstick 4y ago
  The hesitancy in jumping beyond JRE8 is the large backwards compatibility road bumps in JDK9-11, and now again with 17/JavaEE->Jakarta. I wish Java would continue to add new features but be a lot more considerate of avoiding, completely, migration headaches. We are migrating Java 8 -> 17 now and it’s been a right royal pain. I’m glad we didn’t jump to 11 LTS, and instead make one big leap. It might be a very long time before we do another LTS upgrade if they keep making poor migration choices.
  - kaba0 4y ago
    The only relatively bumby migration was 8->9. After that it is a very smooth ride, and that bumpiness was the price for the accumulated tech debt/slow down from the end of the Sun era.
    - vips7L 4y ago
      8 -> 9 wasn’t that hard for me personally. For our applications it was just adding things to the build to make sure javax.xml was present. The real difficulty for us was upgrading the Play framework since the Scala community likes to make breaking changes with every release.
    - Alupis 4y ago
      Well, my understanding is (but I have yet to personally experience) the migration from 17 -> 18+ is rough because of all the javax.* packages being renamed jakarta.* Which likely means touching a pretty significant portion of your codebase for the upgrade, and then who knows what 3rd party libraries you depend on are expecting... So it may be as simple as Find/Replace for some folks, for others, it might be a deep dark rabbit hole. Not breaking things used to be Java's MO. Yes, that means a ton of legacy cruft built up over the years... but we used to be able to depend on Java to "Just Work". Perhaps some of this is necessary. After all, the C# folks seem to have no problem breaking everything to add new features... but I'd assert the Java community as a whole is much less tolerant of breaking changes and rapid deployment of features.

weego 4y ago

You're correct of course, but to back up the parents comment, they do have a habit of implementing things other than the low hanging fruit that developers are frustrated not having, leading the drive towards other jvm langs

mbStavola 4y ago
What are some examples of those low hanging fruits?
- ohgodplsno 4y ago
  Functional/SAM interfaces (transforming interfaces with a single method into a simple lambda), pleasant usage of lambdas (last lambda parameter can be put outside of the call like(this) { ... }, leading to a language that lends itself really well to building a DSL, coroutines were not a low hanging fruit but absolutely are infinitely more pleasant to use than RxJava, operator overload including invoke(), ranges that are pleasant to use (0 .. 10).forEach { }, or when (floatVariable) { in 0.0f .. 1.0f -> ... }, pattern-ish matching with when (not quite full on functional language powerful, and I believe that Java is not only catching up to it but making their switch quite a bit better), a standard lib that is packed full of extremely useful and consistently named methods, extension functions, delegation (if you inherited a SDK that has a piss poor interface, you can simply make a SDKWrapper(val internalSdk: SDK): SDK by internalSdk, which means that it will automatically implement it, and you can then have your wrapper do whatever around it (logging, better functions, DI, etc.))) Kotlin is truly a pleasant language, both when you don't know it (although it can look a bit symbol soup-y at times for juniors), and when you fully know it.
- origin_path 4y ago
  Just browse through the Kotlin standard library. It's basically just a set of mappings to the Java standard library with a whole lot of extension functions to make it easier to use.

quantified 4y ago

In HN a while back, an Oracle dev pointed out that the evolution is slow for a reason. Which confirmed slow. New releases every 6 months, but not that much in the way of changes. This isn't criticism of the fact of it or going into why it is or whether it should be that way. It's just a statement of fact.

Alupis 4y ago

> New Java versions are cut every six months since 2017 and since then has added a significant amount of new features And yet, the overwhelming majority of the Java community are still using JRE8 with none of these new features. There are some that love this new pace of language development, but very few are actually using new features in production code.

yardstick 4y ago
The hesitancy in jumping beyond JRE8 is the large backwards compatibility road bumps in JDK9-11, and now again with 17/JavaEE->Jakarta. I wish Java would continue to add new features but be a lot more considerate of avoiding, completely, migration headaches. We are migrating Java 8 -> 17 now and it’s been a right royal pain. I’m glad we didn’t jump to 11 LTS, and instead make one big leap. It might be a very long time before we do another LTS upgrade if they keep making poor migration choices.
- kaba0 4y ago
  The only relatively bumby migration was 8->9. After that it is a very smooth ride, and that bumpiness was the price for the accumulated tech debt/slow down from the end of the Sun era.
  - vips7L 4y ago
    8 -> 9 wasn’t that hard for me personally. For our applications it was just adding things to the build to make sure javax.xml was present. The real difficulty for us was upgrading the Play framework since the Scala community likes to make breaking changes with every release.
  - Alupis 4y ago
    Well, my understanding is (but I have yet to personally experience) the migration from 17 -> 18+ is rough because of all the javax.* packages being renamed jakarta.* Which likely means touching a pretty significant portion of your codebase for the upgrade, and then who knows what 3rd party libraries you depend on are expecting... So it may be as simple as Find/Replace for some folks, for others, it might be a deep dark rabbit hole. Not breaking things used to be Java's MO. Yes, that means a ton of legacy cruft built up over the years... but we used to be able to depend on Java to "Just Work". Perhaps some of this is necessary. After all, the C# folks seem to have no problem breaking everything to add new features... but I'd assert the Java community as a whole is much less tolerant of breaking changes and rapid deployment of features.