DEV Community: Shai Almog

Dash: An Endless Runner That Races Through Your City

Shai Almog — Sat, 14 Nov 2026 15:29:35 +0000

Skirmish showed that most of a mobile game is app: the sign-in, the menus, the shop, the friends list, the pushes and the server. Dash is the second game template, and it is a different kind of game: an endless runner. A runner dashes down a track of lanes, jumps hurdles, slides under barriers and changes lanes around traffic. You can generate it from the Initializr today, under your own name and package, and the source is MIT-0.

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.

Download the Dash tour.

A level that turns into 3D

The trick I like most in Dash is that a level can start as a side-scroller and become a 3D runner halfway through. The first stretch of Neon Causeway looks like a flat platformer: one row of hurdles and barriers, seen from the side. At 300 meters the camera swings behind the runner, the lanes open up, and the rest is a chase-camera runner.

There is no second game behind that. The simulation always has lanes, heights and distances, and a hurdle is cleared the same way from either angle. A level only carries camera cues, and the renderer blends between the two framings when the runner reaches one. Because the rules never see the camera, a level can change its view anywhere without changing who wins.

Run your own street

This is my favorite part to demo. Tap Run your city, pick a start and a finish on a real street map, and the route becomes a level. Every street is a stretch of track, every turn is a corner on the side it turns to, and the next street's name is called out before you reach it. Landmarks along the way, a station or a museum, show up as boards beside the track.

Pick two points.
Run the streets.
Pass the landmarks.

The map is Codename One's MapView, which draws OpenStreetMap data itself on every platform, and the route comes from Routing. The app reduces the route to streets and turns and hands it to the rules:

CityRoute route = new CityRoute("Old Harbour")
        .leg(420, CityRoute.STRAIGHT, "Quay Street")
        .leg(310, CityRoute.LEFT, "Rope Walk");
LevelDef level = route.level();

level() is deterministic, so the server doesn't need a map. It rebuilds the same level from the encoded route and checks your run against it. The level's id is a hash of the route, so every route gets its own leaderboard, and nobody can trim a hard route into an easy one and keep the same board.

Leaderboards you can trust

A run is never reported as a number. The app sends the seed and the input log, a few hundred bytes, and the server plays it through the same Java rules module the app runs. A typed-in score, or a log edited to dodge an obstacle the player hit, does not reproduce. The rules use no floating point and no clock, so the phone, the server and the replay viewer agree to the bit.

Every level has all-time, weekly, daily, friends and crew boards. Beat a friend's best and they get a push that opens that level's board.

Racing your friends

Open a party, share the link, and everyone runs the same track at the same moment. The server runs the race in lockstep: each phone sends its inputs, the room broadcasts each tick's inputs to every seat, and its own copy of the race decides the places. A client whose state drifts from the server's is caught by a hash it sends every second.

While you race you can talk. Voice uses Codename One's WebRTC API, peer to peer between each pair of players, with the game's own socket carrying the signalling. The server never touches the audio.

Download the gameplay clip.

Build your own levels

The track editor is in the app, on every platform. A level is a strip you paint on: tap a lane to drop a hurdle or a coin, tap the top row for a barrier across every lane, and drop camera cues where the view should change. Playtest runs the draft on the real rules. Publishing requires the bot to finish the level, so nobody can publish one that cannot be beaten. Published packs can be rated, raced, remixed and moderated from the admin console.

Get it

Choose Dash in the Initializr, or read the guide chapter first. It walks through the rules, the camera, the referee, races, voice and the editor, and what to change to make the game yours.

If you've ever wanted to ship a game but stalled on everything around the game, this is the part I'd copy. Sign-in, friends, pushes, a shop, moderation and a server that replays every run are already done, so the week you spend is on the fun part.

Tomorrow: Pulse: Heart Rate Zones From the Watch to the Trainer's Screen.

Embedded Java: 20x Smaller Than Chrome, Faster Than Rust, Royalty Free

Shai Almog — Fri, 13 Nov 2026 14:35:42 +0000

Embedded software has the hardest job description in our industry. It has to run for years without a reboot. It has to fit in whatever RAM and flash the bill of materials allowed, because every chip you add is paid for again on every unit you ship. It has to respond instantly on a CPU slower than a phone from five years ago. And now it also has to look like the phone app, talk to the phone app, and report to a cloud service, because that's what customers expect from anything with a power cord.

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.

Most teams solve that with three or four stacks. C or C++ on the device for size and control, a browser or Qt for the screen, Swift and Kotlin for the companion app, something else on the server. Every boundary between them is a protocol written twice and a bug waiting to happen.

Codename One now runs on embedded Linux, and it covers every one of those pieces with one Java or Kotlin codebase. On our benchmark, the UI drew an animated gauge in 18 MB of memory with no GPU, about a twentieth of what a Chromium kiosk needed to draw the same thing. The headless backend served 379,900 requests per second on two cores, 1.3 times Rust's axum. And we don't charge royalties.

Coming This Week

Today is the embedded story. Then one post a day:

Saturday, November 7: Dash: An Endless Runner That Races Through Your City. A game template that turns from 2D into 3D mid-run, builds levels from real streets, and lets friends race with voice chat.
Sunday, November 8: Pulse: Heart Rate Zones From the Watch to the Trainer's Screen. A gym and studio template built around HealthKit, Health Connect and Bluetooth heart rate straps.
Monday, November 9: Real-Time Java: Control Loops the Garbage Collector Never Stops. What real time means, why it's hard for a managed language, and how we do it.
Tuesday, November 10: Packaging Java Apps for Xbox Developer Mode, and Why Consoles Need Help. One build hint today. Shipping to consoles needs help we can't get alone.
Wednesday, November 11: Port Your Spring Code With Fewer Edits, and Libraries That Bring Their Own Server. Logging, typed JSON, CORS, content negotiation and more of the JDK in the backend, plus cn1libs with a server half.
Thursday, November 12: Debug Your Dart in a Java Debugger, and JFX Central on a Phone. Dart call stacks, Flutter fixes from a real port, a faster web port and a real JavaFX app on an iPhone.

Dash, mid-run in 3D.
Pulse's live class view.
JFX Central on an iPhone.

Two flavors, two kinds of product

The port comes in two flavors. The easiest way to explain them is with two products.

A point of sale terminal: the UI flavor

A POS terminal lives or dies on price. It needs a responsive touch screen, a receipt printer on a serial port, a card reader, and it has to sync with the store's back office. The merchant buys a hundred of them, so ten dollars of hardware is a thousand dollars on the order and the difference between winning and losing the deal.

A GPU is one of the first things you'd like to cut. Android won't let you: AOSP needs a board support package with a GPU driver. Flutter can limp along without one, if Mesa emulates OpenGL on the CPU, and on our gauge that took 1.4 CPU cores and 112 MB. A Chromium kiosk runs in 400 MB of RAM. Codename One draws in software by default, through DRM/KMS or the Linux frame buffer, with no X11 or Wayland. It needs nothing from the board but a frame buffer, so the cheapest SoC that drives your screen is enough.

When the board does have a GPU, set one build hint (or let the board profile choose it) and the same renderer composites through GBM, EGL and GLES 2. The frames are identical to the software output; the CPU time per frame drops. If the GPU driver turns out to be broken, the app logs why and falls back to software instead of showing a black screen.

The screen code is the code you'd write for a phone. Your POS app, the manager's phone app and the back office share the same entity classes, so a change to the receipt format breaks the build rather than a store.

A robot vacuum: the headless flavor

A robot vacuum needs a brain but no screen. The UI is the phone app. The device has to read its sensors, drive its motors, expose an API the app can find on the local network, accept only the owner's phone, take updates and keep working when the Wi-Fi drops. Every component inside it is multiplied by every unit sold, so memory and CPU headroom cost real money for the life of the product.

That's the backend flavor: the same Codename One backend that runs your cloud server, compiled to a native executable for the board. REST endpoints, WebSockets, the ORM, MQTT, Bonjour discovery and mutual TLS for device identity are all there, next to the hardware API.

A controller on the vacuum is a Spring-style class that reads the hardware directly:

@RestController
@RequestMapping("/api/robot")
public class RobotController {
    private final I2cDevice fuelGauge;

    public RobotController() throws HardwareException {
        fuelGauge = Hardware.getInstance().openI2c(1, 0x36);
    }

    @GetMapping("/battery")
    public BatteryDto battery() throws HardwareException {
        return new BatteryDto(fuelGauge.readRegister(0x04));
    }
}

The phone app compiles against the same BatteryDto. It finds the vacuum with Bonjour when it's on the same network and goes through the cloud backend when it isn't, and the API is the same either way.

Competitors that need a GPU, gigabytes and a prayer

We ran the same workload in five toolkits: an 800 by 480 gauge with a sweeping arc, a needle and a bold percentage, redrawn every frame and capped at 60 frames per second, in software. Same Debian arm64 container, three runs each, median shown.

Toolkit	First frame, cold	Frames per second	Memory (PSS)	On disk (files mapped)
Codename One	46 ms	57	18 MB	15 MB
Slint 1.8	45 ms	51	23 MB	4.3 MB
Qt 6.4 Widgets	73 ms	62	23 MB	73 MB
JavaFX 26	327 ms	62	116 MB	102 MB
Chromium kiosk	717 ms	60	398 MB	378 MB
flutter-pi, GPU emulated on the CPU	767 ms	59	112 MB	233 MB
Android (AOSP)	needs a GPU and a BSP

Read that table as a hardware budget. The kiosk browser, the stack most teams reach for when they want "modern UX", needs 22 times our memory and 25 times our disk to draw one gauge, and takes three quarters of a second to show it. JavaFX, the other way to put Java on a board, needs six times our memory. Flutter does run without a GPU, but only by emulating one: it held its frame rate on 1.4 CPU cores, where we used 6% of one, in six times our memory and fifteen times our disk. Android can't run without a GPU at all. We're the only Java option in the table that fits on the board you'd actually want to pay for.

The container ran on an Apple Silicon Mac, not a board, so a real board will be slower. Compare the rows against each other, not against your hardware. Slint needs less disk than we do, and Qt pushes a few more frames. Our form also draws more than the others: a title bar, a button, a slider and a label around the gauge. The flutter-pi row is a release build of the same gauge drawing to the kernel's virtual display, because flutter-pi needs a display device; the others drew to memory. LVGL isn't in the table either. It's a low-level C graphics library: its widgets are drawn objects you wire up by hand, with no component model, data binding, navigation, networking or storage around them. Comparing it with a full application toolkit wouldn't be a fair test of either.

The headless flavor ran its own benchmark: a small JSON service pinned to two cores.

Runtime	Start	Idle memory	Peak requests/s	p99 at peak
Codename One backend	40 ms	9.2 MB	379,900	0.22 ms
Rust, `axum`	35 ms	1.6 MB	290,200	0.25 ms
Go, `net/http`	48 ms	5.2 MB	178,900	0.59 ms
Node.js	147 ms	48 MB	63,500	1.1 ms
Spring Boot 3.5	1,340 ms	164 MB	33,300	3.3 ms
Python, FastAPI	270 ms	42 MB	6,700	11 ms

Rust and Go use less memory. But a Java backend that serves 1.3 times Rust's peak at a lower p99, and starts 33 times faster than Spring Boot in an eighteenth of its memory, changes what you can put in a vacuum. Like Rust, our server makes two system calls per request and allocates nothing but the object the handler returns. CI reruns this on arm64 with every change to the backend runtime and fails the build if we fall below Rust. The harness is public, so check our Rust setup.

The only stack that goes from the vacuum to the browser

Here's what I think matters more than any single number. Look at what each option covers:

	Device UI	Headless device	Real-time loop	iOS and Android	Desktop	Web	Cloud backend
Codename One	yes	yes	yes	yes	yes	yes	yes
Qt	yes	Qt Core	no	yes	yes	WebAssembly	HTTP server module
Slint	yes	no	no	Android, iOS preview	yes	WebAssembly	no
Flutter (flutter-pi)	GPU, or emulated on the CPU	no	no	yes	yes	yes	no
Chromium kiosk	yes	no	no	as a web app	as a web app	yes	no
Android (AOSP)	GPU only	no	no	Android only	no	no	no

Nobody else gives you a device UI, a headless device, a real-time control loop, the phone app, the desktop app, the web app and the cloud server from one language, one build and one set of classes. That's the "super full stack": the entities, the DTOs and the API contract live in a shared module that every target compiles against. A field renamed on the vacuum is a compile error in the phone app, not a support ticket. One team can own the whole product, and one security fix lands everywhere at once.

The rest of the ecosystem comes along: Bluetooth LE, NFC, MQTT, Bonjour, the ORM, push, crash reporting and the build tools you already use for mobile.

What it looks like in code

Hardware access is in the core API. GPIO, I2C, SPI, serial, PWM, CAN, the watchdog and the backlight go through the kernel's own interfaces, with no extra library:

Hardware hw = Hardware.getInstance();
try {
    if (hw.isSupported(Hardware.FEATURE_GPIO)) {
        GpioPin led = hw.openGpioOutput("gpiochip0", 17, false);
        GpioPin button = hw.openGpioInput("gpiochip0", 27,
                GpioPin.BIAS_PULL_UP, GpioPin.EDGE_FALLING);
        button.setListener((pin, rising, nanos) -> {
            try {
                led.setHigh(!led.isHigh());
            } catch (HardwareException e) {
                Log.e(e);
            }
        });
    }
    if (hw.isSupported(Hardware.FEATURE_I2C)) {
        I2cDevice sensor = hw.openI2c(1, 0x48);
        Log.p("Sensor reads " + sensor.readRegister(0));
    }
} catch (HardwareException e) {
    Log.e(e);
}

On a phone, isSupported answers false, so the same class is safe everywhere. In the simulator it runs against a virtual board with 32 GPIO lines, a TMP102 temperature sensor, an EEPROM and loopback SPI, serial, and CAN. You can write and unit test the hardware code before the board arrives.

Getting it onto the board is one command. It builds, copies the executable over SSH, installs it as a systemd service and follows the log:

mvn cn1:runOnDevice -Dcn1.board=rpi5 -Dcn1.device.host=pi.local -Dcn1.device.user=pi

Board profiles cover the Raspberry Pi family, i.MX 8 and i.MX 6, RK3588, Jetson, BeaglePlay and generic arm64, armv7, x64 and RISC-V. There's a Yocto layer for production images, and a cross build can point at a Yocto or Buildroot SDK sysroot.

No royalties, and the support embedded actually needs

Embedded UI is usually sold per unit. You ship ten thousand terminals and pay a royalty on each one, which is fine until the product succeeds and the toolkit becomes a line item on every unit you ship.

Codename One doesn't charge royalties. It's open source under GPL 2 with the Classpath exception, on devices like everywhere else.

What embedded teams need from a vendor is different. A device ships once and stays in the field for ten years or more. It runs the exact framework version it was certified with, and the team needs a security fix in that version five years from now, not an upgrade to whatever master looks like then. That's long-term support: a maintained branch for your product, backports of the fixes that matter to you, and someone who answers when the board vendor's new kernel breaks something.

That runs far past the timeline we normally support, and it's work we're happy to do with you directly. It's a better deal for both sides than a royalty: you pay for the support you use, and the price doesn't grow with your success. If you're planning a product, talk to us early so the branch matches your release.

Linux today, other systems and RTOS on request

We only support embedded Linux right now. If your product runs on Zephyr, QNX, VxWorks, FreeRTOS or a vendor OS, tell us. The renderer needs a frame buffer and the backend needs sockets, and ParparVM already emits portable C, so a new OS means porting two layers. Real demand decides which one comes next, and that includes a proper hard real-time RTOS.

More This Week

Real-time threads

A vacuum's motor loop, or a POS card reader's timing, has deadlines, and a garbage collector that stops the world is the usual reason people say Java can't meet them. Codename One now has real-time threads on PREEMPT_RT Linux that the collector never stops:

class MotorLoop extends RealtimeTask {
    private final double[] gains = new double[64];   // allocate up front
    private PwmChannel pwm;

    public void setup() {                            // may allocate
        try {
            pwm = Hardware.getInstance().openPwm(0, 0);
        } catch (HardwareException e) {
            Log.e(e);
        }
    }

    public void cycle() {                            // must not allocate
        // read sensors, compute gains, then pwm.setDutyCycle(...)
    }
}

Realtime.getInstance().start("motor",
        new RealtimeParameters().setPeriodNanos(1000000).setPriority(80).setCpu(3),
        new MotorLoop());

If cycle() allocates, the build fails and names the method and the line. Every thread keeps latency statistics so you can prove the deadline on your own board. Monday's real-time article explains the terms, what makes this hard for a managed language and how we handle each part.

Dash: race through your city

Dash gameplay on a neon track.

Dash is our second game template: an endless runner whose levels can start as a 2D side-scroller and swing into 3D mid-run. Pick two points on a real street map and the route becomes a level, street names and landmarks included:

CityRoute route = new CityRoute("Old Harbour")
        .leg(420, CityRoute.STRAIGHT, "Quay Street")
        .leg(310, CityRoute.LEFT, "Rope Walk");
LevelDef level = route.level();

The server replays every run to keep the leaderboards clean, and friends race the same track with voice chat. Saturday's Dash article has the details.

Pulse: heart rates from the wrist to the trainer

Download the trainer video.

Pulse is a gym and studio template built around health data. A member's watch or Bluetooth chest strap feeds a workout session, the readings go to the studio's backend, and the trainer sees every member's heart rate zone live. Past workouts come in from HealthKit or Health Connect through one API. Sunday's Pulse article walks through the health code.

Xbox, and help with consoles

codename1.arg.windows.xbox=true builds the native Windows port as a UWP app for Xbox Developer Mode:

Your game keeps reading Display.getGameAction() as it does on a phone. We haven't run it on a real Xbox yet, and Developer Mode can't sell a game. Shipping on consoles needs SDKs behind NDAs, so Tuesday's Xbox article is also a request: if you can open that door, talk to us.

Port your Spring code with fewer edits

Porting real services to the Codename One backend keeps finding the small things a Spring developer expects. This round closed a batch of them, so code like this now moves over unchanged:

@RestController
@CrossOrigin(origins = "https://shop.example.com")
public class OrderController {
    private static final Logger LOG = Logger.getLogger(OrderController.class);

    @PostMapping(value = "/orders", consumes = "application/json", produces = "application/json")
    public Order place(@RequestBody Order order) {
        if (order.lines.isEmpty()) {
            throw new ResponseStatusException(400, "An order needs at least one line");
        }
        MDC.put("customer", order.customer);
        LOG.info("Placing order with {} lines", order.lines.size());
        return orders.save(order);
    }
}

Json.read(body, Order.class) and Json.write(order) work through codecs generated at build time, String.matches and java.util.regex work, and BigDecimal, YearMonth, Semaphore and ConcurrentLinkedQueue are there. A cn1lib can now also ship its own controllers, entities, and migrations. Wednesday's backend article has the full list.

Dart debugging, a faster web port and JFX Central

Download the JFX Central video.

That's JFX Central, a real JavaFX application written by JavaFX experts, running on an iPhone through our JavaFX layer. It isn't as polished as an app written for Codename One, but bindings, cells, CSS and remote images all work.

Flutter apps now debug in Dart: the build rewrites the class files' line tables and adds a JSR-45 source map, so stack traces name your .dart files and the standard Java debugger steps through Dart. The JavaScript port got faster too. It inlines getters and setters, fuses StringBuilder chains into plain string operations and keeps every array packed. String building in our compute suite went from 99 to 68 ms, and every checksum still matches the JVM. Integer division by zero now throws ArithmeticException in the browser, as Java says it should. Thursday's article covers all three.

Try it

The embedded Linux chapter covers displays, the GPU path, board profiles, deployment, hardware access, the five connected-product shapes and the full benchmark with its method. The harness is in scripts/embedded/bench in the repository if you want to rerun it on your own board. I'd love to see those numbers.

If you're building a device, tell me what board it runs on and what you're using today. And if your product needs an OS we don't support yet, that's exactly the conversation I want to have.

Caches, Certificates, Streaming Uploads and a Simulator That Types

Shai Almog — Thu, 12 Nov 2026 14:01:23 +0000

The templates this month (a bank, a streaming service, a messenger, a delivery service and a game) all have servers, and every server ran into something a modern web app takes for granted. This post collects what we added to the Codename One backend to fill those gaps. Several of them apply to the client too. Then there's the simulator, which can now show a virtual keyboard and record a video of your app.

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.

If you write Spring Boot during the day, most of this will look familiar on purpose. When there's no reason to differ, the backend behaves the way Spring does.

A bounded cache

Bastion looks up prices on every quote. Calling the price feed on every quote is slow and burns the feed's quota. Caching forever shows stale prices. The new cache has a size bound, expiry, a removal listener and metrics:

private static final Cache<String, Price> PRICES = Cache.<String, Price>builder("prices")
        .maximumSize(10000)
        .expireAfterWriteMillis(60000)
        .removalListener((sku, price, cause) -> {
            if (cause == Cache.SIZE) {
                System.out.println("evicted " + sku);
            }
        })
        .build();

Tokens for calling other services

Your server calls other servers: a Google API with a service account, a billing service with client credentials. AccessTokenProvider fetches the token, caches it and refreshes it before it expires:

AccessTokenProvider billing(Config config) throws IOException {
    return new AccessTokenProvider(ClientCredentialsGrant
            .builder("https://auth.example.com/oauth/token", "orders-service")
            .clientSecret(config.get("billing.client-secret"))
            .scopes("invoices:write")
            .build());
}

The same change added importing users from an existing identity store, so moving an app's accounts over doesn't mean asking everyone to reset a password.

Certificates without OpenSSL on the command line

Banks and partners love mutual TLS and private certificate authorities. The PKI API parses PEM, validates a chain against your own anchors, creates certificate signing requests and reads and writes PKCS#12:

List<Certificate> anchors = Certificate.listFromPem(KeyFiles.read("/etc/app/partner-ca.pem"));
List<Certificate> path = new CertificateValidator(anchors)
        .forHost("api.partner.example")
        .validate(Certificate.listFromPem(presentedPem));

Errors in one place

@RestControllerAdvice and @ExceptionHandler turn exceptions into responses once, instead of a try and catch in every handler. Interceptors and validation came with the same change.

@RestControllerAdvice
public class ApiErrors {
    @ExceptionHandler(IllegalArgumentException.class)
    public HttpServer.Response badInput(IllegalArgumentException e, HttpServer.Request request) {
        return HttpServer.Response.text(400, e.getMessage()).header("X-Error", "input");
    }
}

Streaming bodies and a proxy

Reel's uploads are video files. Reading them into memory isn't an option. request.getBodyStream() hands you the body as it arrives, and large uploads, multipart ones included, spool to disk instead of the heap:

@PostMapping("/archive")
public Map<String, Long> archive(HttpServer.Request request) throws IOException {
    long total = 0;
    byte[] buffer = new byte[64 * 1024];
    InputStream in = request.getBodyStream();
    try {
        for (int n = in.read(buffer); n > 0; n = in.read(buffer)) {
            total += n;                 // store, hash or forward each block
        }
    } finally {
        in.close();
    }
    return Collections.singletonMap("bytes", total);
}

HttpProxy forwards a request to an internal service. It reaches only its target and the hosts you allow, so a crafted path can't turn your server into an open proxy:

images = new HttpProxy("https://images.internal:8443")
        .allowHost("cdn.internal");

@RequestMapping("/images/{name}")
public HttpServer.Response image(HttpServer.Request request) {
    return images.forward(request);  // the same path and query, upstream
}

JSON codecs and java.time in the ORM

These two apply to the client as well as the server. JSON mapping gained custom codecs through JsonTypeAdapter, constructor based creators, generics, arrays and explicit null handling. A codec turns a type into JSON and back, here a money amount kept as a decimal string so it never passes through a double:

public final class MoneyAdapter implements JsonTypeAdapter<Money> {
    public Object toJson(Money m) {
        return m == null ? null : m.toDecimalString();
    }
    public Money fromJson(Object json) {
        if (json == null) {
            return null;
        }
        if (!(json instanceof String)) {
            throw new IllegalArgumentException("expected an amount");
        }
        return Money.parse((String) json);
    }
}

Put @JsonAdapter(MoneyAdapter.class) on the field or the class and the mapper uses it.

The ORM now maps java.time without an annotation: Instant and LocalDateTime as epoch milliseconds and LocalDate as an epoch day, so a date column is a number you can index and compare:

@Entity
public class Booking {
    @Id
    private long id;
    private Instant created;        // epoch milliseconds
    private LocalDate checkIn;      // epoch day
    private LocalDateTime pickup;   // epoch milliseconds
}

Tests that start only what they need

@WebMvcTest starts one controller and the beans you list, not the whole application, and MockMvc calls it without a socket:

@WebMvcTest(value = GreetingApi.class, includes = Greetings.class)
class GreetingSliceTest {
    @Autowired
    private MockMvc mvc;

    @Test
    void greetsWithOnlyTheControllerWired() throws Exception {
        mvc.perform(get("/greet/{name}", "Ada"))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$.greeting").value("Hello, Ada"));
    }
}

The same change defined a metric schema and probes for observability, so a dashboard means the same thing for every Codename One service.

The backend is still a tech preview. The backend chapters of the developer guide cover each of these, with the code that the snippets above come from.

A simulator that types

Here's a bug you've probably shipped. The login form looks great in the simulator. On a phone, the keyboard slides up and covers the password field, or the layout jumps, and nobody noticed because the simulator never had a keyboard.

Now it does. Simulate > Virtual Keyboard slides up a keyboard styled after the skin's platform, and it behaves the way that platform does:

iOS: the screen keeps its size, Display.getInvisibleAreaUnderVKB() reports the keyboard height, and the focused field scrolls into view.
Android, resize mode: the form gets a sizeChanged and lays out again.
Android, pan mode: the whole screen shifts up.

The simulated iOS keyboard sliding up over a sign up form.Recorded by the simulator itself, driven over MCP by the script below.

By default Android picks a mode per field, the way the real platform does. The Android: Resize and Android: Pan menu items, or the androidSoftInput setting, force one so you can test both.

The simulator also records. It writes MP4, MOV, WebM or an animated GIF, of the screen alone or inside the device skin, on a fixed frame clock so the video doesn't stutter when your machine is busy. Taps show touch indicators and can play a click, and you can add captions. That's a store preview, a bug report or a tweet, without a screen recorder.

Both are also tools in the simulator's built in MCP server, so a coding agent can drive a whole flow and hand you the video:

sim_keyboard_set   {"mode": "ios"}
sim_record_start   {"path": "/tmp/signup.mp4", "frame": "screen"}
sim_record_caption {"text": "The keyboard slides up, the field stays visible"}
ui_snapshot        {}
sim_tap            {"nodeId": 41}
sim_keyboard_type  {"text": "ada@example.com"}
sim_keyboard_key   {"key": "next"}
sim_keyboard_type  {"text": "correct horse"}
sim_keyboard_key   {"key": "done"}
sim_record_stop

It's an emulation of each platform's keyboard behavior, not the native keyboard itself, so do a final pass on a device. But the covered password field shows up on your desk now, not in a one-star review. The simulator keyboard and recording section of the MCP chapter lists every tool.

That's the week

Flutter, Compose, Swing, JavaFX and Android code, a bank, a streaming service, phones without Google and a better backend. Next week, we keep going. The Flutter post links everything from this week in one place.

GrapheneOS, LineageOS, /e/OS and Others Are Now Officially Supported

Shai Almog — Wed, 11 Nov 2026 15:03:44 +0000

This post is mostly about phones that don't have Google at all: GrapheneOS, LineageOS, CalyxOS, /e/OS and other Android builds. Codename One now supports them officially. After that, a shorter update on the Android compatibility layer, which runs existing Android apps on iPhone, desktop and the web.

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.

GrapheneOS, LineageOS, CalyxOS and /e/OS

I was a member of Team OS/2. I know what it's like to use an operating system the big vendors forgot, and to find that half the apps you need just don't start. People choose GrapheneOS, LineageOS and other AOSP builds for good reasons, usually privacy, and they deserve apps that work. There's a business case too: when you support a niche operating system its users have learned to live without, you get the most loyal advocates your product will ever have. They notice, they remember, and they tell each other.

Codename One apps mostly worked on these phones before. But mostly isn't support: call the wrong API and you could hit a failure, or behavior nobody could predict. Now it's official, with a clear boundary. One APK serves both kinds of phone: at run time it checks whether Google Play Services is there. No build hint, no flavor, no second build. The Android port never calls Play services, Play Core or Firebase without checking first, and CI enforces that, so a future change can't quietly break it.

Feature	With Google Play	Without Google Play
UI, storage, networking, SQLite, media	Works	Works
On device ML Kit models	Works	Works
Location and geofences	Fused location	Framework `LocationManager`
Maps	Google Maps	Vector `MapView`
Google sign in	Native	Browser OAuth flow
Push	Firebase	UnifiedPush (ntfy, NextPush, Sunup)
In-app purchase	Play Billing	Not available
Integrity attestation, in-app review	Works	Not available

The location fallback fixed something on Google phones too: builds without Play location now get proximity alerts and background location through the framework API.

Push, with one line

Push needs one line of configuration, because the phone has no Firebase to deliver it. UnifiedPush lets the user pick the app that holds the push connection, called a distributor. A UnifiedPush endpoint is a standard Web Push subscription, so the Codename One push service delivers to it with the Web Push credential your app already has. You copy its public key into a build hint:

codename1.arg.android.unifiedPush.vapidKey=<your 87 character VAPID public key>

Your app code doesn't change, and neither does your server. The registration order is automatic:

The one real gap is in-app purchase. Play Billing needs the Play Store. If selling on de-Googled phones matters to you, tell us; it's something we can add.

To test, use the Android emulator's AOSP system images, the default target, which have no Google apps. The Android without Google Play chapter has the details.

Also new: classic Android apps, on iPhone

Three weeks ago we showed that an Android Studio module's src/main can build unmodified as a Codename One app. There's no Android runtime inside it. Views are Codename One components, layouts follow Android's measure and layout rules, and resources compile to a binary table at build time. Nothing parses XML or uses reflection on the device. You import a project with one command:

mvn cn1:import-android-project -Dcn1.android.import=/path/to/MyAndroidApp
mvn cn1:build -Dcodename1.platform=ios

Material 3.
RecyclerView.
Kotlin activities.

Each pair shows Android on the left and Codename One on the right, from the same source.

What's new: the parts real apps lean on

Toy apps are mostly UI. Real apps store data, run work in the background and talk to the hardware. The layer now covers those:

Room. The build generates the _Impl classes, the way Android's annotation processor does. Features we don't support yet (@Relation, suspend DAOs, Flow, Rx, Paging, @AutoMigration and FTS) fail the build and name the member.
WorkManager. Chains, unique work, retries and LiveData status, persisted across app restarts.
Location and sensors. LocationManager and SensorManager.
Services. Manifest services, including startForeground() mapped to Codename One's ForegroundService. Notifications from NotificationManager and NotificationCompat show as local notifications.
Keystore. AES keys from AndroidKeyStore with GCM and CBC.
Document pickers. ACTION_OPEN_DOCUMENT, ACTION_CREATE_DOCUMENT and ACTION_GET_CONTENT, plus the ActivityResult contracts, open the platform's native open and save dialogs.

So this is ordinary Android code, and it now runs on an iPhone:

@Dao
public interface NoteDao {
    @Query("SELECT * FROM Note ORDER BY created DESC")
    List<Note> all();

    @Insert
    long insert(Note note);
}

Intent save = new Intent(Intent.ACTION_CREATE_DOCUMENT);
save.addCategory(Intent.CATEGORY_OPENABLE);
save.setType("text/plain");
save.putExtra(Intent.EXTRA_TITLE, "notes.txt");
startActivityForResult(save, SAVE_NOTES);

Where iOS says no

Some Android behavior has no iOS equivalent, and the Android chapter has a table for it. Location in a foreground service keeps running in the background when the manifest asks for background location. Other foreground service work gets only the short window iOS allows. Constrained WorkManager jobs go to iOS's background task scheduler, and iOS decides when they run. On iOS, ACTION_CREATE_DOCUMENT returns RESULT_OK right away and shows the save dialog when your app closes the output stream, so a cancel isn't reported back.

Other limits: Keystore keys aren't hardware backed there, Parcel is an in process container, SQLite uses a single connection, there are no system content providers or broadcasts, and reflection based libraries won't run on iOS.

Tomorrow, the last post of the week: Caches, Certificates, Streaming Uploads and a Simulator That Types.

Reel: Your Own Streaming Service or Course Platform

Shai Almog — Tue, 10 Nov 2026 14:36:01 +0000

Video is how a lot of businesses now talk to their customers. A gym sells classes, a university publishes lectures, a creator community wants its own home instead of renting space on someone else's platform. They all need the same pieces: a catalog, a player that remembers where you stopped, uploads, moderation, payments and some protection for paid content.

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.

Reel is those pieces, the app and its server in one Java project. Like last week's Skirmish, Parley and Savor, it's a template you generate and brand, not a demo you admire.

The catalog.
Audio and subtitle tracks.
A course and its lessons.
The moderation queue.

One template, three businesses

Reel's behavior is driven by presets you switch at run time, with no rebuild:

Subscription service. Plans or rentals, profiles, downloads, resume across devices.
Creator platform. Anyone with the creator role uploads video, the server packages it, and moderators approve it before it's public. Think of a community YouTube for your niche.
Academy. Courses, lessons and quizzes, for training and tutorials.

On top of the preset, toggles turn ads, rentals, downloads, uploads, courses, quizzes and polls on or off. The server assigns roles (viewer, creator, moderator and admin) and the app shows each person the screens their role allows.

Uploads and moderation

Creators upload from the app and the server packages each upload for streaming and checks it against blocklists the moderators maintain. A title only goes live after a moderator approves it, and a moderator can take it down later. Takedowns take effect mid-stream: the player's heartbeat checks with the server, so a removed title stops playing instead of running to the end.

A streaming API with DRM, in core

Reel needed playback for protected video, and that belongs in the framework, not in one template. So Codename One now has a streaming API in com.codename1.media. It's small on purpose:

Class	What it does
`StreamRequest`	An HLS manifest or a progressive file URL, plus a start position, request headers, a completion callback and an optional DRM configuration. `create()` or `createAsync()` returns an ordinary `Media`.
`DrmConfig`	The scheme and license server URL, headers sent with every license request, a FairPlay certificate URL and a content id.
`DrmScheme`	`AES_128` (encrypted HLS), `CLEARKEY`, `WIDEVINE` and `FAIRPLAY`.
`MediaManager.isDrmSupported(scheme)`	Whether this device can play a scheme, asked before you open the stream.

Opening a protected stream that resumes where the viewer stopped:

StreamRequest req = new StreamRequest(manifestUrl)
        .setStartPosition(resumeSeconds * 1000)
        .setDrm(new DrmConfig(DrmScheme.CLEARKEY, licenseUrl)
                .addLicenseHeader("X-Reel-License", licenseToken));
req.createAsync().ready(media -> {
    player.add(BorderLayout.CENTER, media.getVideoComponent());
    player.revalidate();
});

Each port maps the scheme to what the device has: AVPlayer decrypts AES-128 HLS and plays FairPlay on Apple, and Android's player and MediaDrm handle AES-128 HLS, ClearKey, and Widevine where the device has it. Devices differ, so Reel asks first and sends the server the schemes this device can play, strongest first. The server picks one and returns the matching manifest and license URL:

List<String> out = new ArrayList<String>();
DrmScheme[] order = {DrmScheme.WIDEVINE, DrmScheme.FAIRPLAY, DrmScheme.CLEARKEY, DrmScheme.AES_128};
for (int iter = 0; iter < order.length; iter++) {
    if (MediaManager.isDrmSupported(order[iter])) {
        out.add(order[iter].name());
    }
}

Out of the box, Reel packages each video once, as AES-128 HLS and as CENC encrypted MP4 for ClearKey, under one key. Keys are issued only against a license token tied to the session, and every playlist, segment and key request carries a media token that expires and is scoped to one video and a maximum quality. Concurrent stream limits are enforced by the heartbeat. Protected video also blocks screenshots and screen recording, and can add a watermark with the account name.

I'll be direct about the limit: AES-128 and ClearKey stop casual copying, not a determined attacker, because the key reaches the device. For studio grade protection you plug in a Widevine or FairPlay license vendor through reel.drm.widevine.url and reel.drm.fairplay.url. The server forwards the license challenge, and the app code doesn't change.

Audio tracks and subtitles

Subtitles over a lesson.
Language and size settings.
A creator adds a track per language.

Creators add a subtitle track per language in the studio, as WebVTT. The server checks that it really is WebVTT and stores it beside the video, not inside the stream.

That last part is a deliberate choice. A platform player can render text tracks, but each one finds them differently, styles them differently, and some can't see a track inside an encrypted stream at all. So Reel draws subtitles itself, over the picture, and they look the same on every device and under every DRM scheme. The parser is about a hundred lines of plain Java in the template: it reads each cue's start and end time and its text, and drops WebVTT's positioning and inline tags such as <i> and <v Speaker>:

Captions.load(track.url(), loaded -> {
    if (wanted.equals(subtitleLanguage)) {
        captions = loaded;
        updateCaption();
    }
});

private void updateCaption() {
    String text = captions == null ? "" : captions.at(media.getTime());
    if (!text.equals(caption.getText())) {
        caption.setText(text);
    }
}

captions.at(millis) returns the cues that cover that moment, one per line, and the player calls it as the position moves. Switching subtitles in the player's Audio & subtitles sheet takes effect at once, because nothing about the stream changes. Switching the audio language or the quality reopens the stream at the same position, and the server marks the viewer's preferred audio track as the playlist default, so it starts in the right language.

Payments and the rest

Payments are simulated in the dev profile; the test card 4242 4242 4242 4242 goes through. Set reel.payments.provider=stripe for Stripe, and store purchases are verified with Apple and Google. Push goes through the Codename One push service. Reel also runs in a browser with nothing installed, which is how many viewers will first meet your service.

The same app on a desktop.

Try it

Generate Reel from the Initializr. The user's guide walks through every screen, and the implementor's guide covers the packaging pipeline, DRM vendors and what to change before you launch. The template source is free under MIT-0, with no royalties and no revenue share.

Tomorrow: GrapheneOS, LineageOS, /e/OS and Others Are Now Officially Supported.

Bastion: A Hardened Bank Template, and Crypto Wallets in Core

Shai Almog — Mon, 09 Nov 2026 14:01:15 +0000

A large share of the teams building on Codename One are banks and financial institutions. They don't ask me for a prettier list component. They ask how to pass a penetration test, what the auditor will want to see, and which protections actually work on which device.

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.

Bastion is my answer, written as code. It's a virtual bank and a small exchange, the app and its server in one Java project. Customers hold dollars, euros, bitcoin and ether, move money, issue and freeze cards, trade, and withdraw coins to addresses they've allowed in advance. Staff verify the ledger and the audit trail. It's a template you can brand, but mostly it's a reference: every hardening technique in it is there so you can read how it's done.

Accounts in four currencies.
The BTC/USD market.
Withdrawals to allowed addresses.
What is on, on this device.

Defense in layers

No single protection makes an app secure. Bastion stacks them, so an attacker who gets past one meets the next.

Signing in. OAuth authorization code with PKCE, five minute access tokens and rotating twelve hour refresh tokens. A TOTP second factor with ten recovery codes, plus WebAuthn passkeys. Once an account has a passkey, Bastion requires the strongest factor it has. Lockouts and per address rate limits slow down guessing, and changing the password ends every other session.

The device. On first sign in, the app generates a P-256 key pair, registers the public key with the server, and seals the private key with AES-256-GCM under a key kept in the Keychain or Keystore. The app locks after 30 seconds in the background or two minutes idle, and unlocks with biometrics, then a PIN, then a full sign in.

Every request that moves money is signed. Not just authenticated with a token. Signed with the device key, over a canonical form that includes a timestamp and a single use nonce:

String text = SignedRequest.canonical(method, target, Hash.sha256(body),
        idempotencyKey, nonce, ts);
byte[] der = Signature.sign(Signature.SHA256_WITH_ECDSA, privateKey, utf8(text));
return SignedRequest.header(deviceId, ts, nonce, Base64.encodeUrlSafe(jose(der)));

A stolen access token can't move money without the device key. A captured request can't be replayed, because the nonce is spent.

The network. The app refuses cleartext, talks only to an allow list of hosts, and pins their certificates. That's AppShield, a Codename One API, configured in a few lines:

ShieldConfig shield = new ShieldConfig().collectSignals(true);
for (String host : AppConfig.ALLOWED_HOSTS) {
    shield.protect(host, HostPolicy.ENFORCED);
}
AppShield.init(shield);

The screen. Secure windows that keep sensitive screens out of screenshots and the app switcher, tapjacking protection, and a clipboard that clears itself after you copy an account number.

Limits. Per transfer and daily limits, a cooling-off period for new payees, step up authentication above a threshold, and an allow list for crypto withdrawals.

The Security Center tells the truth

Most security settings screens show a column of green checks. Bastion's Security Center shows what's actually on for this device and this build. Some protections need a cloud build: code obfuscation with string encryption and control flow flattening (cn1.hardenLevel=aggressive), Play Integrity, jailbreak detection, and blocking screenshots when the app goes to the background. When those aren't active, the Security Center labels them "Cloud build" rather than showing a green check. A test keeps that screen in sync with the build hints, so it can't drift into a lie.

The back office auditors want

Money is a double entry ledger, not a balance column. The admin console has the journal, T-accounts, a trial balance, a balance sheet, an income statement, reconciliation, period close and a maker checker approvals queue. Every event lands in a hash chained audit log, and the console can verify the chain and export evidence as CSV. A read only auditor role sees all of it, on a desktop or on a phone.

The back office console.

Crypto wallets, exchanges and custody, in core

I'm not a fan of crypto currency. I know plenty of people who are, and a few of them are customers. We're here to serve, and if we serve, we should be the best at it. So this isn't a wallet library bolted on the side. It's a big feature: everything a wallet, an exchange or a custodian needs, in core, with no third party library, and the same classes run in the app and in a Codename One backend.

Package	What's in it
`crypto.hd`	BIP-39 recovery phrases, BIP-32 and SLIP-10 derivation, `DerivationPath`
`crypto.evm`	EIP-55 addresses; legacy, EIP-2930 and EIP-1559 transactions; EIP-191 and EIP-712 signing; the Solidity ABI and ERC-20
`crypto.bitcoin`	P2PKH, P2SH, P2WPKH, P2WSH and Taproot addresses, scripts, transactions, PSBT and WIF
`crypto.solana`	Transactions, the system and SPL token programs, priority fees
`crypto.wallet`	`Wallet`, `Signer`, `SeedSigner` and `VaultSigner`
`crypto.rpc`	EVM JSON-RPC, Esplora for Bitcoin, Solana JSON-RPC
`crypto.market`	Price feeds: CoinGecko, any JSON price API, and a caching decorator

A wallet

One recovery phrase gives you addresses on every chain, and they match MetaMask, Electrum, Sparrow and Phantom on the standard paths, so a user can restore the same phrase in another wallet and find the same money:

String words = Mnemonic.generate(256);           // 24 words
Wallet wallet = Wallet.fromMnemonic(words, "");
EvmAddress eth = wallet.getEvmAddress(0, 0);                 // m/44'/60'/0'/0/0
BitcoinAddress btc = wallet.getBitcoinAddress(BitcoinNetwork.MAINNET,
        Wallet.BIP84, 0, 0, 0);                              // bc1q...
SolanaAddress sol = wallet.getSolanaAddress(0);              // m/44'/501'/0'/0'

Bitcoin covers legacy, nested SegWit, native SegWit and Taproot, on the main network and on every test network. Sending ether is an EIP-1559 transaction with the fees the node suggests:

EvmRpc rpc = new EvmRpc(new NetworkTransport(), "https://ethereum-sepolia-rpc.publicnode.com");
DerivationPath path = Wallet.evmPath(0, 0);
EvmAddress from = wallet.getEvmAddress(path);
long nonce = rpc.getTransactionCount(from, "pending");
UInt256[] fees = rpc.suggestFees();                     // {tip, fee cap}
long gas = rpc.estimateGas(from, to, value, null);

EvmTransaction tx = EvmTransaction.eip1559(rpc.chainId(), nonce, fees[0], fees[1],
        gas, to, value, null);
String hash = rpc.sendRawTransaction(wallet.signEvmTransaction(tx, path));

Bitcoin goes through a PSBT, so the same code works with a hardware signer that only sees the partially signed transaction. Taproot inputs are signed with BIP-340 Schnorr automatically:

EsploraClient.Utxo coin = esplora.getUtxos(from).get(0);
BitcoinTransaction tx = new BitcoinTransaction();
tx.addInput(coin.getTxid(), coin.getVout());
tx.addOutput(coin.getValue() - feeSats, BitcoinAddress.parse(recipient, net));

Psbt psbt = Psbt.fromTransaction(tx);
psbt.setWitnessUtxo(0, coin.toOutput());
psbt.signAll(wallet.getBitcoinKey(path));
psbt.finalizeAll();
String txid = esplora.broadcast(psbt.extract());

Keys are handled the way a security review expects. VaultSigner keeps the phrase sealed behind biometrics or a password and refuses to sign while it's locked. revealMnemonic returns a char[] you can wipe, not a String that lingers on the heap, and SeedSigner.destroy() wipes the key.

An exchange

An exchange is mostly the server side, and that's what Bastion's backend shows. It derives a deposit address per customer (m/44'/60'/0'/0/n), scans new blocks, credits deposits once they're deep enough, and sweeps them to a hot wallet on a separate account. It stops scanning and writes an audit event on a reorganization deeper than its confirmation depth. Before every withdrawal it checks that reserves cover what customers hold, and withdrawals go only to addresses the customer allowed in advance. Order prices are collared against the index price, so a fat finger can't sell bitcoin for a dollar.

Every one of those steps lands in the double entry ledger and the hash chained audit log from the previous section, which is what lets the auditor trace a coin from deposit to withdrawal.

Performance

The expensive parts (secp256k1, Schnorr, Ed25519, the hashes and PBKDF2) run as native C on iOS, macOS, Android, Windows and Linux, with a portable Java engine as the fallback. CI benchmarks every kernel against libsecp256k1, OpenSSL and BouncyCastle on the same machine, and a pull request that makes one slower fails.

Throughput as a multiple of the reference library. Above 1 is faster.

Natively, ECDSA signing matches libsecp256k1 (60,770 against 59,453 signatures a second), and Ed25519 signs 2.44 times as fast as OpenSSL. Even the portable Java engine, which the simulator uses, beats BouncyCastle on the JVM: 1.76 times on public key derivation, 1.49 on ECDSA signing, and 20 times the JDK's own Ed25519 provider. On Android the native engine verifies ECDSA signatures six times as fast as BouncyCastle on ART:

Android: the native and Java engines against BouncyCastle on ART.

A phone signs one transaction at a time. An exchange or an indexer checks thousands of signatures at once, so CryptoBatch takes a whole batch:

boolean[] valid = CryptoBatch.verifySecp256k1(hashes, signatures, publicKeys);

It spreads the batch across every core, and for large batches the GPU too: Metal on Apple, Vulkan elsewhere and WebGPU in the browser, split by measured speed. The GPU never sees a private key. On every core, a batch of 1,024 verifies ECDSA 7.46 times as fast as libsecp256k1 called once per signature, and Ed25519 15.6 times as fast. In the browser, WebGPU verifies ECDSA 8.5 times as fast as the portable engine.

A batch on every core, against the reference library one call at a time.

CPU, GPU and both together on an M4 Max.

The GPU's gain on a machine with 12 fast cores is modest, up to 1.63 times for Ed25519, and the chapter says so. Where it pays is a smaller CPU and the browser. Every table and chart is in the crypto wallets chapter, with the machine, the library versions and how to rerun them.

What's simulated

Bastion is a reference, not a licensed bank. Deposits, card spending and the market (a random walk) are simulated, and Android integrity checks trust every device in the dev profile. There's no KYC or sanctions screening, no payment rail, no HSM and no regulatory reporting. The implementor's guide has a section for each of those that says what a production deployment needs. On the crypto side, ether can settle on a real Ethereum node, while bitcoin stays a ledger balance in the sample. Only the three chain families above are supported, and the node clients are blocking calls, so keep them off the UI thread.

Try it

Generate Bastion from the Initializr, or run it from the repository:

CN1_PROFILE=dev backend/server.sh run
mvn verify -Psimulator -DskipTests -Dcodename1.platform=javase

Sign in as customer@bastion.example with the password bastion-demo-password, then open the Security Center and see what your build actually protects.

Tomorrow: Reel: Your Own Streaming Service or Course Platform.

Your Swing and JavaFX Code on iPhone, Android and the Web

Shai Almog — Sun, 08 Nov 2026 14:01:01 +0000

There's a lot of Swing and JavaFX code in the world. Much of it is internal tooling and line of business software that works fine and that nobody wants to rewrite. Then someone asks for it on an iPad, or in a browser, and the answer has always been "rewrite it."

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.

Codename One can now build a large share of that code for iOS, Android, the web and native desktop, as a native app with no JVM inside. SwingSet2 and Notepad, the JDK's own demos, both build and run. This post shows what carries over, what it costs in size and start-up (less than the JVM), and why the parts that don't carry over have better replacements in a client app.

SwingSet2, the JDK demo, on an iPad.
The JavaFX 2048 game on a phone.

What it does

You drop the project's src/main into a Codename One project, or import it:

mvn cn1:import-desktop-project -Dcn1.desktop.import=/path/to/MyDesktopApp

Your code keeps compiling against the JDK's own Swing, or against our JavaFX API under the real javafx.* names. A remap step after javac points the bytecode at our implementations of java.awt, javax.swing, java.beans, javax.imageio, a SwingX subset and a JavaFX subset, all written on top of Codename One. FXML files compile to Java classes at build time, and JavaFX CSS compiles to a table. Nothing parses XML on the device.

Swing controls.
JTable and JXTable.
JavaFX controls.
FXML with its CSS.

Unmodified desktop code on an iPhone, captured by our screenshot tests.

Our test set includes two JDK demos, SwingSet2 and Notepad, along with a Swing gallery, a falling blocks game, a JavaFX gallery, an open source 2048 game, an address book and a Mandelbrot explorer.

The numbers

On Linux, the same app as a jlink image against a Codename One native build:

Application	JVM image, zipped	Native, zipped	Smaller by
SwingSet2, the JDK demo	34.1 MB	8.2 MB	4.2x
Notepad, the JDK demo	32.8 MB	6.5 MB	5.0x
JavaFX gallery	39.1 MB	7.1 MB	5.5x
Address book (JavaFX)	39.1 MB	6.5 MB	6.0x

Download size, zipped.

Cold start on Linux.

From process start to the first painted frame, the native build starts faster than the default JVM in all 8 apps, by 1.5x to 5.5x. Against a JVM tuned with the serial GC, C1 only and an AppCDS archive, it's still faster in all 8, by 1.1x to 3.6x. The closest is the falling blocks game, at 86 ms native against 93 ms tuned. The JavaFX gallery starts in 116 ms native against 637 ms on the default JVM. The same apps build for iOS at 25 to 29 MB and as 2.8 to 4.4 MB Android APKs.

Memory is closer than you might expect. At idle the native Swing gallery holds 64.5 MB resident against 84.2 MB on a tuned JVM. After a scripted session of clicks and drags it's 90.8 MB against 86.0 MB.

What isn't supported

This is the important part, so here it is without softening:

No binary drop in. A third party jar that was compiled against java.awt, javax.swing or javafx fails the build. We don't relocate other people's jars. If the library ships source, you can bring the source.
No class loaders, ServiceLoader, modules or OSGi.
No runtime reflection. java.lang.reflect and Class.getMethod are build errors. Class.forName by string doesn't work on Android or the web.
No Java serialization, HttpURLConnection, java.net.http or raw sockets through these layers.
ProcessBuilder doesn't exist on a phone. Check ProcessBuilder.isSupported().
Only a subset of the API. Swing is big. When you call something we don't have, the build tells you exactly what and where:

com/example/OrdersPanel#restyleTree()V -> javax.swing.JTree.getUI() is not
supported by the Codename One Swing compatibility layer
(com/example/OrdersPanel.class) at OrdersPanel.java:48

That error is the point. You find out at build time, on your machine, with a file and line number. You don't find out from a user on an iPad.

Why pay for what you don't need?

Look at that list again and ask where those features show up in a typical desktop app. Reflection usually powers a binding framework, a serialization library or a dependency injector. Class loaders power plugins. Serialization powers a cache or a save file.

Codename One does those jobs at build time instead. Binding a form to a model is generated code, with no reflection and no listener bookkeeping:

@Bindable
public class LoginModel {
    @Bind(name = "userField", attr = BindAttr.TEXT)
    @Required
    private String user;
    public String getUser()         { return user; }
    public void   setUser(String u) { this.user = u; }

    @Bind(name = "rememberMe", attr = BindAttr.SELECTED)
    public boolean remember;
}

The same goes for JSON and XML mapping, REST and GraphQL clients and the SQLite ORM. They're all generated by the build, so they're type checked, they survive dead code elimination, and they cost nothing at startup. Reflection is what makes a JVM app big and slow to start. Removing it is a large part of why the native build is 4 to 6 times smaller.

What desktop Java never gave you

You don't have to wait for a phone to get something out of this. On the desktop, today, the same app picks up things Swing developers have fought for years to get, and that JavaFX offers only as its own aging WebKit fork:

A real browser. BrowserComponent embeds the system's engine: WebKit on the Mac, WebView2 on Windows and WebKitGTK on Linux, with two way calls between Java and JavaScript. No bundled Chromium, no JEditorPane rendering HTML 3.2.
The camera. Capture takes photos and video from the webcam on macOS, Windows and Linux. In Swing that has meant a native library and a prayer.
Bluetooth LE. The Bluetooth API talks to real devices on all three desktops, so the tool that configures your hardware no longer needs a vendor SDK or a serial port bridge.
Maps. A vector MapView drawn by Codename One itself, with markers and shapes, the same on the desktop as on a phone.
The web. The same app builds for the browser, so the internal tool people install today can also be a link, with nothing installed.
Generated network clients. Point cn1:generate-openapi at an OpenAPI 3 spec and you get a typed client. GraphQL and gRPC have goals of their own, and OAuth and sign in with Google or Apple are built in.
SQLite with an ORM whose mapping mistakes fail the build, CSS styling with light and dark themes and live reload, and a Java backend in the same project, sharing your types.

And when the app does reach a phone, push, biometrics, NFC and location are there too.

SwingInterop.asComponent() and FxInterop.asComponent() wrap a Swing component or a JavaFX node as a Codename One component, so you can migrate one panel at a time and put a Codename One map or camera view next to your existing table.

Try it

The desktop compatibility chapter has the full list of what's covered, the import steps and the benchmark method. Start with the screen your users ask for on mobile, run the import and read the build errors. They'll tell you how far you are.

Tomorrow: Bastion: A Hardened Bank Template, and Crypto Wallets in Core.

Your Compose Code, on More Screens and Less CPU

Shai Almog — Sat, 07 Nov 2026 14:03:54 +0000

If Codename One didn't exist, Kotlin Multiplatform is probably the platform I'd choose. I prefer Java, but Kotlin is a good language, and KMP was one of the strongest platforms we measured against in the Flutter post this week. Its first take on UI leaned on heavyweight native widgets, the way React Native does. The team learned from that, and Compose Multiplatform today is a good product built by people who care about performance.

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 this post isn't about KMP being bad. KMP is good. This is also good, and in a few ways better. Your Compose code now builds as a Codename One app, so it reaches more targets and did less work per frame on our benchmark. You don't have to pick one forever: the same commonMain builds both ways.

What you keep

There's no transpiler here. kotlinc compiles your Kotlin for the JVM with the Compose compiler plugin, exactly as it does today. The Compose runtime and kotlinx.coroutines are the upstream jars. The UI layer (androidx.compose.ui, foundation, material3 and animation) is our reimplementation, written over Codename One components and graphics. Then ParparVM compiles everything ahead of time to a native binary.

Dispatchers.Main is the Codename One event dispatch thread, so your coroutines behave the way you expect. Measuring follows Compose's rules: the modifier chain is walked outermost first, under Compose constraints. LazyColumn and LazyRow compose only what's on screen.

Bringing a KMP module over is one command:

mvn cn1:import-kmp-project -Dcn1.kmp.import=/path/to/MyKmpApp

It copies commonMain and your JVM source set into common/src/main/kmp, leaving out the file that opens a desktop window. A whole app is a ComposeForm:

class MyApp : Lifecycle() {
    override fun runApp() {
        ComposeForm { LayoutScreen() }.show()
    }
}

The numbers, and what they don't mean

The benchmark is Keynote, a Compose conference schedule app, built three ways: Compose on Codename One, Compose Multiplatform, and the same app written in plain Java on Codename One. All three were release builds on an iPhone 17 Pro simulator with Xcode 27, five runs each.

Keynote: Compose Multiplatform on the left, Codename One on the right.

	Compose on Codename One	Java on Codename One	Compose Multiplatform
Executable, stripped	16.8 MB	8.9 MB	22.9 MB
App bundle	18.3 MB	10.2 MB	22.9 MB
Cold start	961 ms	805 ms	1008 ms
Warm start, median	580 ms	572 ms	604 ms
Recomposition on a day change, median	4.58 ms	1.49 ms	19.24 ms
Scroll work per frame, median	4.04 ms	1.76 ms	17.03 ms
Frame interval, median	35.45 ms	34.79 ms	33.35 ms
Memory footprint	47 MB	47 MB	48 MB

Lower is better in every panel.

All three apps hit the same frame rate, and Compose Multiplatform is slightly ahead there. On a fast machine, a simple screen keeps up either way. What differs is how much CPU each one burns to get there: about 4 ms a frame for Compose on Codename One against about 17 ms for Compose Multiplatform. On a phone that's battery life, heat, and headroom for the frame where your screen isn't simple.

A few caveats, because they matter:

This is the simulator, not a phone. Scrolling is programmatic, not a finger fling.
Compose Multiplatform's first frame marker fires before Skia draws, so the start-up figures lean in its favor.
An empty UIKit app takes 640 to 750 ms to start in this setup, so most of every start-up figure is iOS itself.

Why imperative Java is faster and smaller still

Look at the middle column. The same screen, written imperatively in Java, handles a day change in 1.49 ms, a third of the Compose version on the same engine, and its executable is about half the size.

The benchmark is tilted toward Compose, too. The Java version was written to mirror the Compose app screen for screen, so it rebinds cards the way a recomposition would, and carries some of that model's overhead. A Java screen written from scratch the Codename One way would do less.

Declarative UI pays for its model by recomposing, diffing and remembering, which is work an imperative screen never does, because it changes the one label that changed. The usual argument is that the model buys you something back. Here is the same session card both ways. Compose:

@Composable
fun SessionCard(s: Session, favorite: Boolean, onFavorite: () -> Unit, onOpen: () -> Unit) {
    Card(onOpen, Modifier.fillMaxWidth()) {
        Row(verticalAlignment = Alignment.CenterVertically) {
            Box(Modifier.width(6.dp).height(84.dp).background(Color(s.track.color)))
            Column(Modifier.weight(1f).padding(12.dp)) {
                Text(s.timeLabel + "  -  " + s.room, style = MaterialTheme.typography.labelMedium)
                Text(s.title, style = MaterialTheme.typography.titleMedium, maxLines = 2)
                Text(s.speaker.name + ", " + s.speaker.company,
                    style = MaterialTheme.typography.bodySmall)
            }
            FavoriteButton(favorite, onFavorite)
        }
    }
}

Codename One, with the styling in CSS where it belongs:

class SessionCard extends Container {
    private final Label time = new Label("", "SessionTime");
    private final Label title = new Label("", "SessionTitle");
    private final Label speaker = new Label("", "SessionSpeaker");
    private final Button heart = new Button("", "Favorite");
    private Session session;

    SessionCard(Schedule app) {
        super(new BorderLayout(), "SessionCard");
        add(BorderLayout.CENTER, BoxLayout.encloseY(time, title, speaker));
        add(BorderLayout.EAST, heart);
        heart.addActionListener(e -> app.toggleFavorite(session));
    }

    void bind(Session s) {
        session = s;
        time.setText(s.timeLabel() + "  -  " + s.room);
        title.setText(s.title);
        speaker.setText(s.speaker + ", " + s.company);
    }
}

Put them side by side and the claimed advantages don't hold up:

Readability. Both are a box with three lines of text and a button. Neither is shorter in any way that matters. The Java version names its parts, so title is a field you can find, not the second Text call in a nested lambda.
Testability. Compose tests find nodes by test tags you add for the purpose. A Codename One test holds the component, calls bind, and asserts on title.getText(). The test framework and the simulator's MCP tools drive both the same way.
Debugging. This is where imperative code wins outright. Set a breakpoint in bind and you see the one call that changed the text, with a stack that leads back to your code. In Compose, the same change runs through the snapshot system, the runtime that schedules recomposition, and generated code from the compiler plugin, and "why did this recompose?" is a question you need a dedicated tool to answer.

Compose is a fine way to write UI, and if your team already has it, bring it. But it isn't simpler than the imperative code it replaced, and on this screen it costs two to three times the CPU and twice the binary. Codename One lets you choose per screen. Keep Compose where you have it, and write the hot screen in Java:

val form = Form("Mixed", BorderLayout())
form.add(BorderLayout.NORTH, Label("Codename One"))
form.add(BorderLayout.CENTER, ComposeView { ListScreen() })
form.show()

ComposeView is an ordinary Container, so a Compose screen and a Codename One component share a form, a theme and an event thread.

What's different on our side

More targets. iOS, Android, the web, native macOS, Windows and Linux with no JVM, plus watchOS and tvOS. The Keynote benchmark itself hasn't been built for watchOS, tvOS, Windows or Linux yet.
Java too. Your team can write Java and Kotlin in one project, and share code with a Java backend.
Smaller. 16.8 MB of executable against 22.9 MB, or 8.9 MB if the screen is in Java.
Build errors instead of surprises. A composable or modifier we haven't implemented fails the build with its original name and source line. It doesn't render wrong on a device.

What doesn't work yet

LazyColumn(reverseLayout = true) throws; it isn't implemented. Box, Row and Column aren't inline functions here, as they are upstream, because a public inline function can't call our internal layout code. The Compose runtime's inline functions are JVM 11 bytecode, so the build targets 11. On Gradle, the plugin refuses to build until org.jetbrains.kotlin.plugin.compose is applied, and it tells you the line to add.

Try it

The Kotlin Multiplatform chapter covers the import, mixing Compose with Codename One components, and the benchmark. The Keynote source and its harness are in scripts/kmp-bench in the repository. If you run KMP in production, I'd love to hear which composable you hit first that we don't have.

Tomorrow: Your Swing and JavaFX Code on iPhone, Android and the Web.

Flutter Better in Java

Shai Almog — Fri, 06 Nov 2026 16:03:34 +0000

I usually blog about a feature the week it lands. This one landed a few weeks ago and was in development for months before that: Codename One can now take a Flutter app's Dart source and build it as a Codename One app. The results are amazing. I held this post back because I know how explosive these claims are. I wanted the numbers to come from a CI job that runs on every commit instead of a benchmark I tuned once on my laptop.

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.

In the meantime we also added support for Kotlin Multiplatform with Compose, for a big part of Swing and JavaFX, and for classic Android apps on iOS. More is coming. The part that still surprises me is how well Codename One does against the originals where we measured them. The same Flutter app, built from the same Dart files, starts faster, uses less memory and ships less code when Codename One builds it. That holds on Android, macOS, Windows and Linux, and the sizes hold on iOS and the web too.

The same Dart, two builds

This is the Flutter Gallery, the Flutter team's own showcase app. On the left it runs as Flutter built it. On the right, Codename One built it from the same Dart source, with no edits.

Download the side by side video.

Look closely and you'll see it isn't pixel identical. In the Reply inbox the avatars are circles on the Flutter side and rounded squares on ours. Text wraps a few characters apart in places. The translation isn't perfect, and the developer guide says so up front: Dart support is experimental, some callbacks and parameters are accepted and then ignored, and so far we have verified it against one large app. If you bring a Flutter app over, test every interaction your screens depend on.

But the hard part works. Layout, navigation, theming, text input, lists and the Material and Cupertino widgets all render from the original source, and what you get is a real Codename One app, not a picture of one.

Bringing a project over is one command in a Codename One project:

mvn cn1:import-flutter-project -Dcn1.flutter.import=/path/to/flutter_app

It copies lib, the assets and the fonts, adds the Flutter runtime to the build, writes the main class and tells you which of your pub dependencies are covered. You don't need the Dart or Flutter SDK to build the result. The transpiler is Java and runs inside the normal Maven build.

Coming This Week

Today is the Flutter story and the numbers behind it. Then one post a day:

Saturday, October 31: Your Compose Code, on More Screens and Less CPU. Kotlin Multiplatform and Compose, running on Codename One, and why the Java version of the same screen is faster still.
Sunday, November 1: Your Swing and JavaFX Code on iPhone, Android and the Web. What carries over, what doesn't, and why you might not miss the parts that don't.
Monday, November 2: Bastion: A Hardened Bank Template, and Crypto Wallets in Core. A virtual bank and exchange with passkeys, signed requests and a double entry ledger, plus wallets for Ethereum, Bitcoin, and Solana.
Tuesday, November 3: Reel: Your Own Streaming Service or Course Platform. Community uploads, courses, DRM and moderation in one Java project.
Wednesday, November 4: GrapheneOS, LineageOS, /e/OS and Others Are Now Officially Supported. Room, WorkManager and document pickers in the Android layer, and apps that run on GrapheneOS as they are.
Thursday, November 5: Caches, Certificates, Streaming Uploads and a Simulator That Types. Eight backend upgrades and a simulator with a virtual keyboard and video recording.

Compose, on Codename One.
Bastion's Security Center.
Reel's catalog.
Android code, on every target.

The numbers

Every commit to Codename One builds the Flutter Gallery twice: once with Flutter's own release build and once with Codename One. CI measures both on the same machine in interleaved rounds, so a runner that slows down halfway through penalizes both builds equally. The figures below are from the run on October 29.

CI collects 26 metrics: installed size, executable code and download size on six platforms, plus cold start and memory at rest on the four where we can measure both sides fairly. Codename One is ahead on all 26. The Android timings come from an emulator, and iOS start-up and memory aren't measured; both are explained below. The biggest gaps are on Android, where the app starts in a third of the time and carries a quarter of the code, and on Linux, where it settles at 82 MB against 224 MB.

The comparison is tilted toward Flutter, not away from it. The app is Flutter's own showcase, written by the Flutter team in Flutter's idioms, and Codename One runs it as it is. To do that, Codename One carries a runtime that reimplements Flutter's widget, element and layout model on top of Codename One components. That layer is slower than Codename One code written directly; the Compose post shows the same effect, where the imperative Java version of a screen does a third of the work of the declarative one. A Codename One app never pays for that layer. We win while paying for it.

CI also runs eleven compute workloads (hash maps, recursion, string building, sorting, arithmetic and more) in Java and in Dart. On every native platform we measured, Codename One is faster overall, by 1.3x on Android up to 1.9x on Windows and Linux:

Flutter takes 5 of the 43 cells. Two are within 6%. The real one is object allocation on Android and macOS, where Dart's allocator is quick at short lived objects; that's on our list.

The web is the exception, and it's the one place Flutter is faster. We leave it out of the comparison because Flutter's web build gets some of the workloads wrong: integer arithmetic, random array access and quicksort return different checksums than the same code on every other platform, because Dart on the web runs numbers as JavaScript doubles. A benchmark that gets the answer wrong can't be timed against one that gets it right. On the workloads where both sides agree, Flutter is ahead. The browser is asynchronous by nature, and that's the one environment where Flutter's model helps it rather than costing it. The sizes still favor us there.

Some things aren't measured, and the charts leave them out rather than guess. Flutter can't compile Dart ahead of time for the iOS simulator, so iOS start-up and memory would compare Flutter's debug engine against our release build. We report iOS sizes only. Web start-up needs a browser driver the benchmark doesn't have yet. Android timings come from an emulator, so they compare two builds on one machine rather than predicting a phone. The method, the harness and the raw numbers are in the Flutter chapter of the developer guide, and the benchmark lives in scripts/flutter-bench in the repository.

How a compatibility layer can be faster than the original

Each of these compatibility layers is a tool that runs at build time. None of them is a VM inside your app.

The Dart transpiler reads your widget source during generate-sources and writes Java. A runtime library then implements Flutter's layout and composition model (constraints down, sizes up, elements reconciled against widgets) on top of Codename One containers. It does not reimplement Flutter's rasterizer. Painting is ours. Compose works the same way: kotlinc compiles your Kotlin, the Compose runtime ships unmodified, and only the UI layer is ours. Swing, JavaFX and Android apps compile against their usual APIs, and a remap step points the bytecode at our implementations.

So the overhead is real, and it's added on top of Codename One. The reason the result still wins is what's underneath. ParparVM compiles Java ahead of time to C and then to a native binary, and its dead code elimination drops whatever your app doesn't reach. There's no Dart VM, no Skia or Impeller engine and no second runtime in the bundle. That's how the Android build ends up with 4.7 MB of executable code against 20.6 MB.

Here is the Dart that calls into the platform. It's ordinary Flutter code:

final batteryChannel = MethodChannel('com.example.app/battery');

Future<int> getBatteryLevel() async {
  final level = await batteryChannel.invokeMethod('getBatteryLevel');
  return level as int;
}

And here is the other side of that channel, in plain Java, with no plugin and no per-platform Swift or Kotlin:

MethodChannel channel = new MethodChannel("com.example.app/battery");
channel.setMethodCallHandler(new MethodChannel.MethodCallHandler() {
    @Override
    public void onMethodCall(MethodCall call, MethodChannel.Result result) {
        if ("getBatteryLevel".equals(call.method())) {
            result.success(87);
        } else {
            result.notImplemented();
        }
    }
});

You don't have to move the whole app either. FlutterUI.wrap() returns an ordinary Container, so a Dart screen can sit inside a Codename One form next to components you wrote in Java:

Form dashboard = new Form("Dashboard", BoxLayout.y());
dashboard.add(new Label("Written in Codename One"));
dashboard.add(FlutterUI.wrap(new Text("Rendered from Dart")));
dashboard.add(new Button("Also Codename One"));
dashboard.show();

Similar in spirit

Flutter and Codename One made the same bet. Neither wraps the platform's widgets. Both draw every component themselves on a lightweight surface, so you control every pixel and the behavior doesn't drift between platforms. Codename One still ships native themes, so an app can look like iOS on an iPhone and like Material on Android, or look like your brand everywhere. That shared architecture is why a Flutter widget tree maps onto Codename One so naturally. The differences are in what sits around that core: the threading model, how apps are built and how features ship.

Can't Flutter do the same?

No. Flutter could, in theory, run a Codename One app the way we run a Flutter app. It would be slow, because the two models point in opposite directions.

Flutter is asynchronous to the core. Dart runs in an event loop, platform calls are messages that come back as futures, and the engine draws on its own threads. Codename One is synchronous: your code calls the platform and gets an answer. Emulating a synchronous API on top of an asynchronous one means queuing, waiting and copying on every call. Going the other way is cheap: a future is a callback, and a callback is a method call.

The same reason explains why Flutter can't catch Codename One on most platforms. Operating systems, graphics APIs and hardware are synchronous. Codename One calls them directly. Flutter goes through a message channel and its own engine to reach them.

Android makes it obvious. The native platform on Android is Java. Codename One compiles to it and talks to Android the way Android expects. Flutter avoids it, shipping its own VM and engine beside the one the phone already has. That's why Android shows the biggest gap: a third of the start-up time and a quarter of the code.

Two differences you feel every day

The threading model shows up in the benchmarks. These two don't, but you notice them every day you work.

Builders

A Codename One app is a Java project. The build of a native app happens in a builder: our cloud build servers or a local build, which take your compiled code and produce the iOS, Android or desktop binary. That moves the hard part of the developer experience into our hands:

Build iOS apps from Windows or Linux. The cloud builder holds the Mac, Xcode and the signing steps. You don't need to own a Mac to ship to the App Store.
Cheap CI. Your unit and UI tests run in Java, in the simulator, on any CI runner. No emulator to boot and no macOS runner to pay for on every commit.
New features without migration work. When Apple or Google change a requirement, or we add a capability, we update the builder. Your project picks it up on the next build, with nothing to upgrade or reconfigure.

Everything in one place

Codename One used to aim for a modular core, with features broken out into cn1libs. Flutter is going through that phase now, moving pieces such as its Material and Cupertino themes out of the framework into independent packages. We went the opposite way. The Codename One core now covers what Flutter does, plus most of what people reach for in Flutter's most popular packages, and this week's posts add more.

A bigger core costs you nothing, because you don't pay for what you don't use, and that works on two levels. ParparVM drops every class your app doesn't reach. The builder goes further: it looks at what your compiled code calls and adds a native library only when a feature needs it. This week's crypto support is a good example. Its native kernels for secp256k1, Ed25519 and the hashes are what make it fast, and an app that never touches the crypto API shouldn't carry them. It doesn't. Call a wallet or a signature API and the builder links them in, and you get native speed that our CI measures against the reference libraries, libsecp256k1 and OpenSSL among them. That's how the builds above stay smaller than Flutter's. What you get instead:

One version. No matrix of package versions to keep compatible, and no upgrade that breaks because two packages disagree.
Nothing abandoned. No package your app depends on that its author stopped maintaining two years ago.
A short supply chain. This is the big one. Every package in a dependency tree is a person you trust with your users' devices. A maintainer who burns out, sells the package, gets angry or gets hacked can push code into your app on the next update, and attacks on open source packages have done exactly that. With the features in core, your app's dependencies are one project with one review process, not a tree of packages from strangers. That fits the rest of this week: the Bastion template is a hardened bank because security is something we take seriously, and banks and other regulated organizations build on Codename One. For them, a short supply chain is a requirement.
Everything moves together. When we fix rendering, add a platform or change the build, every feature comes along, including the niche ones.
One source of truth. The developer guide documents all of it, and when something breaks there is one team responsible for the answer.

We can finally show the code

For years, every Codename One against Flutter discussion went the same way. I'd explain why ahead of time compiled Java with a lightweight UI should produce a smaller, faster app. Someone would explain why it shouldn't. Neither of us had the same app built both ways, so it came down to which camp you were already in.

Now there's one app, built both ways, measured on every commit. If you think a number is wrong, the harness is in the repository and you can rerun it.

The part I didn't expect is how much this made Codename One better. Each compatibility layer exposed problems we had missed for years:

Styles were parsed over and over. Every component re-parsed its pressed and disabled styles from the theme. Caching them took component creation in the Gallery from 131 ms to 17 ms and resident memory from 247 MB to 144 MB.
Every string constant was created at startup. ParparVM materialized every string literal before main() ran. Making the pool lazy cut that step from 119 ms to 46 ms.
Rounded images were copied. Rounding an image's corners built a second bitmap, 32 times during the first frame. Doing it in the fragment shader removed the copies and stopped memory from swinging between runs.
Images decoded inside the first frame. Deferring that decode took the first frame from 302 ms to 213 ms.
An idle app burned CPU. The Compose work found, and we fixed, a bug where on phones with a notch, safe area padding kept queuing layout so an idle app sat at 14% to 26% CPU.

None of these fixes are specific to Flutter. If you write Codename One apps in plain Java and never touch a Dart file, your app gets these fixes too: faster start-up, lower memory and an idle CPU that stays idle.

More This Week

Your Compose code, on more screens

Kotlin Multiplatform is a good platform, and Compose Multiplatform is well built. Codename One now runs the same Compose code on more targets, used about a quarter of the CPU per frame on our benchmark screen, and lets you drop to Java where it counts.

The same Compose screen: Compose Multiplatform on the left, Codename One on the right.

class MyApp : Lifecycle() {
    override fun runApp() {
        ComposeForm { LayoutScreen() }.show()
    }
}

Saturday's Compose article has the numbers and their caveats.

Swing and JavaFX on phones

A large share of real Swing and JavaFX code now builds for iOS, Android and the web: the samples we test include SwingSet2 and Notepad, the JDK's own demos. On Linux the native build is 4 to 6 times smaller zipped than the same app on the JVM, and starts faster in all 8 apps, even against a JVM tuned with AppCDS.

SwingSet2, the JDK demo, on an iPad.
The JavaFX 2048 game on a phone.

Swing controls.
JTable.
JavaFX.
FXML and CSS.

Sunday's Swing and JavaFX article goes through what carries over and why you won't miss what doesn't.

A bank you can study, and wallets in core

A large share of our users are banks and financial institutions. Bastion is a reference implementation for them: a virtual bank and small exchange with passkeys, TOTP, signed requests, device keys, a hash chained audit log, a double entry ledger and an auditor console. Codename One also gained wallet APIs for Ethereum, Bitcoin, and Solana.

Four currencies.
The BTC/USD market.
The Security Center.

Wallet wallet = Wallet.fromMnemonic(words, "");
EvmAddress eth = wallet.getEvmAddress(0, 0);
BitcoinAddress btc = wallet.getBitcoinAddress(BitcoinNetwork.MAINNET, Wallet.BIP84, 0, 0, 0);
SolanaAddress sol = wallet.getSolanaAddress(0);

Monday's Bastion article covers the hardening, one layer at a time.

Streaming and courses

Reel is a streaming service and its server in one Java project. Switch a preset and it becomes a subscription service, a creator platform in the style of YouTube, or an academy with courses, lessons, and quizzes.

The catalog.
The player.
A course.

StreamRequest req = new StreamRequest(manifestUrl)
        .setDrm(new DrmConfig(DrmScheme.WIDEVINE, licenseUrl));

Tuesday's Reel article walks through uploads, moderation, and DRM.

Android code everywhere, including GrapheneOS

The Android compatibility layer now covers Room, WorkManager, location, sensors, foreground services and the document picker intents, all running on iOS too. And GrapheneOS, LineageOS, CalyxOS and /e/OS are now officially supported, with a boundary CI verifies: one APK checks for Play Services at run time, and push works through UnifiedPush.

Material 3, Android left, Codename One right.
RecyclerView, same source.

Wednesday's Android article has the details.

A modern backend, and a simulator that types

The simulated keyboard sliding up over a sign up form.

Thursday closes the week with eight backend upgrades (a bounded cache, outbound OAuth tokens, PKI, JSON codecs, streaming uploads, error advice, java.time in the ORM and test slices) and a simulator that slides up a virtual keyboard and records video. See the backend and simulator article.

The universal platform

Last week I made the case that a Java word processor beats its Rust twin. This week the swing is bigger. Flutter, Compose, Swing, JavaFX and Android code all build into the same kind of app and run on iOS, Android, desktop, the web and the watch.

Instead of coding to an operating system, you code to Codename One, and Codename One becomes the operating system. The usual price for that kind of abstraction is performance. We don't charge it. You get more performance, more features, more compatibility and more platforms, and it's free and open source.

If you have a Flutter app, run the import on a copy and build it for the simulator. Tell us which screen breaks first; that's the most useful bug report we can get right now. If you're on Kotlin, Swing, JavaFX or Android, the rest of this week is for you. And if you think a number above is wrong, the benchmark is in the repository. Rerun it and open an issue.

WebRTC Calls, Key Agreement and ORM Checks at Build Time

Shai Almog — Thu, 05 Nov 2026 21:17:48 +0000

The last post this week covers what Parley, Savor and Wayline needed underneath: calls, encryption and a backend you can trust with real data. These are features you'd usually assemble from three vendors and a few weekends of glue code.

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.

Voice and video calls with WebRTC

com.codename1.webrtc carries live audio and video directly between two devices, encrypted on the way, with a TURN relay when there's no direct path. On Android it's Google's WebRTC library, on iOS the Apple build of the same library, and in the browser it's the browser's own WebRTC. Referencing the package is what adds the native library to a build, so apps that don't make calls don't pay for it.

WebRtc.openUserMedia(true, true, true).ready(media -> {
    PeerConnectionConfig config = new PeerConnectionConfig()
            .addIceServer(IceServer.stun("stun:stun.example.com:3478"));
    pc = WebRtc.createPeerConnection(config, new PeerConnection.Listener() {
        public void iceCandidate(PeerConnection connection, IceCandidate candidate) {
            signalling.send(candidate);
        }

        public void stateChanged(PeerConnection connection, String state) {
        }

        public void remoteTrack(PeerConnection connection, MediaTrack track) {
            if (track.isVideo()) {
                form.add(BorderLayout.CENTER, new VideoView(track, false));
                form.revalidate();
            }
        }
    });
    pc.addTrack(media.getAudio());
    pc.addTrack(media.getVideo());
    pc.createOffer().ready(offer -> pc.setLocalDescription(offer)
            .ready(done -> signalling.send(offer)));
});

Signaling is yours on purpose. The package creates the offer, the answer and the candidates, and you send them over whatever you already have: a WebSocket, your server, a push. So the same call code works with a Codename One backend or with anything else. Parley sends them over its live channel, and the media never touches its server.

Key agreement and HKDF everywhere

End-to-end encryption needs two parties that have never met to agree on a key over a channel anyone can read. Codename One now does that on every port and on the backend. KeyGenerator.ec(256) makes a P-256 key pair, KeyAgreement.ecdh combines your private key with the other side's public key, and Hkdf turns the shared secret into a proper key:

byte[] shared = KeyAgreement.ecdh(mine.getPrivateKey(), theirs.getPublicKey());

// The shared secret is not a key yet. HKDF turns it into one, and the info
// label keeps keys derived for different purposes apart.
byte[] info = "chat message key v1".getBytes();
byte[] key = Hkdf.derive("SHA-256", null, shared, info, 32);

byte[] nonce = SecureRandom.bytes(12);
byte[] sealed = Cipher.aesEncrypt(Cipher.AES_GCM, new SecretKey("AES", key),
        nonce, null, message);

The key agreement runs in the platform's native crypto provider. Hkdf is portable Java over Hmac, so it gives the same bytes on every device and on your server. These are the building blocks of Parley's X3DH and Double Ratchet, and they're just as useful for encrypted backups, secure pairing or signing data between your app and your server.

A backend client for serious integrations

Real backends call other services: a payment processor, a bank, a partner API. Many of those authenticate callers with a client certificate. The backend's WebClient handles that, along with HTTP/2, timeouts and connection pooling:

this.partner = new WebClient()
        .setClientCertificate(ClientCertificate.pkcs12(archive, password))
        .setRequireHttp2(true)
        .setRequestTimeoutMillis(10000);

Server certificates and host names are always verified, and there is no option to turn that off. Two clients never share a connection, so a connection authenticated with one certificate is never used for a request made with another.

ORM mistakes fail the build

This is my favorite one. With Hibernate and Spring, plenty of mapping mistakes compile fine and only blow up when the application starts, or worse, on the first request that touches the broken entity. You find out in staging if you're lucky.

Codename One's ORM reads your entities when you compile, so those mistakes are build errors that name the class and the field:

@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
@Version requires an int or long field: revision

Repositories get the same treatment: an unsupported method signature, a derived query that names a field the entity doesn't have, or a missing parameter name stops the build and names the repository and the method.

The same release makes it easier to put the ORM on a database you already have. Columns keep their names, native TIMESTAMP and DATE columns map to java.util.Date with @Temporal, and lifecycle callbacks can stay private:

@Entity(table = "legacy_customer")
public class LegacyCustomer {
    @Id @Column(name = "customer_no")
    private long id;

    @Column(name = "full_name", nullable = false)
    private String name;

    @Temporal(TemporalType.TIMESTAMP) @Column(name = "signed_up")
    private Date signedUp;

    @PrePersist
    private void defaults() {
        if (signedUp == null) {
            signedUp = new Date();
        }
    }
}

Before you deploy, session.schemaReport() compares the mappings with the real tables and tells you what's missing, without changing anything in the database.

That's the week

Three new apps you can launch, a word processor that holds up against Rust, and a stack of features that make the next app easier. Everything is in the repository, and the guides for WebRTC, security, backend web and the ORM have the details. If you build something with these, I want to see it.

Native Menus, File Dialogs and 3D Models

Shai Almog — Wed, 04 Nov 2026 20:25:15 +0000

A desktop app gets judged in the first ten seconds. If the menu bar is wrong, Cmd+Q does nothing or the Save dialog looks like it came from a different decade, people notice, even if they can't say what bothers them. The word processor from last Friday's post needed all of that to hold up next to a native app, so those pieces are now part of Codename One. They work with the code you already write for a phone.

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 real open and save dialogs

openFileChooser() picks one file. Desktop apps need more: several filters, a suggested name, extra options in the dialog and a preview while the user browses. showOpenDialog() and showSaveDialog() cover that:

Display.getInstance().showOpenDialog(new OpenFileRequest()
        .title("Import photos")
        .multiSelect(true)
        .addFilter(new FileTypeFilter("Images")
                .extensions("png", "jpg").mimeTypes("image/*"))
        .addOption(FileDialogOption.checkbox("strip", "Remove location data", true))
        .preview(path -> {
            try (InputStream in = FileSystemStorage.getInstance().openInputStream(path)) {
                return new ScaleImageLabel(Image.createImage(in));
            } catch (IOException err) {
                return new Label("No preview");
            }
        }),
    result -> {
        if (result.isCancelled()) {
            return;
        }
        boolean strip = "true".equals(result.getOptionValue("strip"));
        for (String path : result.getPaths()) {
            // import each file
        }
    });

The request above in the simulator, with the preview and the option.

Every platform opens and saves files. The extras appear where the platform has them, and the rest ignore them, so one request works everywhere:

Platform	Open	Save
macOS	`NSOpenPanel`	`NSSavePanel`, with format list, options and tag field
Windows	`IFileOpenDialog`	`IFileSaveDialog`, with options as dialog controls
Linux	`GtkFileChooser`	`GtkFileChooser` with overwrite confirmation
Android	The system document picker, several files, folders	Create document, with no storage permission
iOS	The document picker, several files, folders	Exported through the document picker
Browser	The browser's file picker	A download with the suggested name

A save request writes its content after the user has picked the location, off the EDT, and it can see which format and options were chosen. Platform hints, such as the macOS tag field or the folder Android starts in, are one call each.

A menu bar that follows each platform

A Command already knows its name, icon, and action. Tell it where it goes and it shows up in the native menu bar on macOS, Windows, Linux and in the browser build. Paths make submenus, and check and radio items work the way you'd expect:

String[] zooms = {"50%", "100%", "200%"};
for (String zoom : zooms) {
    Command c = Command.create(zoom, null, e -> setZoom(zoom));
    c.setDesktopMenu("View/Zoom").setDesktopMenuGroup(1).setDesktopRadioGroup("zoom");
    c.setDesktopChecked("100%".equals(zoom));
    form.getToolbar().addCommandToOverflowMenu(c);
}

On a phone the same commands stay in the overflow menu, so there's nothing to branch on.

The word processor's File menu on macOS.

About, Settings and Quit live in different places on every desktop, under different names. Give the command a role and each platform puts it where its own apps do, with its own shortcut:

Command settings = Command.createDesktopRole(Command.DESKTOP_ROLE_SETTINGS, e -> showSettings());
Command quit = Command.createDesktopRole(Command.DESKTOP_ROLE_QUIT, e -> quit());

Role	macOS	Windows	Linux
About	Application menu, first	Help, last	Help, last
Settings	"Settings…" in the application menu, Cmd+,	"Options" under Tools	"Preferences" at the foot of Edit
Quit	"Quit" in the application menu, Cmd+Q	"Exit" at the foot of File	"Quit" at the foot of File, Ctrl+Q

The File and Edit roles work the same way, so Redo is Cmd+Shift+Z on a Mac and Ctrl+Y on Windows without you looking it up. On macOS a role replaces the built-in item, so the menu never shows two Quit items.

Roles landing in the macOS application menu.

One more small thing that makes an editor feel right: form.setDocumentModified(true) puts the dot in the close button on macOS and an asterisk before the title on Windows and Linux, and the Save command enables itself while there's something to save.

Animated 3D models

The other big addition came from Skirmish. GltfLoader loads glTF 2.0 models, binary .glb or JSON .gltf, together with their textures, so a textured model renders with no extra setup. AnimatedModel brings them to life:

GltfScene knight = GltfLoader.loadScene(in);
AnimatedModel unit = new AnimatedModel(device, knight);
unit.play("Walking_A", true);
unit.addTo(gameView);
// later
unit.crossFade("1H_Melee_Attack_Chop", 0.15f, false);

It plays the model's animation clips, cross-fades between them, deforms skinned meshes with their skeleton and carries rigid parts, like a sword in a hand, along with their bones. Skinning runs on the CPU, so it looks identical on every port and needs nothing from the shaders. Many instances can share one loaded scene: the vertex data, clips and textures are shared, and only the posed vertices are per instance. That's how a Skirmish battle fills the arena with troops.

A textured glTF model.
Animated characters in Skirmish.

The desktop integration guide, the file system chapter and the 3D graphics chapter have the details.

Tomorrow, the last post of the week: WebRTC Calls, Key Agreement and ORM Checks at Build Time.

More of the Java API, and an Experiment With Unity Games

Shai Almog — Tue, 03 Nov 2026 20:24:05 +0000

This post is about code you already have: Java code you want to reuse, and, as an experiment, Unity games.

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.

Much more of the Java class library

Codename One always shipped a subset of the Java API. That kept apps small, but it also meant that a library from Maven Central or a utility class from your server often needed edits before it compiled. That gap is now much smaller. 116 classes and interfaces joined the class library:

Package	What arrived
`java.util.function`	The functional interfaces: `Function`, `BiFunction`, `Supplier`, `Predicate` and the primitive variants
`java.util.stream`	The core of the streams API
`java.util`	`Optional`, `StringJoiner`, `UUID`, `Base64`, `HexFormat`, `Spliterator` and more
`java.util.concurrent`	`Executors`, `Future`, `Callable` and friends
`java.time`	`LocalDate`, `LocalDateTime`, `Instant`, `Duration`, `ZonedDateTime` and the rest of the basics
`java.text`	`SimpleDateFormat`, `DecimalFormat`, `MessageFormat`, `NumberFormat`
`java.io`	`BufferedReader`, `BufferedWriter`, `PrintWriter`, `InputStreamReader` and other readers and writers

String's regular expression methods now go through one engine on every platform, so split, matches and replaceAll behave the same on iOS, Android and the browser.

The obvious worry is size. I measured it, and the overhead is minor. ParparVM and the obfuscator strip whatever your app doesn't call, so an app that never touches streams doesn't carry them.

What hasn't changed: there's still no reflection and no class loading. That's a deliberate choice, and it's a big part of why Codename One apps are small, start fast and can be translated ahead of time. I talked about this, and about why Java is a better fit for this world than people assume, in my interview with Frank.

Running Unity 2D games: would this be useful?

This one is an experiment, and I'd like your opinion on it.

We wanted to learn what Unity does right for game developers and what parts of that we can offer. The best way to learn was to try running Unity games. So we built it: a Unity 2D project, with its C# scripts, scenes, prefabs, sprites and settings, copied into a Codename One project. The build compiles the C#, translates it to Java bytecode and runs it on every Codename One target, including iOS, Android, the browser and the desktop.

Fruitopia, a tile map platformer.
Asteroids.
Snake.
Sokoban.

Five open source games run with no change to their scripts or assets. No Unity player and no .NET runtime ship with the app. Scripts become ordinary classes, scenes become generated code, and a runtime that implements the UnityEngine API draws the game into a Codename One component. The .NET SDK is only needed on the machine that builds, and no Unity install or license is needed at all.

That component is the interesting part. The game sits on a Codename One form, so everything around it is regular Codename One: a toolbar, a side menu, a store, sign-in, in-app purchases, push, and ads. Java and the game's scripts call each other:

@Override
protected Form createForm(UnityGameView gameView) {
    Form form = new Form(new BorderLayout());
    Toolbar toolbar = new Toolbar();
    form.setToolbar(toolbar);
    form.setTitle("My Game");
    toolbar.addMaterialCommandToRightBar("", FontImage.MATERIAL_LEADERBOARD,
            e -> callInFrame(() -> services.ShowLeaderboard(score().get_Best())));
    form.add(BorderLayout.CENTER, gameView);
    return form;
}

The scope is 2D: sprites, tile maps, 2D physics, animation controllers, particles, the canvas interface and scripts. You can't take any Unity game and run it. Working on this improved the Codename One gaming API too, and those improvements are what Skirmish's arena uses.

So, would this be useful to you? A way to bring a small Unity game into an app that also needs real app features, or to keep a game going on targets you don't want to pay for? Tell me in the comments below. Your answer decides how far we take it. The Unity guide has the details.

A faster XML parser

XMLParser got a round of fixes and a lot faster. The fast path needs one call, because strict parsing follows the XML rules exactly where the classic parser was forgiving of HTML-like input:

XMLParser parser = new XMLParser();
parser.setStrict(true);
parser.setStripNamespacePrefixes(true); // w:p is reported as p
Element root = parser.parse(reader);

On the desktop JIT a benchmark document went from 13.8 ms to 8.3 ms. Interpreted, where it matters most on older devices, it went from 751 ms to 488 ms, and to 358 ms in strict mode. Mappers.fromXml uses it, so XML mapped to objects gets the same speedup.

Run the samples right in the docs

Every sample in the API docs now has a button that runs it, labeled Try It. Press it and the code compiles and runs in your browser, with the in-tree Java compiler and the ParparVM JavaScript translator. After the first load, a snippet takes about a second. Change the code and run it again.

Try It on the Button docs page.

Tomorrow: Native Menus, File Dialogs and 3D Models.