Latest posts from Codename One.
Blog
Insights, release updates, tutorials, and engineering notes from the Codename One team.
Game Builder Tutorial 3: Build a First-Person 3D Dungeon
The final tutorial takes the same data-driven pattern from Tutorial 1 and Tutorial 2 into 3D. Duke’s last adventure sends him underground: Crypt Walk, a first-person dungeon of stone corridors where the tea cups have invaded his coffee break. He hunts them through the maze and fires coffee beans to smash them, while the walls box him in. The headline difference from the 2D tutorial is what happens at runtime — instead of sprites in a Scene, each element becomes a GPU-rendered Model under a perspective camera with lighting. You author the same way; the runtime renders it in 3D. ...
Game Builder Tutorial 2: Build a Blackjack Card Game (Duke Jack)
In Tutorial 1 Duke dashed for coffee with arcade physics. Now he sets the cup down for a calmer contest: Duke Jack, a game of blackjack. A card game has none of that arcade motion — cards sit on the felt and the rules decide who wins. This tutorial shows how the same Game Builder pattern (visual data + an onUpdate companion) handles a card game, where your code reads the cards and runs the table instead of simulating movement. We’ll build a felt table, deal a real hand, and wire up the complete blackjack rules: hit, stand, the dealer’s draw, and the win/lose decision. ...
Game Builder Tutorial 1: Build a 2D Platformer — Duke's Coffee Run
Most game tutorials make you hand-place every sprite in code. The Game Builder flips that around: you draw the level visually, tag objects with the numbers your game needs (lives, value, speed), and the editor saves it as a small data file that the runtime plays. Your code shrinks to the part that’s actually yours — the rules. This is the first of three tutorials. We’ll build Duke’s Coffee Run: a side-scroller where Java’s mascot Duke dashes right across a grassy floor, collects coffee cups for points, dodges roaming exception monsters, and reaches a flag to win. Along the way we’ll do the part most tutorials quietly skip — bringing in real art, including slicing an animated sprite sheet for Duke. By the end you’ll have a running game and understand every moving part: the assets, the level file, the generated companion class, the built-in arcade behavior, and where your own logic goes. Tutorials 2 (board game) and 3 (3D dungeon) continue the story. ...
The Codename One Game Builder: Draw The Level, Code The Rules
Friday’s release post introduced the Game Builder and promised a tutorial series. This post is the orientation that sits in front of those tutorials: what the Game Builder is, how its pieces fit together, and why it exists. The hands-on builds start Thursday. Last week we shipped the com.codename1.gaming API: a game loop, sprites, scenes, pollable input, a low-latency sound pool, and Box2D physics, all running unchanged on every platform including iOS. That gave you the runtime. The missing half was authoring. Building a level purely in Java means dozens of new Sprite(...), setX, and setY calls you cannot see until you run them and must recompile to tweak. The Game Builder (PR #5253) replaces that with a visual editor and a plain-data level file. ...
Seamless Crash Protection That Symbolicates Native Crashes
Friday’s release post introduced the new crash-protection system. This post is the detailed version: why it exists, what it does on the device, and how to turn it on. The motivation is portability. Every port we add widens the set of platforms an app can break on, and testing across all of them by hand does not scale. The old crash-protection tool emailed you a stack trace; that worked, but it did not symbolicate native crashes, and a busy app could bury you in mail. The new com.codename1.crash package replaces it with something seamless, and the seam it removes is the work you used to do yourself. ...
Just Watch
Friday’s release post announced wearable support. This post covers both wearables in detail: how watchOS works, how Wear OS differs, and the small amount of code you write to reach either one. Why a watch API at all Apple sees watch programming as a completely separate discipline from phone or desktop programming. It is a different API with a different logic, and that makes some sense given the device. The consequence is that several UI metaphors we take for granted are impractical or absent: there is no text field in the form you expect, and no browser. So it is fair to ask what the point of a watch API even is. ...
Java To Native Linux App: One 5MB Binary, x64 And Arm
Yesterday’s release post introduced the new native Linux desktop port. This post is the detailed version: what it is, why the hard parts were hard, and how to build one. The Linux port is the structural twin of the native Windows port from last week. It is the same idea the iOS port has used for years: ParparVM translates your Java and Kotlin bytecode to C, and the C is compiled and linked into a native binary. On Linux that binary is a single self-contained ELF. There is no JVM on the user’s machine, none bundled, none downloaded, and none required. ...
Native Linux, Apple Watch, A Game Builder And Crash Protection
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. ...
Print Anywhere, And Put Your Cards In Apple Wallet
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. 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. ...
Java To A Native Windows EXE: No JVM, 5MB, x64 And Arm
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. ...
Build Games In Java: Sprites, Box2D Physics And Low-Latency Sound
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. ...
3D Graphics Without Writing Shaders: The Portable GPU API
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. ...