DEV Community: Shai Almog

Native Linux, Apple Watch, A Game Builder And Crash Protection

Shai Almog — Fri, 26 Jun 2026 13:40:18 +0000

This week brings a native Linux desktop port, an Apple Watch and Wear OS port, a visual Game Builder with a high-level gaming API, and a new crash-protection system, with a tutorial following each one over the coming days. There is also a large piece of work that you mostly should not have noticed: we rebuilt the build cloud, and that rebuild caused a few failed builds along the way. More on that below.

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.

A native Linux desktop port

PR #5239 adds a native Linux port, the structural twin of the native Windows port we shipped last week. The same ParparVM pipeline that turns your Java/Kotlin bytecode into C, here targeting Linux through GTK3, Cairo, Pango and GdkPixbuf for rendering, OpenGL ES for 3D, GStreamer for media and camera, and WebKitGTK for the browser component. There is no JVM on the target machine: it is a single self-contained ELF you launch like any other program.

We expected this to be painful, and parts of it were, but Linux turned out to be mostly developer friendly. A non-trivial app fits in 5MB, and on my Linux machine it started faster than most of the GNOME native apps already installed; thanks to the default material design theme it tends to look better too:

Most things just work, including the camera and 3D. The hard part of Linux is not the rendering, it is packaging and dependencies. We deliberately stayed out of the package-manager rabbit hole and ship one native binary you launch directly, the same model as Windows. The other classic Linux problem is glibc; if that sentence means nothing to you, consider yourself fortunate. We solved it by compiling against a very old glibc (around GLIBC_2.17, from 2013) and linking GTK3 dynamically, both of which are present on essentially every desktop. We also support musl for Alpine, and both x64 and arm64. Like the other ports, this is not a local-only path: the Linux target builds on the build cloud, and new projects from the Initializr come wired for it. The architecture and the build are covered in .

Codename One on your wrist: Apple Watch and Wear OS

PR #5252 adds a proper native Apple Watch (watchOS) port, alongside Wear OS support on the Android side. Apple treats watch programming as a completely separate discipline from phone or desktop programming: a different API, a different lifecycle, and UI metaphors we take for granted that simply do not exist on the watch (no text field as you know it, and no browser). That is a defensible design, and it raises a fair question: what is the point of a watch API at all?

The answer is that reuse still happens. Many well known apps skip the watch entirely because it is such a chore, yet the amount of work a watch UI actually needs is small, and smaller still with Codename One. watchOS has no UIKit views, no OpenGL ES and no Metal, so the port ships a dedicated Core Graphics rendering backend and hosts the Codename One runtime inside a SwiftUI shell. The same Java code, branched with CN.isWatch(), renders real Codename One UI on the watch:

That is a screenshot from our test framework, which was never designed for a watch: it still has a text field. Because that is a Codename One text field it renders correctly and "just works" right up until you try to edit in it, which on a watch would not give the result you want; a real watch UI would simply leave it out.

Wear OS is simpler: a Wear OS app is an ordinary Android app, so the existing Android port renders it with the same pipeline it uses on phones. You enable each side with one build hint, and with the hints off your phone build is byte-for-byte unchanged. Both wearables are covered in detail in .

A visual Game Builder

PR #5253 adds a visual game level editor on top of the com.codename1.gaming API from last week, plus a high-level data model and a streaming engine for large worlds. Instead of hand-placing every sprite in code, you draw the level, tag objects with the numbers your game needs (lives, value, speed), and the editor saves a small data file the runtime plays. Your code shrinks to the part that is actually yours: the rules.

This is the special case in this week's release. Tuesday's post is a full overview of the editor, the data model, and the streaming engine for large worlds, and then a three-part tutorial series starts Thursday rather than a single follow-up. The first tutorial builds a playable 2D platformer, "Duke's Coffee Run", from an empty scene to a running game, including the part most tutorials skip: bringing in real art and slicing an animated sprite sheet for Duke.

Two more parts follow on the next Thursdays: a blackjack card game, then a first-person 3D dungeon that scales up to large streaming worlds. The full picture of what the builder is and how it fits together is in . One important caveat: the Game Builder and its high-level APIs are beta. We are actively improving them and we want your feedback on the editor, the API shape, and the asset workflow. Tell us what works and what gets in your way through the issue tracker.

Seamless crash protection

PR #5001 replaces the old email-based crash protection tool with a new on-device client, com.codename1.crash, that we think leapfrogs the dedicated tools in this space. As we add more platforms, testing across all of them becomes a bigger challenge; this is the tool for dealing with that, and it is built to be seamless.

It is seamless in three senses. You do not wire up anything complex: the build servers do the heavy lifting. It connects to GitHub issues instead of sending a barrage of emails. And it symbolicates native crashes on every operating system we support, so a faulting address on iOS, Android, Windows or Linux comes back as a readable stack. On the device, reports are written to storage before they are sent and only deleted after the server confirms receipt, so nothing is lost to a flaky connection; a failed send is retried on the next launch and the server deduplicates it.

Personal data is scrubbed on the device before anything leaves it: emails are partially redacted and long digit runs are collapsed, with rules you can override. It is opt-in and off by default; turning it on is two lines, and the full walkthrough is in .

CrashProtection.install();
CrashProtection.setEnabled(true);

Behind the scenes: a rebuilt build cloud

Codename One was founded in 2012, back when Docker was a brand-new alpha product that few people had heard of, and a lot of the infrastructure underneath the build cloud dates back to that era. This week we did a major rebuild and re-architecture of it. The transition caused a few failed builds, and if one of yours was among them, we are sorry for the disruption.

The end result is completely new infrastructure that is far easier to update going forward, with better isolation and security. We are nearly finished with the Mac side (that work continues over this weekend), and every other platform is done except for UWP and the Windows desktop builds. If a build behaves differently from how it did before, please tell us right away, ideally through the chat on our website, so we can act quickly.

Initializr now runs on the JavaScript port

We quietly switched the Codename One Initializr over to the new JavaScript port, and we hope you did not notice the difference. That is the goal: the JavaScript port should feel like every other port.

It is also one of the hardest ports we have ever worked on. Every percentage point of compatibility and every bit of performance is a genuine fight. The work is ongoing, and the aim is to get the JavaScript port aligned with the rest and launch it in the near future.

From the community

Francesco Galgani published another thoughtful piece, Java was supposed to free us from the operating system; today Codename One is getting there. It is worth your time, and we are grateful for the writing and the perspective.

A note on cadence: community activity is slowing down as everyone heads into the summer holidays, and we are not sure how quickly progress will continue through these months. We are still very much here, and we are looking for feedback on all of the above, so this is a good time to send it.

Upcoming attractions

The tutorials follow this post; each link below goes live on its day:

Saturday. . PR #5239.
Sunday. . PR #5252.
Monday. . PR #5001.
Tuesday. . PR #5253.
Thursday. . The first of three parts. PR #5253.

Wrapping up

The issue tracker is here and it is the best place to reach us right now. The discussion forum is here, and the Build Cloud console is at /console/. The Playground, Initializr, and Skin Designer are where they have always been.

Print Anywhere, And Put Your Cards In Apple Wallet

Shai Almog — Tue, 23 Jun 2026 13:51:48 +0000

The last two items in this week's release are platform integrations that business apps ask for constantly: printing a document, and getting a payment card into Apple Wallet. Both are the kind of feature where the cross-platform story usually ends and a pile of per-platform native code begins. Both are now core APIs.

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.

Printing: one call, five platforms

PR #5217 adds com.codename1.printing, a deliberately small API: hand a document to the platform's printing system, typically through the native print dialog, and hear back once about how it went.

if (Printer.isPrintingSupported()) {
    Printer.printPDF(reportPath, result -> {
        if (result.isFailed()) {
            ToastBar.showErrorMessage("Print failed: " + result.getError());
        }
    });
}

Printer.printPDF(path, listener) and Printer.print(path, mimeType, listener) print a file from FileSystemStorage; Printer.printImage(image, listener) takes any Codename One Image and handles the encoding for you. The listener is invoked exactly once, on the EDT, with a PrintResult that is completed, cancelled, or failed.

What backs the API on each platform:

Port	Mechanism
iOS	`UIPrintInteractionController`, presented properly on iPad
Android	`PrintManager` print framework: PDFs stream through a print adapter, images go through the platform print helper
Simulator / desktop	The Java printing pipeline with the native dialog, with real cancel detection
Web	The browser's print flow via a hidden frame
Windows native	The Win32 print dialog, with PDFs rendered at printer resolution through the Windows PDF engine

That last row is worth a beat: the printing API shipped in the same week as the native Windows port and already covers it, dialog, spooling, PDF rasterization and all.

One caveat the JavaDoc spells out per method: "completed" means the document was handed to the printing system. Some platforms don't expose what happened inside the native dialog afterward, so completion there is reported best-effort. Design your UX around handing off, not around confirming pages hit paper.

There is a PrinterSample in the repository that prints a generated image and a downloaded PDF if you want a starting point.

Apple Wallet: provision cards from inside the Wallet app

PR #5227 is for card issuers: banks and fintechs whose users want to add their cards to Apple Wallet. Apple supports this from inside the Wallet app itself (the "From apps on your iPhone" section), but it requires shipping an issuer-provisioning app extension, a separate binary with a strict contract. That has historically meant Xcode, Objective-C, and a long appendix of plist incantations.

Now it means build hints:

ios.wallet.extension=true
ios.wallet.appGroup=group.com.mybank.app
ios.wallet.issuerEndpoint=https://api.mybank.com/wallet/provision

With those set, the iOS build generates Apple's extension pair as fixed, framework-maintained Objective-C. Add ios.wallet.includeUI=true and ios.wallet.authEndpoint=... and you also get the optional in-Wallet login screen.

How it works under the hood

Wallet extensions run in a separate process under a 100-millisecond response deadline, so they cannot spin up your Java code. The design splits the work: your app publishes its card data ahead of time through the new com.codename1.payment.WalletExtension API, and the extension reads it from the shared App Group when Wallet asks.

if (WalletExtension.isSupported()) {
    WalletExtension.setPassEntries(new WalletPassEntry[] {
        new WalletPassEntry()
            .identifier("card-1234")
            .title("Platinum Card")
            .cardholderName("Jane Doe")
            .primaryAccountSuffix("1234")
            .paymentNetwork("visa")
            .artPng(cardArt)
    });
    WalletExtension.setRequiresAuthentication(true);
    WalletExtension.setAuthToken(token);
}

The one step that genuinely needs your backend, producing the encrypted pass payload from Apple's certificates and nonce, is a JSON POST to the issuer endpoint you host. And for teams with special requirements, ten injection hints let you insert custom Objective-C at marked points in every extension callback without forking the generated code.

On the token in that snippet: treat it like any credential. Fetch it from your backend at runtime, hand it to WalletExtension for the extension to use, and never hard-code it or check it into source. Anything baked into a shipped binary is effectively public.

Bring your own extension

Some issuers receive a prebuilt extension from an SDK vendor. The generic iOS app-extension mechanism (ios/app_extensions/<Name>/ in your project) covers that path, and this release improves it: it now works without CocoaPods, and each extension can carry its own provisioning profile, either as a file in its folder or through a per-extension hint. A bug that could duplicate extension targets in the generated Xcode project when build phases re-ran is also fixed.

Before you start

Apple gates issuer provisioning behind the restricted payment-pass-provisioning entitlement, which your developer account must be granted; the new "Apple Wallet Extension" chapter in the developer guide walks through the prerequisites, the endpoint contracts, and both integration modes.

That wraps the week. Yesterday's post covered the native Windows port, and the release post has the full index: the portable 3D API, the game development API, native Windows, and these two. As always, the issue tracker is the best place to reach us.

Java To A Native Windows EXE: No JVM, 5MB, x64 And Arm

Shai Almog — Mon, 22 Jun 2026 14:53:40 +0000

If you were around Java forums in the late nineties you remember the threads. "How do I compile my Java program to an EXE?" was asked constantly, answered badly, and locked periodically. The real answer for most of three decades was: you don't, you ship a JVM. Wrapper tools bundled a runtime next to your jar; the result was a directory pretending to be a program.

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.

This week, PR #5144 and PR #5209 deliver the answer that the forum threads wanted all along: your Codename One app now compiles to a standalone native Windows executable with no JVM anywhere. Not bundled, not embedded, not downloaded on first run. The same ParparVM pipeline that has compiled our iOS apps to native code for over a decade now translates your Java/Kotlin bytecode to C, compiles it with clang-cl, and links a single Win32 .exe.

To be explicit about what that executable contains, because "Java desktop app" carries decades of associations: there is no Swing in it, no AWT, no JavaFX, and no runtime to install. It is the full Codename One framework compiled to machine code, and everything in the framework works there, including the new printing API, the 3D layer, media, networking, storage, and the browser component.

A hello world is around 4MB. The complete Initializr application, the real app from our own site, is around 8MB, and here it is running as a native Windows executable:

Edit: Since publishing this post we found the binaries were carrying their debug and stack-unwind tables inline. We now split that data into a separate symbol file (kept only to symbolize crashes) and dead-strip code the app never reaches, which brings the sizes down further -- the figures above reflect the leaner build.

One build produces both x64 and arm64 executables, so the new wave of Arm-based Windows laptops is a first-class target, not an afterthought under emulation.

This also completes a story we started two weeks ago. The Mac native target brought the same no-JVM compilation to macOS through the iOS pipeline; with Windows joining it, the same Java code base now produces real native binaries for both major desktops, plus iOS, Android, and the web. Write once, run anywhere was Java's original promise for the desktop, and it took compiling the JVM out of the picture to actually deliver it.

How this differs from GraalVM

GraalVM native-image is a remarkable piece of engineering and the comparison is worth making precisely, because it is not "GraalVM ships a JVM". It doesn't, and it doesn't support reflection everywhere either; it compiles ahead of time against a closed world, much like we do. The difference is scope: GraalVM aims to support as much of the Java language and platform semantics as possible, for any Java workload, with server-side frameworks as the marquee use case. That ambition is what makes it far more complex, and it is why its binaries, while impressive for what they carry, are heavy by app-distribution standards. It is a tool designed for a different purpose, and it is very good at that purpose.

Our goal is narrower and that is the point. ParparVM compiles your application against a compact runtime designed for shipping apps to end users: no JIT, no class loader machinery at runtime, a concurrent GC, and only the code your app actually reaches. The output is a lean executable that looks and behaves like a program written natively for the machine, because at that point it is one. It is the same trade-off our iOS port has been making since 2012, battle-tested by every app we have ever shipped through it.

A real rendering stack, not a port of a port

The Windows port renders through the platform's own stack:

Direct2D for graphics, with the full Codename One drawing pipeline on top
DirectWrite for text shaping and fonts
Direct3D 11 for the new portable 3D API, with HLSL generated and compiled at runtime
WIC for image decoding, WinHTTP for networking, Win32 for storage and the clipboard
WebView2 backing BrowserComponent

This is the ChatView sample rendering through Direct2D and DirectWrite, from the same Java code that produces the iOS and Android versions:

And the 3D API on Direct3D 11:

The desktop details that make an app feel native are in place too. Mouse-wheel scrolling maps onto Codename One's own tensile scrolling physics through a new shared core API (the JavaSE simulator was refactored onto the same code path, so every desktop port scrolls identically). execute(url) opens the default browser through the real shell launch services, and dial() and the messaging APIs hand off to whatever the user has registered for tel:, sms:, and mailto: links (Phone Link, for instance); when no handler is registered they report failure instead of pretending. The file picker is the actual Windows file dialog, and printing (covered in ) goes through the native print dialog.

How complete is it?

The port is new, and it should be treated as such; we expect to be shooting down teething issues over the coming weeks, and we want to hear about every one of them. With that said, it covers far more ground than "new port" usually implies. The same screenshot test suite that gates iOS, Android, the web, and the Mac target runs against the Windows port in CI on every change, on both x64 and arm64 runners, with more than 120 screenshot baselines covering components, themes, transitions, graphics, charts, and the 3D API. Almost anything that is viable for a desktop app is expected to work.

Where a capability genuinely doesn't exist on a desktop machine, the port follows a strict rule: phone-hardware APIs (camera-as-sensor flows, GPS-grade location, contacts, push, biometrics) report themselves as unsupported rather than fabricating data. Existing cross-platform feature-detection code keeps working.

Building one

The cloud target is windows-device:

mvn -pl common package -Dcodename1.platform=windows \
    -Dcodename1.buildTarget=windows-device

A regular build returns x64 and arm64 release executables; set the windows.debug build hint for a single x64 debug build. The build runs on our Linux build servers, which cross-compile the Windows PE directly, and if you're on a Windows machine with the toolchain installed, local-windows-device does the same build locally.

There is history here for long-time followers. Codename One has shipped Windows apps before, through UWP and through the JVM-bundled desktop target. This port replaces neither today, but it is the first time the output is what those old forum threads were really asking for: one file, native code, no runtime, double-click and it runs.

Yesterday's post covered the game development API, and the release post has the full index. The week wraps up with printing and Apple Wallet in .

Build Games In Java: Sprites, Box2D Physics And Low-Latency Sound

Shai Almog — Sun, 21 Jun 2026 13:33:41 +0000

A confession before the feature tour: for years I was very much against adding gaming to Codename One. I used to work in the gaming industry (Jane's USAF, among others), so this was never about disinterest or not understanding the domain. The opposite: I knew exactly how much a real gaming stack demands, and I felt that tackling it would dilute our focus on being the best cross-platform app framework. But at the rate we have been building up Codename One lately, it has become a manageable and realistic target.

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.

There is also a bigger reason. Java is the ideal game development platform, as proven by Minecraft. It also has serious problems as a game platform, as likewise proven by Minecraft: a heavyweight runtime between you and the machine, painful distribution, and platforms it simply can't reach. With these APIs, and with native compilation that ships your game as a real iOS app, a real Android app, and now a real Windows executable with no JVM, we can solve most of those core problems while giving indie developers a royalty-free platform for their games. No engine fees, no revenue share, no install-time runtime: Java in, native game out.

So here it is. PR #5166 adds com.codename1.gaming: a game loop, sprites, pollable input, sound effects that fire without latency, and physics, built on the portable 3D API we introduced yesterday and the existing media and animation systems, rather than replacing any of them.

Judging by the reactions in the issue tracker, some of you have been waiting for this one.

The sixty-second tour

You subclass GameView, implement update(double dt), and you have a game. Here is the complete logic of a demo where balls drop, fall under gravity, and bounce off the floor and walls:

static class PhysicsDemoView extends GameView {
    private PhysicsWorld world;
    private final Image ballImage = makeBall(60, 0xffff5a5f);

    PhysicsDemoView() {
        setClearColor(0xff101826);
    }

    private void setupWorld() {
        int w = getWidth(), h = getHeight();
        world = new PhysicsWorld(0, 900); // gravity in pixels/s^2, downward
        world.createBox(w / 2f, h - 10, w, 20, BodyType.STATIC);   // floor
        world.createBox(-10, h / 2f, 20, h * 2f, BodyType.STATIC); // walls
        world.createBox(w + 10, h / 2f, 20, h * 2f, BodyType.STATIC);
    }

    private void dropBall(float x, float y) {
        PhysicsBody body = world.createCircle(x, y, 30, BodyType.DYNAMIC);
        body.setRestitution(0.7f);
        Sprite s = new Sprite(ballImage);
        s.setPosition(x, y);
        body.setLinkedSprite(s);
        getScene().add(s);
    }

    protected void update(double dt) {
        if (getInput().wasPointerPressed()) {
            dropBall(getInput().getPointerX(), getInput().getPointerY());
        }
        world.step((float) dt);
    }
}

Notice what's absent: there is no render code. The Scene draws its sprites, and each sprite tracks the physics body it is linked to. This is the demo running in the simulator:

The view drops into a normal form like any component:

Form f = new Form("Gaming Demo", new BorderLayout());
PhysicsDemoView game = new PhysicsDemoView();
f.add(BorderLayout.CENTER, game);
f.show();
game.start();

The game loop

GameView drives its loop through the existing animation system, so it cooperates with the rest of the UI instead of fighting it. It manages the frame rate while running and restores the global value when it stops, and it releases everything automatically when the view is detached from the form.

For deterministic simulation there is a fixed-timestep mode: set setFixedTimestep(1.0 / 60) and update is called with exactly that delta as often as needed, with getInterpolationAlpha() available for smooth rendering between simulation steps. This is the standard pattern for physics-driven games, and it is one method call here.

Input is pollable, the way game code wants it. getInput() exposes level state (isKeyDown, isPointerDown, getPointerX/Y) and per-frame edges (wasKeyPressed, wasPointerPressed), aware of game actions (fire, directional pad) across platforms. No listeners, no event-versus-frame mismatch: you ask, every frame, and act.

Sprites and scenes

Sprite carries position, anchor, rotation, scale, and alpha, plus an axis-aligned bounding box for simple overlap tests. SpriteSheet slices a packed texture into cached frames, AnimatedSprite plays them back, and Scene holds everything in z-order with a camera, so scrolling a level means moving the camera and not repositioning the world.

It matters where those sprites run. GameView extends the RenderView from the portable 3D API, so sprites are not painted pixel by pixel on the CPU: each one is a textured quad composited by the GPU, through Metal on iOS and Mac, OpenGL ES on Android, WebGL on the web, Direct3D 11 on native Windows, and OpenGL through JOGL in the simulator. A sprite's rotation, scale, and alpha are transformation and blending parameters the GPU applies for free, which is why a scene full of spinning, fading, overlapping sprites holds full frame rate, and why the starfield sample below can animate seventy twinkling stars plus particles without breaking a sweat. Where no GPU backend exists, the same code falls back to the software renderer, so correctness never depends on the hardware.

Because the surface is the 3D surface, the same GameView also scales up to real 3D: a GameCamera in perspective mode, Model instances for meshes, and billboarded sprites that always face the camera. There is no separate "3D mode" to migrate to later; mixing flat sprites and 3D models in one scene is the normal case.

Physics: Box2D in the core

We did not write a physics engine, and that is the point: we took the industry standard. Box2D is Erin Catto's rigid-body engine, the one behind an entire generation of 2D hits, and JBox2D is its faithful Java port. It ships shaded into com.codename1.gaming.physics.box2d, inside the core with no dependency to add, with the BSD license retained and full attribution in the project NOTICE. On top of it sits an idiomatic wrapper, PhysicsWorld / PhysicsBody / ContactListener, that makes the two classic Box2D paper cuts disappear: the pixels-to-meters conversion and the flipped y-axis are centralized, so your game code stays entirely in screen coordinates.

Bodies are created from boxes, circles, polygons, or any Codename One Shape. Collisions arrive through ContactListener. And setLinkedSprite closes the loop: after world.step(), every linked sprite has already moved to where its body is.

Pure Java matters here. Because the engine is plain bytecode, it runs unchanged through ParparVM on iOS, through the new Windows port, on Android, and on the web. There is no native physics library to bind, version, or debug per platform.

Sound effects that keep up

Music and sound effects have opposite requirements: music wants streaming, effects want zero latency and overlapping playback. MediaManager always covered the former; the new SoundPool covers the latter:

SoundPool sfx = SoundPool.create(12); // up to 12 overlapping voices
SoundEffect blip = sfx.load(stream, "audio/wav");
// later, per bounce, with per-drop pitch:
sfx.play(blip, 0.9f, 0f, rate, 0);   // volume, pan, rate, loop

Each platform backs this with its native low-latency path: android.media.SoundPool on Android, an AVAudioPlayer pool on iOS, and a software mixer with volume, pan, and rate control on the desktop. Where no native backend exists, a pure cross-platform fallback over MediaManager keeps the API functional, and isNativeAccelerated() tells you which path you got.

What can you build?

The repository ships six game samples, each a complete, playable game in a few hundred lines, and each generating every pixel of its art and every sound at runtime, so there are no assets to manage. They double as a tour of the API, one genre at a time. Every capture below is the actual sample being played in the simulator.

CasualGameSample is an arena collector: pilot a ship around a starfield with the on-screen joystick, scoop up spinning gems, dodge drifting asteroids. It exercises the breadth of the 2D layer: many sprites in one Scene, per-sprite animation, particle bursts, collision, and a TouchControls joystick that drives the same GameInput a keyboard would.

ScrollerGameSample is the side-scroller hello world: run, jump, collect coins. The Scene camera follows the player so the level slides past, an AnimatedSprite walk cycle flips to face the run direction, and a cheap parallax backdrop (fixed sun, drifting clouds, half-speed hills) sells the depth. Its gravity is a few hand-rolled lines, proof you don't need the physics engine for a platformer feel.

CardGameSample is Memory (Concentration): a sprite per card, a horizontal flip animation that swaps the face at the midpoint, tap hit-testing through GameInput, and a small game state machine. The structure transfers directly to any card or tile game.

BoardGameSample is checkers against a small built-in AI, on an isometric board. Every tile and piece is a flat Sprite, but the 2:1 diamond projection and raised pieces give a convincing 3D look with no camera or models, the classic "faux 3D" trick, and the cell-to-pixel mapping it demonstrates underlies every isometric game.

Gaming3DDemoSample crosses into real 3D: a lit, spinning model on a ground plane, a ring of billboarded coin sprites that always face the orbiting perspective camera, and touch controls, in about two hundred lines.

And GamingDemoSample is the physics demo this post opened with: Box2D bodies, linked sprites, and a SoundPool blip whose pitch varies per drop.

Where to go from here

The new Game Development chapter in the developer guide covers the loop, sprites, physics, and audio in detail, including case studies that walk through the card game and the isometric checkers above section by section.

If you build something with this, we genuinely want to see it, and if you hit a wall, file an issue with the smallest game that reproduces it.

Yesterday's post covered the portable 3D API this is built on, and the release post has the full index. Your Java becomes a native Windows executable with no JVM in .

3D Graphics Without Writing Shaders: The Portable GPU API

Shai Almog — Sat, 20 Jun 2026 13:33:27 +0000

Cross-platform 3D is one of those problems that looks impossible when you list the constraints. iOS wants Metal and Metal Shading Language. Android wants OpenGL ES and GLSL. The web wants WebGL. Windows wants Direct3D and HLSL. Every one of these has its own shader language, its own pipeline model, and its own buffer semantics. Most portable engines solve this by making you write shaders multiple times, or by adopting a giant dependency that becomes your whole application.

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.

PR #5151 takes a different path. The new com.codename1.gpu package is a portable 3D API where applications never write shader source at all. You describe a Material: its lighting model, color, texture, shininess. Per-platform generators emit the actual shader, GLSL ES on Android and WebGL, Metal Shading Language on iOS and Mac, HLSL on the new native Windows port. One Java code base, five GPU backends.

A cube in one screen of code

The API centers on a Renderer you implement and a RenderView that hosts it. Here is a complete Phong-lit cube:

RenderView view = new RenderView(new Renderer() {
    private final Camera camera = new Camera();
    private Mesh cube;
    private Material material;

    public void onInit(GraphicsDevice device) {
        cube = Primitives.cube(device, 1.6f);
        material = new Material(Material.Type.PHONG)
                .setColor(0xff3366ff)
                .setShininess(24f);
        camera.setPerspective(45f, 0.1f, 100f)
                .setPosition(2.6f, 2.1f, 3.4f)
                .setTarget(0f, 0f, 0f);
        device.setLight(new Light().setDirection(-0.4f, -1f, -0.55f));
    }

    public void onResize(GraphicsDevice device, int width, int height) {
        camera.setAspect((float) width / Math.max(1, height));
        device.setViewport(0, 0, width, height);
    }

    public void onFrame(GraphicsDevice device) {
        device.clear(0xff101018, true, true);
        device.setCamera(camera);
        float[] model = Matrix4.rotation((float) Math.toRadians(25), 0.35f, 1f, 0.12f);
        device.draw(cube, material, model);
    }

    public void onDispose(GraphicsDevice device) {
    }
});
form.add(BorderLayout.CENTER, view);

RenderView is a regular Codename One component. It participates in layout, sits next to buttons and labels, and the surrounding form keeps working exactly as before. This is a textured variant of the same code running on an iPhone through Metal:

Real models, not just primitives

Primitives gives you cubes, spheres, and friends for getting started, but real content comes from 3D tools. The GltfLoader reads binary glTF (.glb), the de-facto standard interchange format that Blender and practically every modern 3D tool export:

GltfLoader.GltfModel model = GltfLoader.loadModel(device,
        Display.getInstance().getResourceAsStream(getClass(), "/boombox.glb"));
Mesh mesh = model.getMesh();
Material material = new Material(Material.Type.PHONG)
        .setTexture(model.getBaseColorTexture());

The model ships as a regular project resource, so the same asset loads on every platform. Here is the Khronos BoomBox sample (about 6,000 triangles with its own base-color texture) rendering on the native Mac target:

What runs where

Platform	Backend
iOS / Mac native	Metal (`CAMetalLayer`), runtime MSL compilation, pipeline cache
Android	OpenGL ES 2 via a `GLSurfaceView` peer
Web (JavaScript port)	WebGL on a canvas peer, reusing the core GLSL generator
Windows native	Direct3D 11, HLSL generated and compiled at runtime
Simulator (JavaSE)	OpenGL via JOGL by default, with a pure-Java software rasterizer as the fallback

The simulator's fallback deserves a note: it is a complete depth-buffered, perspective-correct, textured, lit rasterizer written in plain Java. When OpenGL isn't available, headless CI machines for instance, rendering keeps working and stays deterministic, which is how our screenshot test suite gates 3D output on every platform.

On iOS there is one more trick. Vertex and index buffers are backed by SIMD-aligned arrays, so the mesh data sits at a fixed, aligned C address that is handed to Metal directly with no intermediate copy. Java arrays in, GPU buffers out, nothing in between.

Two levels of API

The hybrid design goes deeper than materials. Most applications stay on the high level: Mesh, Material, Camera, Light, and Primitives, with Matrix4 providing the usual transform helpers (perspective, look-at, rotation, scaling, multiplication) as plain float[16] arrays with no object churn per frame.

Underneath sits a command layer for people who know exactly what they want. VertexBuffer and IndexBuffer hold your geometry, VertexFormat describes its layout through typed VertexAttribute usages (position, normal, texture coordinates, color), and Texture exposes wrap and filter modes. RenderState controls depth testing, culling, and blend modes per draw call. Everything funnels through GraphicsDevice, which is the one object a Renderer ever talks to, and GpuCapabilities reports what the device underneath can actually do, maximum texture size for instance, so you can scale content to the hardware.

Two details matter for performance. Pipelines are cached by descriptor, so a thousand draws with the same material compile one shader, not a thousand. And rendering is on-demand by default: a static scene renders when something changes (requestRender()), while setContinuous(true) switches to a steady frame loop for animation. On-demand is the difference between a 3D product view that sips battery and one that drains it.

Designed to degrade

Not every environment has a GPU backend. RenderView.isSupported() tells you whether real 3D is available, and where it isn't the view renders a placeholder rather than failing. The seam into the platform layer mirrors how BrowserComponent works internally, so ports that don't implement 3D simply report it as unsupported and everything else keeps running.

This is a foundation

A portable 3D API is useful on its own, for product viewers, data visualization, and the occasional spinning logo. But the reason it exists is tomorrow's post: a game development API that builds sprites, scenes, physics, and sound on top of this layer.

If you render something and it doesn't look right on one of the backends, please file an issue with the model or code attached. Five GPU backends mean five ways for an edge case to hide, and real reports are how the generators improve.

The new 3D Graphics and Shaders chapter in the developer guide covers both API levels in depth, including the shader generation model and per-platform notes. Friday's release post has the full index of this week's posts, and builds games on top of this API.

Native Java Win32, 3D Gaming, Printing and Wallet

Shai Almog — Fri, 19 Jun 2026 14:02:25 +0000

This week we're introducing native Windows support (no JVM!), a 3D graphics API, a gaming API, support for Apple Wallet, printing and more in what is probably our biggest update ever… But that's not the thing that excites me the most.

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 thing that excites me the most

I won't tease you about this too much. The thing that excited me the most this week is this new article by Francesco Galgani introducing Codename One, published on Baeldung. Beyond the great writing and form, the excitement is about the community: the way you're all using Codename One and helping us build it. The issues, the tracking, and the enthusiasm about upcoming features, like this one where a request to consolidate documentation chapters opens with a triple thank-you for the game development API before it even gets to the point.

Again, thank you all for being a part of this. We literally wouldn't be doing this without you!

What shipped this week

Version 7.0.251 is live, and the four big items each get a full tutorial over the next few days. Here is a deeper look at what's coming.

A portable 3D graphics API

com.codename1.gpu is a GPU-accelerated 3D API where the same Java code renders through Metal on iOS and Mac, OpenGL ES on Android, WebGL on the web, Direct3D 11 on the new native Windows port, and a dependency-free software rasterizer in the simulator. The trick that makes this portable is that you never write shader source: you describe a Material (lighting model, color, texture, shininess) and the engine generates the platform shader, GLSL, Metal Shading Language, or HLSL, depending on where it lands.

A lit, spinning cube is this short:

public void onInit(GraphicsDevice device) {
    cube = Primitives.cube(device, 1.6f);
    material = new Material(Material.Type.PHONG)
            .setColor(0xff3366ff)
            .setShininess(24f);
    camera.setPerspective(45f, 0.1f, 100f)
            .setPosition(2.6f, 2.1f, 3.4f)
            .setTarget(0f, 0f, 0f);
    device.setLight(new Light().setDirection(-0.4f, -1f, -0.55f));
}

public void onFrame(GraphicsDevice device) {
    device.clear(0xff101018, true, true);
    device.setCamera(camera);
    device.draw(cube, material, Matrix4.rotation(angle, 0.35f, 1f, 0.12f));
}

And it isn't limited to primitives. A binary glTF model authored in any 3D tool loads with one call and renders with its own textures. This is the Khronos BoomBox sample model rendering on the native Mac target:

On iOS the vertex buffers are SIMD-aligned so the data is handed to Metal with no copy in between. The RenderView hosting all of this is a regular component, so a 3D view drops into a normal form next to buttons and text. We walk through the whole API in .

Game development in the core

com.codename1.gaming builds a game surface on top of that 3D layer: a GameView with a tight update(dt) loop, sprites, scenes with cameras, pollable input, a low-latency SoundPool, and rigid-body physics powered by a Box2D engine that ships inside the core. This is the complete logic of a physics demo where every tap drops a bouncing ball:

protected void update(double dt) {
    if (getInput().wasPointerPressed()) {
        PhysicsBody body = world.createCircle(
            getInput().getPointerX(), getInput().getPointerY(),
            30, BodyType.DYNAMIC);
        body.setRestitution(0.7f);
        Sprite s = new Sprite(ballImage);
        body.setLinkedSprite(s);
        getScene().add(s);
    }
    world.step((float) dt);
}

No render code in sight: the linked sprites track their physics bodies and the scene draws itself. Here it is running in the simulator:

The physics engine is JBox2D repackaged under com.codename1.gaming.physics.box2d, with an idiomatic wrapper that keeps your code in screen pixels and hides the meters and the flipped y-axis. Because everything is pure Java where it matters, it runs unchanged on every target, including iOS. For years we said no to gaming APIs in Codename One; also explains what changed our mind.

Your Java app as a native Windows executable, no JVM

The new Windows target translates your Java/Kotlin bytecode to C through ParparVM, compiles it with clang-cl, and links a standalone Win32 .exe. Rendering is Direct2D, text is DirectWrite, networking is WinHTTP, the browser component is WebView2, and there is no JVM anywhere: not bundled, not downloaded, not required on the user's machine. A hello world is around 4MB and the full Initializr app is around 8MB. One cloud build produces both x64 and arm64 executables.

Edit: Since publishing this post we found the binaries were carrying their debug and stack-unwind tables inline. We now split that data into a separate symbol file (kept only to symbolize crashes) and dead-strip code the app never reaches, which brings the sizes down further -- the figures above reflect the leaner build.

To be clear about what this is, because "Java on Windows" carries old associations: there is no Swing here, no AWT, no JavaFX, and no bundled runtime. It is the full Codename One framework compiled to native code, and everything in it works there, including the new printing API and the 3D layer. This is the same app from the same code base, rendered by Direct2D and DirectWrite on Windows:

People have been asking how to turn Java into a real .exe since the late nineties, and the modern answer, GraalVM, is a tool designed for a different purpose. The architecture, the history, and how this completes the native desktop story the Mac target started are all in .

Printing and Apple Wallet

Two platform integrations that apps keep needing. com.codename1.printing hands a PDF or image to the native print dialog on every port, including the new Windows one:

if (Printer.isPrintingSupported()) {
    Printer.printPDF(reportPath, result -> {
        if (result.isFailed()) {
            ToastBar.showErrorMessage("Print failed: " + result.getError());
        }
    });
}

And card issuers can now let users add cards to Apple Wallet from inside the Wallet app itself. The iOS build generates Apple's issuer-provisioning extension pair from build hints, with zero native code on your side:

ios.wallet.extension=true
ios.wallet.appGroup=group.com.mybank.app
ios.wallet.issuerEndpoint=https://api.mybank.com/wallet/provision

Your app publishes its card list through the new WalletExtension API and the extension picks it up from the shared App Group. Both features get the full treatment in .

Behind the scenes: the build cloud was rebuilt

Codename One was founded in 2012, when Docker was still a "new thing", and a lot of the infrastructure we built back then was duct-taped together as we were working in startup mode. A big part of this week's work happened at that infrastructure level: the build servers underwent a major rebuild and re-architecture, and more is going on there than is apparent from the outside.

We're telling you this so you're prepared: if a build behaves differently or something breaks where it didn't before, please let us know right away through the issue tracker so we can fix it quickly. The goal of all this is a faster, more maintainable build cloud, and the transition is the risky part.

Simulator UX improvements

PR #5211 reworks the simulator chrome around several long-standing annoyances:

Slow Motion is back. The 50x animation slowdown toggle had been commented out years ago; it's now under Tools.
Rotation keeps your zoom. Rotating the device used to discard the fit-to-screen factor, forcing you to re-toggle Zoom after every rotation. All rotate/zoom paths now share the same fit logic.
The standalone simulator is the default. The plain device window is what you get out of the box; the multi-panel app frame is still available through the Single Window Mode preference, and explicit settings are honored.
The menus make sense. The confusing Simulator vs Simulate split is gone: the device and its window live under one menu, simulated device state (location, push, biometrics, dark mode) under another, and developer tools under Tools.

A verification problem that was very hard to track

PR #5216 fixes a bug in the build pipeline's bytecode compliance check that could silently lose its API rewrites when classes were recompiled with unchanged sources. The symptom was an iOS build failing deep inside Xcode with an error about an undeclared String.replaceAll function, and the only recovery was wiping the build directory. The check now detects recompiled classes and re-runs, and a failed check can no longer be skipped on the next build. If you ever hit that mystery error locally, this was it.

UIScene apps start up smoother

PR #5218 fixes the black flash at iOS app launch that arrived with the UIScene default. iOS wasn't rendering the launch storyboard for scene-based apps, and the render surface was empty until the first form painted. The build now generates the modern launch-screen configuration and the native code covers the hand-off with a placeholder that matches the launch screen exactly, fading into the first form. The result: icon tap, launch screen, invisible hand-off, first form, with no black at any point. If you need the old behavior, the ios.launchPlaceholder=false build hint opts out.

Pin the browser appearance on iOS

Embedded web views on iOS follow the device's light/dark appearance, and since the UIScene transition the app-wide plist override stopped affecting them. PR #5203 adds a per-component property to pin it:

browser.setProperty(BrowserComponent.BROWSER_PROPERTY_INTERFACE_STYLE, "light");

Valid values are light, dark, and auto. It's safe to call in the constructor; the property is applied when the native peer is ready.

Upcoming attractions

Four tutorials follow this post, one per day; each link below goes live on its day:

Saturday. . PR #5151.
Sunday. . PR #5166.
Monday. . PRs #5144, #5209.
Tuesday. . PRs #5217, #5227.

Wrapping up

Background Work, Push Topics, And Richer Notifications

Shai Almog — Tue, 16 Jun 2026 14:37:12 +0000

The work that happens while your app is not in the foreground has always been the fiddly part of mobile development, and Codename One's coverage of it had gaps. PR #5142 modernizes local notifications, push, background execution, and shared content across the core, JavaSE, Android, and iOS, and importantly it makes all of it work in the simulator so you can iterate without a 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.

Background work with constraints

The new com.codename1.background package schedules work that the OS runs when its conditions are met, mapping to Android JobScheduler and iOS BGTaskScheduler underneath. You describe what the work needs, not when to poll:

WorkRequest req = WorkRequest.builder("daily-sync", SyncWorker.class)
    .setRequiresNetwork(true)
    .setRequiresCharging(true)
    .setPeriodic(6 * 60 * 60 * 1000L)
    .build();
BackgroundWork.schedule(req);

The worker is a small class with a no-argument constructor that the platform instantiates when it runs your task:

public class SyncWorker implements BackgroundWorker {
    public void performWork(String workId, Map<String, String> inputData,
                            long deadline, Callback<Boolean> onComplete) {
        boolean ok = pullLatestData();
        onComplete.onSucess(ok);
    }
}

The builder covers the usual constraint set: network, unmetered network, charging, idle, battery-not-low, periodic intervals, an initial delay, and input data. For longer foreground operations there is ForegroundService.start(...), which runs a JVM task behind a persistent notification on Android, and for heavier iOS background processing BackgroundTask.scheduleProcessing(...) maps to BGProcessingTaskRequest. The iOS background-processing identifiers are declared with the ios.backgroundProcessingIds build hint, which the builder turns into the matching Info.plist entries for you.

Notifications got a lot richer

LocalNotification gained a long list of capabilities, all added backward-compatibly so every existing field, getter, and setter behaves exactly as before. New on top of that: an image attachment, multiple action buttons, inline quick reply, per-channel sound, grouping with a summary, full-screen intent, time-sensitive delivery, ongoing and progress notifications, a custom view, and a messaging-conversation style.

A download-progress notification, for example:

LocalNotification n = new LocalNotification();
n.setId("download");
n.setAlertTitle("Downloading");
n.setAlertBody("episode-12.mp4");
n.setOngoing(true);
n.setProgress(100, 40);
Display.getInstance().scheduleLocalNotification(
    n, System.currentTimeMillis(), LocalNotification.REPEAT_NONE);

Or a notification with an inline reply, the kind a messaging app uses:

n.addInputAction("reply", "Reply", "Type a message", "Send");

On newer Android devices, notification channels are now first-class through a builder routed via Display:

Display.getInstance().registerNotificationChannel(
    new NotificationChannelBuilder("messages", "Messages")
        .importance(NotificationChannelBuilder.IMPORTANCE_HIGH)
        .enableVibration(true)
        .lockscreenVisibility(NotificationChannelBuilder.VISIBILITY_PRIVATE));

Permission requests are explicit too, with Display.requestNotificationPermission(...) taking a NotificationPermissionRequest (provisional, critical, time-sensitive, or the Android POST_NOTIFICATIONS permission) and returning a NotificationPermissionResult you can check with isGranted().

Push topics

Push now supports topic subscriptions:

Push.subscribeToTopic("sports");
Push.unsubscribeFromTopic("sports");

On Android these map to FCM topics. On iOS they are a documented no-op, because raw APNs has no topic concept; the call is safe to make on both so your code stays cross-platform.

Receiving shared content

If a user shares text, a URL, a file, or an image into your app from another app, it now arrives through a single lifecycle hook:

public void onReceivedSharedContent(SharedContent content) {
    // content carries text / url / file / image items
}

On Android this is backed by a share-receiver activity that handles SEND and SEND_MULTIPLE and hands files off through app storage. On iOS it reuses the share extension that landed two weeks ago and reads the App-Group payload when the app activates; the App Group is configured with the ios.shareAppGroup build hint. The build plugin wires the manifest entries, services, and intent filters automatically based on a classpath scan, so turning these features on does not mean hand-editing platform descriptors.

All of it runs in the simulator

The piece that makes this practical day to day is the JavaSE support. There is a new "Notifications and Background" entry in the Simulate menu with constraint toggles, a run-the-work-now button, a channel inspector, and shared-content injection, plus a rich notification panel that renders images, actions, inline quick reply, and progress and routes taps back to your LocalNotificationCallback and PushContent on the same code path the device uses. You can build and debug these flows entirely on your desktop before you ever make a build.

A control screen like this, with the scheduled job and the actions wired to the calls above, runs and renders in the simulator:

The previous deep dive was about the new advertising API, and the release post has the full index for the week, including the smaller fixes and the note about how we are handling contributions now. Keep an eye for our next release this Friday.

A New Advertising API, Built From The Ground Up

Shai Almog — Mon, 15 Jun 2026 15:03:04 +0000

Advertising support in Codename One had quietly rotted. It was spread across three mechanisms that no longer work: the original com.codename1.ads and FullScreenAdService APIs built on the long-dead InnerActive and V-Serv networks, the decade-old google.adUnitId and mopubId banner build hints (MoPub is gone), and an AdMob cn1lib that was interstitial-only, built on iOS APIs Google has since removed, busy-polled, and had no consent flow. None of them supported rewarded, rewarded-interstitial, app-open, or native formats, GDPR consent, iOS App Tracking Transparency, server-side reward verification, or mediation.

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.

PR #5169 replaces all of it with one pluggable, format-complete advertising subsystem in the core, plus modern reference providers that actually work!

One API, every format

The public API lives in com.codename1.ads. AdManager is the entry point, and there is a type per format: InterstitialAd, RewardedAd, RewardedInterstitialAd, AppOpenAd, BannerAd, and NativeAdLoader. Consent is handled by AdConsent (UMP plus iOS ATT), and AdConfig, AdRequest, and AdListener round out the surface. The whole thing is event-driven and every callback is marshaled onto the EDT, so you never touch ad SDK threading.

A rewarded ad, the format people most often ask about, reads like this:

AdConfig cfg = new AdConfig().testMode(true);
AdManager.initialize(cfg, ok -> {
    if (!ok) {
        return;
    }
    RewardedAd ad = new RewardedAd("your-rewarded-ad-unit-id");
    ad.setAdListener(new AdListener() {
        public void onLoaded() {
            ad.show(reward ->
                grantCoins(reward.getType(), reward.getAmount()));
        }
    });
    ad.load();
});

Consent is a first-class step rather than an afterthought:

AdConsent.requestConsent(status -> {
    if (AdConsent.canRequestAds()) {
        loadAds();
    }
});

Pluggable by design

The provider side is an SPI (Service Provider Interface) in com.codename1.ads.spi: a network-agnostic AdProvider plus session interfaces. Discovery is zero-wiring. AdManager resolves the provider through a single call to install(), so adding an ad cn1lib to your project auto-registers it with no setup code. AdMob, AppLovin MAX, Unity LevelPlay, or your own mediation layer can be swapped without touching app code.

A few things only the core can do, and they are wired in directly:

// Show an interstitial on form transitions, no more often than every two minutes
AdManager.bindInterstitialOnTransition(interstitial, 120000);

// Show an app-open ad when the app returns to the foreground
AdManager.enableAppOpenAds(appOpenAd);

Banners are peer-backed components, so they sit in your layout like any other component.

AdMob as the reference provider

The reference provider is a real, modern AdMob integration shipped as maven/cn1-admob, modeled on the ML Kit cn1libs. It targets Google Mobile Ads v24 and up on Android, the current GAD* APIs with UMP and ATT on iOS, and AdMob mediation works transparently behind it. You will need to add these to your build hints:

android.xapplication=<meta-data android:name="com.google.android.gms.ads.APPLICATION_ID" android:value="ca-app-pub-XXXXXXXX~YYYYYYYY"/>
ios.plistInject=<key>GADApplicationIdentifier</key><string>ca-app-pub-XXXXXXXX~YYYYYYYY</string>

Those hints set the Android APPLICATION_ID manifest meta-data and the iOS GADApplicationIdentifier. For iOS you should also declare your SKAdNetworkItems and an NSUserTrackingUsageDescription (the ATT prompt copy) the same way.

Debugging Ads

The simulator ships a placeholder provider so you can exercise every format and the consent flow, without a device. The AdsSample in the samples repo runs every format against the simulator placeholder if you want to see the flows before you wire up a real account.

A reminder that applies to any ad integration: if you do server-side reward verification, the verification has to happen on your server. Do not trust a reward granted purely on the client, and do not embed any server secret in the app.

The previous deep dive covered WebSockets, gRPC, and GraphQL in the core, and the release post has the full index. Tomorrow's post, the last of the run, is about background work, push topics, and richer notifications.

WebSockets, gRPC, And GraphQL In The Core

Shai Almog — Sun, 14 Jun 2026 13:32:59 +0000

Three connectivity features landed together this week, and they belong in one place because they build on each other. WebSockets moved into the core; the GraphQL client uses that same WebSocket support for subscriptions; and gRPC reuses the exact code-generation pattern GraphQL and OpenAPI already follow. This post is a tutorial for all three. By the end, you will have a live chat, a typed GraphQL client, and a typed gRPC client, and you will see how little code each one takes.

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.

These features come from PR #5133 (WebSockets) and PR #5141 plus PR #5099 (the typed clients).

Part 1: WebSockets, no cn1lib required

WebSockets used to require the cn1-websockets cn1lib. They are now part of the framework as com.codename1.io.WebSocket, implemented natively on every port (a hand-rolled RFC 6455 handshake on JavaSE and Android, NSURLSessionWebSocketTask on iOS, the browser WebSocket on JavaScript), with no third-party dependencies pulled into your build.

If you're using cn1-websockets you can keep using it. There's no change required from you. We moved the package up one level, so there's no conflict.

Step 1: open a connection

The new API is a final, fluent class with lambda handlers. You build it, attach handlers, and connect:

// Good practice although in reality all current Codename One Platforms support WebSockets
if (!WebSocket.isSupported()) {
    return;
}
WebSocket ws = WebSocket.build("wss://echo.example.com/socket")
    .onConnect(() -> Log.p("connected"))
    .onTextMessage(text -> addIncoming(text))
    .onClose((code, reason) -> Log.p("closed " + code + " " + reason))
    .onError(ex -> Log.e(ex))
    .connect();

There is no URL-in-constructor subclassing trap from the old API; the connection is an object you hold. send(...) has a String and a byte[] overload, getReadyState() returns a WebSocketState, and close() does a clean close handshake.

Step 2: build the chat screen

Here is a compact chat form. Outgoing messages are added immediately; incoming ones arrive on the onTextMessage handler, and because the handler can touch the UI we wrap that in callSerially:

private WebSocket ws;
private Container conversation;

private void showChat(Form parent) {
    Form chat = new Form("Live Chat", BoxLayout.y());
    conversation = chat.getContentPane();

    TextField input = new TextField("", "Message", 20, TextField.ANY);
    Button send = new Button("Send");
    send.addActionListener(e -> {
        String text = input.getText();
        if (text.length() > 0 && ws != null) {
            ws.send(text);
            addBubble(text, true);
            input.clear();
        }
    });
    Container bar = BorderLayout.centerEastWest(input, send, null);
    chat.add(BorderLayout.SOUTH, bar);

    ws = WebSocket.build("wss://chat.example.com/room/general")
        .onTextMessage(text -> Display.getInstance()
            .callSerially(() -> addBubble(text, false)))
        .connect();

    chat.show();
}

private void addBubble(String text, boolean mine) {
    Label bubble = new Label(text);
    bubble.setUIID(mine ? "ChatBubbleMe" : "ChatBubbleThem");
    Container line = FlowLayout.encloseIn(bubble);
    line.getStyle().setAlignment(mine ? Component.RIGHT : Component.LEFT);
    conversation.add(line);
    conversation.animateLayout(150);
}

That is a working real-time chat. The screen it produces, rendered in the simulator:

Step 3: negotiate a subprotocol when you need one

If your server speaks a named subprotocol, set it during the handshake and read back what the server chose:

WebSocket ws = WebSocket.build(url)
    .subprotocols("graphql-transport-ws")
    .onConnect(() -> Log.p("using " + ws.getSelectedSubprotocol()))
    .connect();

That graphql-transport-ws value is not an accident; it is exactly what the GraphQL subscriptions in the next part use.

One reason to trust this implementation: our own screenshot CI now runs on it. The pipeline that ships rendered PNGs from each device back to the host machine uses a WebSocket as its transport, so the same code your app calls is carrying the binary payloads that validate the framework on every commit.

Part 2: a typed GraphQL client

cn1:generate-graphql turns a GraphQL schema into a typed client, and @GraphQLClient is the interface you write against. The runtime lives in com.codename1.io.graphql, and a GraphQLResponse<T> carries data and errors together so partial results survive.

Step 1: declare the client

@GraphQLClient("https://swapi.example.com/graphql")
public interface StarWarsApi {
    @Query("query HeroName($episode: Episode) { hero(episode: $episode) { name homeworld { name } species { name } filmConnection { totalCount } } }")
    void hero(@Var("episode") Episode episode,
              OnComplete<GraphQLResponse<HeroData>> callback);

    @Subscription("subscription OnReview($ep: Episode!) { reviewAdded(episode: $ep) { stars } }")
    GraphQLSubscription onReview(@Var("ep") Episode ep,
                                 GraphQLSubscription.Handler<ReviewData> handler);

    static StarWarsApi of(String endpoint) {
        return GraphQLClients.create(StarWarsApi.class, endpoint);
    }
}

The build-time processor emits the implementation and a bootstrap that registers it; you never write the HTTP plumbing. The generator has two modes. The precise operations mode emits per-selection types from your operation documents; the schema-only quick-start mode auto-selects fields to a bounded depth (cn1.graphql.maxDepth).

Step 2: call it and render the result

StarWarsApi api = StarWarsApi.of("https://swapi.example.com/graphql");
api.hero(Episode.EMPIRE, response -> {
    if (!response.isOk()) {
        return;
    }
    Container list = heroForm.getContentPane();
    for (Hero h : response.getResponseData().heroes) {
        MultiButton row = new MultiButton(h.name);
        row.setTextLine2(h.homeworld + " . " + h.species);
        row.setUIID("HeroRow");
        list.add(row);
    }
    heroForm.revalidate();
});

The list this populates, rendered in the simulator:

Step 3: subscriptions ride the core WebSocket

A @Subscription returns a GraphQLSubscription backed by the core WebSocket using the graphql-transport-ws protocol from Part 1. New events arrive on the handler:

GraphQLSubscription sub = api.onReview(Episode.JEDI, review ->
    Display.getInstance().callSerially(() -> showStars(review.stars)));
// later
sub.close();

This is the payoff of putting WebSockets in the core: the GraphQL layer did not need its own socket implementation, it just used the frameworks.

Part 3: a typed gRPC client

cn1:generate-grpc does the same trick for proto3. Point it at your .proto files and it emits hand-editable @ProtoMessage, @ProtoEnum, and @GrpcClient sources; the annotation processor generates the binary protobuf codecs and call sites into target/generated-sources so your source tree stays clean. There is no protoc dependency.

Step 1: the proto

syntax = "proto3";
service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}
message HelloRequest { string name = 1; }
message HelloReply  { string message = 1; }

Step 2: call the generated client

GreeterGrpc g = GreeterGrpc.of("https://api.example.com");
HelloRequest req = new HelloRequest();
req.name = "world";
g.sayHello(req, "Bearer " + token, response -> {
    if (response.isOk()) {
        renderGreeting(response.getResponseData().message);
    }
});

The wire protocol is gRPC-Web binary (application/grpc-web+proto), the standard variant for mobile and browser clients, which works with Envoy, the official grpcweb Go proxy, and the gRPC-Web filter in modern gRPC servers. Version one covers unary RPCs, all scalar types, nested messages, enums, and repeated fields; streaming, map<K,V>, well-known types, and import are out for now and the parser errors cleanly when it meets one.

Enums bind across all of it

All three connectors share the build-time JSON and XML mapper, and that mapper now binds enums. Previously an enum field was treated as a nested reference, found no mapper, and silently did not serialize. It now writes with name() and reads with valueOf (unknown values decode to null), and it handles List<Enum>, across both JSON and XML. That is why the GraphQL Episode above is a real enum rather than a String, and it is a welcome fix for anyone using @Mapped directly.

Keep your tokens out of the binary

The gRPC and GraphQL samples pass a bearer token, so the rule bears repeating: never hard-code a token, and never check it into source or embed it in the app. Fetch it from your backend at runtime and store it with SecureStorage. A shipped binary can be unpacked, so anything baked into it is effectively public.

These connectors learn from real specs. If a schema or a proto file does not generate the client you expected, please file an issue at github.com/codenameone/CodenameOne/issues with the source attached.

The previous deep dive covered native Mac builds and desktop integration, and the release post has the full index. Tomorrow's post is the new advertising API.

Your Codename One App, Now A Native Mac App

Shai Almog — Sat, 13 Jun 2026 13:33:30 +0000

Codename One has run on the desktop for a long time through the JavaSE target, which is the same engine that powers the simulator. What it did not have was a real native Mac binary, and the desktop output still carried a lot of phone-shaped habits: a drawn toolbar where the OS menu bar belongs, scrollbars you could not grab, no place in the menu for Preferences or Quit. With version 7.0.250 we finally have an actual native macOS application target that doesn't bundle a JVM and is as native as our iOS target.

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.

A native Mac build from the iOS pipeline

PR #5053 adds a Mac Native target that takes the existing project through the same build as the iPhone builder and the ParparVM pipeline that produces an iOS app. In this case it emits a native Mac variant of it.

We can find these targets in the standard maven menu in IntelliJ as "Mac Native Build" to send a build cloud build:

Or as "Mac Native Project" to generate an Xcode project:

These targets should work in the same way as the equivalent iOS targets.

Thanks to our switch to Metal the code for the native Mac build is very similar. That means the code of the Mac native target is mostly battle tested.

We use Mac Catalyst, which is an iOS/Mac porting framework from Apple. The user-facing name is "Mac native," and a future phase might add an AppKit target sharing the same Metal renderer without changing the surface you build against.

One thing to keep in mind is that the iOS native interfaces would be the same for the desktop target, this might work out fine but in case it doesn't you can use #ifdef to adapt code for the Mac target.

Here is a Codename One sample running as a native Mac app, the same Java code that produces the iOS and Android builds (it uses the new advertising API covered later this week):

Certificates

There's one major gap with the Mac target: signing. Right now our certificate wizard, settings etc. are geared towards iOS/Android. Mac uses a different store and different signing tools. We didn't update all of that infrastructure yet, and it might take some time to update. As a short-term solution, we support some build hints to configure this:

Hint	Purpose
`codename1.mac.appid`	Mac bundle identifier (the App Store Connect record is distinct from the iOS one).
`codename1.mac.certificate`	Path to the `.p12` containing the Mac signing certificate. Bundle both Mac App Distribution and Developer ID Application into a single P12 when targeting both channels.
`codename1.mac.certificatePassword`	Password to unlock the P12.
`codename1.mac.provision`	Path to the Mac `.provisionprofile`.

Desktop integration

PR #5136 and the follow-up PR #5170 make a desktop target behave like a desktop app rather than a tablet app in a window. Everything here is opt-in, on by default for newly generated apps, and completely inert on mobile or when disabled. It spans the core plus desktop ports, JavaSE, Mac, and future ports.

Window chrome and the OS title bar

A new build hint chooses how the window is framed:

desktop.titleBar=native

In native mode the Codename One Toolbar is suppressed, the form title goes to the OS title bar, and your commands are bridged to a real native menu bar (a Swing JMenuBar that becomes the macOS screen menu on JavaSE, a UIMenuBuilder menu on Mac Catalyst). custom gives you an undecorated window with Codename One drawn caption buttons and window drag; toolbar keeps the classic behavior. Together these modes let you control how the app looks in a deeply customized way.

Commands land in the right menu

Instead of every command piling into one synthetic menu, a command can declare where it belongs:

Command prefs = Command.create("Preferences...", null, e -> showPreferences());
prefs.setDesktopMenu(Command.DESKTOP_MENU_PREFERENCES);
prefs.setDesktopShortcut(',', Command.DESKTOP_SHORTCUT_MODIFIER_PRIMARY);

Command save = Command.create("Save", null, e -> save());
save.setDesktopMenu(Command.DESKTOP_MENU_FILE);
save.setDesktopShortcut('s', Command.DESKTOP_SHORTCUT_MODIFIER_PRIMARY);

setDesktopMenu(...) takes any of DESKTOP_MENU_APP, ABOUT, PREFERENCES, QUIT, FILE, EDIT, VIEW, WINDOW, HELP, or a custom top-level title string, so Preferences and Quit show up where a Mac user expects them. setDesktopShortcut(...) attaches a keyboard accelerator; DESKTOP_SHORTCUT_MODIFIER_PRIMARY is Command on macOS and Control elsewhere, so the same code does the right thing on each desktop. The accelerator both appears next to the menu item and fires from the keyboard.

Interactive scrollbars

Desktop scrollbars are now grab-and-drag with a draggable thumb, click-track paging, and an always-visible track, following the macOS and Material conventions. The thumb shows its hover style under the pointer and its pressed style while dragged, and a minimum thumb size keeps it grabbable on very long content. This is gated by the interactiveScrollBool theme constant and uses dedicated Desktop* UIIDs, so mobile styling is untouched.

Desktop notifications

PR #5170 makes the standard LocalNotification API work on a real desktop build, not just in the simulator. On JavaSE a scheduled notification surfaces through a persistent system-tray icon as a native OS notification, and clicking it dispatches to your LocalNotificationCallback on the same code path mobile uses. Mac Catalyst keeps using the iOS notification path. The same notification code you already wrote for mobile now runs on the desktop.

Generated apps get this for free

New projects from the archetype and the Initializr default to desktop.titleBar=native with interactive scrollbars on, and the modern themes ship the Desktop* and Window* UIIDs in light and dark (macOS conventions in ios-modern, Material in android-material). If you have an existing app, opt in with the two hints above and check the new UIIDs against your theme.

This was validated end to end on both desktop builds: the JavaSE fat jar and the Mac Catalyst .app were each driven through the same AppleScript robot test for window title, menu placement, and native-menu command firing. The full Desktop Integration chapter in the developer guide covers the details.

The release post has the full week's index. Tomorrow's deep dive covers WebSockets, gRPC, and GraphQL in the core, the same theme of giving a Codename One app better ways to talk to the outside world.

Mac Native Builds, Live Protocols, And Open Issues Under 350

Shai Almog — Fri, 12 Jun 2026 14:02:19 +0000

Our focus was all over the place this week with work that targeted many different directions: desktop, monetization, communication, media, and more. This fits with our roadmap of one platform that delivers the promise Java never delivered: WORA for Everything Everywhere.

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.

But before we dig into the new features, there's one number I'm particularly proud of…

Open issues are under 350

The open issue count is now below 350 (332 at the moment of this writing). That is the result of a deliberate pass through the tracker, closing things that were already fixed, reproducing the ones that were not, and fixing a batch of them outright. Some of the reports we closed this week had been open since 2015. We got a little side-tracked in the process (it is hard to read an old report without wanting to fix it on the spot), but the direction is set: we want this number to keep dropping, and by a lot.

We went over the issue tracker starting with the oldest issues and working our way back. You may recall that when we started tracking this, going under the 500-issue mark was a major milestone and that was just a few weeks back!

What shipped this week

Every one of the bigger items has its own deep-dive tutorial. Here is the tour, with the links to the full posts.

Your app is now a native Mac app

Your existing Codename One app can ship as a 100% native Mac app today, with zero porting effort. No rewrite, no bundled JVM, no Electron shell: the project you already have produces a lean native Mac binary the same way it produces your iPhone app, on the same Metal renderer and battle-tested native pipeline. And it arrives feeling like a real Mac app, not a phone in a window: native title bar, native menu bar, interactive scrollbars, and desktop notifications come with it. Two of this week's features in one shot: the sample below uses the new advertising API covered later in this post, running as a native Mac app from the same Java code that produces the iOS and Android builds:

The full tutorial, including the new desktop menu and shortcut APIs and the Mac signing hints, is in Your Codename One App, Now A Native Mac App.

WebSockets in the core

com.codename1.io.WebSocket is now part of the framework with no cn1lib required, implemented natively on every port. A live connection is a fluent one-liner:

WebSocket ws = WebSocket.build("wss://chat.example.com/room/general")
    .onConnect(() -> Log.p("connected"))
    .onTextMessage(text -> Display.getInstance()
        .callSerially(() -> addBubble(text, false)))
    .connect();

This is the foundation the GraphQL subscriptions below ride on, and it is trusted enough that our own screenshot CI uses it as the transport for device renders. The hands-on tutorial that builds a live chat with it is WebSockets, gRPC, And GraphQL In The Core.

A typed GraphQL client from your schema

cn1:generate-graphql turns a GraphQL schema into a typed client: you declare an interface against your operations and the build emits the implementation, with zero HTTP plumbing on your side. A @Subscription gets you live server-pushed updates over the new core WebSocket:

@GraphQLClient("https://swapi.example.com/graphql")
public interface StarWarsApi {
    @Query("query HeroName($episode: Episode) { hero(episode: $episode) { name } }")
    void hero(@Var("episode") Episode episode,
              OnComplete<GraphQLResponse<HeroData>> callback);

    @Subscription("subscription OnReview($ep: Episode!) { reviewAdded(episode: $ep) { stars } }")
    GraphQLSubscription onReview(@Var("ep") Episode ep,
                                 GraphQLSubscription.Handler<ReviewData> handler);
}

Note that Episode is a real enum: enum binding landed in the JSON/XML mapper alongside this work, fixing a long-standing gap for @Mapped users too. The full tutorial is in WebSockets, gRPC, And GraphQL In The Core.

gRPC clients with no protoc

cn1:generate-grpc does the same for proto3. Point it at your .proto files and it generates the messages, the binary protobuf codecs, and the client, speaking the standard gRPC-Web wire protocol that works with Envoy and modern gRPC servers. There is no protoc to install and no native dependency; calling a service looks like this:

GreeterGrpc g = GreeterGrpc.of("https://api.example.com");
HelloRequest req = new HelloRequest();
req.name = "world";
g.sayHello(req, "Bearer " + token, response -> {
    if (response.isOk()) {
        renderGreeting(response.getResponseData().message);
    }
});

Together with cn1:generate-openapi and cn1:generate-graphql, this means a typed client for practically any backend is one Maven goal away. The walkthrough from proto file to running call is in WebSockets, gRPC, And GraphQL In The Core.

A new advertising API

Advertising support had quietly rotted across three dead-end legacy mechanisms. A pluggable, format-complete com.codename1.ads subsystem replaces all of them, with a modern AdMob reference provider, GDPR consent and iOS App Tracking Transparency built in, and a simulator placeholder provider so you can exercise every format without a device. A rewarded ad, the format people most often ask about, is now this short:

RewardedAd ad = new RewardedAd("your-rewarded-ad-unit-id");
ad.setAdListener(new AdListener() {
    public void onLoaded() {
        ad.show(reward ->
            grantCoins(reward.getType(), reward.getAmount()));
    }
});
ad.load();

The full story, including banners, native ads, app-open ads, and the provider SPI, is in A New Advertising API, Built From The Ground Up.

Background execution and push

Constraint-based background work, foreground services, push topics, shared-content handling, and a much richer local notification API, all of it usable in the simulator so you can debug these flows on your desktop. You describe what the work needs, not when to poll:

WorkRequest req = WorkRequest.builder("daily-sync", SyncWorker.class)
    .setRequiresNetwork(true)
    .setRequiresCharging(true)
    .setPeriodic(6 * 60 * 60 * 1000L)
    .build();
BackgroundWork.schedule(req);

The walkthrough, from progress notifications and inline replies to push topics and shared content, is Background Work, Push Topics, And Richer Notifications.

Building screens from screenshots, and a simpler Initializr

Generated apps ship with a codename-one agent skill under .claude/skills/, so an AI agent working in your project already knows how to build, test, and screenshot a Codename One UI. PR #5161 teaches it the single most common design task: "make this screen look like this mockup."

The hard part of that task was that the agent had no objective measure of how close it had gotten. The existing screenshot test only compares a render to a baseline the system produced itself, which measures consistency, not correctness. The new CompareToMockup tool is a single-file, pure-JDK CLI that scores a render against a target image and prints a similarity percentage: a STRUCTURAL score (an SSIM-style perceptual measure, robust to font and anti-aliasing noise against a vector mockup) and a PIXEL score (the fraction of pixels within the framework's own three-channel "same pixel" tolerance). It has a region mode so device chrome does not sabotage the score, a --diff heatmap, and a --min gate. That gives the agent a real signal: render, score, read the heatmap, adjust, repeat until the number stops climbing. A companion DesignImport tool turns a Figma, Sketch, or Adobe XD file (and, after PR #5168, the tokens.css from an HTML or React mockup) into a starter theme.css so the agent adjusts rather than starting from a blank page. The skill can also update itself now through an UpdateSkills tool, so a project generated months ago can pull the current guidance instead of carrying a frozen copy.

Agents can now automatically update the skills to the latest versions and also describe the content of Codename One GUIs. This is valuable as they review their work and don't need to use vision which is both more expensive and not as accurate. We also added the ability to check component alignment, which is often a problem that LLMs find difficult. There is also a new linter that I think we should expose to the human developers as well in the future. Right now you can see all of these tools and use them just as an agent would, but they are more CLI oriented.

PR #5168 also rebuilt the Initializr, the tool that scaffolds a new project, around the Codename One design language, and trimmed it so it is easier to approach. It leads with the essentials (main class, package, and a Java or Kotlin toggle) and tucks IDE, localization, Java version, and current settings into collapsible cards, with a live preview and a single generate bar at the bottom. The four-template picker became the Java/Kotlin toggle, and the accent, rounded-buttons, and custom-CSS controls were dropped. The project model behind it is unchanged, so generated projects are the same; this is purely about lowering the barrier to getting started.

Smaller fixes worth knowing about

Several of these came straight out of the issue-tracker pass:

cubic-bezier() motion now matches CSS. PR #5122 fixes #1524: Motion.createCubicBezierMotion was feeding its control points into a 1D polynomial directly, so the curve did not match the CSS cubic-bezier() it was modeled on. It does now so animations might act differently in some cases.
Always-tensile on the X axis. PR #5112 closes #1399, the next-oldest open issue (filed March 2015): setAlwaysTensile(true) now applies horizontally as well as vertically. This means you would see the rubber-band effect also on X axis scrolling.
Validation highlights on tap-away. PR #5123 closes #1459: a field with an invalid value is now highlighted when you tap into a different field, not only when you press the virtual keyboard's next/enter.
EncodedImage.dispose() actually frees memory. PR #5127 makes dispose() release the decoded image and the encoded bytes (it was a no-op before) and adds isDisposed(). Closes #3733.
NetworkManager.ping(). PR #5130 adds ping(url, timeoutMillis), a real server-reachability probe to pair with the device-side isConnected(). Closes #3669.
ImageViewer drag bubbling. PR #5132: a vertical drag on an ImageViewer at zoom 1 now scrolls the parent container instead of being swallowed. Closes #3700. This means you can now include many image viewers in a scrollable Y container.
Graphics.isVisible(). PR #5129 adds a clip-intersection primitive so a zoomed canvas can cull off-screen content and skip the decode/scale. Closes #3846.
Screenshot block now covers peers. PR #5107: ios.blockScreenshotsOnEnterBackground=true was hiding the render surface but leaving peer components (such as a BrowserComponent's WKWebView) visible in the app-switcher snapshot. Fixed.
Better site search. PR #5090 sorts the on-site search index newest-first and stops the giant developer-guide page from crowding out every result. We also have dates visible next to blog post results in the search and a new highlight explaining we don't search the developer guide/Javadoc.

A note on contributions

We stopped accepting community pull requests. We want to be precise about why, because it would be easy to read more into this than is there.

This is not about AI-generated PRs. We are not policing how a contribution was written.

The real reason is mechanical: our CI does not run correctly against pull requests from forks. The screenshot pipeline, the device runners, and the protocol tests all need credentials and a setup that a forked PR cannot get, so a community PR cannot actually be validated by the same gates we hold our own work to. This isn't something we can easily solve without introducing major security vulnerabilities to our process. Recently, a change that looked completely safe slipped through and triggered a CI regression that took the builds down. That was on us, not on the contributor, but it convinced us that merging code we cannot fully run is the wrong trade.

So the door is open the other way. Please keep filing issues. A clear issue with a test case is genuinely no trouble for us to pick up, and as the number above shows, we are actively working the tracker. If you have a fix in mind, describe it in the issue, attach the failing case, and we will carry it through CI ourselves.

To everyone who has sent us patches over the years, and especially the people who contributed recently: thank you. The effort was real and appreciated, and this decision is about our pipeline, not your work.

Upcoming attractions

Four deep-dive tutorials follow this one, one per day:

Saturday. Native Mac builds and deeper desktop integration. PRs #5053, #5136, #5170.
Sunday. WebSockets, gRPC, and GraphQL in the core. PRs #5133, #5099, #5141.
Monday. The new advertising API. PR #5169.
Tuesday. Background work, push topics, and richer notifications. PR #5142.

Wrapping up

We Will Not Sabotage Your Code

Shai Almog — Wed, 10 Jun 2026 14:07:54 +0000

This is a very low bar. I am genuinely saddened that I need to write it down at all, because until last week it seemed too obvious to say out loud.

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

Last week the news broke of an open source developer doing something I find reprehensible. The short version: fed up with "vibe coders," he embedded a hidden prompt aimed at AI agents inside his framework, with instructions designed to destroy data on the machines of people who used it.

So let me say it plainly, on behalf of Codename One: we will not sabotage your code. Not now, not as a protest, not ever. We won't do it for free users, we won't do it for paid users, and we won't do it if we disagree with you politically.

Why this matters

From what I have read of the relevant laws, this is likely a crime in some jurisdictions. But beyond that, as an open source maintainer, I find it deeply offensive: it is a violation of trust which I find morally reprehensible.

Trust is the greatest currency open source actually has. We spend years earning it one bug fix, one release, one honest answer on a forum at a time. When a maintainer weaponizes a dependency against the people who chose to rely on it, the damage is not contained to one project. It teaches every developer that the code they pull in might be quietly hostile, and that fear lands on all of us. We already have supply chain attacks to worry about. We do not need maintainers volunteering to become the next one.

To be clear about the principle: a maintainer can do whatever the license allows. If you do not want AI agents touching your work, that is a legitimate position. Write a license that says so it probably can't be defined as "open source" though. That's an honest choice, and it's yours to make. What this developer chose instead was sabotage dressed up as a stand, and the fact that some people find that normal, or even justified, is the part that disheartens me most.

I understand the fear

I do understand where the anger comes from.

Calling AI agents a "disruptor" is a massive understatement. Many of us will lose the jobs we have today. Things may get worse for a while before they get better. That is real, and dismissing it would be dishonest.

But we are engineers. Our entire profession is solving problems and building on top of whatever the new layer turns out to be. Lashing out at the people downstream of us is not engineering. It is the opposite of it.

Why I am optimistic anyway

The potential of AI for open source is groundbreaking, and I do not use that word lightly. Before this current generation of agents, competing with a company like Google was a fantasy. They can put 100+ developers, designers, and technical writers on the exact field we are fighting in. We could only dream of keeping pace.

I now genuinely believe we can surpass them by the end of the year.

Large organizations are going to struggle to adopt AI properly. Process, politics, risk committees, and sheer inertia will slow them down. That difficulty is precisely the opening for the small, agile player working out of the proverbial garage. For the first time, leverage is on our side.

This means reinventing yourself, again

None of this is free. The skills you need to work well with LLMs are radically different from the skills most of us built our careers on, and that adjustment is hard.

My best analogy is my own start. When I began programming there were no IDEs, no code completion, no internet to search. My biggest asset was my memory. I read everything like a sponge, I could recall every book and every subject, and I always knew where to look for an answer. That was my edge.

Then the world changed and that edge mattered less, so I reinvented myself for a newer age. I am doing it again right now, learning to work with these tools instead of against them. And I love this type of programming even more. I can focus on the stuff I enjoy, build huge ambitious tools and actually finish the work with testing and all the parts I used to hate writing.

That is the spirit I want for this community. Not sabotage. Not fear turned into payloads hidden in someone else's build. We solve problems, we build on top, and we earn trust by being the kind of people others can safely rely on.

We will not sabotage your code. We are too busy figuring out how to make it better.

Thank you for being a part of our community.