4 ms·

I never thought of Java being the 'move fast ~and break things~' alternative over .NET, but Java has a faster release schedule to get features out sooner.

gf000 19d ago
It's pretty much the opposite. A fixed release schedule makes development more relaxed so it can be properly done, no need to rush for some release date. If it's not yet ready, there is 6 more months to get it merged.
madduci 19d ago
Seriously, how many are using always the latest releases of Java instead the LTS ones? With LTS ones you have ~2/3 years between the versions.
- throwaway91033 19d ago
  We often use the latest version of Java at my work place. We haven't had any issues with upgrading, so there's no benefit of waiting for an LTS. There's no big process behind it either. The developers just quietly change the version as part of keeping the project up to date (BAU) It may be that we are shielded from edge cases because we are based on Spring, which is probably the most tested piece of software before new versions of Java are released. But it's my impression that the risk of upgrading to a new version of Java is not the same today as it was in the past. The only advantage of an LTS is that it is supported longer, so that you can postpone the upgrade if you really want. It's not as if the intermediate releases are inferior or less safe.
- varikin 19d ago
  At my last job, we only used LTS in production. Upgrading Java was always a long process, but that's more due a legacy monolithic app across thousands of servers. You can almost think of the LTS releases as a major release and the non-LTS as a minor release, so really this could be 25.2. The current Java release schedule is to maintain a consistent and predictable release cadence instead of pushing big new features every 6 months.
- peterashford 18d ago
  I'm always switching to the latest versions. Performance upgrades with no effort. Why wouldn't you (assuming you're not pinned by a dependency)
  - madduci 18d ago
    Privately yes, but at work getting the latest edge version isn't always the case
troupo 19d ago
> Java has a faster release schedule to get features out sooner While still being behind on most features?
- MBCook 19d ago
  To misquote Bart Simpson: > Let me get this straight: we're behind the [other languages] and we're going to catch up to them by going slower than they are? Gotta go faster if you ever wanna catch up. However, Java is also purposefully slow. Everything is extremely considered. And while it means it takes a while before you get a feature it tends to be pretty good.
- za3faran 19d ago
  Which features exactly? Java got exhaustive pattern matching before C# (through sealed interfaces), it has switch expressions, multi-line strings, green threads and structured concurrency, is getting value types, and even type classes in the work.
  - joe_mwangi 19d ago
    Typeclasses caught me by surprise. Smart move by the java team.
  - troupo 19d ago
    Granted, I havent' used either for a couple of years, so my knowledge is a little rusty. Yes, some of them are "just syntax sugar", but man oh man does it make C# such a pleasant language to work with. Used to work at a company which had services both in Java and C#, so some of Java's decisions or indecisions felt like pain points when switching between the two: - Proper IEnumerable with proper iterators that in turn enables Linq (but in general permeates everything and is insanely easy to use and build upon). E.g. building an async service that behaves like an IEnumerable? Implement two methods. Collection is halfway there, but I honestly cannot remember what was irking me about it in comparison to C#. - Properties. Yeah, yeah, sealed classes, records and all that. Often you still need plain old classes. - object initialisers. Which makes constructing anything a breeze. And on top of that you don't need manual .of methods for anything Colleciton-like if it'sa an IEnumerable. - extension methods. - named and optional arguments in functions - null coalescing operator - generics over primitive types (unless it was already implemented, I remember seeing a JEP about it) - async/await. Yes, I know: different approaches to concurrency and all that. A lot of unnecessary verbiage could still probably be hidden behind a friendlier syntax. - (sadly impossible in JVM to type erasure, only including this because I remember needing it many moons ago) generics metadata in runtime - .... definitely a bunch more I don't remember at this point ...
leapingdog 19d ago
I don't think modern Java is a 'move fast ~and break things~' environment. It's a comparatively stable platform with an enviable focus on backwards compatibility. The maintainers have talked about "last mover's advantage" when it comes to introducing new language features. Java has a checkered history when it comes to novel programming language features, so I think this is good. Granted, the maintainers are more inclined to deprecate and remove parts of the API than has historically been the case but it is mostly obsolete things like applets. And you may need to keep a close eye on runtime flags and their effects.
MaxBarraclough 19d ago
Move fast and break things does not describe Java well at all. Their process is still very deliberate, they go to some lengths to avoid getting it wrong when they add new features to the standard. New features have to get through their preview phase successfully before becoming final. [0] They're also pretty committed to not breaking existing source code or bytecode. [0] https://openjdk.org/jeps/12 https://openjdk.org/jeps/12 JEP 12: Preview Features
- wink 18d ago
  One of the releases was that, though - either 9 or 11, with the package reorgs that broke everything. OK... it wasn't fast. But Java 8 was stable (as in APIs, not judging its quality here) and since then it's gotten good again.

gf000 19d ago

It's pretty much the opposite. A fixed release schedule makes development more relaxed so it can be properly done, no need to rush for some release date. If it's not yet ready, there is 6 more months to get it merged.

madduci 19d ago

Seriously, how many are using always the latest releases of Java instead the LTS ones? With LTS ones you have ~2/3 years between the versions.

throwaway91033 19d ago
We often use the latest version of Java at my work place. We haven't had any issues with upgrading, so there's no benefit of waiting for an LTS. There's no big process behind it either. The developers just quietly change the version as part of keeping the project up to date (BAU) It may be that we are shielded from edge cases because we are based on Spring, which is probably the most tested piece of software before new versions of Java are released. But it's my impression that the risk of upgrading to a new version of Java is not the same today as it was in the past. The only advantage of an LTS is that it is supported longer, so that you can postpone the upgrade if you really want. It's not as if the intermediate releases are inferior or less safe.
varikin 19d ago
At my last job, we only used LTS in production. Upgrading Java was always a long process, but that's more due a legacy monolithic app across thousands of servers. You can almost think of the LTS releases as a major release and the non-LTS as a minor release, so really this could be 25.2. The current Java release schedule is to maintain a consistent and predictable release cadence instead of pushing big new features every 6 months.
peterashford 18d ago
I'm always switching to the latest versions. Performance upgrades with no effort. Why wouldn't you (assuming you're not pinned by a dependency)
- madduci 18d ago
  Privately yes, but at work getting the latest edge version isn't always the case

troupo 19d ago

> Java has a faster release schedule to get features out sooner While still being behind on most features?

MBCook 19d ago
To misquote Bart Simpson: > Let me get this straight: we're behind the [other languages] and we're going to catch up to them by going slower than they are? Gotta go faster if you ever wanna catch up. However, Java is also purposefully slow. Everything is extremely considered. And while it means it takes a while before you get a feature it tends to be pretty good.
za3faran 19d ago
Which features exactly? Java got exhaustive pattern matching before C# (through sealed interfaces), it has switch expressions, multi-line strings, green threads and structured concurrency, is getting value types, and even type classes in the work.
- joe_mwangi 19d ago
  Typeclasses caught me by surprise. Smart move by the java team.
- troupo 19d ago
  Granted, I havent' used either for a couple of years, so my knowledge is a little rusty. Yes, some of them are "just syntax sugar", but man oh man does it make C# such a pleasant language to work with. Used to work at a company which had services both in Java and C#, so some of Java's decisions or indecisions felt like pain points when switching between the two: - Proper IEnumerable with proper iterators that in turn enables Linq (but in general permeates everything and is insanely easy to use and build upon). E.g. building an async service that behaves like an IEnumerable? Implement two methods. Collection is halfway there, but I honestly cannot remember what was irking me about it in comparison to C#. - Properties. Yeah, yeah, sealed classes, records and all that. Often you still need plain old classes. - object initialisers. Which makes constructing anything a breeze. And on top of that you don't need manual .of methods for anything Colleciton-like if it'sa an IEnumerable. - extension methods. - named and optional arguments in functions - null coalescing operator - generics over primitive types (unless it was already implemented, I remember seeing a JEP about it) - async/await. Yes, I know: different approaches to concurrency and all that. A lot of unnecessary verbiage could still probably be hidden behind a friendlier syntax. - (sadly impossible in JVM to type erasure, only including this because I remember needing it many moons ago) generics metadata in runtime - .... definitely a bunch more I don't remember at this point ...

leapingdog 19d ago

I don't think modern Java is a 'move fast ~and break things~' environment. It's a comparatively stable platform with an enviable focus on backwards compatibility. The maintainers have talked about "last mover's advantage" when it comes to introducing new language features. Java has a checkered history when it comes to novel programming language features, so I think this is good. Granted, the maintainers are more inclined to deprecate and remove parts of the API than has historically been the case but it is mostly obsolete things like applets. And you may need to keep a close eye on runtime flags and their effects.

MaxBarraclough 19d ago

Move fast and break things does not describe Java well at all. Their process is still very deliberate, they go to some lengths to avoid getting it wrong when they add new features to the standard. New features have to get through their preview phase successfully before becoming final. [0] They're also pretty committed to not breaking existing source code or bytecode. [0] https://openjdk.org/jeps/12 https://openjdk.org/jeps/12 JEP 12: Preview Features

wink 18d ago
One of the releases was that, though - either 9 or 11, with the package reorgs that broke everything. OK... it wasn't fast. But Java 8 was stable (as in APIs, not judging its quality here) and since then it's gotten good again.