4 ms·

It's like desktop Windows, server Linux or Android of programming languages. So big it does not need to be good or innovative.

marginalia_nu 3y ago
The slow rate of change is arguably the biggest selling point for Java. You don't need to waste time on language churn, can spend the entire time building stuff instead.
- cesarb 3y ago
  > The slow rate of change is arguably the biggest selling point for Java. Unfortunately, since Java 9 the rate of change seems to have increased a lot. > You don't need to waste time on language churn, can spend the entire time building stuff instead. In my experience, every time you upgrade to a new Java LTS, either something breaks or a library you depend on is incompatible with that Java LTS, and you have to waste some time fixing the breakage (the most recent one I saw: latest Mockito is incompatible with Java 21, unless you set a magic system property).
  - lbalazscs 3y ago
    The latest Mockito works with Java 21; you'll just see a warning about the usage of the bytebuddy agent. In the future, you'll need to explicitly approve the loading of agents (you can call it "magic"), which will improve the security of your programs.
    - cesarb 3y ago
      > The latest Mockito works with Java 21 That was not the case a couple of days ago when I last looked; I see now that they released Mockito 5.7.0 two days ago, which probably fixes this issue. But that still shows my point: for every new Java LTS, you have to either fix some breakage, or update some library you depend on to a new version (which might then require further changes to your code, or even dropping compatibility with some older Java LTS). Edit: I just tried with the latest Mockito (5.7.0), and it still gave me the same "Java 21 (65) is not supported by the current version" error, when run without the magic system property. It seems something else earlier in the dependencies had a dependency on an older release of byte-buddy, so I will have to manually upgrade byte-buddy, and hope that it doesn't break that earlier dependency.
      - marginalia_nu 3y ago
        I haven't really experienced this. I'm on Java 21 and haven't had any problems with Mockito what so ever. I needed to bump the version of guice, but beyond that it was a very smooth transition.
      - krzyk 3y ago
        You have to update dependencies that depend on bytecode, like ASM, bytebuddy or aspectj. Those deps upgrades in 99% cases don't break the library that uses them. I upgraded to JDK 21 on the day of release and haven't had issues with mockito (or spring, hibernate, junit, etc.)
  - krzyk 3y ago
    > Unfortunately, since Java 9 the rate of change seems to have increased a lot. Since Java 9, they don't introduce changes, they introduce new features which is a bit different. IT is a field that (should) attract people that are for fast paced environments, not old school slow-to-innovate industries.
  - samus 3y ago
    Since Java 9, new features are finally coming again. However, the ecosystem had gotten reliant on certain JDK internals being accessible and stable, while in fact they were neither. That will require some more years to properly transition over. The only feature that really got obsoleted is the Security Manager and the underscore variable name. Primitive wrapper class constructors are on the chopping block next. Most other things are merely being restricted to harden the platform, with ample time to prepare. Edit: LTS hopping is probably an unwise strategy as one will harvest only disadvantages: few updates, no performance improvements, no new features, and complicated migrations when it is time to upgrade. One best upgrades as soon as the new version becomes available (as people did before Java 8) or stays on LTS until the software is retired.
pron 3y ago
It's not about that. 1. The rate of change that the industry demands of super-popular languages is not the same rate that PL fans demand. Java innovates a lot in, e.g., GC algorithms and low-overhead profiling because there's more demand for more rapid innovation in those areas than in language features. Java's strategy from day one is to have an innovative runtime and a conservative language (James Gosling called it "a wolf in sheep's clothing") under the assumption that that's what the industry wants. So far, that strategy has worked very well. 2. Because Java will likely continue to be super-popular for many years to come, it's more important to avoid introducing harmful features than to introduce beneficial ones. If you've introduced a "good" feature five years after a less popular language introduced it, you've only lost five years of possible slightly better productivity; if you're introducing a "harmful" feature, you've harmed your language for decades to come. Super successful language need to think more more long-term than languages vying for more users right now.
- foobarian 3y ago
  I feel that there is a particular "race horse" mindset when it comes to programming languages. It's very academic - for a thing to be good, it needs to have novel, never before implemented features, it needs to have intellectually superior properties, it needs to have them first, etc. I used to think more this way in school. It leads one to view the world as two camps: the language makers, who compete with the best new features in order to woo the language users (the industry). This results in being disappointed and puzzled that the language users consistently ignore the new shiny stuff and pick an ostensibly boring unsexy choice. However languages are not startup companies trying to sell a product, it's the other way around. The popular ones are largely driven by industry to suit the industry needs, which are largely very conservative. Nobody wants another Perl 6 or Python 3.
- Tainnor 3y ago
  I don't think it's fair to couch this in terms of opposition to "breakneck speed" language development. Even when Java was created, many languages supported FP, but Java chose not to. They had to retrofit it in many years later and it's still awkward to use compared to many other languages (not just ones created in the last 10 years).

marginalia_nu 3y ago

The slow rate of change is arguably the biggest selling point for Java. You don't need to waste time on language churn, can spend the entire time building stuff instead.

cesarb 3y ago
> The slow rate of change is arguably the biggest selling point for Java. Unfortunately, since Java 9 the rate of change seems to have increased a lot. > You don't need to waste time on language churn, can spend the entire time building stuff instead. In my experience, every time you upgrade to a new Java LTS, either something breaks or a library you depend on is incompatible with that Java LTS, and you have to waste some time fixing the breakage (the most recent one I saw: latest Mockito is incompatible with Java 21, unless you set a magic system property).
- lbalazscs 3y ago
  The latest Mockito works with Java 21; you'll just see a warning about the usage of the bytebuddy agent. In the future, you'll need to explicitly approve the loading of agents (you can call it "magic"), which will improve the security of your programs.
  - cesarb 3y ago
    > The latest Mockito works with Java 21 That was not the case a couple of days ago when I last looked; I see now that they released Mockito 5.7.0 two days ago, which probably fixes this issue. But that still shows my point: for every new Java LTS, you have to either fix some breakage, or update some library you depend on to a new version (which might then require further changes to your code, or even dropping compatibility with some older Java LTS). Edit: I just tried with the latest Mockito (5.7.0), and it still gave me the same "Java 21 (65) is not supported by the current version" error, when run without the magic system property. It seems something else earlier in the dependencies had a dependency on an older release of byte-buddy, so I will have to manually upgrade byte-buddy, and hope that it doesn't break that earlier dependency.
    - marginalia_nu 3y ago
      I haven't really experienced this. I'm on Java 21 and haven't had any problems with Mockito what so ever. I needed to bump the version of guice, but beyond that it was a very smooth transition.
    - krzyk 3y ago
      You have to update dependencies that depend on bytecode, like ASM, bytebuddy or aspectj. Those deps upgrades in 99% cases don't break the library that uses them. I upgraded to JDK 21 on the day of release and haven't had issues with mockito (or spring, hibernate, junit, etc.)
- krzyk 3y ago
  > Unfortunately, since Java 9 the rate of change seems to have increased a lot. Since Java 9, they don't introduce changes, they introduce new features which is a bit different. IT is a field that (should) attract people that are for fast paced environments, not old school slow-to-innovate industries.
- samus 3y ago
  Since Java 9, new features are finally coming again. However, the ecosystem had gotten reliant on certain JDK internals being accessible and stable, while in fact they were neither. That will require some more years to properly transition over. The only feature that really got obsoleted is the Security Manager and the underscore variable name. Primitive wrapper class constructors are on the chopping block next. Most other things are merely being restricted to harden the platform, with ample time to prepare. Edit: LTS hopping is probably an unwise strategy as one will harvest only disadvantages: few updates, no performance improvements, no new features, and complicated migrations when it is time to upgrade. One best upgrades as soon as the new version becomes available (as people did before Java 8) or stays on LTS until the software is retired.

pron 3y ago

It's not about that. 1. The rate of change that the industry demands of super-popular languages is not the same rate that PL fans demand. Java innovates a lot in, e.g., GC algorithms and low-overhead profiling because there's more demand for more rapid innovation in those areas than in language features. Java's strategy from day one is to have an innovative runtime and a conservative language (James Gosling called it "a wolf in sheep's clothing") under the assumption that that's what the industry wants. So far, that strategy has worked very well. 2. Because Java will likely continue to be super-popular for many years to come, it's more important to avoid introducing harmful features than to introduce beneficial ones. If you've introduced a "good" feature five years after a less popular language introduced it, you've only lost five years of possible slightly better productivity; if you're introducing a "harmful" feature, you've harmed your language for decades to come. Super successful language need to think more more long-term than languages vying for more users right now.

foobarian 3y ago
I feel that there is a particular "race horse" mindset when it comes to programming languages. It's very academic - for a thing to be good, it needs to have novel, never before implemented features, it needs to have intellectually superior properties, it needs to have them first, etc. I used to think more this way in school. It leads one to view the world as two camps: the language makers, who compete with the best new features in order to woo the language users (the industry). This results in being disappointed and puzzled that the language users consistently ignore the new shiny stuff and pick an ostensibly boring unsexy choice. However languages are not startup companies trying to sell a product, it's the other way around. The popular ones are largely driven by industry to suit the industry needs, which are largely very conservative. Nobody wants another Perl 6 or Python 3.
Tainnor 3y ago
I don't think it's fair to couch this in terms of opposition to "breakneck speed" language development. Even when Java was created, many languages supported FP, but Java chose not to. They had to retrofit it in many years later and it's still awkward to use compared to many other languages (not just ones created in the last 10 years).