5 ms·

C# dev here: it’s amazing how different this is from a Microsoft release. First off, Oracle are doing versions at approximately twice the cadence. But also, and

by moomin 19d ago

C# dev here: it’s amazing how different this is from a Microsoft release. First off, Oracle are doing versions at approximately twice the cadence. But also, and I’m guessing this is a function of the much larger Java audience: things rarely get two preview versions in a proper release. Updates in beta versions, yes, all the time. It also feels like Microsoft are bundling a lot more into the platform and leaving less to the community. Again, probably an artifact of the different sizes of the communities. Also, the page reads like an open source “We’re finished, we’re tired.” announcement rather than the razzmatazz of a Microsoft release.

theandrewbailey 19d ago
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 18d 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 17d 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.
kllrnohj 19d ago
> First off, Oracle are doing versions at approximately twice the cadence Is that actually a good thing? But Oracle started playing a game, for better or worse, where they decided to couple the "language version" with a single specific runtime's release schedule. For example, in "Java 27" there are exactly 0 language changes and 1 minor feature addition to the TLS library. Everything else is OpenJDK runtime internals which don't impact the language or how you use it. So if you don't use OpenJDK (such as if you use Oracle's other runtime, GraalVM), then Java 27 basically doesn't even exist at all. Skimming the past couple of C# releases, it doesn't look like Microsoft is playing that game, so the release cadence will of course be different.
- hyperpape 19d ago
  You’re only counting JEPs, which are only for more involved features. There are lots of changes to the JDK apis that are used by other runtimes. See, for instance: https://javaalmanac.io/jdk/27/apidiff/26/ https://javaalmanac.io/jdk/27/apidiff/26/. Admittedly, the terminology here is almost designed to be maximally confusing, and I’ve never read a good post that laid out how everything relates.
  - kllrnohj 19d ago
    Fair, although even there I don't know if I'd call that "lots" at just 23 added or modified methods that aren't in preview
    - hyperpape 19d ago
      There are also bug-fixes and performance improvements that are not going to show on the page I linked. I do think it’s plausible this is a smaller release. Not that this was the real point of the discussion, but I think it’s still just a good idea to have more than one release a year. It keeps things moving smoothly, and lowers the cost of missing a release, which has beneficial effects.
      - flakes 19d ago
BatchJob 19d ago
razzmatazz? Do you mean marketing lies and self aggrandizement for merely doing shoddy work?
- jayd16 19d ago
  Mads Torgersen's previews and such are enjoyable and upbeat, for example.
petilon 19d ago
> Microsoft are bundling a lot more into the platform and leaving less to the community. This is a good thing. In Java everything has multiple community offerings, so before doing anything you have to evaluate the community offerings and decide which one to go with. If you go with the wrong one you may end up having to switch at some point, and that can be painful. This happens so often that most of the time spent when using Java is doing these evaluations and comparisons. With C# you just use the one built into .NET platform. Saves a ton of time.
- throwaway91033 19d ago
  If someone wants to create a project by assembling bits and pieces from different open source products they can, but many just go for Spring (Boot) and call it a day. All of my projects are based on Spring and I don't really have to look outside of that ecosystem. It almost acts as an aggregator of different open source solutions and often works by abstracting the functionality so that differences are not that big. I recently switched messaging providers and didn't have to change much of my code.
  - rwyinuse 19d ago
    Yep, with Spring Boot development is so easy, and even decade old projects are mostly easy to upgrade. I don't have experience from C# or .NET development, but at least compared to Python and especially JS ecosystems it's so much better.
    - hirvi74 19d ago
      > Python and especially JS ecosystems it's so much better. That's a pretty low bar to beat.
      - PaulHoule 19d ago
        10 years ago I was working at a place that was building Python systems that had dependency graphs too complicated for pip to handle. I was able to solve the problem for my system with a "wheelhouse" system that could compute a list of wheels that could be installed to build it but the confidence of my team in Python had flagged. I had a sheaf of notes about the problem and figured out the math to build a proper dependency resolver for Python and tested out a lot of ideas such as being able to use http range requests to get the metadata out of wheels on PyPi without having to download the whole wheel. The problem I had no solution for though was "how to stop developers from trashing the environment that the dependency manager runs in." The data scientists I worked with had an astonishing target for wrecking anything at all. Myself I would have my poetry's environment got bad for reasons I didn't understand every few months ago. I also found the Python community just didn't care that pip didn't really work right. The most seductive form of blub is "I can accept using things that fail intermittently." I got a job coding Java and Javascript and never built the package manager. Then uv came along and managed to sell itself as "crazy fast" which did connect with people more than "correct". Written in rust, uv would have beaten my system in the fast department, and since it is a binary, there is no way anyone can screw up a Python it depends on -- as I see it, both technical and marketing genius!
Phelinofist 19d ago
> Also, the page reads like an open source “We’re finished, we’re tired.” I mean it's short and concise and there are additional resources that provide more detail. IMHO it's not a bad thing.
Betelbuddy 19d ago
>> Oracle are doing versions at approximately twice the cadence. This has nothing to do with Oracle. All good that you hear from Java in the last few years, is the great community and good old people from Sun working at Oracle.
- grodriguez100 19d ago
  “The good old people from Sun working at Oracle” is now Oracle as well.
- GrumpyGoblin 19d ago
  Someone doesn't know their Java history. Oracle bought Java 16 years ago in 2010. At that time Sun had been working on Java 7 for over 4 years with no release date in sight. Oracle trimmed the fat and released Java 7 in less than a year. And since then has kept a regular release cadence. Sun would probably still be working on Java 7.
  - Romario77 19d ago
    it wasn't about Oracle trimming the fat. Java 8 took 3 years to release and then Java 9 another 3 years. They had to commit to half a year release cycles and LTRs every 2 years. Since then the releases became a lot more predictable. Whatever is not ready is not released (or is there as a preview feature). This more agile approach is a lot better in my experience and we see that the changes made are more relevant and what people actually want.
hirvi74 19d ago
I kind of wish C# would slowdown releases in some areas. I have not been a huge fan of some of the changes in the past year. I love the performance changes and bits of functionality here and there, but the syntax-sugar is getting annoying.
- kittoes 19d ago
  Interesting take, how is optional functionality annoying? Isn't the fact that it's just sugar a huge benefit? Us old timers can simply stick to what we're familiar with.
  - pjc50 19d ago
    I don't get this either. You can even lock the language level if you really don't want it, or you can just ignore it.
  - fourseventy 19d ago
    Because unless you are the only person maintaining your codebase other people in your organization will start using the cool new syntax sugar and optional functionality. So you will be forced to deal with it as it starts showing up in your codebase.
    - samus 18d ago
      I'm sure that there is a tool like Checkstyle that can be used to ban features.
  - hirvi74 19d ago
    (GP here) > Isn't the fact that it's just sugar a huge benefit? My main gripe is that I cannot remember what is allowed and not allowed between multiple versions of the same language. On a daily basis I hop between apps versioned in .NET Framework 4.8 all the way to .NET 10. I have to constant remember, are nullable types allowed here? What about 'new(); vs. new Object();', new collection syntax, new switch syntax, new extensions syntax, etc.. Plus, I just find it obnoxious that the same thing can be written so many different ways. I can think of 7 ways to assign a new empty List<T>. List<T> foo = new List<T>(); var foo = new List<T>(); List<T> foo = new(); List<T> foo = new List<T> { }; var foo = new List<T> { }; List<T> foo = []; var foo = (List<T>)[]; There are probably more that I am forgetting. What irks me most is Java is older than C#, and from what I can remember, it is not nearly this ridiculous in terms of syntactical sugar. So, what is the true benefit behind all this sugar? It hardly saves any keystrokes in the age of autocomplete in IDEs. I am inclined to believe most of the sugar is an attempt to make the language appeal to a newer generations of programmers. But I would argue features are more attractive than syntactical sugar. I believe Rust is truly impressive language. In my opinion, its syntax is uglier than sin, but that does not seem to deter many from using Rust.
32oqa9 19d ago
It's a normal open source announcement without the corporate bullshit. No fatigue. No doom. Just facts! /s
derefr 19d ago
> Also, the page reads like an open source “We’re finished, we’re tired.” announcement rather than the razzmatazz of a Microsoft release. I think this is because the JRE/JDK upstream releases are a bit like Linux kernel releases: all the major first-party feature development goes on in subprojects that maintain their own "living forks" during feature development, with the teams on these features doing PRs against the fork's own "main"; that "fork's main" having its own subproject maintainers who ensure a mess isn't made of it; and then those maintainers eventually polishing up that fork-main into a single big one-shot PR to upstream once the feature-as-a-whole is ready. (Compare/contrast: the Linux kernel's mm, rt, and kvm feature development efforts.) Because of this, the top-level "project maintainers" (i.e. the people who decide what gets merged into upstream main) aren't really the same people as these subproject people who care deeply about these new features. They want to ship stuff people want, but they personally mostly deal all day with requests to merge 1. small bugfixes, and 2. features so small that no JEP is needed. But then, every once in a while, they have to deal with a request to merge one of these huge subproject upstreaming PRs. And sure, it's already heavily reviewed by the subproject's maintainers, who they trust. But they do still have to audit it and learn it and create a stabilized release path for it. "Handover" stuff. And that's tiring! So, given that the toplevel project maintainers write the release notes, I'm not surprised they come off as weary about releases. (That being said, for purely PR reasons, the toplevel maintainers could ask the subproject staff to contribute their perspective to the release notes of a release that merges their work? But this could also just-as-well be a separate blog post—which would probably be better for sharing. I don't think I've ever seen a centralized Java blog [is there one?] but I think the subproject teams do tend to have them.)
Romario77 19d ago
the release cycle time was a deliberate choice. Java tried to do fairly large updates and sometimes the release cycle would be very unpredictable as things would slip and take much longer than anticipated. So to make it more predictable and to keep updates coming they switched to 6 months cadence with long term support (LTS) every two years. This I think is a pretty good way of doing things, makes people who plan things figure out how to split feature development into these 6 months cycles, it made JEPs more granular and I think it made project Valhalla possible, if they tried doing it the old way it would never happen. Splitting things in small chunks clarified what needs to be done and the path forward. It still takes very long time, but doesn't cause big incompatible changes and I think overall Java has good progress without being stalled.
- dcminter 19d ago
  I remember Dolphin being a particularly painful one, and as I recall it ended up with some weird compromises (wasn't erasure supposed to avoid needing to update the bytecode format, but then annotations required it anyway? Something along those lines)
  - Romario77 19d ago
    yeah - they took forever, one reason being that Sun was in financial troubles and then acquisition took a long time. Second was about licensing and Apache Harmony. So, eventually they dropped most of the big things that were planned - Project Lambda with closures, Project Jigsaw with modularisation, Collection Literals. They eventually came back, but took a while to implement, so it was a prudent decision to make.
dcminter 19d ago
Java releases used to be glacial multi-year affairs. Lots of discussion of features that then missed the release train and you knew they'd not be with you for another multi-year period. They made a conscious decision to switch to a regular six-month cadence and it's been all the better for it. The preview-mechanism has been terrific there too, allowing half-baked features to be aired without absolutely committing to something that turns out to be flawed. Edit: Ninja-ed by Romario77's sibling comment :)
PaulHoule 19d ago
One difference I think about is generics. Java and .NET bolted generics on to an existing system. Java used type erasure in such a way that a List<OfThat> is really just a List. Type erasure has a lot of limitations. If I am coding in Java for days I never get into trouble with it because I know how to color in the lines. But do some balls-to-the-walls metaprogramming and then it is annoying that you can't write Expression<Integer> add(Expression<Integer> a, Expression<Integer> b); Expression<Double> add(Expression<Double> a, Expression<Double> b); because in the end they both look like Expression add(Expression a, Expression b) we have ways to cope, like unerasing the types by rewriting the names... And now you've got a reason to do balls to the walls metaprogramming! Similarly if I do a lot of C# or Scala or something I will get into the habit of doing things I can't do in Java. .NET on the other hand did not keep backwards compatibility, so a List is not a List<X> so .NET had a schism where some API functions use generic collections and others use non-generics which was annoying in its own way. Something like that is how all methods in Java are virtual whereas methods in C# may or not be virtual. All-virtual is probably not the best for performance, but it is simple for understanding. You never have to think "do I make this virtual or not?" or think "is that method virtual or not and does that have consequences for how I use it?"
- za3faran 19d ago
  This should address your example https://openjdk.org/jeps/218 https://openjdk.org/jeps/218
  - PaulHoule 19d ago
    I am looking forward to it, and many other things planned for Java!
  - AgentME 19d ago
    That's about letting you do Expression<int>, not about removing type erasure or otherwise allowing overloads based on type parameters.
    - gf000 18d ago
pjmlp 19d ago
Polyglot dev here, that uses both ecosystems, Java since 1996, .NET before it was announced to the public in 2001, only available to selected Microsoft partners. A big difference between both ecosystems is that the Java world is like C and C++, even though Java isn't defined by ISO or ECMA, since Sun days the main implementation is only a reference, there are official documents for everything, and there is a plethora of implementations, with various kinds of JIT, GC and AOT approaches. You can pick the real time versions for embedded from PTC and Aicas, the cloud first from IBM and Azul with finance markets in mind, the Android cousin, the various implementations for M2M gateways, copiers and phone dashboards (Ricoh, Xerox, Cisco), IoT with microEJ, and many more. Whereas Microsoft hardly cares about ECMA nowadays, most of Mono/Xamarin is gone replaced by Core CLR and modern .NET, .NET Compact is gone, community maintained and so on. That alone, regardless of the languages on top of JVM, or CLR, makes a big difference on the audiences when one silos themselves to a single ecosystem.
- bel8 19d ago
  interesting. So less specialization on one side but also less fragmentation.
hitekker 19d ago
> the page reads like an open source “We’re finished, we’re tired.” rather than the razzmatazz of a Microsoft release. The vibe selects the audience perhaps. People who are tired and just want to finish their work like the first style. People who want to do more cool work more quickly, maybe without finishing, like the second. Depends on the work, I suppose.
roflburger 19d ago
Because there is nothing in it, that's why this release, along with majority of the recent ones drop like wet farts. How many previews of the vector API would you like?
- samus 18d ago
  I read nine JEPs. Sure, some are re-Previews, but they are important since they often contain improvements from community feedback. Specifically, it would be quite unwise to finalize the Vector API before Project Valhalla. Apart from that, I'm sure that there are lots of minor visible changes that didn't get a JEP. Anyway, not every release can be filled to the brim with new features, and people were also kinda busy whipping Project Valhalla into shape. INHO it's still preferable to stick to a predictable schedule instead of creating uncertainty in the community.
Areading314 19d ago
> Java 27: “We’re finished, we’re tired.” Seems about right
_the_inflator 18d ago
I worked at a MS "fanboy" company around 2011-2013. Highly competent guys, really Senior Devs, C#, MS SQL, as well as using graph data - with one distinction: it must be MS. Open Source? No way. Git? No, they relied as die hard MS believers on the MS software called Team Foundation or something like that, that was integrated into Visual Studio Pro - sorry, I forgot about it, I considered it kind of bloat and outdated. Also I couldn't stand the nomenclature. A project was called "Solution" - I died inside, because this sounded like utter nonsense to me, because how do they know it would be one in the end? While JetBrains as well as Linux quickly iterated through everything and got traction as well as a cadence that overall kind of was paced around sprint cycles that lasted two or four weeks, the company finally started to break up with project management and implemented Scrum. As the JavaScript guy, the only one, because a customer wanted a SaaS "solution" but with static web content this wasn't really dynamic. I knew one of the founders who was a managing partner and he asked me to join as Web Developer. Overall, all were very skeptical towards me because how could someone bet on JavaScript at the time? Well I turned the argument around and said the same about C# with its closed source walled garden approach to everything relying on MS to solve their problems with no way of giving feedback while there was no real release cycle and roadmap available - hopium and copium. Statically typed languages for the win they said, blabla. I wasn't against static types, but did pure magic in JS, that they saw me as magician and I got some fans and I found one team mate who wanted to be coached by me on JS, Ajax and stuff. So, there you have it. History. I think there are pros and cons to any approach as always. Both language suffer from feature creep. C# is still tightly knit into some products from MS and there are some backwards compatibility issues to take care of that limit certain progress and need substantial change. Java isn't that way and was near dead and went OS. That's why they moved to the current model. Former versions were also hardly changed, have a look at everything before Java Version 12 or so. Java wasn't community driven all the time. So, C# has its merits, TypeScript for the win, so MS won over JavaScript ironically but only on the outside. I shocked my MS fanboy colleagues when I really gave them a shock therapy regarding security when they mocked me with the examples given by MS why JavaScript was so bad and C# would beat it. We all know the infamous type coercion examples with mixed types, arrays etc. So I shocked them with eval function of course but then gave them nightmares and mental overload with Function.prototype.toString and new Function() trickery. It blew their mind, there was nothing remotely available in their world. Not introspection, nothing. JavaScript was kind of assembler like I said. Highly flexible, you need to use modules, like jQuery did but have to build your own. So TypeScript used exactly this flexibility: compiling to JavaScript. A metalanguage. For the true insider, JavaScript won.

by moomin 19d ago

theandrewbailey 19d ago

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 18d 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 17d 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.

kllrnohj 19d ago

> First off, Oracle are doing versions at approximately twice the cadence Is that actually a good thing? But Oracle started playing a game, for better or worse, where they decided to couple the "language version" with a single specific runtime's release schedule. For example, in "Java 27" there are exactly 0 language changes and 1 minor feature addition to the TLS library. Everything else is OpenJDK runtime internals which don't impact the language or how you use it. So if you don't use OpenJDK (such as if you use Oracle's other runtime, GraalVM), then Java 27 basically doesn't even exist at all. Skimming the past couple of C# releases, it doesn't look like Microsoft is playing that game, so the release cadence will of course be different.

hyperpape 19d ago
You’re only counting JEPs, which are only for more involved features. There are lots of changes to the JDK apis that are used by other runtimes. See, for instance: https://javaalmanac.io/jdk/27/apidiff/26/ https://javaalmanac.io/jdk/27/apidiff/26/. Admittedly, the terminology here is almost designed to be maximally confusing, and I’ve never read a good post that laid out how everything relates.
- kllrnohj 19d ago
  Fair, although even there I don't know if I'd call that "lots" at just 23 added or modified methods that aren't in preview
  - hyperpape 19d ago
    There are also bug-fixes and performance improvements that are not going to show on the page I linked. I do think it’s plausible this is a smaller release. Not that this was the real point of the discussion, but I think it’s still just a good idea to have more than one release a year. It keeps things moving smoothly, and lowers the cost of missing a release, which has beneficial effects.
    - flakes 19d ago

BatchJob 19d ago

razzmatazz? Do you mean marketing lies and self aggrandizement for merely doing shoddy work?

jayd16 19d ago
Mads Torgersen's previews and such are enjoyable and upbeat, for example.

petilon 19d ago

> Microsoft are bundling a lot more into the platform and leaving less to the community. This is a good thing. In Java everything has multiple community offerings, so before doing anything you have to evaluate the community offerings and decide which one to go with. If you go with the wrong one you may end up having to switch at some point, and that can be painful. This happens so often that most of the time spent when using Java is doing these evaluations and comparisons. With C# you just use the one built into .NET platform. Saves a ton of time.

throwaway91033 19d ago
If someone wants to create a project by assembling bits and pieces from different open source products they can, but many just go for Spring (Boot) and call it a day. All of my projects are based on Spring and I don't really have to look outside of that ecosystem. It almost acts as an aggregator of different open source solutions and often works by abstracting the functionality so that differences are not that big. I recently switched messaging providers and didn't have to change much of my code.
- rwyinuse 19d ago
  Yep, with Spring Boot development is so easy, and even decade old projects are mostly easy to upgrade. I don't have experience from C# or .NET development, but at least compared to Python and especially JS ecosystems it's so much better.
  - hirvi74 19d ago
    > Python and especially JS ecosystems it's so much better. That's a pretty low bar to beat.
    - PaulHoule 19d ago
      10 years ago I was working at a place that was building Python systems that had dependency graphs too complicated for pip to handle. I was able to solve the problem for my system with a "wheelhouse" system that could compute a list of wheels that could be installed to build it but the confidence of my team in Python had flagged. I had a sheaf of notes about the problem and figured out the math to build a proper dependency resolver for Python and tested out a lot of ideas such as being able to use http range requests to get the metadata out of wheels on PyPi without having to download the whole wheel. The problem I had no solution for though was "how to stop developers from trashing the environment that the dependency manager runs in." The data scientists I worked with had an astonishing target for wrecking anything at all. Myself I would have my poetry's environment got bad for reasons I didn't understand every few months ago. I also found the Python community just didn't care that pip didn't really work right. The most seductive form of blub is "I can accept using things that fail intermittently." I got a job coding Java and Javascript and never built the package manager. Then uv came along and managed to sell itself as "crazy fast" which did connect with people more than "correct". Written in rust, uv would have beaten my system in the fast department, and since it is a binary, there is no way anyone can screw up a Python it depends on -- as I see it, both technical and marketing genius!

Phelinofist 19d ago

> Also, the page reads like an open source “We’re finished, we’re tired.” I mean it's short and concise and there are additional resources that provide more detail. IMHO it's not a bad thing.

Betelbuddy 19d ago

>> Oracle are doing versions at approximately twice the cadence. This has nothing to do with Oracle. All good that you hear from Java in the last few years, is the great community and good old people from Sun working at Oracle.

grodriguez100 19d ago
“The good old people from Sun working at Oracle” is now Oracle as well.
GrumpyGoblin 19d ago
Someone doesn't know their Java history. Oracle bought Java 16 years ago in 2010. At that time Sun had been working on Java 7 for over 4 years with no release date in sight. Oracle trimmed the fat and released Java 7 in less than a year. And since then has kept a regular release cadence. Sun would probably still be working on Java 7.
- Romario77 19d ago
  it wasn't about Oracle trimming the fat. Java 8 took 3 years to release and then Java 9 another 3 years. They had to commit to half a year release cycles and LTRs every 2 years. Since then the releases became a lot more predictable. Whatever is not ready is not released (or is there as a preview feature). This more agile approach is a lot better in my experience and we see that the changes made are more relevant and what people actually want.

hirvi74 19d ago

I kind of wish C# would slowdown releases in some areas. I have not been a huge fan of some of the changes in the past year. I love the performance changes and bits of functionality here and there, but the syntax-sugar is getting annoying.

kittoes 19d ago
Interesting take, how is optional functionality annoying? Isn't the fact that it's just sugar a huge benefit? Us old timers can simply stick to what we're familiar with.
- pjc50 19d ago
  I don't get this either. You can even lock the language level if you really don't want it, or you can just ignore it.
- fourseventy 19d ago
  Because unless you are the only person maintaining your codebase other people in your organization will start using the cool new syntax sugar and optional functionality. So you will be forced to deal with it as it starts showing up in your codebase.
  - samus 18d ago
    I'm sure that there is a tool like Checkstyle that can be used to ban features.
- hirvi74 19d ago
  (GP here) > Isn't the fact that it's just sugar a huge benefit? My main gripe is that I cannot remember what is allowed and not allowed between multiple versions of the same language. On a daily basis I hop between apps versioned in .NET Framework 4.8 all the way to .NET 10. I have to constant remember, are nullable types allowed here? What about 'new(); vs. new Object();', new collection syntax, new switch syntax, new extensions syntax, etc.. Plus, I just find it obnoxious that the same thing can be written so many different ways. I can think of 7 ways to assign a new empty List<T>. List<T> foo = new List<T>(); var foo = new List<T>(); List<T> foo = new(); List<T> foo = new List<T> { }; var foo = new List<T> { }; List<T> foo = []; var foo = (List<T>)[]; There are probably more that I am forgetting. What irks me most is Java is older than C#, and from what I can remember, it is not nearly this ridiculous in terms of syntactical sugar. So, what is the true benefit behind all this sugar? It hardly saves any keystrokes in the age of autocomplete in IDEs. I am inclined to believe most of the sugar is an attempt to make the language appeal to a newer generations of programmers. But I would argue features are more attractive than syntactical sugar. I believe Rust is truly impressive language. In my opinion, its syntax is uglier than sin, but that does not seem to deter many from using Rust.

32oqa9 19d ago

It's a normal open source announcement without the corporate bullshit. No fatigue. No doom. Just facts! /s

derefr 19d ago

> Also, the page reads like an open source “We’re finished, we’re tired.” announcement rather than the razzmatazz of a Microsoft release. I think this is because the JRE/JDK upstream releases are a bit like Linux kernel releases: all the major first-party feature development goes on in subprojects that maintain their own "living forks" during feature development, with the teams on these features doing PRs against the fork's own "main"; that "fork's main" having its own subproject maintainers who ensure a mess isn't made of it; and then those maintainers eventually polishing up that fork-main into a single big one-shot PR to upstream once the feature-as-a-whole is ready. (Compare/contrast: the Linux kernel's mm, rt, and kvm feature development efforts.) Because of this, the top-level "project maintainers" (i.e. the people who decide what gets merged into upstream main) aren't really the same people as these subproject people who care deeply about these new features. They want to ship stuff people want, but they personally mostly deal all day with requests to merge 1. small bugfixes, and 2. features so small that no JEP is needed. But then, every once in a while, they have to deal with a request to merge one of these huge subproject upstreaming PRs. And sure, it's already heavily reviewed by the subproject's maintainers, who they trust. But they do still have to audit it and learn it and create a stabilized release path for it. "Handover" stuff. And that's tiring! So, given that the toplevel project maintainers write the release notes, I'm not surprised they come off as weary about releases. (That being said, for purely PR reasons, the toplevel maintainers could ask the subproject staff to contribute their perspective to the release notes of a release that merges their work? But this could also just-as-well be a separate blog post—which would probably be better for sharing. I don't think I've ever seen a centralized Java blog [is there one?] but I think the subproject teams do tend to have them.)

Romario77 19d ago

the release cycle time was a deliberate choice. Java tried to do fairly large updates and sometimes the release cycle would be very unpredictable as things would slip and take much longer than anticipated. So to make it more predictable and to keep updates coming they switched to 6 months cadence with long term support (LTS) every two years. This I think is a pretty good way of doing things, makes people who plan things figure out how to split feature development into these 6 months cycles, it made JEPs more granular and I think it made project Valhalla possible, if they tried doing it the old way it would never happen. Splitting things in small chunks clarified what needs to be done and the path forward. It still takes very long time, but doesn't cause big incompatible changes and I think overall Java has good progress without being stalled.

dcminter 19d ago
I remember Dolphin being a particularly painful one, and as I recall it ended up with some weird compromises (wasn't erasure supposed to avoid needing to update the bytecode format, but then annotations required it anyway? Something along those lines)
- Romario77 19d ago
  yeah - they took forever, one reason being that Sun was in financial troubles and then acquisition took a long time. Second was about licensing and Apache Harmony. So, eventually they dropped most of the big things that were planned - Project Lambda with closures, Project Jigsaw with modularisation, Collection Literals. They eventually came back, but took a while to implement, so it was a prudent decision to make.

dcminter 19d ago

Java releases used to be glacial multi-year affairs. Lots of discussion of features that then missed the release train and you knew they'd not be with you for another multi-year period. They made a conscious decision to switch to a regular six-month cadence and it's been all the better for it. The preview-mechanism has been terrific there too, allowing half-baked features to be aired without absolutely committing to something that turns out to be flawed. Edit: Ninja-ed by Romario77's sibling comment :)

PaulHoule 19d ago

One difference I think about is generics. Java and .NET bolted generics on to an existing system. Java used type erasure in such a way that a List<OfThat> is really just a List. Type erasure has a lot of limitations. If I am coding in Java for days I never get into trouble with it because I know how to color in the lines. But do some balls-to-the-walls metaprogramming and then it is annoying that you can't write Expression<Integer> add(Expression<Integer> a, Expression<Integer> b); Expression<Double> add(Expression<Double> a, Expression<Double> b); because in the end they both look like Expression add(Expression a, Expression b) we have ways to cope, like unerasing the types by rewriting the names... And now you've got a reason to do balls to the walls metaprogramming! Similarly if I do a lot of C# or Scala or something I will get into the habit of doing things I can't do in Java. .NET on the other hand did not keep backwards compatibility, so a List is not a List<X> so .NET had a schism where some API functions use generic collections and others use non-generics which was annoying in its own way. Something like that is how all methods in Java are virtual whereas methods in C# may or not be virtual. All-virtual is probably not the best for performance, but it is simple for understanding. You never have to think "do I make this virtual or not?" or think "is that method virtual or not and does that have consequences for how I use it?"

za3faran 19d ago
This should address your example https://openjdk.org/jeps/218 https://openjdk.org/jeps/218
- PaulHoule 19d ago
  I am looking forward to it, and many other things planned for Java!
- AgentME 19d ago
  That's about letting you do Expression<int>, not about removing type erasure or otherwise allowing overloads based on type parameters.
  - gf000 18d ago

pjmlp 19d ago

Polyglot dev here, that uses both ecosystems, Java since 1996, .NET before it was announced to the public in 2001, only available to selected Microsoft partners. A big difference between both ecosystems is that the Java world is like C and C++, even though Java isn't defined by ISO or ECMA, since Sun days the main implementation is only a reference, there are official documents for everything, and there is a plethora of implementations, with various kinds of JIT, GC and AOT approaches. You can pick the real time versions for embedded from PTC and Aicas, the cloud first from IBM and Azul with finance markets in mind, the Android cousin, the various implementations for M2M gateways, copiers and phone dashboards (Ricoh, Xerox, Cisco), IoT with microEJ, and many more. Whereas Microsoft hardly cares about ECMA nowadays, most of Mono/Xamarin is gone replaced by Core CLR and modern .NET, .NET Compact is gone, community maintained and so on. That alone, regardless of the languages on top of JVM, or CLR, makes a big difference on the audiences when one silos themselves to a single ecosystem.

bel8 19d ago
interesting. So less specialization on one side but also less fragmentation.

hitekker 19d ago

> the page reads like an open source “We’re finished, we’re tired.” rather than the razzmatazz of a Microsoft release. The vibe selects the audience perhaps. People who are tired and just want to finish their work like the first style. People who want to do more cool work more quickly, maybe without finishing, like the second. Depends on the work, I suppose.

roflburger 19d ago

Because there is nothing in it, that's why this release, along with majority of the recent ones drop like wet farts. How many previews of the vector API would you like?

samus 18d ago
I read nine JEPs. Sure, some are re-Previews, but they are important since they often contain improvements from community feedback. Specifically, it would be quite unwise to finalize the Vector API before Project Valhalla. Apart from that, I'm sure that there are lots of minor visible changes that didn't get a JEP. Anyway, not every release can be filled to the brim with new features, and people were also kinda busy whipping Project Valhalla into shape. INHO it's still preferable to stick to a predictable schedule instead of creating uncertainty in the community.

Areading314 19d ago

> Java 27: “We’re finished, we’re tired.” Seems about right

_the_inflator 18d ago

I worked at a MS "fanboy" company around 2011-2013. Highly competent guys, really Senior Devs, C#, MS SQL, as well as using graph data - with one distinction: it must be MS. Open Source? No way. Git? No, they relied as die hard MS believers on the MS software called Team Foundation or something like that, that was integrated into Visual Studio Pro - sorry, I forgot about it, I considered it kind of bloat and outdated. Also I couldn't stand the nomenclature. A project was called "Solution" - I died inside, because this sounded like utter nonsense to me, because how do they know it would be one in the end? While JetBrains as well as Linux quickly iterated through everything and got traction as well as a cadence that overall kind of was paced around sprint cycles that lasted two or four weeks, the company finally started to break up with project management and implemented Scrum. As the JavaScript guy, the only one, because a customer wanted a SaaS "solution" but with static web content this wasn't really dynamic. I knew one of the founders who was a managing partner and he asked me to join as Web Developer. Overall, all were very skeptical towards me because how could someone bet on JavaScript at the time? Well I turned the argument around and said the same about C# with its closed source walled garden approach to everything relying on MS to solve their problems with no way of giving feedback while there was no real release cycle and roadmap available - hopium and copium. Statically typed languages for the win they said, blabla. I wasn't against static types, but did pure magic in JS, that they saw me as magician and I got some fans and I found one team mate who wanted to be coached by me on JS, Ajax and stuff. So, there you have it. History. I think there are pros and cons to any approach as always. Both language suffer from feature creep. C# is still tightly knit into some products from MS and there are some backwards compatibility issues to take care of that limit certain progress and need substantial change. Java isn't that way and was near dead and went OS. That's why they moved to the current model. Former versions were also hardly changed, have a look at everything before Java Version 12 or so. Java wasn't community driven all the time. So, C# has its merits, TypeScript for the win, so MS won over JavaScript ironically but only on the outside. I shocked my MS fanboy colleagues when I really gave them a shock therapy regarding security when they mocked me with the examples given by MS why JavaScript was so bad and C# would beat it. We all know the infamous type coercion examples with mixed types, arrays etc. So I shocked them with eval function of course but then gave them nightmares and mental overload with Function.prototype.toString and new Function() trickery. It blew their mind, there was nothing remotely available in their world. Not introspection, nothing. JavaScript was kind of assembler like I said. Highly flexible, you need to use modules, like jQuery did but have to build your own. So TypeScript used exactly this flexibility: compiling to JavaScript. A metalanguage. For the true insider, JavaScript won.