DEV Community: Shai Almog

Parley: A Private Messenger Template You Can Brand

Shai Almog — Sun, 01 Nov 2026 20:51:05 +0000

Plenty of organizations want their own messenger and can't use WhatsApp for it. A hospital that needs staff chat it controls. A company that wants messaging inside its product, under its brand, with no third party reading along. A community that doesn't want to live on someone else's platform. Building a secure messenger from scratch is a long project: the encryption protocol, multi-device sync, push, calls, media, groups and moderation are each a project of their own.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

Parley is that messenger, finished. It's the second of this week's templates, after Skirmish, and like the others it comes as one Java project with the app, the server and the admin console. Pick the messaging template in the Initializr and you have it. The source is under MIT-0: brand it, sell it and keep your changes private.

Chats, groups and channels.
An encrypted conversation.
Voice and video calls.

What you get

Part	What's in it
Messaging	One-to-one chats, groups of up to 256 with invite links, broadcast channels, replies, forwards, edits and delete for everyone
Media	Photos, video and voice notes, encrypted on the device before upload
Calls	Voice and video calls over WebRTC, peer to peer
Privacy	Disappearing messages, safety numbers, app lock, screen security, and controls for last seen, profile photo, read receipts and typing
Devices	Linked devices, including a browser as another device
Bridges	Optional Telegram and WhatsApp bridges, clearly marked in every conversation that uses them
Operations	An admin console with a dashboard, users, reports and bridges
Reach	iOS, Android, desktop and the browser from one project, in five languages including right-to-left Hebrew

The server can't read your users' messages

Parley uses the same design as Signal: X3DH to agree on keys and the Double Ratchet to rotate them with every message. It uses P-256 ECDH, which every platform's native crypto supports, with HKDF-SHA-256 and AES-256-GCM. Each message has its own key, and a key that leaks doesn't expose earlier messages.

The server stores and forwards envelopes: sender, target device, header, and ciphertext. It never sees the payload, so a breach of your server is a breach of ciphertext. Attachments are encrypted on the device with a fresh key before upload. On the phone, the history is sealed with a key held in the platform keystore.

The code that does this is short and readable, because the primitives are part of Codename One. This is the start of a session, from Ratchet.java:

```java {class="cn1-no-try"}
KeyPair ephemeral = KeyGenerator.ec(256);
PrivateKey me = Identity.privateKey();
byte[] dh1 = KeyAgreement.ecdh(me, pub(signedKey));
byte[] dh2 = KeyAgreement.ecdh(ephemeral.getPrivateKey(), pub(identity));
byte[] dh3 = KeyAgreement.ecdh(ephemeral.getPrivateKey(), pub(signedKey));
byte[] secret = x3dh(dh1, dh2, dh3,
oneTime == null ? null : KeyAgreement.ecdh(ephemeral.getPrivateKey(), pub(oneTime)));




`KeyAgreement`, `KeyGenerator` and `Hkdf` are new in `com.codename1.security`, added for Parley. They work on every platform, on the backend too, and Thursday's post covers them along with the WebRTC API.

## Calls that never touch your server

Calls use WebRTC with DTLS-SRTP, directly between the two devices. The Parley server rings the other side, relays the offer, answer and ICE candidates over the live WebSocket channel and hands out STUN and TURN credentials. The audio and video never pass through it, so a call costs your server almost nothing and stays private.

## Make it yours

The look starts at the top of `theme.css`:



```css
--brand: #0a7d6b;  /* White on the teal reads at 5:1. */
--brand-contrast: #ffffff;

Change the brand color and every screen follows, with dark mode variants beside it. The name, icon, languages, push and SMS providers, database and hosting work the same way they do in Wayline. A few directions to take it:

An internal company messenger: run your own TURN relay for calls (parley.ice.turn) and leave the bridges out, so nothing leaves your infrastructure.
Messaging inside your product: a marketplace that lets buyers and sellers talk, a clinic that talks to patients, a coaching app that talks to clients. The chat screens are ordinary Codename One forms, so they fit into another app.
A community app: channels for announcements, groups for members and the admin console for moderation.
Your own crypto choices: the curve and the cipher are in one class, Ratchet, if your compliance team has opinions.

Privacy settings.
Dark mode.
The admin dashboard.

Moderation without reading messages

An encrypted messenger still needs moderation. The admin console only sees what the server sees: accounts, message counts, conversation types and busy hours. When a user reports a conversation, their phone attaches the messages they chose to report, so content reaches an admin only through the people in that conversation. That keeps the privacy promise while still letting you handle abuse.

Try it

The development profile runs with nothing installed. Start the server, open two simulators, sign in as alice@parley.example and bob@parley.example, and message yourself. The server can also host the browser build, so a laptop browser becomes a linked device. The Parley page has the overview, and the user's guide and implementor's guide cover the rest.

Tomorrow: Savor: A Food Delivery Template for Restaurants and Local Fleets.

Skirmish: A Multiplayer Strategy Game Template in Java

Shai Almog — Sat, 31 Oct 2026 18:31:24 +0000

For years I avoided pitching Codename One as a game engine. Unity, Unreal and Godot own that market, and I didn't see a reason for a game developer to pick us. That changed while we were building our app templates. A modern mobile game is mostly app: sign-in, menus, a shop, friends lists, quests, push notifications, analytics and a server. The battle itself is a small part of the code. Those other parts are exactly what Codename One is good at.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

Yesterday's post argued that complete applications are the new starting point. Skirmish is that idea applied to games. It's a real-time strategy game in the style of Clash Royale: two players face each other across a 3D arena, each drawing troops and spells from a deck, and the first to bring down the other's towers wins. The client, the server and the admin console are one Java project. Watch it first:

Download the Skirmish walkthrough video.

Open the Initializr, pick the Skirmish template, set your name and package, and you get the whole game. The source is under MIT-0. No royalties, no per-install fees, no revenue share and no runtime fee that can show up in your inbox next year. The characters and towers are KayKit models released under CC0.

What you get

Part	What's in it
Battle	A 3D arena with animated glTF characters, drag-and-drop cards, elixir, overtime, particle effects and a finishing camera sweep
Online play	Trophy-banded matchmaking, challenge links, spectating and replays you can seek through
Progression	A guided training battle, levels, daily quests, chests and achievements, all granted by the server
Monetization	Gem packs and a season pass with server-side receipt checks, rewarded and interstitial ads
Growth	Invite-a-friend links, campaign links, push notifications, a home screen spotlight and opt-in funnel analytics
Operations	An admin console with live matches, player lookup, reports, queries, engagement pipelines and audited moderation
Content	The Forge, an in-game editor where players and designers build cards, arenas, missions and campaigns

Home: battle, chests and quests.
A battle in the 3D arena.
The finishing camera.

The menus are the easy part

Ask anyone who has shipped a mobile game in a game engine where the time went, and menus come up fast. Scroll views that fight the touch input, text that doesn't wrap, layouts that break on a tablet, a store screen built out of sprites. Game engines are built around a scene graph, and a settings screen doesn't fit in one.

Every button, list, tab and dialog in Skirmish is an ordinary Codename One component, laid out with layout managers and styled in CSS. The wooden buttons you saw in the video are a style, with no images involved:

WoodButton {
    background: linear-gradient(to bottom, var(--wood-light), var(--wood));
    border: 0.6mm solid var(--wood-dark);
    border-radius: 2mm;
    color: var(--ink);
    font-family: "native:MainBold";
    font-size: 4mm;
    text-align: center;
    padding: 2.5mm;
    margin: 1.2mm 2mm;
}

Because the look is a gradient and a border, it stays sharp at every screen density. Want a different visual identity? The palette is a list of CSS variables at the top of theme.css (--night, --stone, --wood, --gold and more). Change them and every screen follows. Text wraps, lists scroll natively, right-to-left languages work, and the same screens run on a phone, a tablet and the desktop.

The battle is 3D, and it's Java

The arena is a GameView from com.codename1.gaming, rendered with the GPU API, with a perspective camera behind your king. The characters are rigged glTF models with skeletal animation, a new part of the gaming API that came out of this work. Playing a walk cycle and blending into an attack takes a few lines:

```java {class="cn1-no-try"}
GltfScene knight = GltfLoader.loadScene(in);
unit = new AnimatedModel(device, knight);
unit.hideNode("Shield_Spike"); // the file carries every prop
unit.play("Walking_A", true);
unit.addTo(this);
// in update(double dt): unit.update((float) dt);
// on attack: unit.crossFade("1H_Melee_Attack_Chop", 0.15f, false);




Swap in any rigged glTF character with the same animation names and it fights.

## Multiplayer without a networking team

The game rules live in their own module, `rules`. It's deterministic Java with no floating point and no clock, and four things compile it: the app, the server, the replays and the tests. Adding a card is one line:



```java {class="cn1-no-try"}
add(new CardDef("squire", "Squire", CardDef.TROOP, 3)
        .hp(1450).damage(160).hitTicks(24).range(700).speed(45).radius(500));

Online matches run in lockstep over a WebSocket. The server is the referee: it stamps each card a player drops with a tick slightly in the future and sends it to both phones, so both simulations stay identical and nobody can cheat by editing their client. Everything else, from sign-in to the shop, is REST through @RestClient interfaces in a module both sides share. Client and server compile against the same types, so a renamed field is a compile error on both ends instead of a bug report.

Promotion and monetization are built in

A game that nobody installs doesn't make money. Skirmish uses the Codename One APIs for growth, so the code is short. Inviting a friend from Friends.java:

```java {class="cn1-no-try"}
Invite invite = Invites.create(InviteRequest.create()
.campaign(CAMPAIGN)
.channel("share_sheet")
.payload(mine.code())
.title("Join me in Skirmish")
.description("A real-time card battle. Build a deck and fight me.")
.build());




The friend who joins gets bonus coins, and the Friends screen shows who joined and who has played. The same template wires up:

- **In-app purchases** of gem packs and a season pass, with receipts verified by your server.
- **Rewarded and interstitial ads**, where a rewarded ad grants its reward through the server.
- **Push notifications** when a chest opens or a friend challenges you.
- **Funnel analytics** that show where new players drop off, with opt-in consent.
- **Campaign links** for ads and social posts outside the app, and a home screen spotlight you change from the console.

The implementor's guide includes a step-by-step tutorial on growing a game with these: turn on measurement, read the funnel, bring players back with push, then grow through invitations.

## Run the game like a live service

The admin console ships in the same app. Moderators see live matches, automatic and reported flags, and player history, and they can warn, mute, suspend or ban with an audit trail. Product owners write queries over the game data, set up engagement pipelines and broadcast promotions. It runs on the desktop as well as on a phone.


<div class="release-screenshots" style="display:grid;grid-template-columns:repeat(auto-fit,minmax(270px,1fr));gap:16px;align-items:start;margin:24px 0">
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-desktop-admin-overview.png"><img width="800" height="480" src="https://www.codenameone.com/developer-guide/img/skirmish-desktop-admin-overview.png" alt="The Skirmish admin console overview on the desktop" loading="lazy" style="width:100%;height:auto" /></a><figcaption>The admin overview.</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-desktop-admin-pipelines.png"><img width="800" height="480" src="https://www.codenameone.com/developer-guide/img/skirmish-desktop-admin-pipelines.png" alt="Engagement pipelines in the Skirmish admin console" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Engagement pipelines.</figcaption></figure>
</div>


## Make it yours

Skirmish is meant to be remixed. A few directions it could take:

- **Re-skin it** for a different setting: space, pirates, a cartoon farm. Swap the CSS palette, the glTF models and the card portraits. `PortraitStudio` renders new portraits from the models so the art stays consistent.
- **Change the game.** New cards, new arenas and a different elixir economy are data in the `rules` module. Bump `RulesVersion.ID` and the golden replay tests tell you which recorded battles changed.
- **Let players make content.** The Forge lets players build and share packs of cards, arenas and missions, and lets your designers publish official campaigns from the same editor.
- **Point an AI agent at it.** The whole game is one readable Java project, so "turn this into a cyberpunk tower defense with four lanes" is a reasonable prompt to start from.


<div class="release-screenshots" style="display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,150px),1fr));gap:16px;align-items:start;margin:24px 0">
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-deck.png"><img width="420" height="909" src="https://www.codenameone.com/developer-guide/img/skirmish-deck.png" alt="The Skirmish deck builder" loading="lazy" style="width:100%;height:auto" /></a><figcaption>The deck builder.</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-shop.png"><img width="420" height="909" src="https://www.codenameone.com/developer-guide/img/skirmish-shop.png" alt="The Skirmish shop with gem packs and a season pass" loading="lazy" style="width:100%;height:auto" /></a><figcaption>The shop.</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-friends.png"><img width="420" height="909" src="https://www.codenameone.com/developer-guide/img/skirmish-friends.png" alt="The friends screen with invitations" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Friends and invitations.</figcaption></figure>
</div>


The development profile needs nothing installed: an in-memory database, demo accounts and a simulated store. Run the server, start the simulator and play against the bot or a second simulator. The [Skirmish page](https://www.codenameone.com/skirmish/) has the overview and the [implementor's guide](https://www.codenameone.com/developer-guide/skirmish-implementors-guide/) walks through every part.

Tomorrow: [Parley: A Private Messenger Template You Can Brand](https://www.codenameone.com/blog/launch-your-own-private-messenger/).

Rewrite Everything in Java: Not Rust

Shai Almog — Fri, 30 Oct 2026 22:46:41 +0000

Rust is a great language for a kernel, a driver or a database engine. Code like that can't pause for a garbage collector and has to account for every byte, and Rust's ownership model pays for itself there. Somewhere along the way "rewrite it in Rust" turned into the default answer for everything, including desktop and mobile applications. For applications, I think that's the wrong trade. You pay more to write the code, more to review it and more to build it, and you don't get a better application in return.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

So we tested it instead of arguing about it. Wordcraft is an open source word processor written in Rust with egui. It's a serious project with over 15,000 GitHub stars, a ribbon, styles, tables, track changes and mail merge, and it publishes a 502-row feature catalog, which makes it a fair target. We built the same word processor in Java with Codename One, implemented every catalog row Wordcraft implements, and measured both apps on the same GitHub runners in the same CI run.

The Java version is faster, smaller, uses less memory, has about two thirds of the code and runs its tests several times cheaper. It also feels more native: it has a real macOS menu bar, copies formatted text into other apps, and lets you drag text and files between the document and the rest of the OS. And it ships to iPhone and Android from the same source. The details are below.

This is also the start of a busy week. A word processor makes the case with one app; the rest of the week is about what you can start with today. Three new full-stack templates join Wayline: a real-time 3D strategy game, an end-to-end encrypted messenger and a food delivery service. Each one is an app and its server in one Java project that you can brand and ship.

Coming This Week

Today is the Java against Rust story. Then one template a day, followed by the framework features those templates pushed into Codename One:

Saturday, October 24: Skirmish: A Multiplayer Strategy Game Template in Java. A real-time strategy game in the style of Clash Royale, with a 3D arena, online matches, a level editor, in-app purchases, ads and a moderation console.
Sunday, October 25: Parley: A Private Messenger Template You Can Brand. An end-to-end encrypted messenger with groups, channels, voice notes, voice and video calls, linked devices and an admin console.
Monday, October 26: Savor: A Food Delivery Template for Restaurants and Local Fleets. Customer, restaurant, courier and admin roles in one app, with card holds, live tracking and payouts.
Tuesday, October 27: More of the Java API, and an Experiment With Unity Games. A much bigger Java class library, an experiment that runs simple Unity 2D games as Codename One apps, a faster XML parser and runnable samples in the docs.
Wednesday, October 28: Native Menus, File Dialogs and 3D Models. Native open and save dialogs, native menu bars with standard commands, and animated 3D models.
Thursday, October 29: WebRTC Calls, Key Agreement and ORM Checks at Build Time. WebRTC calls, key agreement and HKDF everywhere, a backend client with mutual TLS, and ORM mistakes that fail the build.

Skirmish, Saturday.
Parley, Sunday.
Savor, Monday.

The numbers

Every figure below comes from one CI run (39825464193) that builds both apps from source and runs them on the same machines against the same documents. The workflow is in the repository, so you can rerun it. Desktop values are macOS / Linux / Windows medians with a 1,000-paragraph document.

What we measured	Java (Codename One)	Rust (Wordcraft)
Startup to the first painted document	370 / 231 / 288 ms	821 / 246 / 455 ms
Type a character to painted frame	8.9 / 10.7 / 12.4 ms	51.9 / 14.9 / 24.9 ms
Idle RAM	112 / 111 / 90 MiB	145 / 187 / 106 MiB
Executable size	34.7 / 37.7 / 32.5 MiB	55.0 / 75.2 / 57.5 MiB
Feature catalog rows	487 of 487 implementable	487 implemented, 15 stubs
Application code	76,275 lines	118,659 lines
Tokens an AI agent reads to see all of it	1,006,395	1,646,847
Cold build and full test run	97 s	961 s
CI time per test	86 ms	500 ms
Platforms from one source	macOS, Linux, Windows, iPhone/iPad, Android, browser	macOS, Linux, Windows, FreeBSD, browser

Java wins 38 of the 42 desktop measurements. The chart shows the gap on macOS as a ratio, so 2× means the Rust version needs twice as much of that resource:

The other four are close calls, and none of them is a win on every OS:

Measurement	Where Rust was ahead	Where Java was ahead
Startup with a one-paragraph document	Linux, by 4 ms (166 against 170 ms)	macOS (320 against 651 ms) and Windows (189 against 343 ms)
Save a DOCX	Linux, by 1.8 ms (5.9 against 7.7 ms)	macOS (7.7 against 12.0 ms) and Windows (7.4 against 10.3 ms)
Peak RAM during the workload	macOS by 7 MiB, Windows by 18 MiB	Linux (190 against 241 MiB)

A 4 ms difference in launching a nearly empty document isn't something a person can notice, and the same measurement on the other two systems goes to Java by hundreds of milliseconds.

It's faster

Typing latency is the number users feel. A character typed into the Java app reaches the screen in 8.9 ms on macOS; the Rust app takes 51.9 ms. At 60 Hz a frame lasts 16.7 ms, so one app stays inside a single frame and the other spends more than three. Undo is the same story, 8.9 ms against 52.3 ms.

Opening documents shows it too. Reopening the test DOCX takes 31.6 ms on macOS against Wordcraft's 132 ms, and 31.5 ms against 261 ms on Windows.

How does Java beat Rust here? Codename One compiles the app ahead of time through ParparVM, which translates the bytecode to C after dropping every class and method the app never reaches. The C compiler then inlines and optimizes across what's left. There's no JVM at run time. Garbage collection makes allocation cheap and reclaims memory on its own thread, so the application code has no ownership bookkeeping, no defensive clones and no reference counting. The UI runs on one thread while work such as saving runs in the background, and saving compresses large parts on several cores at once, without lifetimes or Send bounds to design around. We didn't use profile-guided optimization or special tuning for this benchmark. These are the defaults every Codename One app gets.

It's smaller, and it scales better

"Garbage collection wastes memory" is the first thing people tell me when I say Java should be used for desktop and mobile apps. The measurements say otherwise. The executable is less than two thirds the size on every OS, half on Linux. Idle memory is lower on all three, and the gap grows with the document:

Idle RAM	1 paragraph	1,000 paragraphs	10,000 paragraphs
macOS, Java / Rust	96 / 106 MiB	112 / 145 MiB	220 / 364 MiB
Linux, Java / Rust	94 / 164 MiB	111 / 187 MiB	198 / 387 MiB
Windows, Java / Rust	71 / 82 MiB	90 / 106 MiB	169 / 308 MiB

With a 10,000-paragraph document, the Rust version needs between 65% and 95% more memory. Startup with that document is 917 ms against 1,670 ms on macOS. Manual memory management doesn't make an app lean by itself. Data structures do, and a garbage collector frees you to pick good ones instead of the ones the borrow checker accepts.

It costs less for AI and CI

The Java code base is about two thirds of the lines and three fifths of the tokens. If you work with coding agents, tokens are the cost model: every task starts with the agent reading code, and every edit it proposes is code a human reviews. A smaller code base for the same feature catalog means less to read, a smaller context and smaller diffs.

The word processor itself was written that way. I started with Codex, then switched to Claude, and Codename One's built-in MCP server let the agents drive the running app and inspect it while they worked.

CI tells the same story. A cold build plus the full test suite takes 97 seconds for the Java app and 961 seconds for Wordcraft, on the same runner. The Java tests run on the JVM against the same code that ships natively, so a test run doesn't need a native toolchain. Rust compiles its whole dependency tree and its test binaries before it runs anything. The suites have different sizes (1,123 tests against 1,922), so per test it's 86 ms against 500 ms. About a quarter of Wordcraft's tests cover plumbing such as scroll viewports, popup placement and window state that Codename One provides as framework services and tests once.

It's easier to review

Here is how the spell checker loads its 2 MB word list without slowing startup, from Proofing.java:

```java {class="cn1-no-try"}
public static synchronized void preload(final Runnable done) {
if (preloading) return;
preloading = true;
new Thread(
(Runnable) () -> {
WordList.get();
extra();
done.run();
},
"proofing-load")
.start();
}




Any Java developer can review that in seconds. A background thread fills a shared structure, and the garbage collector owns the memory. There are no lifetimes, no `Arc<Mutex<...>>` and no `Send` bounds.

Familiarity matters too. Far more developers read Java every day than Rust, so the person reviewing a change is more likely to know the idioms. Java also asks less of them. A reviewer checks what the code does, not whether ownership, borrowing, lifetimes and trait bounds were satisfied in a way that happens to compile. That lighter mental load is a real cost difference. When an agent writes 500 lines for you, how fast a human can review them decides how fast you move.

### It's more portable

The same source builds a native iPhone and iPad app, an Android app, a browser app and desktop apps for macOS, Linux, and Windows. CI builds every one of them on each run, with a screenshot from each. On a phone, the ribbon collapses into a tab picker, the page reflows to the screen width and a touch toolbar replaces the status bar. Wordcraft has no mobile target.

There's one platform Wordcraft supports that we don't: FreeBSD. Codename One doesn't target it today. If there's demand for FreeBSD support, we'll add it, so tell us in the comments.


<div class="release-screenshots" style="display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,150px),1fr));gap:16px;align-items:start;margin:24px 0">
<figure style="margin:0"><a href="https://www.codenameone.com/blog/release-2026-10-23/wordprocessor-iphone.jpg"><img width="552" height="1200" src="https://www.codenameone.com/blog/release-2026-10-23/wordprocessor-iphone.jpg" alt="The Java word processor on an iPhone" loading="lazy" style="width:100%;height:auto" /></a><figcaption>iPhone</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/blog/release-2026-10-23/wordprocessor-android.jpg"><img width="540" height="1200" src="https://www.codenameone.com/blog/release-2026-10-23/wordprocessor-android.jpg" alt="The Java word processor on Android" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Android</figcaption></figure>
</div>



<figure style="margin:24px 0"><a href="https://www.codenameone.com/blog/release-2026-10-23/wordprocessor-web.jpg"><img src="https://www.codenameone.com/blog/release-2026-10-23/wordprocessor-web.jpg" alt="The Java word processor running in a browser" loading="lazy" style="width:100%;height:auto" /></a><figcaption>The same app in a browser.</figcaption></figure>


### It feels more native

This is the part I care about most, because users feel it before they ever see a benchmark. Portability usually means the lowest common denominator. Here it's the other way around: the Java app integrates with the operating system more deeply than the Rust one. On a Mac it has a real menu bar with the standard shortcuts, copies formatted text that Pages and Mail paste correctly, and lets you drag a selection out into another app or drop files and text in from the Finder:

| Feature | Java (Codename One) | Rust (Wordcraft) |
| --- | --- | --- |
| macOS menu bar | A native menu bar with about 40 commands and standard shortcuts | No menu bar, commands live only in the ribbon |
| Copy to other apps | HTML, RTF, Markdown and plain text, so Pages, Mail or a browser receive formatted text | Plain text only |
| Drag out to other apps | A selection drags out as rich text | No drag source |
| Drag in | Files and text, dropped at the caret | Files only |
| Paste in | HTML, RTF, Markdown, images and files | HTML, RTF and images |
| High contrast | Follows the OS setting live | Not supported |
| iPhone, iPad and Android | Native apps with touch selection handles | No mobile target |


<figure style="margin:24px 0"><a href="https://www.codenameone.com/blog/release-2026-10-23/native-menu-submenu.jpg"><img width="1400" height="871" src="https://www.codenameone.com/blog/release-2026-10-23/native-menu-submenu.jpg" alt="The Java word processor's native File menu with an Export submenu on macOS" loading="lazy" style="width:100%;height:auto" /></a><figcaption>The native menu bar on macOS, with submenus.</figcaption></figure>



<figure style="margin:24px 0"><a href="https://www.codenameone.com/blog/release-2026-10-23/native-menu-app-roles.jpg"><img width="1000" height="600" src="https://www.codenameone.com/blog/release-2026-10-23/native-menu-app-roles.jpg" alt="The macOS application menu with About, Settings and Quit" loading="lazy" style="width:100%;height:auto" /></a><figcaption>About, Settings and Quit where a Mac user expects them. Wednesday's post shows how any app gets this.</figcaption></figure>


### It looks at least as good

Wordcraft is on the left, the Java app on the right. Both are polished desktop apps, and both follow the OS dark mode live. Only one of them also looks right on a phone and follows the high contrast setting.


<div class="release-screenshots" style="display:grid;grid-template-columns:repeat(auto-fit,minmax(270px,1fr));gap:16px;align-items:start;margin:24px 0">
<figure style="margin:0"><a href="https://www.codenameone.com/blog/release-2026-10-23/wordcraft-rust.jpg"><img width="1600" height="1000" src="https://www.codenameone.com/blog/release-2026-10-23/wordcraft-rust.jpg" alt="Wordcraft, the Rust word processor, showing its built-in sample document" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Wordcraft (Rust). Screenshot from its README.</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/blog/release-2026-10-23/wordprocessor-editor-light.jpg"><img width="1600" height="835" src="https://www.codenameone.com/blog/release-2026-10-23/wordprocessor-editor-light.jpg" alt="The Codename One word processor in light mode on macOS" loading="lazy" style="width:100%;height:auto" /></a><figcaption>The Java version on macOS.</figcaption></figure>
</div>



<figure style="margin:24px 0"><a href="https://www.codenameone.com/blog/release-2026-10-23/wordprocessor-editor-dark.jpg"><img src="https://www.codenameone.com/blog/release-2026-10-23/wordprocessor-editor-dark.jpg" alt="The Codename One word processor in dark mode" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Dark mode, following the OS live.</figcaption></figure>


### It's just as secure

Memory safety is the reason most people give for choosing Rust, and it's a good reason. Java has been memory safe since 1995. Bounds are checked, there are no dangling pointers and there's no manual `free`. To its credit, Wordcraft forbids `unsafe` in its own crates, so on memory safety the two apps are even.

The difference is in the supply chain. Wordcraft's `Cargo.lock` pulls in 534 external crates. The Java app depends on the Codename One framework and its own modules. Every dependency is code someone has to trust, update and audit, so a smaller dependency tree is a smaller attack surface.

### Can Rust catch up?

For size and speed, probably. It would take a lot of work and a deep rethink of memory layout and inlining, which means even more code and even slower builds. Matching Java here would mean rebuilding, inside Rust, what Java already provides. That's the cost I'm talking about.

A personal note. I use Firefox every day, and I love what the Rust work did for its speed and stability. But Firefox is a special case, and I think it proves my point. The parts Rust replaced are the low-level ones: the style engine, the renderer, media parsing. That's exactly where Rust belongs, and it works great there. The browser's user interface, the high-level part, is written in JavaScript, a JIT compiled, garbage collected language that gives the team flexibility. Firefox effectively reinvented the high-level side of Java for itself. A browser has to have both halves. Your application only has the second one.

## Why this matters now

When I wrote [Create an Uber Clone in 7 Days](https://www.amazon.com/Create-Uber-Clone-Days-mobile/dp/1983258784) in 2018, building an Uber-style app was the goal. Today it should be where you start. With coding agents, one developer can take on a scope that used to need a team. Hello world isn't a label on a screen anymore. It's a full application with a backend, an admin console, payments and push notifications, and your work begins from there.

At that scale, the language's overhead compounds. Every extra line is something an agent writes, a human reviews and CI builds, on every change, for the life of the product. Java was designed for big code bases maintained by many people, and it shows. It has a huge ecosystem, readable code, a fast compiler, fast tests and a garbage collector that takes memory management off your plate. Spending that budget on lifetimes in a settings screen doesn't buy your users anything.

That's the direction Codename One is taking: complete starting points, plus everything around the code that a real product needs.

Each template is a working application and its server in one Java project. The client and server share the API types, so a REST call or a WebSocket message is type checked on both ends. Growth and monetization are built into the framework instead of bolted on: invite-a-friend links, analytics, push notifications, ads and in-app purchases are all Codename One APIs that the templates already use. Commerce is the next piece we're working on. The template source is free under [MIT-0](https://github.com/codenameone/CodenameOne/blob/master/scripts/skirmish/LICENSE), with no royalties and no revenue share.

## More This Week

### A real-time 3D strategy game, royalty free

For years I avoided pitching Codename One for games. That changed while we built these templates: a modern mobile game is mostly app. Sign-in, menus, a shop, friends, quests, push and a server, with the battle as a small part of the code. **Skirmish** is a real-time strategy game in the style of Clash Royale. Two players face each other across a 3D arena of animated glTF characters, each drawing troops and spells from a deck, and try to bring down the other's towers. Matches run online in lockstep over a WebSocket, with replays, progression, gem packs, a season pass, ads, and invites.


<video controls playsinline preload="metadata" poster="https://www.codenameone.com/blog/release-2026-10-23/skirmish-walkthrough-poster.jpg" style="width:100%;max-width:420px;height:auto;display:block;margin:0 auto" aria-label="A walkthrough of Skirmish: sign-in, the home screen, the guided training battle and a battle against a bot">
<source src="https://www.codenameone.com/blog/release-2026-10-23/skirmish-walkthrough.mp4" type="video/mp4">
<a href="https://www.codenameone.com/blog/release-2026-10-23/skirmish-walkthrough.mp4">Download the Skirmish walkthrough video</a>.
</video>


Every menu in that video is a regular Codename One component, laid out with layout managers and styled in CSS.


<div class="release-screenshots" style="display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,150px),1fr));gap:16px;align-items:start;margin:24px 0">
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-home.png"><img width="420" height="909" src="https://www.codenameone.com/developer-guide/img/skirmish-home.png" alt="The Skirmish home screen" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Home, chests and quests.</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-online-battle.png"><img width="420" height="909" src="https://www.codenameone.com/developer-guide/img/skirmish-online-battle.png" alt="An online Skirmish match" loading="lazy" style="width:100%;height:auto" /></a><figcaption>An online match.</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-shop.png"><img width="420" height="909" src="https://www.codenameone.com/developer-guide/img/skirmish-shop.png" alt="The Skirmish shop" loading="lazy" style="width:100%;height:auto" /></a><figcaption>The shop.</figcaption></figure>
</div>


The game is only half of what ships. **The Forge** is a level editor inside the game, where players and your designers build units, arenas, missions and whole campaigns and share them as packs. And an admin console runs the game like a live service: live matches, reports and flags, player history with audited moderation, queries over game data, engagement pipelines and promotions. It works on a phone and on the desktop.


<div class="release-screenshots" style="display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,150px),1fr));gap:16px;align-items:start;margin:24px 0">
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-forge-editor.png"><img width="1125" height="2436" src="https://www.codenameone.com/developer-guide/img/skirmish-forge-editor.png" alt="The Forge level editor in Skirmish" loading="lazy" style="width:100%;height:auto" /></a><figcaption>The Forge, the level editor.</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-forge-arena.png"><img width="1125" height="2436" src="https://www.codenameone.com/developer-guide/img/skirmish-forge-arena.png" alt="Designing an arena in the Forge" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Designing an arena.</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-admin-overview.png"><img width="420" height="909" src="https://www.codenameone.com/developer-guide/img/skirmish-admin-overview.png" alt="The Skirmish admin console on a phone" loading="lazy" style="width:100%;height:auto" /></a><figcaption>The admin console.</figcaption></figure>
</div>



<div class="release-screenshots" style="display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,270px),1fr));gap:16px;align-items:start;margin:24px 0">
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-desktop-admin-overview.png"><img width="800" height="480" src="https://www.codenameone.com/developer-guide/img/skirmish-desktop-admin-overview.png" alt="The Skirmish admin console on the desktop" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Live operations on the desktop.</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/skirmish-desktop-admin-pipelines.png"><img width="800" height="480" src="https://www.codenameone.com/developer-guide/img/skirmish-desktop-admin-pipelines.png" alt="Engagement pipelines in the Skirmish admin console" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Engagement pipelines.</figcaption></figure>
</div>


Adding a unit to the game is one line in the shared rules module:



```java {class="cn1-no-try"}
add(new CardDef("squire", "Squire", CardDef.TROOP, 3)
        .hp(1450).damage(160).hitTicks(24).range(700).speed(45).radius(500));

No royalties, no per-install fees, no revenue share. Saturday's Skirmish article walks through the arena, the multiplayer model and the monetization.

A messenger your server can't read

Hospitals, companies and communities want their own messenger and can't use WhatsApp for it. Parley is that messenger: chats, groups, channels, voice notes, voice and video calls and linked devices, encrypted end to end with X3DH and the Double Ratchet, the design Signal uses. The server stores and forwards ciphertext, and calls go peer to peer.

Chats, groups and channels. An encrypted conversation. Calls, peer to peer. Moderation without reading messages.

The crypto reads like ordinary Java because the primitives are now part of Codename One:




Sunday's [Parley article](https://www.codenameone.com/blog/launch-your-own-private-messenger/) covers the protocol, moderation and how to brand it.

### Food delivery without the platform's cut

Delivery platforms often take between 15% and 30% of every order. **Savor** gives a restaurant, a chain or a local startup its own service: one app whose landing screen depends on the role (customer, restaurant, courier or admin), card holds captured on delivery, live tracking on a map with no API key bill, and order and delivery state machines that can't get confused when two people act at once.


<div class="release-screenshots" style="display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,150px),1fr));gap:16px;align-items:start;margin:24px 0">
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/savor-customer-home.png"><img width="420" height="909" src="https://www.codenameone.com/developer-guide/img/savor-customer-home.png" alt="The Savor customer home screen" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Customer</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/savor-merchant-queue.png"><img width="420" height="909" src="https://www.codenameone.com/developer-guide/img/savor-merchant-queue.png" alt="The restaurant's order queue" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Restaurant</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/savor-courier-offer.png"><img width="420" height="909" src="https://www.codenameone.com/developer-guide/img/savor-courier-offer.png" alt="A delivery offer for a courier" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Courier</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/savor-admin-dashboard.png"><img width="420" height="909" src="https://www.codenameone.com/developer-guide/img/savor-admin-dashboard.png" alt="The Savor admin dashboard" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Admin</figcaption></figure>
</div>


Monday's [Savor article](https://www.codenameone.com/blog/launch-your-own-food-delivery-app/) shows the flow and the ways to reshape it, from a single restaurant to groceries or flowers.

### More of Java, and a question about Unity

The class library gained 116 classes and interfaces, including `java.util.function`, streams, `Optional`, `java.time` and readers and writers. Existing Java code ports with fewer changes, and ParparVM and the obfuscator strip whatever your app doesn't call, so the overhead is minor. There's still no reflection and no class loading, on purpose.

We also tried something new to learn from what Unity does right: simple Unity 2D projects, C# scripts and all, now build and run as Codename One apps. Five open source games run unmodified. It's a proof of concept, and you can't take any Unity game and run it.


<div class="release-screenshots" style="display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,270px),1fr));gap:16px;align-items:start;margin:24px 0">
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/unity-interop-fruitopia.png"><img width="960" height="540" src="https://www.codenameone.com/developer-guide/img/unity-interop-fruitopia.png" alt="Fruitopia, an open source Unity platformer, running on Codename One" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Fruitopia</figcaption></figure>
<figure style="margin:0"><a href="https://www.codenameone.com/developer-guide/img/unity-interop-sokoban.png"><img width="960" height="540" src="https://www.codenameone.com/developer-guide/img/unity-interop-sokoban.png" alt="An open source Unity Sokoban game running on Codename One" loading="lazy" style="width:100%;height:auto" /></a><figcaption>Sokoban</figcaption></figure>
</div>


Would that be useful to you? Tuesday's [Java and Unity article](https://www.codenameone.com/blog/bring-your-java-code-everywhere/) asks, and also covers a faster XML parser and a button in the API docs that runs each sample in your browser.

### Desktop apps that feel native

The word processor needed a real menu bar and real file dialogs to hold up next to a native app, so now every Codename One app has them. A `Command` goes into the native menu bar with one call, and standard commands land where each OS expects them, with its own shortcuts:



```java {class="cn1-no-try"}
Command settings = Command.createDesktopRole(Command.DESKTOP_ROLE_SETTINGS, e -> showSettings());
Command quit = Command.createDesktopRole(Command.DESKTOP_ROLE_QUIT, e -> quit());

That's "Settings…" with Cmd+, on a Mac, "Options" under Tools on Windows and "Preferences" under Edit on Linux. Open and save dialogs are the operating system's own, with filters, options and a preview where the platform supports them:

An open dialog with a preview and an option. Standard commands in the macOS application menu.

Wednesday's desktop article has the details, plus the animated 3D models behind Skirmish.

Calls, crypto and an ORM that fails the build

Voice and video calls are now a Codename One API, built on WebRTC on Android, iOS and the browser. Signaling stays yours, so the same code works with any server:

```java {class="cn1-no-try"}
WebRtc.openUserMedia(true, true, true).ready(media -> {
pc = WebRtc.createPeerConnection(config, listener);
pc.addTrack(media.getAudio());
pc.addTrack(media.getVideo());
pc.createOffer().ready(offer -> pc.setLocalDescription(offer)
.ready(done -> signalling.send(offer)));
});




Turning a key agreement into an encryption key takes two lines, and works the same on every device and on the server:



```java {class="cn1-no-try"}
byte[] shared = KeyAgreement.ecdh(mine.getPrivateKey(), theirs.getPublicKey());
byte[] key = Hkdf.derive("SHA-256", null, shared, "chat message key v1".getBytes(), 32);

On the server, a partner API that wants a client certificate and HTTP/2 is one builder:

```java {class="cn1-no-try"}
WebClient partner = new WebClient()
.setClientCertificate(ClientCertificate.pkcs12(archive, password))
.setRequireHttp2(true)
.setRequestTimeoutMillis(10000);




And with Hibernate and Spring, plenty of mapping mistakes compile fine and blow up when the app starts or on the first request that touches the entity. Codename One's ORM reads your entities at compile time, so these are build errors:

@temporal requires a java.util.Date field: signedUp
Persistent fields must be writable: name
@entity class com.example.Customer must declare a public no-arg constructor




Thursday's [calls and backends article](https://www.codenameone.com/blog/private-calls-and-safer-backends/) goes through each of these.

## Where is this going?

I don't want this read as "Rust is bad." If you're writing a kernel module, a codec, an embedded controller or anything with hard real-time limits, determinism matters more than throughput, and Rust is an excellent choice. A user-facing application has different constraints. It can trade determinism for throughput, for a smaller code base and for a team that moves faster.

For applications, Java is the better tool, and Codename One is turning into the place where you start with a whole product instead of a blank screen. The word processor is now on the [demos page](https://www.codenameone.com/demos/). Clone the [repository](https://github.com/shai-almog/cn1-wordprocessor), rerun the benchmark workflow and check my numbers. If you find a measurement I got wrong, open an issue there. And if you want to start a project today, the [Initializr](https://www.codenameone.com/initializr/) generates any of the templates in a minute.

A Java IDE in Your Browser, With Your Files in Your Browser

Shai Almog — Thu, 29 Oct 2026 19:19:54 +0000

If you're used to opening a page and immediately changing an app, installing a Java development environment is a substantial detour. I want your first encounter with Codename One to be the app running.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

Our new browser IDE is a highly experimental, very early preview. Open it, press Run and start changing the Java. It has a project tree, multiple files and an application preview. Think of the Playground growing into a proper IDE workspace.

I'm calling it Not a Cloud IDE because the editing, compilation for preview and application execution happen in your browser. Your project files stay in that browser's storage. The ordinary build server enters the workflow when you request a cloud build.

Start with an app on the screen

The first visit opens a GettingStarted project. Press Run in the top toolbar. The editor compiles Java and shows the application beside its source. This screenshot shows that starter running in the public preview:

You can start with a small edit. Inside the starter's runApp() method, this replaces its initial screen with a counter:

Form hi = new Form("First app", BoxLayout.y());
Label count = new Label("Trips: 0");
Button add = new Button("Add a trip");
int[] trips = {0};
add.addActionListener(event -> count.setText("Trips: " + (++trips[0])));
hi.addAll(count, add);
hi.show();

The starter already imports the UI and layout classes. Run it, click the button and change the label. The point of this first exercise is to shorten the distance between an idea and a visible result.

Compiler errors appear against the source. Completion, hover information and source navigation help you explore the API. They don't amount to a full Java language server or IntelliJ's refactoring model, and I don't want to present them that way.

What runs where

The site delivers the editor and toolchain. Dependencies may need downloading too. That doesn't make the editing session a remote machine: there is no server-side workspace running your development loop.

A cloud build is an explicit handoff of build inputs to the existing Codename One service. It is separate from local preview and doesn't back up your editable workspace. Opening the IDE also doesn't make the whole workflow available offline.

Browser storage is local storage

The toolbar says Saved only in this browser · No cloud backup. Take that literally. Signing in on a second computer or switching browser profiles won't bring your project along.

Use Download ZIP to keep a backup and take the project to your desktop. Clearing the site's browser data or using private browsing can erase your local work. The export gives you a project you can continue building with the usual Maven or Gradle tools.

This is also why I like the approach for getting started. You can try the framework in a page, then keep the code when you're ready to set up a local environment.

Where the experiment ends today

This will not replace IntelliJ. We can't reproduce the full Java ecosystem, every desktop tool and every build plugin inside JavaScript. Browser preview supports a defined subset of dependency and build behavior; projects outside that subset need a local build.

Backend projects can be created, edited and exported, but there is no backend runtime in the browser. Full stack preview currently runs the client only. Don't expect Wayline's backend to start inside the editor tab.

The IDE exposes settings, GUI Builder and cloud-build actions, but this is early software. A successful browser preview is also not proof that every device API will behave identically on a phone. Check your real targets as the project grows.

Make the first experiment small

Last week's Playground compiler showed real Java compilation in a page. The IDE gives that loop a workspace you can grow beyond one snippet.

Try the counter, change its layout and download the project. That is the experience I want to make ordinary: a person curious about Java can see their own change running before spending the afternoon configuring tools.

This closes our weekly release series. Between a full-stack ride-hailing application and a browser workspace, we're working on both ends of the same problem: getting you to the part of an application that is yours.

Discussion

What is the first small app you would try if opening a page were all the setup it needed?

Let Users Install Your Java Web App Again

Shai Almog — Wed, 28 Oct 2026 21:00:54 +0000

We lost progressive web app support when we moved the JavaScript port from TeaVM to ParparVM. It's back. Users can install your browser app on supporting browsers, and its cached application files can load when the network is unavailable.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

For a small business, a link can be the quickest way to put an app in someone's hands. Installation lets that same app remain within reach after the tab closes. This is Wednesday's follow-up to the Wayline release story.

The build makes the installation files

A ParparVM JavaScript application build now produces manifest.json, home-screen icons and sw.js automatically. There is no separate PWA enablement switch.

Deploy the whole generated bundle, including subdirectories, over HTTPS. Localhost also works for testing. Relative manifest and asset URLs let an application live under a path such as /dispatch/ rather than requiring a dedicated domain root.

You can customize the app's identity through build hints in codenameone_settings.properties:

codename1.arg.javascript.manifest.name=Station Dispatch
codename1.arg.javascript.manifest.short_name=Dispatch
codename1.arg.javascript.manifest.description=Your station's dispatch app
codename1.arg.javascript.manifest.display=standalone

The default manifest already requests a standalone window. name and short_name default to the application's display name. Installation UI and eligibility depend on the browser, so avoid making your onboarding depend on one particular prompt appearing.

Offline launch has a precise boundary

The service worker caches generated application files: the runtime, translated JavaScript chunks, themes and bundled resources. It must finish installing while online before those files can support an offline launch.

It doesn't cache API responses, proxy requests or external resources. Application data and synchronization remain your responsibility.

In Wayline, that means a cached UI is not permission to accept a ride offline. Matching needs the server, and the map's external tiles and routes aren't bundled application assets. A dispatch app should say that it is disconnected rather than show a stale assignment as confirmed.

This distinction is useful outside ride hailing too. A locally stored draft can remain editable; publishing that draft still needs a connection. Design the interaction around what you actually have on the device.

An update should belong to one version

A running app needs its runtime and resources to agree. The worker creates a new cache when content changes, even if the application's version string stays the same.

The new worker waits until the old app's tabs and windows close before activating. That keeps an open app from mixing an old runtime with new chunks. Each deployment path has its own cache, so two apps on the same host don't share one undifferentiated bucket.

Deploy the files together and allow the browser to revalidate sw.js. Cache versioning helps the client choose a coherent bundle; it doesn't turn a partially uploaded deployment into a complete one.

Check the behavior your users will get

After deploying a test build, open the browser's Application tools and inspect the manifest, service worker and cache. Wait for installation to finish, then reload offline. Check both the UI that should work and the operations that should report a missing connection.

For an update check, keep one old tab open, deploy a visibly changed build and confirm that the new worker waits. Close the old tabs and reopen the app. Test a subdirectory deployment too if that is how you host it.

The repository includes a browser smoke test and service-worker contract checks. Those tests exercise caching and update behavior; they don't establish that every browser offers the same install experience.

PR #6022 restores the capability, and the JavaScript guide explains manifest customization. A web deployment can be a useful first distribution channel for your application, with native apps alongside it when their device integration matters.

Discussion

What should your app still let a user do after the connection drops?

Give Your Desktop App a Useful Title Bar and Real Tools

Shai Almog — Tue, 27 Oct 2026 19:01:49 +0000

A document editor needs room for the document. Giving an entire row to a title, then adding another row for Save and Search, spends that room quickly.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

You can now put Codename One components into the title area of native macOS, Windows and Linux apps. It's a niche capability until you're building an editor. Then the details of window dragging and button hit testing become part of your product.

This weekly follow-up also covers two less visible desktop capabilities: launching external tools and reading or writing ZIP streams. Together they make it easier to build an application that fits into the user's existing workflow.

Our native macOS editor prototype, cropped to its title area and ribbon. Save, Undo, document status and command search use the top row; the document begins below the ribbon.

Put Save where the user is already looking

Use desktop.titleBar=custom, then supply a title component through the ordinary toolbar API. This is the guide's editor example:

public static Form createEditor(Command save, Command search) {
    Display.getInstance().setProperty("desktop.titleBar", "custom");
    Toolbar.setGlobalToolbar(true);
    Form editor = new Form("Quarterly report", new BorderLayout());
    Container title = new Container(new BorderLayout());
    title.add(BorderLayout.WEST, new Button(save));
    title.add(BorderLayout.CENTER, new Label("Quarterly report"));
    title.add(BorderLayout.EAST, new Button(search));
    editor.getToolbar().setTitleComponent(title);
    return editor;
}

Call it from the application's normal lifecycle, after framework initialization and before constructing other forms that need this mode. The Command arguments are your actions. You can also select the mode with codename1.arg.desktop.titleBar=custom in the build settings.

Don't add fixed padding for macOS traffic lights or Windows caption buttons. The framework reserves space for the real OS controls, accounting for changes such as window DPI. Your components stay in the Java component tree while the port handles window gestures.

Native desktop	Who owns the window behavior?
macOS	AppKit keeps the traffic lights, resizing and system menu. Empty title space follows native dragging and the user's double-click preference.
Windows	The Desktop Window Manager keeps caption controls. Native hit testing handles empty title space and resize edges.
Linux	A GTK header bar places rendered application content beside real window controls and follows desktop decoration settings.

Buttons, editable fields and other interactive descendants keep their input. Disabled buttons are excluded from dragging too. Plain labels and passive container backgrounds can move the window. For a custom painted background, Toolbar.setTitleBarDragRegion(component, true) opts it into dragging while preserving interactive children.

There are platform differences. Windows custom mode omits the separate Win32 menu row; provide visible access through your toolbar, side menu or ribbon. Linux keeps its menu row below the header, and macOS keeps the system menu bar. This applies to the main form in native desktop builds. Separate dialogs retain their decorations, and browser pages don't gain control of browser chrome.

The desktop integration guide has the full contract, introduced in PR #6019. The useful feature is the complete interaction, including the parts that keep a click on Search from moving the window.

Call the tool your user already has

We originally wanted a Process API for backend work. It made sense for desktop applications too: an editor can invoke a converter, inspect a tool's version or run an existing command-line utility.

The shared classes are com.codename1.io.ProcessBuilder and com.codename1.io.Process. Check support before offering the action:

boolean canRunTools = com.codename1.io.ProcessBuilder.isSupported();

The API works in JavaSE desktop builds, the native Windows/macOS/Linux ports, the JVM backend and the packaged Linux ParparVM backend. Android, iOS and the browser don't support process launching through this API.

Here is the launch portion of a worker task, assuming toolPath names an installed executable:

try (com.codename1.io.Process child =
        new com.codename1.io.ProcessBuilder(toolPath, "--version")
                .redirectErrorStream(true)
                .start()) {
    child.getOutputStream().close(); // This command needs no stdin.
    // Start a reader for child.getInputStream() before waiting.
    // Apply a timeout, inspect the exit code, and handle the output.
}

This is a launch excerpt, not a complete runner. The complete guide example drains output on a separate thread and uses a timed wait. Waiting first can deadlock if the child fills its output pipe. Keep both process I/O and waits off the UI event thread.

Arguments are passed literally; the API doesn't insert a shell. Working directories are native path strings. File redirection, pipelines and ProcessHandle aren't part of this subset. Closing the process requests termination and closes its streams, but doesn't kill descendants or wait for exit. PR #6010 contains the implementation.

Give users an archive they can use

ParparVM now implements the streaming subset of java.util.zip. That includes ZIP entry streams, GZIP, deflate/inflate and checksums. JVM and Android builds use their platform implementations; ParparVM uses the existing Java compression engine.

Writing a small UTF-8 entry looks familiar. Here destination is the output stream your caller supplies; closing the ZIP also closes it:

try (java.util.zip.ZipOutputStream zip =
        new java.util.zip.ZipOutputStream(destination)) {
    zip.putNextEntry(new java.util.zip.ZipEntry("report.txt"));
    zip.write("Completed rides\n".getBytes("UTF-8"));
    zip.closeEntry();
}

A project export has an extra requirement: its launcher should still be executable after extraction. ZipArchiveOutputStream adds a permission argument to the familiar entry operation:

ZipEntry launcher = new ZipEntry("project/run.sh");
launcher.setTime(0);
zip.putNextEntry(launcher, 0755);
// Copy the launcher bytes to zip, then call closeEntry().

Here zip is a com.codename1.io.zip.ZipArchiveOutputStream. The server download example streams directly to an HTTP response and includes the full copy loop. This avoids building an entire archive in memory, although entry metadata still takes space.

This isn't every Java SE archive feature. ParparVM's subset excludes random-access ZipFile, ZIP64 and encrypted archives. Reading to the end of an entry verifies its CRC and size; closing an archive early doesn't verify unread entries. An importer still needs to validate paths and bound extracted data. PR #6006 introduced the streaming support.

A useful title area, an external tool and an export users can open are modest features individually. They are also the things that decide whether a desktop app can become part of someone's daily work.

Discussion

What would you put in your app's title area if the window controls were already handled?

Build Your App Theme Without a Display Server

Shai Almog — Mon, 26 Oct 2026 19:15:24 +0000

A build container shouldn't need a pretend monitor to compile a stylesheet. Until now, parts of our CSS build path pulled in desktop machinery that made that a practical concern.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

The CSS compiler now runs 100% headless. You can compile the same theme over SSH, in a container or on a CI worker without starting a display server or virtual framebuffer. This is Monday's build-tools installment of the weekly series.

Keep the output, remove the window

Codename One CSS is compiled into a resource file. The app loads theme.res; it doesn't parse your stylesheet at runtime.

The compiler needs enough of the framework to construct fonts, convert some units and process images. Previously, reaching those APIs could bring desktop initialization along with them. The new implementation supplies the services theme construction needs without starting a GUI.

Images still need decoding and scaling. The implementation uses Java's image APIs with buffered images, which work in headless mode. A build without a monitor is still a build that processes visual assets.

The headless implementation fixes the conversion values used during theme construction instead of taking them from the build machine's display. That removes another source of variation between a developer laptop and a worker.

Use your existing CSS workflow

New Maven apps already enable CSS. An older project can enable it in common/codenameone_settings.properties:

codename1.cssTheme=true

The existing goal still compiles the theme:

mvn cn1:css

For a check that explicitly exercises headless operation, run the goal with the JVM's headless flag:

mvn -Djava.awt.headless=true cn1:css

Your normal application build invokes CSS compilation as needed too. The CSS goal reference and CSS chapter cover the project layout and output.

Stylesheets can be split into local files. Imports go before ordinary rules, and a URL inside an imported stylesheet remains relative to that file:

@import "widgets/buttons.css";

WlPrimary {
    background-color: #1f5eff;
    color: #ffffff;
    border-radius: 2.4mm;
}

WlPrimary is a component UIID, the name a Codename One component uses to select its style. It isn't a browser class selector. Missing imports and import cycles fail the build. Remote stylesheet imports are refused.

What gets faster, and what to measure

Removing GUI startup and framebuffer setup removes work from the theme build. It also removes display configuration that an automated tool otherwise has to install and diagnose. That's a useful reduction even before comparing build times.

I don't have a representative end-to-end timing to attach to every project. A large build may spend most of its time compiling Java or downloading dependencies. Measure the CSS step and the complete build separately before attributing a change to this compiler.

A simulator still displays a GUI. UI tests still need their own execution environment. This change lets a theme compile without one; it doesn't make every graphical test headless.

The risk is in the small details

Our CSS compiler already had fragile corners. Replacing its execution environment is a change I want users to benefit from, and also one I want them to check carefully.

A build can succeed while a shadow, font metric or image border looks different. Compare representative screens after updating, particularly where styles depend on physical units, generated images, pressed states or dark-mode overrides. A tiny stylesheet that reproduces a difference is much more useful than a screenshot of a whole application without its theme.

Wayline gives us concrete screens to inspect. Its primary buttons share a style, and the rider map switches colors with the theme:

Wayline rider map in the light theme.
The same rider screen in the dark theme.

These are maintained Wayline guide screenshots, not a before-and-after comparison of compiler output.

The new compiler is in PR #5965. Try the headless CSS goal on your CI image, then inspect the screens your users actually use. The build setup should get smaller while the app keeps the appearance you chose.

Discussion

Which part of your build still needs a desktop environment when it shouldn't?

Thymeleaf, Spring MVC and htmx for Native Java Backends

Shai Almog — Sun, 25 Oct 2026 17:22:45 +0000

Thymeleaf, Spring MVC and htmx are a combination Java developers can put to work quickly: templates for the view, controllers for the request and partial updates where they help. We now support that programming model with a different execution path: statically compiled rendering code inside a native Java backend.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

The template compiler processes a supported subset of Thymeleaf syntax and emits Java renderers with direct model access. Spring MVC-style controllers choose the page or fragment. ParparVM compiles the renderers with the rest of the backend into native code. The response is still ordinary HTML that any browser can display.

This is Sunday's follow-up to Create an Uber Clone in 1 Minute. It also gives you another way to build an admin site: ordinary HTML served by your Java backend, without requiring a Codename One client.

Move template work out of the request path

The performance case is concrete: production doesn't parse template files, interpret property expressions or discover model accessors through reflection. A model property becomes a Java getter or field access; a loop becomes generated control flow. The native compiler sees that code alongside the controller and service.

With htmx, the server returns only the part of the page that changed. Static rendering and smaller responses address different costs, and work well together. Database work, network latency and the page itself still determine end-to-end response time.

Keep the useful part of JSP

JSP compiled pages into Java servlet code, as Tomcat's Jasper documentation describes. Native compilation wasn't the JSP contract. The useful idea was that a template could become code the runtime already knew how to execute.

The old workflow suited a long-running server you could telnet into and edit in place. I want to edit quickly while developing too. In production, I want a built artifact that went through the same checks as the Java beside it.

Thymeleaf supports template caching, so it would be wrong to describe every request as parsing a fresh file. Our choice goes further: the request path has no template interpreter at all. Editing a template means rebuilding the application.

The sample running locally on the JVM with generated view classes. The same renderers enter the native package.

The controller still looks like a controller

The runnable catalog has an in-memory inventory. Its listing method is short:

@GetMapping("/products")
public synchronized String list(Model model, HttpServer.Request request) {
    populate(model);
    return Htmx.isRequest(request) ? "products :: catalog" : "products";
}

This method belongs to a @Controller using com.codename1.backend.annotations and com.codename1.backend.mvc imports. populate copies the catalog into the model. A normal request gets the page; a request from htmx gets its named catalog fragment.

That return value names a compiled view. It doesn't open a path supplied by the request. The list is synchronized because this small example keeps mutable data in memory; restarting it resets the catalog. A persistent application would delegate to a service and database.

Tell the compiler what your model contains

The template declares the Java type of products. A shortened version of the catalog view looks like this:

<!-- cn1:model products java.util.List<example.Product> -->
<main id="workspace" th:fragment="catalog">
  <table>
    <tbody>
      <tr th:each="product : ${products}">
        <td th:text="${product.name}">Notebook</td>
        <td th:text="${product.quantity}">12</td>
        <td th:text="${product.active ? 'Active' : 'Inactive'}">Active</td>
      </tr>
    </tbody>
  </table>
</main>

The compiler resolves the Java getters or public fields and emits direct access. Rename a property without updating the template and the build fails with a file and source position. That is a useful failure to get before deployment.

Dynamic text is escaped. URL expressions encode their arguments before HTML attribute escaping. Raw HTML insertion and arbitrary method calls are outside this first version's expression language.

Update a section without building a second frontend

The Add product link in the catalog works as ordinary navigation and carries the htmx enhancement:

<a href="https://www.codenameone.com/products/new"
   hx-get="/products/new"
   hx-target="#workspace"
   hx-swap="outerHTML">Add product</a>

The server can return the editor fragment and replace the workspace. The sample includes a pinned local htmx script, shared layout fragments and forms that also work with JavaScript disabled.

Form binding uses a dedicated DTO. Keep BindingResult immediately after that parameter, then return the editor when validation fails:

@PostMapping("/products")
public synchronized String add(
        @ModelAttribute("form") ProductForm form,
        BindingResult errors,
        Model model,
        HttpServer.Request request) {
    validate(form, errors);
    if (errors.hasErrors()) return invalid(model, request, "/products", "Add product");
    int id = nextId++;
    products.put(id, new Product(id, form.name.trim(), form.quantity, form.active));
    return saved(model, request);
}

This is an excerpt from Catalog, including its storage and validation helpers by reference. saved chooses the full-navigation redirect or the updated fragment. Returning form errors with status 200 lets htmx display them normally.

Submitting the form without a name returns the editor fragment with the error beside the field.

The existing security chain handles cross-site request forgery (CSRF) protection. Generated forms and mutating htmx controls carry the available token. Declaring an HTML controller doesn't create that security configuration for you; the sample's WebSecurity shows it.

A smaller language is a trade

This is a Thymeleaf-style subset, not the Thymeleaf library. There is no Spring Expression Language, custom dialect support, arbitrary method invocation or runtime template editing. Form DTOs support scalar values; they don't bind whole ORM entity graphs. The views chapter lists supported attributes and migration boundaries.

Those restrictions buy typed property access and a renderer that ships as ordinary compiled application code. They also mean porting an existing template can take work. I would start with a small admin page and its form errors before attempting a large site.

From scripts/backend-mvc, with this checkout's backend and plugins installed, run:

mvn package
mvn com.codenameone:codenameone-maven-plugin:8.0-SNAPSHOT:backend

Open http://localhost:8080/products. The sample's README has the native packaging command and a smoke test covering normal forms, htmx, escaping and CSRF rejection. PR #5974 introduced the implementation.

I want the development loop to stay short. I also want the production binary to know how to render every page before the first user arrives.

Discussion

Which template error would you most like your build to catch?

Spring Data-Style Repositories Compiled to Native Code

Shai Almog — Sat, 24 Oct 2026 16:40:54 +0000

If you use Spring Data, a method such as findFirstByDriverAndStateIn tells you what a repository does before you open its implementation. Codename One now brings that repository model to both the client and backend, with generated Java code that can compile directly into a native executable.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

The advantage is familiar data access with the runtime setup removed. The build generates concrete repository implementations. Native packaging compiles them ahead of time, so startup doesn't need to scan for repositories or generate proxies. Direct calls also give the compiler code it can analyze and optimize.

This week's Wayline application uses these repositories for its ride-hailing service. Alongside them, Spring-style transaction isolation and completion callbacks let you control when another part of the system can act on a database change.

Put the query where you can find it

Wayline's repository declares what it needs to read. This shortened interface comes from its RideRepository:

import com.codename1.orm.repository.CrudRepository;
import com.codename1.orm.repository.Repository;
import com.codenameone.examples.wayline.api.RideState;
import com.codenameone.examples.wayline.domain.Ride;

@Repository(entity = Ride.class, key = String.class)
public interface RideRepository extends CrudRepository<Ride, String> {
    Ride findFirstByRiderAndStateIn(String rider, RideState[] states);
    Ride findFirstByDriverAndStateIn(String driver, RideState[] states);
}

The build generates the implementation. It makes direct calls into the session; it doesn't discover repositories by scanning classes at runtime. There is no Hibernate dependency or runtime proxy generation. The same repository API works with client ORM sessions and backend sessions.

Spring Data users will recognize the naming convention. Hibernate users will recognize managed entities and dirty checking. These are supported conventions under Codename One's packages, with a deliberately bounded API. Existing Spring or Hibernate dependencies don't become portable just because the method names look familiar.

The inherited methods include insert, save, findById, findAll, count, existsById and deleteById. There are a couple of details to remember: a missing findById returns null, and save returns the managed object produced by merge. Keep that returned value if you continue changing it.

Static compilation does the setup work once

A repository interface becomes a concrete implementation during the build. With ParparVM, that Java implementation joins the rest of the application in the native binary. There is no reflective repository dispatch or runtime implementation factory to initialize.

That removes work from startup and from dispatching repository calls. It doesn't remove the cost of the database query: indexes, round trips and the number of rows still matter. CASE aggregation and pagination help keep that work in the database instead of loading unnecessary entities.

A long method name isn't always the clearest query

Derived finders cover comparisons, And/Or, explicit ordering and limited results. A final PageRequest(offset, size) gives a list query a page without issuing a separate total-count query. Include a unique tie-breaker in the ordering so rows with equal scores don't wander between pages.

For a conditional aggregate, declare the query. This shortened example uses the guide's RepositoryRecord entity, which has a numeric score:

@Query("select sum(case when r.score >= :floor then 1 else 0 end) "
        + "from com.codenameone.developerguide.snippets.repository.RepositoryRecord r")
Long qualified(@Param("floor") long floor);

CASE expressions let the database count qualifying rows instead of making the app fetch them all. Named values are bound parameters. Native SQL queries are available too, with a narrower scalar-result API and the portability costs of the SQL you choose.

The repository reference spells out the grammar. Unsupported method signatures fail generation. JPQL syntax and mapped names are checked when the method creates its query, before SQL execution. That distinction matters: this isn't a promise that every query error becomes a compile error.

Keep the transaction in the service

Repositories don't open or commit transactions. The service owns that boundary. Here is Wayline's actual read path:

@Transactional(readOnly = true)
public RideDto activeForRider(String rider) throws IOException {
    Ride ride = rides.findFirstByRiderAndStateIn(rider, ACTIVE);
    return ride == null ? none() : toDto(ride, rider, new HashMap<String, Profile>());
}

The snippet sits inside Rides, with its repository and mapping helpers. Methods that change several entities use a transaction around that unit of work. A repository's session participates in it, so changing a managed entity can be flushed when the transaction completes.

Bulk operations deserve separate attention. Derived deletes and declared modifying queries flush pending changes, execute bulk SQL and clear the persistence context. They bypass per-entity callbacks and cascades. Reload objects before continuing; references you kept still contain their old Java values.

Choose isolation at the outer boundary

The annotation now accepts an isolation level:

import com.codename1.backend.annotations.Isolation;
import com.codename1.backend.annotations.Transactional;

// Annotation for a service method that owns the transaction:
@Transactional(isolation = Isolation.SERIALIZABLE)

This is an annotation excerpt, to place on the method that starts the work. It requests a physical transaction with that level. It doesn't silently upgrade an outer transaction that already exists.

Database	Explicit isolation levels
SQLite	`SERIALIZABLE`
PostgreSQL	`READ_COMMITTED`, `REPEATABLE_READ`, `SERIALIZABLE`
MySQL/MariaDB	Those three plus `READ_UNCOMMITTED`, with transactional tables

A joined scope requesting an explicit level must match the outer scope's explicit level. Joining a DEFAULT scope with an explicit request fails. Choose the level at the start, or use REQUIRES_NEW when the operation really needs an independent transaction and connection.

Notify after the database agrees

Inside a thread-bound transaction, register a Transactions.Synchronization. This is the guide's callback shape, with comments marking where application work belongs:

Transactions.registerSynchronization(new Transactions.Synchronization() {
    public void beforeCommit(boolean readOnly) {
        // Validate before the ORM flush and commit.
    }
    public void afterCommit() {
        // Invalidate a cache or schedule an event.
    }
    public void afterCompletion(Transactions.Outcome outcome) {
        // Release resources for COMMITTED, ROLLED_BACK, or UNKNOWN.
    }
});

The connection has already returned to the pool when afterCommit runs. More database work needs a new transaction. If a callback fails, the original database change remains committed and the caller receives an exception saying so. Retrying the entire operation blindly can duplicate the work.

These callbacks are synchronous and in memory. They don't make event delivery durable across a process crash. For a message that must eventually arrive, write an outbox record in the original transaction and deliver it separately.

Wayline currently expresses a similar ordering with a transactional private method followed by its notification code. The compiler writes transaction handling into the method, so a call through this doesn't bypass it. Completion hooks give other services an explicit place for that post-commit work.

The transaction guide covers nested scopes, failure outcomes and connection ownership. Repositories and CASE expressions and isolation and callbacks are separate additions that become more useful together: less query plumbing, with the important ordering still visible.

Discussion

Which Spring Data repository pattern would you want to bring to a native Java app first?

Create an Uber Clone in 1 Minute

Shai Almog — Fri, 23 Oct 2026 17:52:24 +0000

A lot has changed since 2018, both in programming and in Codename One. Back then I wrote Create an Uber Clone in 7 Days: Build a real world full stack mobile app in Java. Today you can start with the application those seven days were meant to teach you to build, then spend your time making it yours.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

Meet Wayline, a full-stack, white-label ride-hailing application written in Java. Rider and driver apps, an administration console, payments, live tracking and push notifications are already connected to a Java backend. You get the application and its source, ready to adapt to your business. Open the Initializr, choose Wayline, give it your own name and package, and generate the project. That's the one-minute task. Downloads and a first build depend on your machine; launching a real transport service still takes real work.

The source is 100% free, under MIT No Attribution, also called MIT-0. No royalties, no revenue share, no required subscription to use Wayline. You can modify it, sell your application and keep your changes private. Hosting and external services carry their own costs and terms. Your application belongs to you.

Coming This Week

Today is the full application tour, including the code and the parts you would adapt for your own business. The next six posts look at the tools that help you build and ship that work:

Saturday, October 17: Spring Data-Style Repositories Compiled to Native Code. Generated ORM repositories, isolation and completion callbacks.
Sunday, October 18: Thymeleaf, Spring MVC and htmx for Native Java Backends. Thymeleaf-style templates, Spring MVC-style controllers and htmx.
Monday, October 19: Build Your App Theme Without a Display Server. A fully headless compiler and the visual details worth checking after the change.
Tuesday, October 20: Give Your Desktop App a Useful Title Bar and Real Tools. Integrated title content on all three desktop OSs, the Process API and streaming ZIP support.
Wednesday, October 21: Let Users Install Your Java Web App Again. PWA support returns to the ParparVM JavaScript port.
Thursday, October 22: A Java IDE in Your Browser, With Your Files in Your Browser. An early preview of what I'm calling Not a Cloud IDE.

Choose a destination.
Accept a ride as a driver.
Manage the service.

A full-stack Java application you can make your own

Wayline includes both sides of the service. The frontend implements the rider, driver and administrator workflows across mobile, desktop and browser builds. The backend owns authentication, ride matching, pricing, payments and the database. This is a white-label application you can brand and extend, with the operational details already expressed in code.

The project has three modules: common for the frontend, backend for the server and shared for the typed contract between them. Both sides use Java. You can follow a button press through an API call, a service and a repository without switching languages or maintaining a second set of request models.

Here is the booking method in the shared RiderApi interface:

@POST("/api/rides")
void request(@Body RideRequestDto request,
        OnComplete<Response<RideDto>> callback);

The interface carries @RestClient. The build generates its client implementation and the RiderApiServer contract. Wayline's RiderEndpoint implements that contract, injects the Rides service and delegates the request:

@Override
public RideDto request(RideRequestDto request) throws Exception {
    return rides.request(Caller.name(), request);
}

The rider identity comes from the authenticated caller. The client supplies the trip it wants, and the server decides whether the signed-in user can request it. Spring-style dependency injection and authorization keep that decision in the backend; generated DTO serialization and API bindings keep the frontend and backend in agreement.

You can run the server on the JVM while developing, then package it as a native executable with ParparVM. The frontend shares its screens and behavior across targets. The user's guide tours the application, while the implementor's guide follows each feature into its classes. All the Wayline screenshots below come from those guides and open at full size when clicked.

Start with the whole trip

The application opens in the mode that fits the signed-in user. Riders get the booking screen, drivers get their shift, and administrators get the console. An account can have several roles and switch between them. These are distinct workflows within one shared application, so you don't maintain three unrelated clients.

A new user registers, verifies a phone number and chooses whether to share usage statistics. The development profile displays verification codes instead of sending an SMS, so you can try the flow before connecting a provider.

Sign in, create an account or choose the server.
Register to ride or apply to drive.
Verify a phone number; development shows the code.
Choose whether this device shares usage statistics.

The rider searches for a destination, sees the route and compares three vehicle categories with a fare for each. Home and Work shortcuts save repeated typing. Ride preferences cover quiet trips, accessibility and pets, and can restrict matching to women drivers based on the driver's profile.

After requesting, the rider follows the approaching driver, sees the car and plate, and can call or message them. At the end, the flow moves to a rating, optional tip and itemized receipt.

Compare vehicle categories and quoted fares.
Follow the driver to pickup.
Rate the completed ride and choose a tip.

The screen follows the server's state. A button asks for a change; the server decides whether that change is valid. The repositories use conditional updates so competing actions can be settled by the database. That matters when a cancellation and an acceptance arrive together.

The request flow is visible in Rides:

public RideDto request(String rider, RideRequestDto request) throws IOException {
    validate(request);
    String id = attempt(() -> open(rider, request));
    live.rideChanged(id, RideState.REQUESTED, rider, "", "");
    search(id);
    return read(id, rider);
}

open is transactional. It serializes competing requests from the same rider before creating the ride; attempt handles the retry path. Once that work returns, the service publishes the change and starts matching. The details that prevent two active rides belong here, where every client gets the same rules.

The normal journey is shown here. The application also handles declined offers, expiry, cancellation and payment failures.

Give the driver an application too

A ride-hailing demo that stops at the passenger screen leaves most of the service for you to build. Wayline includes driver signup, document submission and review, then the actual working day.

Submit the documents needed to apply.
See where an application stands.
Go online when ready to take rides.

An offer shows the pickup, destination, fare and a countdown. During a trip the driver sees the route and the next action, including the amount to collect for a cash ride. The earnings view shows daily totals and the balance recorded by the service.

Follow the trip and complete it.
Inspect earnings and the recorded payout balance.

When the driver switches to a navigation app or locks the phone, the mobile background-location service keeps reporting during the shift. Reports are spaced by time and distance instead of forwarding every location change. iOS uses background location; Android uses a location foreground service. The browser and desktop preview don't reproduce that mobile background behavior.

Shift.begin() starts tracking and, on Android, creates the foreground service with a method reference for its background task:

service = ForegroundService.start(CHANNEL, "You're online",
        "Wayline shares your location with riders while you drive.", null,
        Shift::keepAlive);

Shift.end() removes the location watcher and stops that service when the driver goes offline. The same class throttles reports by distance and elapsed time, including a heartbeat for a parked car.

There are ride widgets outside the main screen too. The rider's active trip appears as an iPhone Live Activity, an ongoing Android notification, or a small desktop/simulator window. A browser has no equivalent surface in Wayline. The lock-screen section explains the distinction: the iPhone implementation updates when the app receives messages, and doesn't use ActivityKit's direct server push token. A suspended app can therefore leave the activity showing its last received state.

The widget's layout is Java too. This excerpt from RideCard.descriptor() supplies the compact iPhone presentation:

return new LiveActivityDescriptor(RideActivityKeys.KIND)
        .setContent(content())
        .setCompactLeading(new SurfaceText("${driver}").setFontSize(13)
                .setMaxLines(1))
        .setCompactTrailing(new SurfaceText("${eta}").setFontSize(13)
                .setColor(SurfaceColor.ACCENT));

The complete descriptor also supplies expanded and minimal layouts. LiveActivity.start(descriptor(), now) starts it, and current.update(now) sends new state. Wayline registers the resulting activity ID with the backend so later push messages can address it.

Live updates over WebSockets

An open app needs to hear when the ride changes or the driver moves. LiveChannel opens a WebSocket and hands its callbacks back to the UI event thread:

socket = WebSocket.build(url)
        .onConnect(ws -> CN.callSerially(() -> opened(mine)))
        .onTextMessage((ws, text) -> CN.callSerially(() -> frame(text, mine)))
        .onClose((ws, code, reason) -> CN.callSerially(() -> lost(mine)))
        .onError((ws, err) -> CN.callSerially(() -> lost(mine)))
        .connect(10000);

This is the connection portion of LiveChannel.open(). Its helpers handle reconnects, heartbeats and stale callbacks from previous connections. The app obtains a short-lived, single-use ticket through its authenticated API before connecting to /ws/live.

The backend endpoint implements WebSocket and is registered with @WebSocketMapping("/ws/live"). It redeems the ticket, checks the account and adds the connection to LiveHub. When a ride changes, the hub constructs the message:

Map<String, Object> frame = new LinkedHashMap<String, Object>();
frame.put("type", "ride");
frame.put("id", id);
frame.put("state", state.name());
String text = Json.write(frame);

It sends that frame through WebSocketSession.sendText to the rider, the driver and connected administrators. Driver positions have their own message type. Removing an admin role also closes that account's old connections, so a previously authorized socket cannot keep receiving fleet locations. The live channel guide traces both sides.

Push v3 callbacks and backend delivery

The live WebSocket channel serves an app that is open. Push covers the rider with a phone in a pocket and the driver who has just been offered a job.

The frontend uses the Push v3 PushClient API. This is the registration code inside Notifications.start():

client = PushClient.builder(AppConfig.PUSH_APP_KEY)
        .listener(new Listener())
        .build();
client.register();

Its PushListener receives the token through onRegistration and ride notifications through onMessage:

@Override
public void onRegistration(PushSubscription registered) {
    subscription = registered;
    signedIn();
}

The message callback reads the payload and opens the relevant ride screen:

@Override
public void onMessage(PushMessage message) {
    Object ride = message.getData().get("rideId");
    Object role = message.getData().get("role");
    String title = message.getTitle();
    if (ride != null && title != null && title.length() > 0
            && Session.user() != null) {
        Nav.showRide(role == null ? Nav.RIDER : String.valueOf(role));
    }
}

The screen fetches the current ride state rather than trusting an old notification. Silent messages can update the Live Activity without opening a screen. These callbacks run on the UI event thread.

The app registers a device token for the signed-in account and removes that association on sign-out. A notification carries the ride ID and role so tapping it opens the right screen, which then reads the current ride from the server. Expiring driver offers use a short lifetime so a delayed notification doesn't look like a fresh job.

On the backend, RidePushes builds the message with ordinary Java calls:

return PushNotification.builder()
        .title(title)
        .body(body)
        .collapseKey("ride-" + id + "-" + role)
        .data("rideId", id)
        .data("state", state.name())
        .data("role", role);

CloudPushSender sends the built notification and device targets through CloudPush:

PushResult result = push.send(message, to);
accepted = result.isAccepted();

The call runs on a background task so the ride request doesn't wait for the push service. Acceptance here means the service accepted the notification; it isn't proof that someone read it. Wayline also checks the latest ride state before composing a notification, preventing a delayed acceptance event from announcing a ride that has since been canceled.

The server publishes ride changes after they commit. A push delivery failure doesn't undo an accepted ride. Those are small decisions that make a much bigger difference than adding another animation to the booking screen.

Wayline includes the integration, while development logs notifications to the console. Real mobile push requires the app and server keys and platform credentials described in the push setup. Android push starts disabled so a generated project can build before you have a Firebase or Huawei configuration.

The admin console is part of the product

Someone has to approve drivers, answer a payment question and find out why a rider was blocked. Those jobs shouldn't require opening a database console.

On a phone, administration is one screen at a time. The dashboard starts with work needing attention, then shows current activity and trends. An application review includes documents, and moderation records both the reason and the administrator responsible.

Inspect daily rides and fares.
Review a driver application.
See an account and its moderation history.

On a wide screen, the same app becomes a console with navigation and room for a list beside the selected item. This is a layout you can work in all day:

The wide dashboard puts activity and trends together.
Review applications without losing the list.

Flagging and blocking aren't the same operation. A flag calls attention to an account; a block signs it out and prevents access until it is lifted. The people view includes role changes, ride history and financial totals. The rides view lets an administrator inspect or cancel work and request a card refund where applicable.

The backend guards the awkward cases too. Inside Accounts.suspend(), an administrator cannot strand someone halfway through a ride by disabling the account:

if (suspended && signIn.isEnabled() && cleanup.inRideUnderWay(username)) {
    throw new ResponseStatusException(409,
            "That account is on a ride. Block it when the ride has ended");
}

The operation runs in a transaction and records who changed the account and why. The administrator must end the ride first. That rule protects both participants even if moderation is invoked through a different client.

Search accounts, change roles and inspect history.
Filter and inspect rides across the service.

Pricing is editable: base fare, distance, time, minimum fare, fees, commission, and multipliers. The payments list distinguishes a completed refund from one still pending. The live map shows online cars, and the guide screenshot below captures its empty state rather than inventing a busy fleet.

Inspect charges and their payment state.
Set the service prices in the console.
The live map, here with no drivers online.

Billing includes the awkward cases

The wallet stores payment methods, and receipts break down the fare. Development uses simulated cards with test behavior for success, decline and uncertain results. Real payment providers sit behind a PaymentProvider interface.

Keep a default card or choose cash.
Read the fare breakdown and payment result.

A completed ride and a settled payment are separate facts. Wayline commits the trip, calls the payment provider without holding that database transaction open, then records the result. Charges carry a key derived from the ride so retrying an uncertain request can reuse the same payment identity. This call from Payments.settle() makes that key explicit:

reference = charge("ride-" + ride.getId(), ride.getRider(), ride.getMethodId(), amount,
        ride.getCurrency(), "Wayline ride");

The helper resolves the stored provider references and delegates to PaymentProvider.charge. A definite decline becomes FAILED; an I/O failure leaves the result PENDING so recovery can ask again using the same key.

If the server stops between those steps, a recovery pass revisits pending payments. A definite decline is treated differently from a lost response. Refunds can be pending too; the admin screen doesn't call the money returned just because a provider accepted the request.

The included Stripe adapter uses hosted card setup so card details don't pass through the app's server. It has tests against stand-in provider responses, but hasn't been validated against a Stripe account. Before taking real payments, exercise its full flow with your provider and complete the missing production work described in the billing section: webhooks, required cardholder authentication, driver transfers and your tax/invoice rules.

In particular, Cash out currently records a payout in the ledger; it doesn't transfer money to a driver's bank. That is a concrete extension point, not a hidden promise behind a finished-looking button.

Maps change the starting economics

In 2018, native maps were central to this kind of app. We still support native maps, including the platform integration described in the guide. Wayline focuses on hosted map data rendered by Codename One's MapView, which gives a small operator more control over the provider and the cost model.

The default setup draws OpenStreetMap vector tiles from OpenFreeMap without an API key. Routes use the OSRM demo service, and place search goes through your backend to Photon. These are separate choices, not one inseparable maps account. The map factory selects the tile source and style directly:

MapView map = new MapView(tiles == null ? MvtTileSource.openFreeMap() : tiles,
        Look.dark() ? MapStyle.dark() : MapStyle.light());
map.setWheelZoom(true);
map.moveCamera(center, zoom);

This excerpt comes from Maps.create(). Maps.useTiles(TileSource source) supplies a replacement source, which also lets the screenshot tests use bundled tiles instead of depending on a network service.

You can point the app at your own tile and routing services, or choose hosted providers. A small business can begin without a map SDK billing account and later choose whether it wants a provider bill or the work of hosting its own data services. Self-hosting still costs money and operational time; public routing and search servers aren't a production service guarantee. The default routes don't include live traffic.

That changes the question from “which map vendor must this application use?” to “which service fits this region and volume?” The maps chapter of the implementor's guide shows the replacement points and the decisions to make before launch.

The vector map follows the dark theme.
The rider experience in a wide desktop window.

Readable Java, even when an agent makes the change

You can hand an agent the job of changing a fare rule, adding a service area or branding the screens. Java's strict types and straightforward structure help keep that work readable. A request has a declared type, a service has explicit dependencies, and a repository states what it reads. A changed method signature must agree with its callers.

Wayline gives the agent the same things I want as a developer: named responsibilities, conventional code, tests and a development MCP endpoint. You can review the resulting diff and follow the behavior through the application. The code remains yours to understand and maintain.

Spring Security users should recognize the authorization rules. This excerpt is part of SecurityConfig's API chain:

.authorizeHttpRequests(auth -> auth
        .requestMatchers(AntPathRequestMatcher.antMatcher("POST",
                "/api/account/register")).permitAll()
        .requestMatchers("/api/driver/**").hasRole(Roles.DRIVER)
        .requestMatchers("/api/admin/**").hasRole(Roles.ADMIN)
        .anyRequest().authenticated())

The complete chain configures JWT authentication and other protections. The server reads the caller from its security context, rather than accepting a rider identity supplied by the client. The APIs use Codename One packages and supported Spring-style conventions; this isn't a Spring runtime hidden in the project.

The data layer is similarly recognizable. Wayline's RideRepository begins:

@Repository(entity = Ride.class, key = String.class)
public interface RideRepository extends CrudRepository<Ride, String> {
    Ride findFirstByRiderAndStateIn(String rider, RideState[] states);
    Ride findFirstByDriverAndStateIn(String driver, RideState[] states);
}

The build writes the query implementation. Services decide what changes belong in one transaction. If you prefer a direct data access object, the backend also generates DAOs. This separate example from the database guide shows that lower-level style using its Reminder entity:

Dao<Reminder> reminders = em.dao(Reminder.class);
Reminder reminder = new Reminder();
reminder.title = "renew the certificate";
reminder.due = new Date();
reminders.insert(reminder);

Reminder stored = reminders.findById(Long.valueOf(reminder.id));
stored.done = true;
reminders.update(stored);

On the frontend, a helper creates an ordinary component, gives it a test name and attaches an action. This is Wayline's button helper:

private static Button button(String text, String name, String uiid,
        ActionListener<ActionEvent> onClick) {
    Button button = new Button(text, uiid);
    button.setName(name);
    if (onClick != null) {
        button.addActionListener(onClick);
    }
    return button;
}

The UIID connects it to CSS. The primary style uses shared variables for branding and shape:

WlPrimary {
    color: var(--brand-contrast);
    background-color: var(--brand);
    border-radius: var(--radius);
    font-family: "native:MainBold";
    font-size: 2.9mm;
    text-align: center;
    padding: 2.75mm 4mm 2.75mm 4mm;
    margin: 1.6mm 0 0.8mm 0;
}

The variables and their dark variants live near the top of theme.css. An agent changing your brand color has a clear place to edit, and a human reviewing the change can see whether it touched anything else.

You can inspect these excerpts in the Wayline source. The implementor's guide links each feature to its implementation and explains how to adapt it.

Settings are part of making the app yours

Wayline includes light and dark themes, distance units and translations into English, Spanish, French, German, and Hebrew. The Hebrew layout runs right to left. Wide settings screens stay in a readable column instead of stretching every field across the monitor.

Account, ride and appearance preferences.
The same settings in dark mode.
Hebrew text and right-to-left layout.
Usage statistics remain a device-level choice.

Settings adapt to a desktop window.

Some settings are hooks for your product policy. The promotions switch is stored, but Wayline sends no promotions. The emergency contact and automatic trip-sharing preference are stored without sending messages; the ride's Share action is separate. The guide calls these out so you can decide what they should mean for your service.

Run it, then change one thing

Generate the Wayline template from the Initializr. It renames the Java package, artifacts and application configuration for your project. With JDK 17 or newer and Maven installed, start the development backend from the generated project's root:

CN1_PROFILE=dev backend/server.sh run

In another terminal, start the simulator:

mvn verify -Psimulator -DskipTests -Dcodename1.platform=javase

The development profile uses an in-memory database, demo accounts and simulated external services. The launch instructions list the accounts and show how to run the rider and driver together. Keep that profile for development.

For a browser version hosted by the same backend:

backend/server.sh web
CN1_PROFILE=dev backend/server.sh run

Then open http://localhost:8080/. The first command builds the browser application; rerun it after changing the client. Server packaging can also produce a native binary.

Before handing a change to an agent, give it a useful check. The backend test command is:

mvn -pl shared,backend -Dcodename1.platform=backend test

The suite covers roles, the ride lifecycle and payment outcomes, among other service behavior. Native compiled test execution is available as a local-only option in the testing guide. The development profile's /mcp endpoint gives an agent another way to inspect the backend; it isn't an endpoint to expose publicly without the production authentication configuration.

Build a service your market needs

I see this as an opening for startups whose idea begins with ride hailing. Airport transfers, a specialist fleet or transport for a particular community can start here, then build the part that makes the service useful to those people. Make something better.

A taxi company can run its own branded, hosted app with central management. The taxi-station adaptation discusses a fixed fleet, manual dispatch and phone bookings as changes to make. Those additions aren't all finished screens in Wayline, but the guide shows where they belong.

I can see a cottage industry around that work: developers who adapt and operate these applications for local businesses. A small operator gets more freedom over its brand and service rules, and the developer can spend time on the local requirements instead of recreating the wallet and sign-in flow. Whether that becomes a business depends on finding operators whose problems you can solve. The starting code is now available to try.

More This Week

Spring Data-style repositories, statically compiled

A finder such as findFirstByDriverAndStateIn puts a query next to the rest of the entity's data access. The new repository generator supplies its implementation, including support for declared queries and CASE expressions.

@Repository(entity = Ride.class, key = String.class)
public interface RideRepository extends CrudRepository<Ride, String> {
    Ride findFirstByDriverAndStateIn(String driver, RideState[] states);
}

You get Spring Data-style finder methods and familiar Hibernate persistence conventions with generated Java implementations. Native builds compile those implementations ahead of time. There is no repository classpath scan or runtime proxy generation, and the resulting calls are available to the compiler for optimization.

Transaction isolation and callbacks deal with the next question: when can another part of the system act on that result? A completion callback runs after the database acknowledges the commit. If the callback fails, the database change is still committed, so retrying the entire operation is the wrong default.

Saturday's repository and transaction article covers both the convenience and the boundaries, including bulk updates, supported isolation levels and durable event delivery.

Thymeleaf, Spring MVC and htmx in a native backend

Thymeleaf-style templates, Spring MVC-style controllers and htmx make a useful combination for a fast server-rendered admin site. Our implementation compiles the supported template syntax into Java renderers, then into the native backend. The controller can return a page or a fragment for htmx:

return Htmx.isRequest(request) ? "products :: catalog" : "products";

Typed model access becomes direct Java access. Production requests execute compiled rendering code, without parsing templates or interpreting property expressions. That is the performance advantage of doing the template work during the build.

Sunday's Thymeleaf and Spring MVC article follows a working catalog through controllers, form errors and partial updates. It also explains what this subset leaves out.

A stylesheet shouldn't need a monitor

The CSS compiler is fully headless. The same mvn cn1:css goal can run on a worker without a display server or framebuffer setup. Removing that machinery removes startup work and display-dependent assumptions from theme compilation.

This is also a substantial change to an old compiler with fragile corners. Fonts, image borders and physical-unit conversions deserve visual checks even when a build succeeds. Monday's headless CSS article shows the workflow and what to compare.

Use the desktop title area

The title area of our native macOS editor prototype. Document actions share the top row with the OS controls, leaving the ribbon and document below.

Putting Save, Search or document controls in the window title area is a niche feature. If you're building an editor, it can save a whole row. Codename One supports it in the native macOS, Windows and Linux ports while keeping real OS window controls.

editor.getToolbar().setTitleComponent(title);

With custom title mode selected, the framework reserves room for the native controls and separates interactive components from draggable background. Tuesday's desktop tools article explains the differences between the three operating systems.

Run an external tool from Java

The new shared com.codename1.io.ProcessBuilder started with backend needs, then extended naturally to desktop apps. You can launch an installed command, stream its input and output, wait with a timeout and inspect its exit status.

boolean available = com.codename1.io.ProcessBuilder.isSupported();

Mobile and browser targets return no process-launch capability. Tuesday's article covers that boundary and the output-draining pattern that keeps a full pipe from hanging the worker.

Export a ZIP without inventing an archive format

The ParparVM runtime now provides streaming java.util.zip APIs, including ZIP, GZIP, and checksums. An app can export data through the familiar stream interfaces; a backend can write an archive straight to its response.

zip.putNextEntry(new java.util.zip.ZipEntry("report.txt"));
zip.write("Completed rides\n".getBytes("UTF-8"));
zip.closeEntry();

This excerpt assumes an open ZipOutputStream. The desktop tools article also shows the helper for preserving an executable launcher's Unix permissions, and the limits of the streaming subset.

Install the web app again

PWA support disappeared during the move from TeaVM to ParparVM. JavaScript builds now generate the manifest, icons and service worker again, giving supporting browsers an installable application and cached offline launch.

Wednesday's PWA article covers deployment, cache updates and the difference between an offline UI and a ride request that still needs a server.

Not a Cloud IDE

The experimental browser IDE opens a Java project with an editor and a running preview. Compilation and execution happen in the page, and files stay in this browser's storage. The cloud build server does its usual job when you explicitly request a platform build.

This is a very early preview. It won't replace IntelliJ or reproduce all of Java inside JavaScript. It can let someone try an app before installing a development environment, then download the project when they're ready to continue locally. Thursday's IDE tour shows that path and explains browser-local storage.

Where is this going?

Everywhere. Wayline is the first step in a wider collection of full-stack application templates in Initializr. We plan to do this for many more applications, including delivery: choose a template, generate your own project, then build the service your market needs. Raising the starting point is good for the whole market. Your moat can grow in the part competitors can't get from a template: the service you provide, the relationships you build and the problems you understand better. Starting with an application as substantial as Wayline gives you more time to build that advantage. I want to see what you make of it.

Smaller Simpler Maven Projects

Shai Almog — Thu, 22 Oct 2026 17:57:54 +0000

Opening a new application should show you the application. A directory full of platform modules makes you learn the build's structure before you have written a screen.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

Last week we added smaller Gradle projects. Maven now starts small too. The application archetype defaults to the root POM and common, with no platform modules. You can still run the simulator and build the target apps. This closes our weekly release series.

The default tree matches the first task

The relevant part of a new project looks like this:

my-app/
    pom.xml
    common/
        pom.xml
        codenameone_settings.properties
        src/main/java/
        src/main/resources/

This is a shortened tree, not a count of every generated resource or launcher script. The structural count is two POMs. Source, CSS and resources remain where an existing Maven user expects them.

When a platform has no module, common handles its build. These commands keep their meaning:

mvn cn1:run
mvn package -Dcodename1.platform=android
mvn package -Pexecutable-jar -Dcodename1.platform=javase

The desktop executable JAR goes under common/target in this layout. Platform modules become useful when a target needs independent dependencies or plugins, rather than because every possible target needs a directory on day one.

A native implementation does not need another POM

mvn cn1:generate-native-interfaces still creates platform-specific source directories. An Android implementation can live under android/src/main/java, and an iOS implementation under ios/src/main/objectivec, without either directory becoming a Maven module.

The build treats a platform as a separate module when <platform>/pom.xml exists. Native source directories alone do not make that decision. JavaSE implementations are compiled into common/target/cn1-javase/classes, separate from application classes, so they are not accidentally uploaded into a device build.

This also keeps the Android migration introduced on Friday approachable. Imported Android sources live under common/src/main/android; your initial port need not begin by learning every target module's POM.

Ask for the structure you need

The archetype's platformModules property defaults to none. all restores the full platform layout, and a comma-separated value such as javase,android creates only those modules. Its projectType defaults to app; app-with-backend adds the server, and backend-only creates a standalone server project.

For example, these are options to append to your normal archetype generation command, not commands on their own:

-DplatformModules=javase,android
-DprojectType=app-with-backend

A backend-only project has its POM and src/main/java at the root. It needs no empty client beside it:

./mvnw cn1:backend
./mvnw cn1:backend-package

The minimal default applies to newly generated projects using the updated archetype. It does not delete modules from an existing checkout. Before simplifying an older project, check for platform-specific build configuration rather than assuming its POMs are empty scaffolding.

Less structure to explain and inspect

I still prefer Maven's explicit XML for build configuration. I also prefer having less of it to read. Those preferences can coexist.

A smaller project tree helps a new contributor find the code that matters. It also leaves fewer generated configuration files for an LLM to misread when asked to change one screen. That is a reduction in surrounding material, not a guarantee that generated code is correct. Review the diff and run the relevant application behavior just as before.

PR #5937 introduced these project shapes. The current archetype reference defines how target selection and native directories work. Start with the default, then add a platform module when you have a concrete setting to put in it.

Discussion

How many of your platform POMs contain configuration you actually maintain?

PGO for Faster Apps and Generational/Adaptive GC

Shai Almog — Wed, 21 Oct 2026 18:01:09 +0000

Your native compiler can optimize an app more effectively when it knows which code actually runs. Profile-guided optimization, or PGO, gives it that information. The build service runs an instrumented version of your application, records its execution and uses the profile to compile the binary your users receive.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

PGO is now a Pro and Enterprise cloud-build feature for iOS, native macOS and native Linux. You enable it with a build hint; the service handles the extra compilation and training. It is a way to improve native performance without rewriting application logic or managing a profiling pipeline yourself.

This release also adds adaptive generational garbage collection to ParparVM. We will start with PGO and how to use it, then look at the GC changes and the memory cost behind their CPU improvements. This continues our weekly release series and last week's object-layout work.

Let your app guide the compiler

An ordinary optimizing compiler has to estimate which branches are common and which functions are worth inlining. PGO replaces some of those estimates with counts from an actual run. Frequently executed code can be placed together and optimized for speed, while code outside those paths can stay compact.

The profile applies to translated Java, Codename One's runtime and your native sources. The instrumented binary stays on the build server. Your users receive the second build, without the training counters.

Turn on PGO for your target

Add the relevant hint to codenameone_settings.properties. This example enables it for iOS and sets a 90-second training period:

codename1.arg.ios.pgo=true
codename1.arg.pgo.trainingSeconds=90

Each target has its own switch:

Build hint	Target	Training environment
`codename1.arg.ios.pgo=true`	iOS device app	Temporary iOS simulator on the build server
`codename1.arg.macos.pgo=true`	Native macOS app	Build server
`codename1.arg.linux.pgo=true`	Native Linux app	Build server with a virtual display

The training period defaults to 60 seconds. Values below 10 or above 300 are brought into that range. Increasing it gives the application longer to exercise its startup work; it does not create user interactions.

If you already subscribe to Pro or Enterprise, enable the hint and submit a supported cloud build. PGO is included in those plans. You can compare plans here. These hints belong to the cloud build service; local builds do not consume them.

Give the training run useful work

The app starts from a clean state and runs unattended. Resource loading, initial layout and painting can contribute to the profile, as can animations, timers and network work that start automatically. Repeated work is particularly useful because the compiler can identify the paths that dominate execution.

Nobody signs in or taps a button during training. If the app stops at a login screen, the profile describes that screen. Code behind it remains correct, but the compiler has no evidence that it is an important execution path. Before enabling PGO, run the app from a clean installation and check what it does without input.

PGO adds build time because it requires two compilations and a training run. Start with a normal Release build and record the time for a representative task. Repeat that task with the profile-guided build on the same device. Check memory and the result of the task as well as elapsed time. The gain depends on how much of your workload the training run reached; we are not assigning a universal speedup percentage to it.

A requested profile-guided build either produces that binary or fails with a reason. An empty profile, a crash during training or an incompatible build mode does not silently produce an ordinary build. The performance guide lists the settings, training rules and incompatible configurations, including debug and simulator-only modes. PR #5945 introduced the build support.

Adaptive GC reduces the work left to run

PGO improves the generated native code. The collector changes reduce how much work that code needs to do. In our allocation workload, the concurrent collector spent time tracing fresh objects and sweeping their slots even when almost none survived.

ParparVM now has an adaptive generational phase. Holding more memory can reduce collection frequency, but it can also make the next full trace or transition much worse. The standard Codename One benchmarks use no PGO, so the following GC results measure the runtime changes separately.

Collect survivors instead of revisiting every allocation

A generational collector concentrates frequent work on young objects, based on the observation that many die quickly. References from older objects to young ones must still be tracked, and surviving objects cannot simply disappear when a young page is reset.

Our hybrid chooses between the existing concurrent path and stop-the-world generational cycles. On eligible multicore processes, it enters after repeated low-survival cycles with allocation demand and a concurrent collector busy for at least half the interval between cycles. Low available memory is an exit condition, not the trigger to enter.

An all-dead young page can be reset in constant time. The allocator's bump path is inline again, and accounting moves from each object to each page where possible. Those changes remove work rather than merely asking another CPU to do it.

A process that has created virtual threads stays concurrent. A registered native thread that the collector cannot hold also prevents these stop-the-world cycles. Pausing only some allocating threads is not a valid stop-the-world algorithm. The runtime implementation enforces those boundaries.

More memory can buy fewer collections

The young-generation budget responds to collection duty. Two successive minors consuming more than 5% of their intervals can grow it; below 1%, it can shrink. Growth is bounded, including by a fraction of host memory. Requiring two busy minors avoids treating one collection delayed by the OS scheduler as proof that the application needs a larger heap.

A larger young generation lets more short-lived objects die before the next collection. That can save CPU. It also leaves more memory resident, and increases the amount of work a later phase may inherit. You have to measure both sides.

Conceptual diagram, not benchmark data. Increasing a budget can reduce frequent collection work while increasing retained memory and the cost of a later scan. The actual curves depend on survival and reference patterns.

One failed transition made this concrete. Deferring the exit decision until the next cycle handed as much as 128 MB of young objects to a concurrent collection. Its fresh-object protection retained them, while application threads kept allocating behind it. The engineering record reports a roughly 500 ms cycle and a page-heap count rising from 3,446 to 10,538 in the affected stress test. The exit decision now runs at the end of the stopped cycle, before application threads resume.

Another attempted concurrent major promoted about 6.4 million dead objects into the old generation. The next minor then spent 260 to 305 ms examining the remembered set. Those are failure observations from the GC engineering record, not advertised pause bounds for the corrected collector.

Read time and memory together

The committed calibration change for PR #5940 gives a useful view of the trade. These are historical gate baselines for objectAllocation, with JDK 25 equal to 1. Lower is better in both columns.

Runner	Time ratio, before → after	Peak memory ratio, before → after
macOS ARM64, three-CPU runner	3.696 → 1.106	0.481 → 0.937
Linux x64, AMD EPYC 7763	5.011 → 1.649	0.370 → 0.370
Linux ARM64, Neoverse N2	3.043 → 3.043	0.239 → 0.378
Windows x64, AMD family 25/model 1	4.932 → 1.559	0.400 → 0.386

The macOS row is the clearest cost: much less allocation time, almost twice the previous memory ratio. Linux ARM64 records more memory with its time baseline unchanged. A value unchanged in the overlay can be a carried-forward baseline; it is not a fresh measurement of zero change. The ratios still show ParparVM slower than JDK 25 on this allocation workload after the improvement.

These are calibration records, not a new controlled before/after experiment. Most selected rows record one calibration run; the Windows row records three. They have no confidence intervals, and later master baselines include further recalibrations. The data CSV and original overlay retain that context. Compare within a runner row; do not rank different machines from these ratios.

The allocation workload is deliberately narrow. It tells us about allocation and collection behavior for that survival pattern, not frame latency, network throughput or every application. A backend using virtual threads also follows the concurrent path, so an allocation microbenchmark's hybrid gain cannot be assigned to that backend.

Make a speed gain part of the next baseline

The performance gate runs paired ParparVM and JDK 25 workloads on Linux x64 and ARM64, Windows x64 and ARM64, and macOS ARM64. It alternates which runtime goes first, verifies output and records median ratios. CPU-specific baselines keep one runner model from silently standing in for another.

For workload timings, the gate uses the fastest measured repetition inside each process; JVM startup is not charged to the workload. Memory is a process peak: footprint on macOS, RSS on Linux and working set on Windows. Those are related measurements, not identical operating-system counters.

A change outside the permitted tolerance fails in either direction. A large improvement needs a reviewed baseline update too, otherwise a later regression could give it back while remaining below the old limit. Each PR owns an overlay, records a reason for an intentional change and names the value it replaces. Merged overlays are folded without changing the resolved baseline.

# Run locally on the appropriate platform and inspect both metrics.
vm/selfhost/ci-perf-gate.sh run macos-arm64 /tmp/cn1-perf
vm/selfhost/ci-perf-gate.sh verdict /tmp/cn1-perf

This comparative gate covers the five host OS/architecture combinations above. It is not a JDK comparison running on an iPhone, Android device or browser. Those ports have their own behavior and screenshot coverage. The port status page exposes the distinction, and PR #5930 explains the baseline workflow.

Keep the gain you measured

PGO and adaptive collection improve different parts of execution. Compare a profile-guided build with a regular build using the same application workflow, and keep the time and memory results together. For compiler and runtime changes, the performance gate gives the next release a baseline to preserve.

Discussion

Which part of your app would benefit most from a profile-guided build: startup, rendering, or repeated background work?