But doesnt that mean we get ultimate features for free?

More ai enshittification

Took them long enough, eclipse has only had this for like a decade at this point

What I understood from the article, is that they are going to publish articles on what changed from one LTS to the next, starting with 8 to 11.

My point was that such articles already exist^1^3, so I see little point to do it, except for Search Engine Optimisation, which seems likely since PVS Studio sells a static analyser. And looking through OP's post history I see that they post an awful lot of articles from them, which might imply they are affiliated to them.

If you're not sarcastic, it means (to me, at least) that the series comprises more than one entry and that is the first of those entries.

This is the first article in a series on what developers can expect when upgrading between LTS versions of Java.

I understand the goal of this series, but I'm pretty sure it has been done multiple times already.

Thank you, I wondered what the catch was.

No, the Community Edition still exists and is available from github. They doesnt want people to use that though, since they want people to use the "free" Ultimate Edition with the colorful subscription link in the face of the user.

Pay to text search my own files? Cloud first needs to be reigned back. Self hosting should be the default for open source projects with optional porting a cloud service.

Unlike Java’s Optional, which is a library feature, JPlus provides null-safety at the language level. It allows developers to write code where null-safety is enforced consistently, without wrapping every value in an Optional. In that sense, JPlus brings the same kind of safety and clarity that Kotlin offers but keeps full compatibility with Java syntax and tooling.

Modern Java already has null safety via the Optional class. If a developer is too lazy to use that, what makes you think they would use JPlus?

In my opinion this one is a bad selling point, because you're really just offering a cleaner looking alternative to what's already there, but you're not focusing on that, you're presenting it as if it solves a problem, which it doesn't.

That seemed like a bold claim, and, indeed, this is more like "tool-assisted rewriting".

Kotlin is great for null-safety, but Kotlin isn’t a superset, you can’t just compile a java file with kotlin and have it work.

JPlus allows you to enforce null-safety without rewriting your existing Java code, which can be easier for teams working in legacy projects or who prefer staying in pure Java.

So like... Kotlin then?

Ah, interesting. I haven't kept up with the newest Java changes, so you kind of answered that backwards for me. Being able to just use IO.println() is already pretty good and for sure what I'd prefer over having to add an import. Seems to also be a new addition in Java 25, so I guess, Hello World looks a lot different all of a sudden.

My code was merely a demonstration that just println is possible now. Like you, I'd prefer IO.println in "real" code. My bar for static imports is extremely high.

Also interesting that this kind of static import doesn't work with System.out.println, I'm guessing because out is already a field of System rather than a package or type. It can be used to write it as out.println, but yeah, not much of a point anymore when IO.println exists.

Static imports are only for static fields and methods. System.out::println is an instance method.

Ah, interesting. I haven't kept up with the newest Java changes, so you kind of answered that backwards for me. Being able to just use IO.println() is already pretty good and for sure what I'd prefer over having to add an import. Seems to also be a new addition in Java 25, so I guess, Hello World looks a lot different all of a sudden.

Also interesting that this kind of static import doesn't work with System.out.println, I'm guessing because out is already a field of System rather than a package or type. It can be used to write it as out.println, but yeah, not much of a point anymore when IO.println exists.

If you import java.lang.IO.println statically, you can simply write println

import static java.lang.IO.println;

static void main() {
  println("Hello, World!");
}

the trend of serverless means that people are writing a ton more programs that are smallish single endpoint things. not that a ton of people are using java there, but that was a major motivation for c#

Sure, but I think the argument in favor of this feature is that the overwhelming majority of people picking up programming for the first time tend to be beginners, so if it helps them learn the basics before having to grapple with OOP then it is worthwhile.

I'll be honest, I don't get the point of this feature. It's nice for beginners or for writing small, quick, programs...but for the overwhelming majority of all java code I don't see it being useful

I enjoy that the monstrous System.out.println is still right below. 🙃

Oh come on, please don't kill the public static void main(string args) meme!

Oh come on, please don't kill the public static void main(string args) meme!

You mean this?

Now Java supports top-level instance main methods and class-less compact files. That means now the following declaration is valid:

void main() {
    System.out.println("Hello from Java 25!");
}

A whole bunch of stuff I don't really care about: compact source files, instance main methods, module imports

and even more I really want: flexible constructor bodies, primitive type patterns, scoped values, AOT stuff, compact object headers.

I mostly hope I get to move my apps to it now. When I asked for changes to allow Java 21 I was told we'd go to 25 instead, so 🤞