blog/official-experimental-java-17-support/

[giscus[bot]]

blog/official-experimental-java-17-support/

Codename One projects generated with the Initializr can now use official experimental Java 17 support, with record support arriving in Codename One 7.0.229 on March 20, 2026, and more JDK support planned next.

https://www.codenameone.com/blog/official-experimental-java-17-support/

[jsfan3]

Thanks for this update.
Just out of curiosity, I’d like to better understand how it works behind the scenes. Is Java 17 bytecode still converted to Java 5 for transcompilation? I’m asking because I recall that Codename One used to convert Java 8 to Java 5, but I don't know if that’s still the case.

[shai-almog]

That's a great question!

Thanks for asking that, I skimmed over a lot of these details. TL;DR: no. We did the right thing and no longer dowgrade to Java 5.

We did the hard work here. We removed all usage of retrolambda and updated our iOS vm (ParparVM) to support bytecode all the way up to Java 25. We wrote a lot of CI test code to verify that and its behavior. In fact, this is the main motivation behind dropping UWP support. Its usage was very low and updating it to a new JDK would have been a huge effort.

We also fixed the Android pipeline to use the newer JDK 17 compiler and updated TeaVM JavaScript build to support a newer version albeit not the latest.

Moving forward, newer JVMs will be much easier to support as most current language changes are somewhat trivial. I'm looking forward for vector support and valhalla both of which can really make a performance impact for ParparVM.

[ThomasH99]

Great to see the speed that CN1 is moving with (again :-). If I update to 7.0.229 can I use Java17 when building locally?

[shai-almog]

Thanks!

No. This requires more extensive changes both to maven pom files and codenameone_settings.properties. I suggest generating a new clean project with the initializr (where you can also add localization resource bundles now) and then copying the code over to the new scaffold.

One of the things I discussed with @shannah is simplifying the maven project structure. I think we have too many pom files and a structure that's hard to understand. This would make changes like these easier, but would be itself a painful migration.