3 ms·

> 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 wors

> 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 18d 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 18d 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 18d 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 18d ago
      I started programming when Java 6 was relatively new. Back then it was about 3-4 years in between releases. Although I don’t write much Java any more, I’m happy to see changes shipping more frequently now.
cogman10 18d ago
There's not really a second C# runtime. Java has several, some based on the Openjdk, but a few that are completely new like OpenJ9 and Graal. The closest C# has is mono. This sort of thing is bound to happen with that situation. Heck, it happens with C++ whenever a new C++ version comes out. Some C++11 features took years to make their way into all the compilers.
- deleted 18d ago
  [deleted]
- vlovich123 18d ago
  Graal is based on OpenJDK. OpenJ9 while using a separate JVM and JIT leverage the openjdk class path as well as the build environment and various other things. I don’t think there’s a single alternate implementation that doesn’t leverage a good chunk of openjdk somehow
  - samus 17d ago
    For the simple reason that class files with JVM bytecode are the standardized intermediate representation. Therefore, duplicating the frontend is wasted effort.
    - pjmlp 17d ago
      Up to a point. Embedded systems versions tend to have their own ways, which is why despite everything Android using Dex isn't a first in the Java ecosystem.
      - samus 17d ago
        IMHO, Dex is a historical artifact. In the past it was thought that the format provides benefits for JIT compilation because it's register based, which turned out to not be case.
        pjmlp 17d ago
pron 18d ago
The Java language and runtime have been co-designed as a unified platform for many years now. Virtually every significant feature has language, library, and VM people working on it, and we often don't even know when we start how much of the feature would be in the language, library, or VM. Consequently, there is no "language version" or a "runtime version". There's only a platform version, which is defined in a single spec approved by the JCP (https://openjdk.org/projects/jdk/27/spec/ https://openjdk.org/projects/jdk/27/spec/). This also makes things easier with regards to compatibility and evolution.
- kllrnohj 18d ago
  > There's only a platform version, And of the 4 non-preview JSRs in the Java 27 release, only 1 of them is actually part of the "platform version". The other 3 are strictly changes to Hotspot internals with no platform involvement at all. They did not change any aspect of any Java platform in any way whatsoever. That is what I'm referring to. I'm not referring to the fact that the core library, language syntax, and runtime specs are all part of the same version. I'm referring to the fact that Hotspot specific behaviors and adjustments are also branded as being part of the platform release. Like there's no Java 27 platform spec that says that G1 is the default garbage collector. That would of course be an absurd platform spec change. But that is still somehow a "feature" of the Java 27 release according to Oracle.
  - pron 18d ago
    Right. There's a "Java SE" (platorm spec) version, and a JDK version that corresponds to it, but not everything in the JDK affects or is dictated by the spec. BTW, Java is developed "code first", which means that we first work on the implementation in OpenJDK, and then extract the relevant spec changes from it. > But that is still somehow a "feature" of the Java 27 release according to Oracle. It's a feature of the OpenJDK JDK, which is, indeed, the Java implementation done by Oracle (with contributions from others). The language is very careful, as you can see in the announcement: "JDK 27, the reference implementation of Java 27". The Java SE 27 spec is here: https://www.jcp.org/en/jsr/detail?id=402 https://www.jcp.org/en/jsr/detail?id=402
- 18d ago
saghm 18d ago
I didn't read the parent comment as being particularly positive in their description; it didn't sound like it was being stated as a good thing to me.
dwaite 17d ago
Historically, Java had a real habit of delaying new major versions for years as features hardened. Some of those features even lost relevance before their first shipping version. So now they have a precise release cadence that features can fall into. If it is a large feature, it better get worked in incrementally (via feature previews) because it is unlikely to be able to land completely within the release window. One could pessimistically say the faster release cadence partially serves to provide more opportunities for extended support revenue, though.

hyperpape 18d 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 18d 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 18d 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 18d ago
    I started programming when Java 6 was relatively new. Back then it was about 3-4 years in between releases. Although I don’t write much Java any more, I’m happy to see changes shipping more frequently now.

cogman10 18d ago

There's not really a second C# runtime. Java has several, some based on the Openjdk, but a few that are completely new like OpenJ9 and Graal. The closest C# has is mono. This sort of thing is bound to happen with that situation. Heck, it happens with C++ whenever a new C++ version comes out. Some C++11 features took years to make their way into all the compilers.

deleted 18d ago
[deleted]
vlovich123 18d ago
Graal is based on OpenJDK. OpenJ9 while using a separate JVM and JIT leverage the openjdk class path as well as the build environment and various other things. I don’t think there’s a single alternate implementation that doesn’t leverage a good chunk of openjdk somehow
- samus 17d ago
  For the simple reason that class files with JVM bytecode are the standardized intermediate representation. Therefore, duplicating the frontend is wasted effort.
  - pjmlp 17d ago
    Up to a point. Embedded systems versions tend to have their own ways, which is why despite everything Android using Dex isn't a first in the Java ecosystem.
    - samus 17d ago
      IMHO, Dex is a historical artifact. In the past it was thought that the format provides benefits for JIT compilation because it's register based, which turned out to not be case.
      - pjmlp 17d ago

pron 18d ago

The Java language and runtime have been co-designed as a unified platform for many years now. Virtually every significant feature has language, library, and VM people working on it, and we often don't even know when we start how much of the feature would be in the language, library, or VM. Consequently, there is no "language version" or a "runtime version". There's only a platform version, which is defined in a single spec approved by the JCP (https://openjdk.org/projects/jdk/27/spec/ https://openjdk.org/projects/jdk/27/spec/). This also makes things easier with regards to compatibility and evolution.

kllrnohj 18d ago
> There's only a platform version, And of the 4 non-preview JSRs in the Java 27 release, only 1 of them is actually part of the "platform version". The other 3 are strictly changes to Hotspot internals with no platform involvement at all. They did not change any aspect of any Java platform in any way whatsoever. That is what I'm referring to. I'm not referring to the fact that the core library, language syntax, and runtime specs are all part of the same version. I'm referring to the fact that Hotspot specific behaviors and adjustments are also branded as being part of the platform release. Like there's no Java 27 platform spec that says that G1 is the default garbage collector. That would of course be an absurd platform spec change. But that is still somehow a "feature" of the Java 27 release according to Oracle.
- pron 18d ago
  Right. There's a "Java SE" (platorm spec) version, and a JDK version that corresponds to it, but not everything in the JDK affects or is dictated by the spec. BTW, Java is developed "code first", which means that we first work on the implementation in OpenJDK, and then extract the relevant spec changes from it. > But that is still somehow a "feature" of the Java 27 release according to Oracle. It's a feature of the OpenJDK JDK, which is, indeed, the Java implementation done by Oracle (with contributions from others). The language is very careful, as you can see in the announcement: "JDK 27, the reference implementation of Java 27". The Java SE 27 spec is here: https://www.jcp.org/en/jsr/detail?id=402 https://www.jcp.org/en/jsr/detail?id=402
18d ago

saghm 18d ago

I didn't read the parent comment as being particularly positive in their description; it didn't sound like it was being stated as a good thing to me.

dwaite 17d ago

Historically, Java had a real habit of delaying new major versions for years as features hardened. Some of those features even lost relevance before their first shipping version. So now they have a precise release cadence that features can fall into. If it is a large feature, it better get worked in incrementally (via feature previews) because it is unlikely to be able to land completely within the release window. One could pessimistically say the faster release cadence partially serves to provide more opportunities for extended support revenue, though.