Codename One takes Java from your UI to your server, compiled to native code. Share models and typed APIs across the full stack, control the UI you ship, and deploy your server without a JVM. Target iOS, Android, desktop, watch and TV, with a JavaScript port for the web. Published benchmarks below compare runtime performance with HotSpot, Spring and Go.
The UI ships with your app, so you control its components and theme. Native interfaces and peer components give you access to platform SDKs and views. The framework is GPLv2 with the Classpath Exception: free for commercial applications, with no royalties.
| What do you want to build? | Start here |
|---|---|
| A new Java app | Generate a project or try the browser playground |
| A native Java service | Build a backend with Spring-style APIs and no JVM in the deployed executable |
| An app and its backend | Share models and generated REST clients |
| An existing Android app on more platforms | Import classic Android application code, including activities, XML layouts and resources |
| Evidence before adopting | Compare performance and inspect platform support |
Write controllers, dependency injection, transactions and scheduled jobs with Spring-style annotations. The build generates routing and wiring as ordinary code, then ParparVM translates Java bytecode to C and the native toolchain compiles the executable. Develop and debug on the JVM; deploy a native service without it.
The backend includes PostgreSQL, MySQL/MariaDB and SQLite access, managed ORM, WebSockets, sessions, an OAuth2/OIDC security stack, database migrations, OpenTelemetry and MCP tools. Initializr offers App with backend and Backend only project types.
This is an evolving backend with its own supported API surface. Its annotations live in com.codename1.backend.annotations; it is not a drop-in Spring Boot replacement and does not run arbitrary JVM libraries. Start with the backend guide and its compatibility limits.
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, including activities, fragments, XML layouts, RecyclerView, ConstraintLayout and Material Components. Java and Kotlin sources are supported.
The application runs through Codename One's ports without an Android runtime on the other platforms. This supports the documented classic Android API surface, not every Android library or framework behavior. Check the supported APIs, side-by-side captures and limitations, particularly reflection, Parcel and SQLite concurrency, against your application's screens and data flows.
These are published reference measurements, not a promise about every application. Each comparison uses a different workload; follow the links for hardware, commands and raw results.
| Comparison | Recorded result | Scope |
|---|---|---|
| HotSpot / JDK 25 | 37.5% less elapsed time and 45.8% less peak memory for ParparVM self-translation | Linux ARM64 Neoverse N2 baseline, seven calibration runs, identical generated files. All machines and workloads. Allocation-heavy code can favor HotSpot. |
| Spring Boot 4.1.1 / JDK 25 | 3.9× plaintext and 3.4× JSON throughput | Two pinned server CPUs in a Linux ARM64 VM on an M4 Max, 32 connections, matched 60-second warmup. Lower-level CN1 HTTP handlers versus Spring MVC/Tomcat; no database, TLS or authentication. Methodology and reproduction bundle. |
| Go / fasthttp | 595,610 vs 496,293 requests/s | Separate plaintext test: CN1 native musl, two pinned cores, 64 connections, medians of three interleaved runs. Go used less memory and a smaller binary. Full comparison. |
The Spring comparison measures selected HTTP stacks, not equivalent framework features or the cost of CN1's annotation-generated controllers. The HotSpot comparison measures our compiler workload; the linked results also show workloads where HotSpot is faster. Measure your own service before sizing a deployment.
- UI you control: CSS themes, Liquid Glass and Material 3, layouts, animation, vector graphics and custom drawing. Embed platform views where needed.
- Shared app and server code: typed REST contracts, generated clients, entities and persistence APIs, with platform-specific code kept behind explicit boundaries.
- Local development: simulator, device skins, component and network inspectors, live CSS, JUnit and screenshot tests. Maven and Gradle tooling are available.
- Coding-agent tools: generated project instructions and semantic MCP tools for the simulator and JavaSE-hosted tooling.
- Device integration: camera, notifications, maps, Bluetooth LE, biometrics, secure storage and native SDK access.
- Native build options: use local toolchains or the optional cloud service, including iOS builds from Windows or Linux. The free cloud tier includes 100 build credits per month.
| Form factor | Targets |
|---|---|
| Mobile | Android and iOS |
| Desktop | Native Windows, Linux and macOS; JVM desktop applications |
| Web | JavaScript applications and installable PWAs |
| TV | Apple TV (tvOS) and Android TV / Google TV |
| Watch | Apple Watch (watchOS) and Wear OS |
| Vehicle | Apple CarPlay and Android Auto integrations |
| Server | Native Java backend; JVM development mode |
Check Port Status for each target's architecture, OS requirements and test coverage.
ParparVM translates reachable JVM bytecode into C for the native Apple, Windows, Linux and backend targets. The platform compiler builds the generated code together with the runtime. Android applications use the Android toolchain; the JavaScript port produces browser applications. JavaSE powers the JVM desktop target and simulator.
Codename One draws its portable UI rather than wrapping every platform widget. Native interfaces and PeerComponent connect it to platform SDKs and views. The Android compatibility layer compiles supported Android resources and API calls into this same application model.
Generate a project, choose an app, app with backend, or backend-only project, and follow the getting-started guide.
- Developer guide
- Client Javadoc and backend Javadoc
- Libraries and native integrations
- Engineering blog
- GitHub Discussions
The setup is covered in depth in this article and video.
IMPORTANT: Building the Codename One framework from source requires JDK 8 -- some sub-modules must use -source 1.5 and -target 1.5 to maintain backward compatibility with parts of the toolchain, and newer JDKs cannot emit those targets.
Running a Codename One application (the simulator or the "Run as desktop app" target) supports JDK 11 through 25 (Eclipse Temurin: https://adoptium.net).
git clone https://github.com/codenameone/CodenameOne
cd CodenameOne/maven
mvn install -Plocal-dev-javase
NOTE: The -Plocal-dev-javase profile is necessary for building the javase port. Without it, you'll get build errors.
This will build and install Codename One in your local Maven repository, including the cn1app-archetype and cn1lib-archetype Maven archetypes. This process can take a while since it automatically downloads dependencies with a size of ~1GB.
Now that Codename One is installed in your local Maven repository, you can use that version in a project instead of the release version. A new testing project can be quickly generated with the Codename One initializr.
After downloading and extracting the project, open its pom.xml file and and look for the <cn1.version> and <cn1.plugin.version> properties.
Then change these to point to the version that got installed into your local maven repository by mvn install -Plocal-dev-javase. The locally built version will usually be a SNAPSHOT version (e.g. 7.0.21-SNAPSHOT).
Getting and Building Sources
$ git clone https://github.com/codenameone/CodenameOne
$ cd CodenameOne
$ ant
Running Unit Tests
$ ant test-javase
Running Samples
The Samples directory contains a growing set of sample applications. These samples aren't meant to be demos, but rather samples of how to use APIs.
You can launch the sample runner app from the command-line using:
$ ant samples
Codename One's native compiler is open source. You can read more about it in its dedicated folder in this repository.
ParparVM translates Java bytecode to portable C, performs reachability analysis to remove unused code, and then hands the generated project to the target's native compiler. It powers the native Apple, Windows, Linux and backend targets.
You can open the generated native project and use the platform's debugger and profiler directly. On Apple platforms, for example, the output is a standard Xcode project with readable call stacks and native performance tooling.
Outside pull requests are disabled because even a small framework change can interact with the repository's cross-platform build and screenshot pipelines. The maintainers integrate code changes after running that matrix.
You can still materially improve the project:
- Ask usage and API-design questions in GitHub Discussions.
- File GitHub Issues for reproducible bugs, performance counterexamples, toolchain compatibility problems, and documentation gaps.
- Include a minimal project, the affected target, Codename One and JDK versions, complete logs, and screenshots where they help.
- Challenge the published benchmarks and architecture. A counterexample we can reproduce is more useful than a general feature request.
Read How to Help Improve Codename One before opening a report. The codenameone tag on Stack Overflow also contains years of community questions and answers.
Thanks goes to these wonderful people (emoji key):
This historical list recognizes people who contributed code and documentation before outside pull requests were disabled. Current participation happens through issues and discussions.