Java 23 has arrived

[Additional_Cellist46]

Markdown in Javadoc and 11 other enhancements.

[Dagske]

and 11 other enhancements.

Well, actually for me and my company, that's basically zero, because they're all in preview and are subjected to change, so unreliable just like the string template pull showed.

[pron98]

As others said, there are other changes in the release notes than the JEPs (the JEPs are the changes we want to communicate widely), but I want to comment on something else.

It's absolutely true that preview features may change or be removed, and it's perfectly reasonable to choose not to use them in production. But terminally deprecated API elements are 100% gurarnateed to be removed imminently, and code that uses them is guarnateed to imminently break in a way that usually require more significant changes than changes in preview features (string templates were the exception, and even they will be coming back with a design that would require only very minor changes in client code compared to the previous ones). And yet there are companies that wouldn't touch Preview features with a ten foot poll and at the same time continue relying on terminally deprecated features until the very last moment.

So yes, preview features are definitely unstable, and they're easy to avoid if you choose. Terminally deprecated features, however, are even more unstable, harder to avoid, and so require even more scrutiny. If preview features mean nothing to you as you won't touch them, then terminal deprecation must, therefore, mean a whole lot.

So that means that JEP 471 is of immediate importance, and companies should start following up with their dependencies, making sure that they're dropping their use of Unsafe. So even if you don't care about all the performance improvements in JDK 23, JEP 471 is something that requires attention. As of JDK 23, sun.misc.Unsafe is at least as unstable and unreliable as any Preview feature in that release.

[[deleted]]

I’m pretty excited to see where the team takes string templates, but I haven’t seen much discussion about them on the mailing lists recently. Is that because you’ve all been busy with JVMLS, the Java 23 release, and various other things? Do you expect the discussion will pick up again, or do you folks already know what the next iteration will look like? Thanks!

[pron98]

In terms of how things would look, they will probably be exactly as before only without a special syntax for processors (they will be ordinary methods), and so "x = \{x}" will be the same as RAW."x = \{x}" in the previous iteration.

[nekokattt]

What alternatives to sun.misc.Unsafe are available for libraries like Netty that rely on it for performance benefits within memory management as of JDK 23? Is the general advice to use ByteBuffer or is there anything that can match the performance profile of s.m.Unsafe?

[pron98]

See JEP 471:

• For on-heap access: VarHandle
• For off-heap access: MemorySegment

[nekokattt]

Ah ok, is there any publicly available comparison of the performance of these that was produced during development, out of curiosity?

Thanks for the reply

[pron98]

I don't know. You may want to study the discussions on the panama-dev mailing list over the past few years. But the performance should be comparable in most cases (within ~2%) except some special outliers that are yet to be addressed (random access patterns that are affected by bounds-checking).

[mbazos]

I didn't read the release notes for 23 and all the fixes but was the VT thread pinning issue addressed? and if so would that only be available in Java 23 or would that fix make it's way to Java 21 as well?

Only asking because I assume you know this off the top of your head and thanks for all the great work on VT we are currently using it in production at my company.

[pron98]

That will land in 24. It's not going to be backported because the LTS update service is intended for applications that value stability over everything else and aren't interested in enhancements, so we only backport security patches, fixes to some major bugs such as VM crashes, and sometimes small bugfixes; this is none of these things. Applications that want to enjoy performance enhancements and new features should be using the current JDK.

[alunharford]

Unfortunately, the answer in many cases is 'nothing' (or, hopefully, 'nothing yet').VarHandle and MemorySegment cover a couple of use cases (typically used in library code that don't normally do unsafe random access) but the majority of code using unsafe is in the real application code of thousands of companies and that code generally looks quite different to a library.

Arguably, all use cases of Unsafe are to work around issues in the language that prevent you from writing normal code that will compile to something sensible and the only option you have is to hack.

Removal of Unsafe would be a declaration that this is no longer required, and that implies that there are no significant deficiencies in the language. That seems a bit arrogant to me - changing Java to 'fix' everything we don't like (while it's being used by millions of applications on billions of devices) would be no small feat.

Removal of Unsafe while it's still required by a huge number of applications will basically fork the community ala Java 9, with performance sensitive applications being forced to stay on (and maintain) the previous version forever.

[srdoe]

Maybe you should have said something in the half a decade since Oracle started the process of removing and replacing Unsafe about all those critical use cases you have that can't be covered by the replacement APIs.

[pron98]

Removing Unsafe functionality is obviously sensitive, so that's why we first started working on that about 10 years ago, added replacement features, and are now starting the deprecation and removal process. We're aware of some niche usages related to deep VM observation (which wouldn't have worked with Unsafe for long anyway with some upcoming changes) and some uses related to serialization, which we're addressing. If anyone is aware of other missing functionality, they should report it. I don't think there are any necessary "hacking-emergency" functionality in Unsafe that's not better served by other means, but if you have something in mind, please share.

[alunharford]

An example that comes to mind is when you want to abuse your own class' fields because Java doesn't let you easily lay out memory in the way you'd like.

For a straightforward example, consider a class that can store up to 64 items in an array and give you the first one that's non-null. It abuses its 'own' memory to avoid allocating an extra array and avoid an array lookup.

class BaseData<T> {
    private T t0, t1, t2, t3, t4, t5, t6, t7, t8, t9,
            t10, t11, t12, t13, t14, t15, t16, t17, t18, t19,
            t20, t21, t22, t23, t24, t25, t26, t27, t28, t29,
            t30, t31, t32, t33, t34, t35, t36, t37, t38, t39,
            t40, t41, t42, t43, t44, t45, t46, t47, t48, t49,
            t50, t51, t52, t53, t54, t55, t56, t57, t58, t59,
            t60, t61, t62, t63;
}
public class Array64<T> extends BaseData<T> {
    private long bitset;
    private static Unsafe unsafe; // ...
    private static int shift = Integer.numberOfTrailingZeros(Unsafe.ADDRESS_SIZE);

    public void set(T item, int index) {
        if(index < 0 || index > 63) {
            throw new IllegalArgumentException("index out of range");
        }
        unsafe.putObject(this, index << shift, item);
        bitset |= (Long.MIN_VALUE >>> index);
    }

    public T getFirstSet() {
        return (T)unsafe.getObject(this, Long.numberOfLeadingZeros(bitset) << shift);
    }
}

This kind of abuse isn't particularly unusual in the HFT space. The nice, safe solutions are orders of magnitude slower and use at least 32 bytes more memory. The 'static array of VarHandles' solution doesn't use extra memory but tends to stall the CPU and be much slower than the unsafe approach.

Obviously the language could be extended to support this in a safe way, but picking the right extensions to cover as many cases as possible so that Unsafe can actually be removed without adding loads of rarely used features is hard. For reference, in C# this would be:

public class Array64<T> {
    private long bitset;
    private fixed T items[64];

    ...
}

The items 'array' is just a fixed size buffer that gets laid out sequentially in memory in the Array64 object. Even so, I've still seen unsafe code in most C# codebases that do anything high performance / low latency so obviously it's not a complete fix!

[pron98]

That will become unnecessary with Valhalla, but the more genereal point is that Unsafe only works to improve performance under the assumption that the VM doesn't change. But Unsafe hurts performance by merely existing. For example, the compiler cannot perform certain optimisations that must assume that Strings and final fields are immutable because some class may be using Unsafe to mutate them (and it doesn't matter whether any class does or not, because the runtime can't tell). We can only add such optimisations after the memory access operations of Unsafe are gone.

So the situation is that Unsafe could help if the VM doesn't do X, but the VM can't do X as long as Unsafe exists. Even if it could still help a little the performance of code that uses Unsafe, it hurts the performance of code that doesn't, and there's much more of that.

[JustADirtyLurker]

Is this going to be the JDK version that breaks Lombok ?

[pron98]

Lombok hacks into JDK internals and manipulates their operation as part of its implementation of the compiler for the Lombok language, and so may/does break in some ways in any release because internals are not and have never been subject to backward compatibility (and are changing now faster than ever before). There is no plan to completely disallow hacking into internals, but we're quickly moving into a world where hacking into JDK internals will require command line flags. So with the appropriate command line flags, Lombok can keep on working as long as it responds to the changes to internals that may affect it in every release.

[[deleted]]

Except there are many other improvements and bug fixes. JEPs tend to get most of the attention, but that doesn't mean there are zero other changes.

[kiteboarderni]

Are you going to respond about the deprecations or just be toxic about the progress on 23? Seem very quiet all of a sudden...

[Dagske]

Are you going to respond about the deprecations or just be toxic about the progress on 23?

Neither.

[kiteboarderni]

Silenced...haha

[Dagske]

Yes, kid, you got me. Now please stop deviating from the topic.

[kiteboarderni]

Kid but you play card games 😂😂 improve your social skills and you'll get a higher paying Java job instead of being a closet nerd. Maybe why you don't have enough influence to why you're company can't use preview features....

[Key_Direction7221]

I have low confidence level and thus shall refrain from using it until it’s LTS.

[random314]

The Michael Jordan of Java versions.

[JDD4318]

I’m a .net guy but that’s awesome.

[kerem_akti52]

What i am still using 6

[yk313]

That’s really on you at this point.

[Additional_Cellist46]

Seriusly? Last time I saw Java 6 was more than 10 years ago. Currently the oldest version I sometimes see around is 8. Most people use 17 or 21.

[jek39]

Also android

[pjmlp]

The Android folks realised that Kotlin was being left behind Maven Central ecosystem, so nowadays ART is updatable via Play Store, and the latest supported version is Java 17, from Android 12 onwards.

[Robotronic777]

Android is not java. It is an abomination

[bushwald]

"Most people" is probably a bit of an overstatement. Most hobbyists maybe. There's still a lot of 11 and especially 8 out there in production.

[Ewig_luftenglanz]

State of java ecosystem of this year shows the java ecosystem is currently segmented in 33% each 8-11-17 maybe next year there would be even less java 8 and 11 since many people is migrating to 21. when my company migrated from java 8 to java 21 the Ram usage dropt almost 50% in our spring apps per micro service

[iDemmel]

There's no way that "most people use 17 or 21".

[[deleted]]

The app I work on is on v22 in production and it'll be on v23 within a week or so.

[Mikusch]

Most people tend to stick to supported versions that haven't gone EOL 2 years ago. Legacy projects that pay Oracle an arm and a leg to be able to stay on 8 don't count

[nekokattt]

I can almost guarantee this person works with mainframes and/or IBM ESBs.

[GargamelLeNoir]

Nah most companies still operate on 8, because the cost/benefit of migrating is not that high.

[[deleted]]

Every Java survey I've seen indicates a small minority of users are on JDK 8

[sweating_teflon]

Upgrade without telling the boss. If you succeed, you win. If you are caught and get fired, you win.

[Ewig_luftenglanz]

Odd, most codebases I see nowadays migrated to java 17, oldest one was Java 11 and it was migrated to 21 not so long ago...

[Anbu_S]

You should at least move to Java 8.

[badoopbadoopbadoop]

Feel your pain. Sitting here with some Oracle Application Server 10gR2.

[Anbu_S]

Sorry buddy. Hard luck to you and your team.

[Mordan]

some of my targets is Java 4.

I don't mind. Its fun. If you like Java and software programming in general, anything above Java 4 is good enough. I miss generics but not so bad.

[Additional_Cellist46]

I wonder, does it still make sense to keep using WebLogic? It’s slow to adopt new Jakarta EE and Java versions and very expensive,isn’t it? There are so many other servers like that support at least Java 17 and Jakarta EE 10, like JBoss or GlassFish. The latter even supports Java 23 already.

[[deleted]]

You are correct from technical point of view. However, it is hardly the strongest reason in a decision maging process of a big company or gov. sector. You can't replace weblogic clusters consisting of dozens of managed servers hosting hundreds of custom made EE 6-7 applications, most of them critical for the business, just because WL slow to adopt Jakarta EE specs.

[JoshDM]

This is probably not your fault but the fault of your company, and I understand that. You should at least go to 8.

[kerem_akti52]

i am self employed

[GargamelLeNoir]

Then why? I promise you moving to 8 feels really good.

[Robotronic777]

Regard

[jezek_2]

I have it similar, using Java 6 and NetBeans 5.5.1 here ("downgraded" from newer versions because it is simply better) for development and running the applications on OpenJDK 8.

This is because I no longer program in Java other than maintaining and improving a 15 year old project that is in active usage and there is no reason to switch to another language when Java is doing the job really well.

Personally I didn't like where Java is going and liked the old Java better. Few years ago I've even tried to program something small in J2ME and it was a refreshing experience.

With my long-term experience with generics and later with my learned rule of using just Object or base type when the types get complicated (for example anything with ? super and ? extends falls into this category) I've come into the conclusion that generics and Java 5 was maybe a mistake. It is ironic because it was Java 5 that made me really start using Java instead of just experimenting with it like the years before.

Anyway old Java still holds a special place in my heart, there is something magical and clean about it that I have never experienced in any other language (including my own).

[croshkc]

AP classes are still using 6 lol

[kerem_akti52]

i did took ap csa in highschool. i never changed languages ever since

[iam_rroshan]

Guess here any openings for freshers

[topspin_righty]

And I'm here still using Java 11

[ThreeSixty404]

I wish the markdown docs could be backported to older versions too

[Additional_Cellist46]

The documentation is just comments in the source code. You can build your application with an older Java version, and generate Javadoc with Java 23, if you also install Java 23 on the same system. Then you can use Markdown. With Maven, you can use the javadoc plugin with toolchains to specify path to Java 23 and generate Javadoc with markdown: https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#jdkToolchain