Codename One’s November 1, 2026 engineering post describes building a large share of Swing, SwingX and JavaFX application code for phones, browsers and native desktops. For a team considering an existing business application, the useful first question is which dependencies can accompany its own source.
Separate source reuse from binary compatibility
The post says a third-party JAR compiled against java.awt, javax.swing or javafx is not a binary drop-in for this route. Bringing a library’s source into the project is a different path. It also lists unsupported mechanisms, including runtime reflection and class loaders, and describes unsupported API calls as build errors.
That makes a dependency inventory more informative than a screenshot of one imported screen. A panel can look familiar while a library behind a button still determines whether the intended workflow can be built.
Use the report to identify the next question
The desktop-compatibility guide says each build using a desktop layer writes target/codenameone/desktop-port-report.md, whether the compliance check passes or fails. The report describes supported calls, source-level changes and dependency outcomes. The guide distinguishes dependencies implemented by the layer from other libraries whose classes are not relocated.
Read the findings against the workflow you intend to deliver. Keep the affected dependency, source location, proposed change and unresolved question together. A completed import is a useful observation; it is not a complete estimate of the remaining work.
Rehearse one workflow before estimating the application
Consider a fictional stockroom application with a product table, an edit dialog and an export button. A team builds an isolated trial of the product table and gets it to appear. In the full application, the export button depends on a separate UI library supplied only as a JAR. The team has demonstrated the table, but has not yet established the whole stockroom workflow.
Its review sheet can record three separate outcomes: what built, what the dependency check rejected and what the user could actually complete on the intended target. Keep the export step open until the team has chosen and validated an approach. This example describes no real application or measured migration.
Keep a build result beside a user result
- Choose a small but complete workflow, including its dependencies.
- Preserve the port report and the build version used for the trial.
- Record actual target-device behavior separately from compilation.
- Estimate the next step from unresolved findings rather than assuming the rest matches the demo.
These are suggested evaluation steps. No Codename One build, third-party library, phone app or migration benchmark was independently run for this article. Vendor demonstrations and performance figures do not establish the result for your application.
Primary sources
- Codename One engineering post, November 1, 2026: https://www.codenameone.com/blog/swing-and-javafx-on-phones/
- Codename One desktop-compatibility guide: https://www.codenameone.com/developer-guide/desktop-interop/
Check the migration evidence
