Codename One targets native apps across multiple platforms

The core decision: your UI ships with your app

Most cross-platform frameworks hide this. Flutter draws its own pixels, React Native maps to native views, and JavaFX renders its own scene graph. Codename One makes the choice explicit in the README: the UI ships with your app, so you control your components and theme.

That single sentence explains most of the framework's trade-offs. Because the UI is custom-rendered rather than assembled from platform widgets, the same Java UI code produces the same interface on iOS, Android, desktop, watch, TV and the web port, and you are not exposed to the differences between native controls on each platform. The README lists CSS themes, Liquid Glass and Material 3, layouts, animation, vector graphics and custom drawing, and adds that native interfaces and peer components give you access to platform SDKs and views when you need them. That last point is the escape hatch: native where it matters, custom everywhere else.

The targeting story is unusually wide for a Java framework. The repository topics cover android, iOS, linux, macos, windows, watchos, wear-os, pwa, jvm, kotlin, maven and AOT, and the README describes a JavaScript port for the web. It takes Java from your UI to your server, compiled to native code, and describes itself as full-stack Java.

That breadth is the ambition. Whether a given app needs all of it is a separate question, and the README anticipates it by linking to a port status page rather than claiming uniform support.

The backend: ParparVM removes the JVM from deployment

The server half is the more unusual claim. The README says you write controllers, dependency injection, transactions and scheduled jobs with Spring-style annotations, and the build generates routing and wiring as ordinary code. Then ParparVM translates Java bytecode to C and the native toolchain compiles the executable.

So you develop and debug on the JVM and deploy a native service without it. That is the interesting part, because a JVM-free binary changes the operational profile: no JVM flags to tune, no runtime dependency to keep patched.

What comes with it is a specific list: PostgreSQL, MySQL/MariaDB and SQLite access, a managed ORM, WebSockets, sessions, an OAuth2/OIDC security stack, database migrations, OpenTelemetry and MCP tools. Initializr offers two project types, App with backend and Backend only.

The README is careful to bound this, and that caution is the most useful sentence in the section. It calls the backend an evolving system with its own supported API surface, states the annotations live in `com.codename1.backend.annotations`, and says plainly that it is not a drop-in Spring Boot replacement and does not run arbitrary JVM libraries.

So the Spring-style syntax is a convenience layer, not compatibility. Any library you bring from Maven for the server side should be assumed unavailable until the documentation says otherwise.

Importing an Android app, and where the compatibility layer stops

For teams with an existing Android codebase, the framework offers an import path. You import an Android Studio module with `cn1:import-android-project`, or place its sources in `common/src/main/android`. The compatibility layer implements supported `android.*` and AndroidX APIs over Codename One, and the README names activities, fragments, XML layouts, RecyclerView, ConstraintLayout and Material Components. Java and Kotlin sources are both supported.

The app then runs through Codename One's ports on the other platforms without an Android runtime being present.

The limits are stated clearly enough to be actionable. The README says this covers the documented classic Android API surface, not every Android library or framework behavior, and directs you to check the supported APIs, side-by-side captures and limitations, particularly around reflection, Parcel and SQLite concurrency, against your own screens and data flows.

Those three words are the ones to take seriously. Reflection is how a lot of Android code discovers behaviour at runtime, Parcel is how Android passes structured state between components, and SQLite concurrency is where the threading model differs most between Android and a reimplemented layer. An app that leans on any of them is where this migration path gets expensive.

Getting started: Initializr, the playground and Ant

The README does not give a command-line installation sequence. It routes you to Codename One tooling by name instead, which is the honest description of how this framework is used.

For a new Java app, the two entry points are an online project generator at codenameone.com/initializr and a browser playground at codenameone.com/playground. The playground is the faster of the two for evaluating whether the custom-rendered UI suits you, since it needs nothing installed.

For an existing Android module, the command is a Maven plugin goal:

cn1:import-android-project

The repository itself is built around Ant, which the top-level layout makes visible. There is a `build.xml` at the root, another `build.xml` under `Samples/`, an `antw` wrapper, and a `maven/` directory alongside it, so both Ant and Maven appear in the build. `BUILDING.md` sits at the top level for the actual procedure, and there is also an `AGENTS.md`, a `CLAUDE.md` and a `skills/` directory.

Other directories explain the scope. `CodenameOne/` is the core library, `Ports/` the platform ports, `vm/` the virtual machine work including ParparVM, `CodenameOneDesigner/` the GUI designer, `Factory/` the Cloud Factory, `Themes/` and `native-themes/` the theme assets, `tools/` the build tools, and `tests/` the test suites.

The published benchmarks, read carefully

The README publishes three comparisons and, unusually, describes their limits as explicitly as their numbers. That framing is the reason to include them.

Against HotSpot on JDK 25, the recorded result is 37.5% less elapsed time and 45.8% less peak memory for ParparVM self-translation, on a Linux ARM64 Neoverse N2 baseline over seven calibration runs with identical generated files. The README then notes that allocation-heavy code can favour HotSpot, and states elsewhere that the linked results also show workloads where HotSpot is faster. In other words, the comparison measures the compiler's own workload, not an application workload.

Against Spring Boot 4.1.1 on JDK 25, the claim is 3.9 times plaintext and 3.4 times JSON throughput, across two pinned server CPUs in a Linux ARM64 VM on an M4 Max, with 32 connections and a matched 60-second warmup. The README states the scope explicitly: lower-level CN1 HTTP handlers against Spring MVC and Tomcat, with no database, TLS or authentication.

Against Go and fasthttp, the numbers are close: 595,610 versus 496,293 requests per second, from a separate plaintext test on CN1 native musl with two pinned cores and 64 connections, medians of three interleaved runs. Here the README concedes the other side: Go used less memory and produced a smaller binary.

The README's own closing instruction is the right one, and it is that you should measure your own service before sizing a deployment.

Licence and upgrade cost

The licence deserves reading before any other consideration, because it is unusual for this category of product. The README states the framework is GPLv2 with the Classpath Exception, free for commercial applications with no royalties. The GitHub badge reads GPL + CE.

The Classpath Exception is the mechanism that makes this workable. GPL with that exception permits linking to the library from code under your own terms, so you do not have to open-source your application. What remains GPL is any modification to Codename One itself. If your organisation runs a licence scanner over dependencies, this file will need a human decision rather than an automated one, and the repository carries both `LICENSE` and `NOTICE` plus a `SECURITY.md` for the responsible disclosure route.

On upgrade cost, the version number is the signal: releases are at 7.0.276 on 2026-10-11, 7.0.275 on 2026-10-09 and 7.0.274 on 2026-10-02, with the last push on 2026-10-16. This is a project shipping continuously, which means frequent releases and a correspondingly frequent habit of upgrading. Whether your application absorbs that cadence is the practical question, and the README does not describe a long-term-support branch.

Editorial conclusion

Adopt Codename One when you want one Java codebase across mobile, desktop and web, and you want the shipped UI to be your own components and theme rather than platform widgets, and you can accept that only the framework's own APIs are available on every target. Do not adopt its backend if you need to run arbitrary JVM libraries, because the README states that it cannot. or if you need to import an Android app that depends on reflection, Parcel or SQLite concurrency behaviour it does not replicate. Before starting, read the platform support status page linked from the README and check your target against it, since parity differs per platform and the README does not enumerate the differences.

Frequently asked questions

Official sources

1. codenameone/CodenameOne on GitHub
2. Issues
3. Project website
4. README
5. Releases