A tab bar can look right in a screenshot and feel wrong the first time you tap it. Its selection moves, stretches, samples the content underneath, and settles. A still image catches one moment in that process.

Alongside that rendering work, we’re bringing back an option long-time Codename One users will remember: choosing the Xcode version on our build servers. It follows last week’s build migration. We have separate iOS 26 and 27 theme generations, revised glass materials, and a closer look at the tab-selection animation. We also have local iPhone Duo support, with a different validation boundary from the ordinary iOS 27 CI runs.

Xcode Selection Is Back

You can ask the cloud build service to use Xcode 27 now. In the Settings app, under Build Hints, add:

ios.xcode_version=27

If you’ve been using Codename One for a while, this might look familiar. We supported Xcode selection in the past, then discontinued it because Apple’s Xcode upgrades kept forcing us to upgrade macOS too. With Xcode 27, that OS upgrade isn’t required yet. We can use virtualization to make both versions available again.

The current default is Xcode 26. We recommend leaving ios.xcode_version unset for most apps. The hint is mainly for testing against a newer toolchain, or for using a specific feature that needs the new SDK. There is no need to set it just to keep your app up to date with the build service.

Xcode 27.1 is still a beta. We’ll add it when it’s released, and we’ll switch the default to Xcode 27 when Apple’s requirements call for it. Leaving the hint unset lets your builds follow that default.

Choose the Theme Separately

Set these values in the Settings app under Build Hints:

ios.themeMode=modern
ios.themeGeneration=27

If you want native themes across platforms, use the shared hint instead of ios.themeMode:

nativeTheme=native
ios.themeGeneration=27

On iOS, that selects the modern family. It also enables the desktop platform themes, which nativeTheme=modern deliberately leaves unchanged. An explicit ios.themeMode takes precedence over the shared setting. See the theme selection in the iOS builder.

Setting What it chooses What leaving it unset means ios.themeMode The iOS theme family, overriding the shared hint Follows nativeTheme; with neither set, keeps the existing iOS 7 theme ios.themeGeneration Generation 26 or 27 of the modern family Generation 26 ios.xcode_version A toolchain on the cloud build service Xcode 26, the current service default

The generation hint is consulted only for the modern theme. An older theme doesn’t turn modern because you set 27 beside it.

An explicit Xcode version must exist on the server handling the cloud build. An unavailable version fails instead of silently substituting another SDK. This is a server selection hint; it doesn’t install Xcode or change a local build. The hint definition documents that distinction.

Local Builds Use Your Xcode Installation

For a local build on a Mac with Xcode 27 installed, select that installation for the build process. For example, with the application at /Applications/Xcode27.app:

DEVELOPER_DIR=/Applications/Xcode27.app/Contents/Developer \
  mvn cn1:buildIosXcodeProject

Use the same installation when building and running the generated project. The CI screenshot workflow and fidelity workflow now have Xcode 27 legs alongside the existing generation. A workflow entry proves what is configured; the result of a particular run still matters.

Dark glass needs an edge

A blur softens the backdrop. It doesn’t by itself make a dark floating surface distinguishable from the dark content behind it.

The iOS 27 rendering work adjusts the luminance curve and adds the dark outline visible around the native floating material. We group the material settings into recipes: chrome for edge bars, pill for the floating tab surface, and panel for panels and buttons. A UIID selects the appropriate recipe instead of independently tuning a pile of glass constants.

The theme sources are split into common rules and generation-specific rules. That keeps ordinary controls shared while allowing the glass treatment to change. It also gives your own CSS the same place to override the result.

See the Glass in Motion

The selection stretches as it moves between tabs. The backdrop and edge treatment have to remain readable throughout that movement, including against dark content:

Codename One’s iOS renderer on an iPhone 16 simulator running iOS 27.0. These are deterministic samples across the theme’s 480 ms animation, with holds before and after. The clip shows the rendered motion; it isn’t a live frame-rate measurement.

We use fixed samples to catch rendering regressions while changing the glass recipes. There is still work to do on fidelity, and a short animation can’t tell you how the theme will behave over all of your app’s content. Try it over images, scrolling lists, and your own brand colors before adopting it.

PR #5888 refines the dark rendering and animation tests; PR #5876 connects the selected generation through to the device theme.

A closed foldable still has a hinge

The Duo work exposed a useful trap. A closed device can report no dividing screen region while still reporting a live, closed hinge. If you identify foldables only by looking for a region that divides the screen, the device stops being a foldable precisely when it folds shut.

The iOS bridge uses hinge state as well as division regions. It also distinguishes a fold from an occlusion such as the camera housing. The public Java API stays DevicePosture:

import com.codename1.ui.CN;
import com.codename1.ui.DevicePosture;
 
DevicePosture posture = CN.getDevicePosture();
if (posture.isFoldable()) {
    int angle = posture.getHingeAngle(); // Degrees; -1 means unknown.
    int state = posture.getPosture();
    // Choose the layout for this state, then observe later posture changes.
}

For a top-and-bottom layout, also check that getFoldOrientation() is FOLD_ORIENTATION_HORIZONTAL. A partially open book posture needs a different layout. Keep important controls outside getFoldBounds(null) when a separating region exists.

Local capture of the installed HelloCodenameOne instrumentation app in the Duo simulator, including the simulator device frame. This shows the app running on the beta device profile. It is not a fold-transition test or a demonstration of the new glass theme.

Duo support has been tested locally with the iOS 27.1 beta simulator. It has not been validated on shipping Duo hardware. Hinge support requires the iOS 27.1 SDK at compile time as well as a supporting runtime. The bridge checks for UIKit/UIHingeInteraction.h before compiling the implementation, then checks runtime availability before calling it. The cloud's Xcode 27.0 toolchain does not include that header, so ios.xcode_version=27 builds contain no hinge implementation, even if installed on iOS 27.1. For now, testing the hinge API requires a local build with the Xcode 27.1 beta. We expect the path to carry forward when the SDK is released, but that still needs a release-SDK and device check. The bridge source and PR #5871 show the boundary.

Health data needs the same precision

The Health API adds HealthDataType.HEART_RATE_VARIABILITY_RMSSD. RMSSD and SDNN are different heart-rate variability statistics. The API doesn't substitute one for the other when a platform lacks the requested type.

RMSSD on iOS requires both the iOS 27 SDK at build time and a supporting runtime. An older combination reports TYPE_NOT_SUPPORTED. Android Health Connect has RMSSD, while SDNN is unsupported there. That is API interoperability, not an assertion that two different measurements can be compared as if they were the same. The Health guide explains the mapping.

One iOS renderer to maintain

We removed the OpenGL ES renderer in PR #5875. Metal now handles iOS rendering. Remove ios.metal from old projects; the hint that previously selected the rendering path is no longer valid.

That removes a deprecated path from the compiler output and from our maintenance work. We aren’t attaching an unmeasured build-speed number to it. The practical benefit is that the renderer receiving these glass fixes is also the renderer our iOS builds use.

Start with a copy of a screen you know well. Build against the selected Xcode installation, enable generation 27, and check light and dark appearances while interacting with it. Then test your branded overrides and any embedded native peers. The weekly overview explains the wider release; tomorrow we move from UI state to managed database state.

iOS 27 Glass You Can Choose, Measure, and Test was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

Apple’s design team doesn’t know what’s on your backlog. A new iOS appearance might be exactly what you want for your next release. It might also arrive halfway through a customer rollout, when changing the navigation is the last thing you need.

We want to support the new SDK without making that decision for you. This week, you can select Xcode 27 on our build servers with the returning ios.xcode_version hint. Local builds and CI also support Xcode 27, and our iOS 27 theme gets more detailed Liquid Glass effects. You choose when to adopt that appearance. Codename One renders most controls itself, so the theme ships with your app. Updating the SDK can leave that theme and your application CSS in place.

Last week we covered the build settings needed for Xcode 27. This week we’ll show the glass in motion, explain the theme switches, and take a first look at the foldable Duo in the simulator. There is substantial work beyond iOS, too. The JPA inspired ORM is probably the biggest addition: relationships and managed sessions now work in both the app and the backend. OpenTelemetry and WebSocket support give that backend more of what a real service needs.

Coming This Week

We’ll cover the release in six follow-ups, with code you can try and screenshots of the UI changes:

• Saturday, September 26: . Try Xcode 27 with the returning build hint, choose your theme independently, and see the glass animation and Duo simulator work.
• Sunday, September 27: . Model relationships, update managed objects, fetch the data a screen needs, and handle conflicting writes.
• Monday, September 28: . Connect app and backend spans with OpenTelemetry and send them to your existing tracing infrastructure.
• Tuesday, September 29: . Add persistent, two-way connections to your app. Our device-test screenshot receiver shows the server handling real traffic.
• Wednesday, September 30: . Receive signed delivery digests and remove invalid targets without deleting devices after temporary failures.
• Thursday, October 1: . Use Fluent, Aqua, or Adwaita with desktop dialogs and title bars. See them in our Settings app, then apply them to yours.

Xcode Selection Is Back

Long-time Codename One users might recognize this hint. In the Settings app, under Build Hints, you can now select Xcode 27 on the cloud build service:

ios.xcode_version=27

We discontinued Xcode selection because Apple’s upgrades kept requiring a macOS upgrade too. That isn’t required for 27 yet, and virtualization lets us offer the choice again. Xcode 26 remains the default. Leave the hint unset unless you’re testing or need a new SDK feature. We’ll add 27.1 after beta and move the default to 27 according to Apple’s requirements.

This hint only affects cloud builds. Local builds use the Xcode installation selected on your Mac. The theme is a separate choice: ios.themeMode=modern or the shared nativeTheme=native selects the modern family, and ios.themeGeneration=27 selects its iOS 27 appearance.

Deterministic samples of Codename One’s 480 ms tab-selection animation on an iPhone 16 simulator running iOS 27.0. The animation shows rendered motion, not a live frame-rate measurement.

Saturday’s follow-up covers the build and theme settings, refined glass materials, Health API changes, and local Duo testing. . Duo hinge support needs a local Xcode 27.1 beta build; the cloud’s Xcode 27.0 SDK doesn’t contain the hinge API.

We also removed OpenGL ES. Metal is now the iOS renderer, and old projects should remove the obsolete ios.metal hint. Dropping that deprecated path removes compiler warnings and lets us concentrate rendering work on Metal. See PR #5875.

JPA Inspired ORM

Last week’s backend tutorial used explicit foreign-key fields and immediate DAO writes. The new managed ORM adds relationships and a session that tracks the objects involved in one unit of work. The same mapping annotations work with client SQLite and the backend databases.

Session session = entities.openSession();
try {
    session.beginTransaction();
    Customer customer = session.find(Customer.class, customerId);
    if (customer != null) {
        customer.name = "Updated name";
    }
    session.commitTransaction();
} finally {
    session.close();
}

Here entities is an EntityManager, Customer is a mapped entity, and customerId identifies the row. The session detects the changed field and writes it at flush time. Closing the session never commits unfinished work.

Relationships, lazy loading, version checks, and a supported JPQL subset make this a much larger change than another query convenience method. They also introduce choices a tutorial needs to explain: which side owns a relationship, when a query loads it, and what happens after the session closes. Sunday’s article works through those choices. This is a JPA-inspired API, with its own packages and documented limits, rather than a claim of complete JPA compatibility. See PR #5885.

OpenTelemetry Support

A slow screen can be waiting for the network, the service, or one database query. A server log alone can’t show where the user spent that time.

Our new OpenTelemetry integration connects the app’s network requests to backend request and database spans. A span records one operation; related spans form a trace. An annotation enables the instrumentation, and the spans use the standard OTLP transport to reach a collector.

That is useful for a team introducing a small service into a large organization. The new service can participate in the tracing system the operations team already uses. It doesn’t need its own isolated diagnostic UI. Monday’s article covers collector configuration, sampling, the app relay, and the exact instrumentation boundary in PR #5887.

WebSocket Support

Your backend can now keep a connection open and send data when it changes. Live status screens, chat, and progress updates can use WebSockets instead of repeatedly polling an HTTP endpoint. Register a Java endpoint with @WebSocketMapping, then handle text and binary messages through the backend API.

We use the same implementation to receive screenshots from our device tests. Metadata arrives as text, the image arrives as binary, and the server acknowledges the saved image before the device continues. That gives the public API a regular workload in our CI: a lost message can interrupt a test run we depend on.

Tuesday’s article includes a complete endpoint and explains connection limits, timeouts, and how slow clients affect sending. It also follows the screenshot receiver from PR #5880, including the legacy Windows test path that still uses the earlier server.

Push Delivery Callbacks

The cloud accepting a push request doesn’t mean the provider accepted every target. Delivery feedback gives your backend the later results in a signed daily digest. It is an organization-level setting on Pro and above.

The decision worth automating is narrow: remove a key after INVALID_TARGET. A temporary provider failure can exhaust its retry budget while the key remains valid. Wednesday's article shows how to verify the digest, deduplicate on deliveryId, and acknowledge only after database writes commit. The examples in PR #5890 cover the CN1 backend, Spring, MicroProfile, and Node/serverless JavaScript.

Native Desktop Themes for Production Apps

Last week’s native desktop themes were an experiment. This release brings them into production use, with refined controls, light and dark appearances, and desktop window behavior integrated into the themes. Your app can select Fluent on Windows, Aqua on macOS, or Adwaita on Linux while keeping its own branding.

We’ve adopted them in the Codename One Settings tool. Its forms and dialogs helped us find and fix the details that isolated component screenshots missed.

The Settings tool with the Aqua theme, captured on macOS. Thursday’s article includes all three theme families in light and dark appearances.

The change reaches the window as well as the controls. Desktop native themes open ordinary dialogs in real OS windows. Packaged JavaSE apps use native title bars with all three themes by default; the simulator can instead use the title-bar style declared by the theme. Existing projects still choose whether to adopt these themes. PR #5886 shows the application work that exposed and helped refine the defaults.

Shorten the trip from documentation to a running device

Two smaller changes make the rest easier to investigate.

The generated agent skill now explains the native-device debugger and MCP workflows. An agent can inspect and operate the running app through semantic UI tools, while a debugger handles breakpoints and stack inspection. For an MCP-only iOS session, ios.onDeviceDebug.waitForAttach must be false: otherwise the application waits before start() and never opens its MCP listener. Physical iPhones also need a USB relay for that loopback port. The on-device reference includes the commands and platform limits from PR #5864.

The Developer Guide now has chapter pages with site search, navigation, and links to individual sections. The single-page edition is still available. Following last week’s Javadoc work, guide links can take you to the relevant chapter instead of dropping you into the whole book. Both views come from the same AsciiDoc sources. PR #5860 contains the generator and compatibility routing.

Put the Next Release on Your Schedule

Supporting Xcode 27 is our job. Deciding when your app should look different belongs to you. The theme settings let you keep those decisions separate, whether you’re trying Liquid Glass on iOS or adopting a desktop theme for an app that started on a phone.

There’s plenty to use here even if you’re leaving the UI alone. A screen that edits related records can use a managed ORM session. A status screen can receive WebSocket updates. When a request is slow, OpenTelemetry can show which service or query needs attention. Those are changes you can put to work on the features already in your backlog.

Tomorrow we’ll start with the iOS changes, including the code to select a theme and the Duo simulator capture. Then we’ll spend the rest of the week working through the data, service, and desktop features in detail.

Apple Shouldn’t Dictate Your App’s Redesign Schedule was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

Changing a customer’s name should not require remembering which DAO to call after every assignment. Loading twenty orders should not accidentally fetch each customer’s entire history. Those are the kinds of problems that appear once an application grows beyond a few independent tables.

Last week’s ORM example introduced shared entities and generated DAOs. This release adds a managed session: an object that keeps track of the entities involved in one unit of work, detects their changes, and coordinates persistence. Relationships now belong in the model too.

The client and backend use the same mapping annotations. The client stores data in SQLite; the backend supports SQLite, PostgreSQL, MySQL, and MariaDB. This is a JPA-inspired layer, not a JPA provider or a way to run arbitrary Hibernate code unchanged.

Model a customer and their orders

These are two separate source files in the same package. Existing Entity and Id annotations stay in com.codename1.annotations; the new relationship and version annotations live in com.codename1.annotations.db.

// Customer.java
package com.example.model;
 
import com.codename1.annotations.Entity;
import com.codename1.annotations.Id;
import com.codename1.annotations.db.OneToMany;
import com.codename1.annotations.db.Version;
import java.util.ArrayList;
import java.util.List;
 
@Entity(table = "customers")
public class Customer {
    @Id public long id;
    @Version public long version;
    public String name;
 
    @OneToMany(mappedBy = "customer")
    public List<Order> orders = new ArrayList<Order>();
}

// Order.java
package com.example.model;
 
import com.codename1.annotations.Entity;
import com.codename1.annotations.Id;
import com.codename1.annotations.db.JoinColumn;
import com.codename1.annotations.db.ManyToOne;
 
@Entity(table = "purchase_orders")
public class Order {
    @Id public long id;
 
    @ManyToOne
    @JoinColumn(name = "customer_id")
    public Customer customer;
 
    public long totalCents;
}

Order.customer owns the foreign key. Customer.orders describes the other direction through mappedBy. Application code maintains both sides when it changes the in-memory relationship:

order.customer = customer;
customer.orders.add(order);

Those two assignments describe one relationship from two viewpoints. They don’t persist either object on their own. This mapping doesn’t request cascading, so the transaction below explicitly persists both.

Commit the unit of work

On the client, import com.codename1.orm.EntityManager. On the backend, use com.codename1.backend.orm.EntityManager. Both expose openSession() and the shared com.codename1.orm.session.Session interface.

For a development database, call session.createTables() before beginning a transaction to create missing mapped tables. Production schema changes belong in your migration process.

The following code takes an entity manager named entities, with the schema already created:

import com.codename1.orm.session.Session;
 
Session session = entities.openSession();
try {
    session.beginTransaction();
 
    Customer customer = new Customer();
    customer.name = "Alice";
    session.persist(customer);
 
    Order order = new Order();
    order.customer = customer;
    order.totalCents = 4900;
    customer.orders.add(order);
    session.persist(order);
 
    session.commitTransaction();
} finally {
    session.close();
}

The build generates metadata and enhances entity access. The session uses that metadata to manage the object graph without runtime reflection or proxy generation. Generated IDs are filled in as inserts occur.

Closing a session rolls back an active transaction. It never commits. That makes the finally block meaningful when an insert or commit fails. A session belongs to one thread and one unit of work; don't put it in a shared backend controller field. A pooled backend entity manager can be shared while each request opens its own session.

The session keeps one object instance per entity identity. Finding the same row twice within that session gives application code one managed object to work with. Updating customer.name changes that object; a flush detects the difference and issues the update. Queries inside a transaction flush pending changes too, so a query can trigger database writes before your explicit commit.

Fetch the screen you intend to show

A relationship is also a loading decision. To-one mappings default to eager loading; to-many mappings default to lazy loading. You can override either default.

This query selects at most twenty customers and loads their otherwise-lazy order collections before returning:

List<Customer> customers = session.query(Customer.class)
        .eq("name", "Alice")
        .orderBy("id", true)
        .limit(20)
        .fetch("orders")
        .list();

Without .fetch("orders"), these collections remain unloaded until accessed inside the session. The eager Order.customer mapping would not demonstrate that difference.

The query uses Java field paths. The ORM resolves them into the SQL joins and parameters for the database in use. Pagination applies to the root entities before fetched collections are loaded.

A direct to-one fetch with a single-column key can be batched. So can an inverse foreign-key collection fetch in that case. Ordered, map, composite-key, and join-table collections currently use individual loaders. An ORM doesn’t make query count irrelevant; inspect the access pattern for the mapping you actually use.

To load a relationship deliberately before leaving the session:

Customer customer = session.find(Customer.class, customerId);
if (customer != null && !session.isLoaded(customer, "orders")) {
    session.initialize(customer, "orders");
}

An unloaded relationship read after detachment or session close throws LazyInitializationException. Already-loaded data remains readable. Generated @Mapped serialization also refuses an unloaded association instead of quietly fetching it during output. Load what the response needs, or map to a smaller response object while the session is open.

On a phone, do this work off the event dispatch thread (EDT). Fetching is synchronous. The UI should receive ready data, not discover a database trip while painting or handling a tap.

Query in the vocabulary of the model

The supported JPQL subset gives more complex queries a familiar form:

List<Order> orders = session.createQuery(
        "select o from Order o "
        + "where o.customer.name = :name order by o.id",
        Order.class)
        .setParameter("name", "Alice")
        .list();

It includes relationship joins, named parameters, scalar projections, aggregates, grouping and HAVING, plus supported nested queries and bulk mutations. Unsupported syntax is rejected. It is deliberately described as a subset; a query accepted by another persistence provider still needs to fit this implementation.

Bound parameters carry values into SQL. They don’t make a field name supplied by an untrusted caller safe to use as a query structure. Keep the query shape under application control.

Bulk update and delete operations need a transaction. They flush pending changes, bypass per-entity callbacks and cascades, then clear the persistence context so later reads don’t reuse stale objects. Use them when you intend those semantics, not as a shorter spelling of a per-entity operation.

Detect the edit that happened elsewhere

Customer.version is an optimistic-lock field. An update checks the previous version, and a conflicting update or deletion produces OptimisticLockException.

Imagine two administrators opening the same customer. Both start with version 4. The first saves an edit and advances the version. The second cannot quietly overwrite that newer row with a change based on version 4.

The application still decides what the user should do next: reload, compare changes, or retry an operation that is safe to repeat. After an optimistic-lock or database failure, roll back an active transaction before continuing. isTransactionActive() lets you check whether the underlying transaction is still open.

A detached object has another important rule: session.merge(detached) returns the managed copy. Keep that return value. Calling merge doesn't attach the object you passed in.

How much of JPA does this bring?

The new layer includes all four relationship kinds, cascades, orphan removal, composite assigned IDs, generated ID strategies, embedded values, converters, lifecycle callbacks, and supported inheritance mappings. That is a substantial step beyond scalar DAOs.

The old scalar DAO API still writes immediately. Models using managed features require a session; asking the legacy DAO to handle them fails rather than silently losing relationship or version behavior. Production schema migration remains a deployment responsibility. Shared entity definitions also do not synchronize a phone database with a server database or resolve offline conflicts for you.

Start with one relationship and one explicit transaction. Check what gets loaded before adding more cascading or fetch behavior. The ORM guide lists the supported mappings and query restrictions, and PR #5885 contains the implementation. Tomorrow’s explains how to see the backend’s database work inside a request trace.

JPA Inspired ORM from SQLite to PostgreSQL was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

Your server sends a push request and gets a successful response. Somewhere in the target list is a device key that stopped working weeks ago. The response can’t identify it because the provider hasn’t answered yet.

BuildCloud now sends delivery feedback to your backend. It closes the gap between admitting the request and learning what happened during provider delivery, so your own device database can stop retaining keys that the provider has rejected.

The feedback is a signed daily digest, configured per organization on Pro and above. It isn’t an immediate webhook for every notification, and provider acceptance isn’t proof that a device displayed or a person read the message.

Configure the return path

In the Console, open Push > Settings > Delivery feedback. Set an HTTPS endpoint, enable the daily digest, and use Send test event to exercise the receiver. The card supplies the signing secret and reports what the endpoint returned.

The setting belongs to the organization, so a digest can contain outcomes for several applications. Store the deliveryId returned by a v3 send alongside the application and target you sent to. Classic sends don't return that ID, so their correlation uses the device key.

A successful send response is an admission result. The later digest describes provider outcomes. Keeping those two stages separate prevents a successful HTTP request from becoming a misleading “delivered” label in your own administration UI.

Delete on the reason, not the status

The digest itemizes failures and summarizes accepted deliveries. This shortened example shows the part a cleanup handler needs:

{
  "deliveryId": "6f0f6f1e-9a1e-4f2a-9a7a-6d5f5f6a1b02",
  "provider": "fcm",
  "token": "example-device-token",
  "status": "FAILED",
  "reason": "INVALID_TARGET",
  "attempts": 1
}

Reason What your device store should do INVALID_TARGET Remove the rejected key PERMANENT_FAILURE Keep the key; investigate the message or credentials TRANSIENT_FAILURE Keep the key; attempts were exhausted, but the target may still work

A transient failure can have status: "DEAD". That describes the exhausted delivery job. It doesn't establish that the device key is dead.

Match the Key Your App Actually Stored

Push.getPushKey() returns a full key such as cn1-fcm-example-device-token. The digest's token is only example-device-token. Comparing those strings deletes nothing. Matching device alone also misses legacy cn1-gcm- keys because the digest uses the canonical cn1-fcm- spelling.

Keep the original key for sending, and store a normalized provider and target alongside it. This registration helper handles Android and Apple mobile keys:

function mobileTarget(pushKey) {
  const match = /^cn1-(gcm|fcm|ios|apns)-(.+)$/.exec(pushKey);
  if (!match) throw new Error('Expected an Android or Apple push key');
  const provider = {gcm: 'fcm', ios: 'apns'}[match[1]] || match[1];
  return {provider, target: match[2], pushKey};
}

Both cn1-gcm-abc and cn1-fcm-abc now match feedback for provider fcm, token abc. Apple keys with the ios prefix match provider apns. For web push, store the subscription's endpoint separately from its key material; don't treat the whole cn1-web-... key as an endpoint.

Backfill these normalized columns for existing registrations before enabling cleanup. The examples below expect that schema. Scope lookups to the organization receiving the digest, and use both provider and target so identical strings from different providers don’t collide.

Verify before interpreting the body

The request carries:

X-CN1-Signature: t=<unix-millis>,v1=<hex>

The signature is HMAC-SHA256 over the timestamp, a period, and the raw body bytes. Use the secret from the Settings card, compare the MAC in constant time, and reject timestamps outside your allowed age window. Do not parse JSON and serialize it again before verification; whitespace and field ordering can change the signed bytes.

For the Codename One backend, the guide includes a complete Java receiver. It uses the raw HttpServer.Request, Crypto.hmacSha256, and Crypto.equalsConstantTime, so it also fits native backend packaging. Its device store is an application-supplied interface, not an automatically provisioned database.

After verification, a CN1 backend receiver can apply each failure like this:

// Inside the loop over the verified digest's event maps.
if (!"INVALID_TARGET".equals(event.get("reason"))) {
    continue;
}
String provider = (String) event.get("provider");
String target = (String) event.get("token");
if (target == null || target.length() == 0) {
    target = (String) event.get("endpoint");
}
if (provider == null || provider.length() == 0
        || target == null || target.length() == 0) {
    throw new IllegalArgumentException("Missing push target");
}
String deliveryId = (String) event.get("deliveryId");
String eventKey;
if (deliveryId != null && deliveryId.length() > 0) {
    eventKey = "delivery:" + deliveryId;
} else {
    Object at = event.get("at");
    if (at == null) {
        throw new IllegalArgumentException("Missing classic event timestamp");
    }
    eventKey = "classic:" + provider + ":" + target.length()
            + ":" + target + ":" + at;
}
if (!store.alreadyApplied(eventKey)) {
    store.removeTargetAndMarkApplied(eventKey, provider, target);
}

Here store is an organization-scoped durable store with alreadyApplied(eventKey) and removeTargetAndMarkApplied(eventKey, provider, target) methods. The latter deletes by the normalized columns and writes the marker in one transaction. It must enforce a unique event key even if two requests pass the initial check concurrently.

The fallback key includes the provider, target, and event timestamp. It handles classic events without a deliveryId, distinguishes devices, and lets a later event for the same target be processed. A missing target or timestamp fails the request instead of acknowledging an event we couldn't correlate.

If a device has since registered a replacement key, remove the rejected key associated with the event. Don’t translate an old failure into “delete whatever key this user has now.”

Acknowledge after the database commits

Delivery is at-least-once. A lost HTTP response can cause a digest to arrive again even after you processed it.

Only a 2xx response advances the sender’s watermark. Return it after your writes are durable. If you return success first and the database write then fails, the acknowledged window won’t be resent. If the database commits and the response gets lost, the durable event-key marker lets the retry do nothing safely.

A digest has a size cap. truncated: true means another page follows in the same run, so the receiver must handle several requests close together. eventsOmitted counts accepted deliveries included only in the summary. It doesn't mean a set of unreported failure events has been lost.

A failing receiver is retried and eventually disabled after repeated failures. Check the reason on the Settings card and exercise the test event after fixing the endpoint. A receiver that has quietly stopped accepting feedback won’t keep your database clean.

Use the backend you already run

The push guide includes CN1 backend, Spring, MicroProfile, and Node/serverless receiver examples. PHP and other stacks can implement the same signed JSON contract, but the guide doesn’t include a PHP receiver.

Here is the equivalent event-key helper for Node:

function cleanupTarget(event) {
  const provider = event.provider;
  const target = event.token || event.endpoint;
  if (typeof provider !== 'string' || !provider
      || typeof target !== 'string' || !target) {
    throw new Error('Missing push target');
  }
  let eventKey;
  if (typeof event.deliveryId === 'string' && event.deliveryId) {
    eventKey = `delivery:${event.deliveryId}`;
  } else {
    if (!Number.isSafeInteger(event.at)) {
      throw new Error('Missing classic event timestamp');
    }
    eventKey = `classic:${provider}:${target.length}:${target}:${event.at}`;
  }
  return {eventKey, provider, target};
}

For a concrete durable store, this Node example uses the built-in node:sqlite module. Run it on a Node version that provides that module. The devices table holds the normalized registration described above; populate it as devices register, and migrate existing keys before turning on the receiver.

const {DatabaseSync} = require('node:sqlite');
const db = new DatabaseSync('push-feedback.sqlite');
db.exec(`
  CREATE TABLE IF NOT EXISTS devices (
    organization TEXT NOT NULL,
    provider TEXT NOT NULL,
    target TEXT NOT NULL,
    push_key TEXT NOT NULL,
    PRIMARY KEY (organization, provider, target)
  );
  CREATE TABLE IF NOT EXISTS applied_feedback (
    organization TEXT NOT NULL,
    event_key TEXT NOT NULL,
    PRIMARY KEY (organization, event_key)
  );
`);
 
function applyInvalidTarget(organization, event) {
  if (event.reason !== 'INVALID_TARGET') return;
  const {eventKey, provider, target} = cleanupTarget(event);
  db.exec('BEGIN IMMEDIATE');
  try {
    const marker = db.prepare(`
      INSERT OR IGNORE INTO applied_feedback (organization, event_key)
      VALUES (?, ?)
    `).run(organization, eventKey);
    if (marker.changes) {
      db.prepare(`
        DELETE FROM devices
        WHERE organization = ? AND provider = ? AND target = ?
      `).run(organization, provider, target);
    }
    db.exec('COMMIT');
  } catch (error) {
    db.exec('ROLLBACK');
    throw error;
  }
}

Use the configured organization’s ID after verifying the digest signature. Process its events through applyInvalidTarget, then return 2xx. On a database error, return a non-2xx response so the digest can be retried. The marker and deletion share a transaction: a failed deletion rolls the marker back too. A serverless deployment needs durable storage outside an ephemeral function filesystem; the local SQLite file above is for a server with persistent storage.

PR #5890 adds those examples and documents the contract. Start with the test event, then send the same valid digest to your test receiver twice. Confirm that both requests get an appropriate response and only one durable cleanup operation occurs. Also test a failed database write: that request must not acknowledge a window it failed to apply.

Your Push Request Succeeded. The Device Key Is Dead. was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

A desktop app needs more than larger versions of its phone controls. Dialogs need their own windows. Title bars, scrollbars, and keyboard focus need to behave as desktop users expect.

Last week we introduced the native desktop theme experiment. This week we bring those themes into production use. Fluent, Aqua, and Adwaita include refined controls in light and dark appearances, plus the window and dialog defaults that go with them. Your application can inherit those styles and retain its own branding.

The Codename One Settings tool now uses them too. Its main class selects @DesktopBuild(themeMode = "native"), choosing Fluent on Windows, Aqua on macOS, and Adwaita on Linux. Working through its forms and dialogs gave us concrete problems to fix in the themes. The screenshots below show the result, followed by the settings and CSS you can use in your own app.

See the same application in each theme

These are repository captures of the real Settings application. All six were made on a Mac. They show theme colors, borders, spacing, and light/dark styling. Fluent and Adwaita fall back to the Mac’s font in these captures; they are not screenshots of the application running on Windows or Linux. The respective platform fonts change the text on those hosts.

Fluent

Aqua

Adwaita

The captures come from the native-theme guide. Their value is the complete screen: the theme has to make the relationships among controls readable, rather than make one isolated button resemble a reference tile.

Opt in without repainting every control

For a JavaSE desktop build, set this in the Settings app under Build Hints:

desktop.themeMode=native

native and auto select the host's theme. An explicit fluent, aqua, or adwaita selects that family even on another host. Unset remains legacy, preserving existing applications. On the separate native macOS port, Aqua is already the default when neither macos.themeMode nor the shared nativeTheme hint is set. You can select it explicitly with:

macos.themeMode=native

An explicit shared theme setting still applies: for example, nativeTheme=modern selects the iOS-style modern theme on this port. JavaSE desktop and native macOS are separate ports with different defaults.

In the simulator, select the Desktop skin, then choose a theme from Native Theme. With Auto, the Desktop skin follows desktop.themeMode, matching the packaged application's choice.

Inherit the role and override the brand

A custom UIID should begin with the native UIID whose behavior it refines. For example, in your application’s theme.css:

/* Compiler fallbacks. Native theme palette values replace these at runtime. */
Container {
    --text-secondary-color: #5D5D5D;
    --text-secondary-color-dark: #CFCFCF;
}
 
ProjectNameField {
    cn1-derive: TextField;
}
 
ProjectPrimaryAction {
    cn1-derive: RaisedButton;
}
 
ProjectCard {
    cn1-derive: GroupBox;
}
 
ProjectHelp {
    cn1-derive: Label;
    color: var(--text-secondary-color);
}
 
@media (prefers-color-scheme: dark) {
    ProjectHelp {
        color: var(--text-secondary-color-dark);
    }
}
 
#Constants {
    includeNativeBool: true;
    --accent-color: #00796B;
    --accent-color-dark: #4DB6AC;
    --accent-fg-color: #FFFFFF;
    --accent-fg-color-dark: #102522;
    --accent-pressed-color: #00695C;
    --accent-pressed-color-dark: #26A69A;
    --selection-color: #00796B;
    --selection-color-dark: #4DB6AC;
}

The Container declarations give the CSS compiler concrete values for var(). Keep these palette fallbacks outside #Constants: the compiler records their bindings, and the installed native theme supplies the runtime colors. Exporting the fallbacks as constants would override the platform palette.

The brand colors belong in #Constants because they should override the native palette. Both appearances need their own values, including the pressed and selection colors. The field and card inherit the platform's control treatments; ProjectHelp binds to its secondary text color in each appearance.

Assign the UIID in Java as usual:

TextField projectName = new TextField();
projectName.setUIID("ProjectNameField");
 
Button create = new Button("Create project");
create.setUIID("ProjectPrimaryAction");

This doesn’t turn every component into an OS widget. Codename One still draws the controls. Theme inheritance lets the same application rules use each platform’s styles without copying its palette into the application.

A dialog should be a window when the desktop expects one

The native desktop themes set defaultNativeWindowModeBool to true. An ordinary Dialog opens in a real operating-system window instead of appearing only as an overlay inside the application form. Its content remains CN1-rendered. Anchored popups such as combo boxes and context menus retain their popup behavior.

That distinction affects focus, ownership, placement, and keyboard handling. It is also why “native dialog” needs a precise meaning here: a native window contains the CN1 dialog; we aren’t claiming every dialog becomes an OS alert with OS-drawn controls.

Packaged JavaSE apps use native title bars by default with all three themes. The wrapper generator writes desktop.titleBar=native when the build hint is unset, and that property takes precedence over the theme constant. Set desktop.titleBar=custom explicitly if you want custom desktop chrome.

The simulator can expose a different default: without a title-bar property, it falls back to desktopTitleBarMode from the theme. That constant is native in Fluent and Aqua, and custom in Adwaita. An Adwaita simulator capture therefore doesn't establish the title bar a packaged app will use. The wrapper generator controls that packaging behavior.

Mouse behavior belongs in the theme too

A desktop scrollbar needs a thumb you can grab, a track you can click, and space that doesn’t disappear while you’re aiming at it. The desktop themes enable interactive scrollbars with that behavior.

Hover is another platform decision. Fluent and Adwaita have their own pointer states. Aqua keeps ordinary button and field hover equal to normal because the AppKit reference does. Adding a highlight everywhere would make the theme less faithful, even if it looked more responsive in a demo.

JavaSE reads the desktop’s light/dark appearance at launch. The simulator has its own appearance menu. Don’t assume these captures establish live theme switching on every packaged desktop platform.

Try a form with awkward content

PR #5886 connects the Settings application and simulator to the themes and records the six captures. The theme sources and behavior notes show the UIIDs and constants the application inherits.

For your first screen, choose one with a long label, a validation error, and a dialog. Check keyboard navigation, resizing, and dark appearance. A compact component gallery can hide the spacing and window-ownership problems that an ordinary application exposes immediately.

This closes the weekly series. The same choice runs through the iOS and desktop work: use the platform conventions deliberately, keep the application styling under your control, and test the result in a screen people actually need to use.

Native Desktop Themes for Production Apps was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

What do you pay for Spring and Java’s dynamic architecture? Can you deliver the same API without the same runtime cost?

For a small service, you might want dependency injection, transactions and scheduled jobs without a long startup or a large deployment. That is the case our native Java backend is trying to make. Write a controller and a service, compile their wiring into the application, then deploy a native executable.

The HTTP runtime underneath that API is small. In the two-core Linux test below, its lower-level Bench handler occupies 5.17 MiB and reaches its first verified response in 14.8 ms. The same two endpoints in Spring/GraalVM occupy 88.31 MiB and respond in 43.6 ms. This handler uses no controller annotations or generated wiring, so those numbers measure the HTTP stacks, not the cost of the Spring-style API.

This week’s Spring-style API adds the parts that make that approach useful beyond a greeting endpoint: transaction propagation, scoped beans, background tasks, sessions, metrics and MCP tools. ParparVM supplies the native runtime, including virtual threads that can park while a handler waits for PostgreSQL, MySQL or another HTTP service.

This is a Spring-style API, not a drop-in Spring implementation. Its annotations live in com.codename1.backend.annotations. Spring itself supports AOT processing and GraalVM Native Image. Our proposition is a smaller supported surface with direct generated calls, a native runtime shared with our app framework, and code you can inspect when you want to know what an annotation costs.

The backend is still a work in progress. It sits on ParparVM, the runtime behind our native iOS apps, and is maturing rapidly. The local measurements below show where it earns the “smaller, faster” description. They also define the narrow workload being compared.

Coming This Week

Today’s article covers the backend API, generated code and local server comparison. The follow-ups explore what you can do with the rest of the release:

• Saturday, October 3: . How object headers, compiler optimizations and garbage collection affect the memory and CPU your application needs.
• Sunday, October 4: . Compare the videos, then see how measured motion and glass formulas make your UI feel closer to UIKit.
• Monday, October 5: . Start with fewer files, build a standalone backend, find the right Javadocs, and try the separate Android Gradle 9 option.
• Tuesday, October 6: . Connect your client app and native backend to traces across your enterprise services, with metrics and MCP alongside them.
• Wednesday, October 7: . Use desktop themes and visible menus in the browser. The Certificate Wizard gets the same theme families.
• Thursday, October 8: . Catch private API imports before submission, and what a difficult Friday release taught us about gaps in testing.

Compare startup, memory, throughput and build time

The measurements use CN1 revision 60c4f310. For the comparison, we ran two small HTTP handlers on the Linux deployment target: a 13-byte plaintext response and a JSON object containing one message field. The CN1 executable uses the repository's lower-level Bench handler. Spring Boot 4.1.1 uses Spring MVC and embedded Tomcat, running either on Temurin JDK 25 or as a GraalVM 25 native executable.

This compares the selected HTTP stacks, not equivalent framework features. The CN1 handler does not exercise the annotation-generated application shown below. There is no database, TLS, authentication, or telemetry in either application. Both JSON handlers create a map per request; CN1 also allocates a fresh response object.

The host is an Apple M4 Max with 16 logical CPUs and 64 GiB RAM. The local Linux ARM64 VM has four virtual CPUs and 8 GiB. Linux CPU affinity restricts the server to 1, 2, or 4 CPUs. At 1 and 2, the load generator runs on the remaining CPUs; at 4, it shares them with the server. These are actual scheduling restrictions, not just a reported processor count.

Start quickly and ship a smaller executable

The two-core configuration gives the server and load generator separate CPUs. Here are medians from three fresh processes, with the startup range in parentheses:

Application First response, ms: median (range), lower is better Native executable, MiB, lower is better CN1 native 14.8 (5.3–15.1) 5.17 Spring Boot / JDK 25 1,501.1 (1,407.6–1,617.8) N/A Spring Boot / GraalVM 25 43.6 (32.5–45.6) 88.31

[

](https://www.codenameone.com/blog/native-http-charts/startup.png)

Startup includes spawning the process and receiving a verified HTTP response. File system caches are left warm; this is not a cold-machine or serverless measurement. The polling loop and taskset launcher also contribute to the short native times. The JVM run uses its default runtime settings without an AOT cache.

[

](https://www.codenameone.com/blog/native-http-charts/binary-size.png)

The CN1 executable is 5.17 MiB, compared with 88.31 MiB for this Spring native build. These are uncompressed executable files from the default build outputs. Both files were unchanged by an additional pass that strips symbols. Both builds use shared system libraries, which are excluded here. This is not a container-size or complete-deployment comparison. The JVM column is N/A because its JAR is not a standalone native executable.

Leave more memory for the work your service does

A server’s memory use changes after it starts accepting traffic. We recorded all three stages using the same windows for each runtime:

Application, 2 allowed CPUs Idle before load, MiB Peak through load, MiB Idle after load, MiB CN1 native 10.0 57.8 29.8 Spring Boot / JDK 25 163.0 282.2 282.3 Spring Boot / GraalVM 25 78.1 117.0 79.6

[

](https://www.codenameone.com/blog/native-http-charts/memory.png)

Lower is better in all three memory columns. Idle before load is sampled three seconds after the first verified response. Peak is the kernel’s resident-memory high-water mark through startup and both routes. Idle after load is sampled five seconds after traffic ends, without forcing collection. Each table entry is the median of the three process measurements.

CN1 uses less resident memory in both the idle and loaded measurements here. Four-byte object metadata is only one part of that cost. RSS also includes code, stacks, allocator pages and library state; it is not the live Java heap. This Linux build uses native virtual threads, so its connection costs differ from a platform-thread pool.

Serve requests with 1, 2 or 4 CPUs

Allowed server CPUs Application Plaintext requests/s JSON requests/s 1 CN1 native 164,542 138,555 1 Spring Boot / JDK 25 34,721 64,068 1 Spring Boot / GraalVM 25 40,286 39,167 2 CN1 native 287,997 261,121 2 Spring Boot / JDK 25 69,953 70,491 2 Spring Boot / GraalVM 25 51,729 49,000 4 CN1 native 245,608 251,435 4 Spring Boot / JDK 25 116,491 110,530 4 Spring Boot / GraalVM 25 80,053 61,873

[

](https://www.codenameone.com/blog/native-http-charts/throughput.png)

Higher is better. Points are medians; whiskers show the three-run range. Each route has ten seconds of warmup and ten seconds of measurement, using two wrk threads and 32 connections. Plaintext precedes JSON. Four-core points include load-generator contention, so this is not a clean four-core scaling curve.

Does HotSpot catch up after warmup?

CN1 still leads after a minute of warmup per endpoint: 3.9 times the plaintext throughput and 3.4 times the JSON throughput of Spring/JDK 25 in the matched two-core follow-up. Both servers received the same longer warmup, followed by three consecutive ten-second measurement windows for each route.

Application, 2 allowed CPUs Plaintext requests/s JSON requests/s CN1 native, 60 s warmup per route 296,928 250,268 Spring Boot / JDK 25, 60 s warmup per route 75,721 73,613

[

](https://www.codenameone.com/blog/native-http-charts/warmed-throughput.png)

Higher is better. These are medians of three windows within one fresh process per runtime, separate from the three-process matrix above. The server uses CPUs 0 and 1; wrk uses CPUs 2 and 3, with 32 connections. Both routes completed without socket or non-2xx errors.

We checked HotSpot’s compiled-method list during warmup: Spring’s request dispatcher and handler adapter had reached tier-4 compilation. The snapshot is included in the reproduction bundle. The extra warmup does not close the gap for these two handlers. More complex application code, dependencies and different concurrency levels can change that comparison.

The matrix rotates runtime order and reverses CPU order in its middle round. Every response body is checked before load; any socket or non-2xx error during warmup or measurement rejects the run. All 27 process runs completed without those errors. Keep-alive request limits are raised or disabled on both servers; other runtime settings use their defaults.

How long do you wait for a build?

Native compilation moves work out of startup and into the build. You do not need to pay that cost after every edit: CN1’s debug/development mode runs on the JVM, while the native build produces the deployment executable.

Build Median elapsed, seconds Three-run range, seconds Spring Boot / JDK 25 2.07 1.54–2.57 CN1 debug / JVM 1.67 1.57–2.49 CN1 native 95.34 75.43–107.08 Spring Boot / GraalVM 25 200.89 174.80–214.39

[

](https://www.codenameone.com/blog/native-http-charts/build-time.png)

Lower is better. Three builds per configuration, with runtime order rotated, on the same four-vCPU, 8 GiB Linux VM. Application outputs are rebuilt each time; dependencies and toolchains are cached. Downloads, tests and server startup are excluded.

For this example, the CN1 native build takes 53% less elapsed time than Spring/GraalVM. The JVM builds take seconds. That keeps the edit-and-debug loop short while letting you check the native artifact before deployment.

The CN1 development measurement compiles the repository’s Bench handler, JavaSE backend runtime and shared sources with JDK 25. The native path compiles Java with JDK 8, translates it, then compiles and links the generated C with Clang at -O3; the translator and Java API dependencies are prebuilt. Spring uses Maven clean package on JDK 25; its native build adds Spring AOT processing and GraalVM native:compile. These are build-path timings for the HTTP examples, including their different build tools, rather than isolated javac or incremental-build timings.

The reproduction bundle includes sources, commands, artifact hashes, every raw sample, the matched longer-warmup comparison, clean-output build timings, and the controller and transaction examples. The results make a small native backend worth trying for services with these constraints. Measure your own handlers and dependencies before using them to choose deployment capacity.

Start your service with less runtime setup

Here is a complete controller for a backend module:

package example;
 
import com.codename1.backend.annotations.GetMapping;
import com.codename1.backend.annotations.RestController;
 
@RestController
public class GreetingApi {
    @GetMapping("/hello")
    public String hello() {
        return "Hello, World!";
    }
}

After javac compiles your sources, the build reads the annotations and generates Java classes for routing, dependency injection and method instrumentation. ParparVM translates the resulting bytecode to C, then the native compiler builds the executable.

[

](https://www.codenameone.com/developer-guide/img/backend-build-pipeline.svg)

From the current Backend guide. The generated classes are ordinary input to the translator and its dead-code analysis.

A generated Router holds the route as bytes and binds parameters according to their declared types. BackendWiring creates beans in dependency order. Missing dependencies, ambiguous candidates, constructor cycles and duplicate routes fail the build with the relevant class or injection point.

The wiring constructs this controller and the Notes service in the next section with direct calls like these:

b_greetingApi = new example.GreetingApi();
b_notes = new example.Notes(
        com.codename1.backend.Backend.requireDataSource(
                dataSource, "constructor parameter 1 of example.Notes"));

There is no runtime search for a Notes constructor or a matching database bean. The call is in the generated program. With more dependencies, the build orders the constructor calls and emits field or setter injection afterward. A private @Autowired field gets a generated setter so the assignment can still be a direct call.

This gives you a useful debugging option: follow the call into the generated code and see exactly what it constructs. It also lets the native linker remove unreferenced classes. You exchange some of Spring’s runtime flexibility for a build that can resolve more of the application before deployment.

Keep your transaction when you call another method

If you use Spring’s usual proxy-based transactions, a call through this bypasses the proxy. That can make a refactor change transactional behavior even though the annotation is still on the method. Spring documents both the limitation and its bytecode-weaving alternative in the proxying guide.

Our build rewrites the annotated method itself. @Transactional, @Async, @Timed and @Counted therefore apply when another method on the same object calls it. They also apply to private methods and project classes you construct with new.

For example, this service writes a note and an audit row in one transaction. Assume migrations have created note(body) and audit(message) in the configured database:

package example;
 
import com.codename1.backend.DataSource;
import com.codename1.backend.annotations.Component;
import com.codename1.backend.annotations.Transactional;
import java.io.IOException;
 
@Component
public class Notes {
    private final DataSource db;
 
    public Notes(DataSource db) {
        this.db = db;
    }
 
    @Transactional(rollbackFor = IOException.class)
    public void add(String body) throws IOException {
        db.execute("INSERT INTO note (body) VALUES (?)", new Object[] {body});
        db.execute("INSERT INTO audit (message) VALUES (?)",
                new Object[] {"note created"});
    }
}

What does the annotation become? The build moves the original method body into a separate method and wraps its call in transaction handling. This pseudocode shows the control flow for Notes.add; helper names and generated class layouts are implementation details:

transaction = begin(REQUIRED, readOnly = false, timeout = none)
try:
    call original add(body)
catch error:
    rollback = error is IOException
            or error is RuntimeException
            or error is Error
            or error is DataAccessException
    completeAfterFailure(transaction, rollback)
    rethrow error
commit(transaction)

The body runs inside a transaction boundary regardless of how you reached add. On failure, the wrapper applies the rollback rule to that boundary and rethrows the error. Completing a joined transaction can mark the outer transaction for rollback; it does not necessarily commit or roll back the connection immediately. There is no runtime annotation lookup or proxy dispatch for this method. The processor source and bytecode weaver show how this is implemented.

The database connection is borrowed lazily, at the first database operation. The method can return without touching the pool if it never accesses the database. DataSource, generated DAOs and managed ORM sessions join the transaction associated with the executing thread.

[

](https://www.codenameone.com/developer-guide/img/backend-transaction-propagation.svg)

You can choose all seven propagation modes: REQUIRED, REQUIRES_NEW, NESTED, SUPPORTS, MANDATORY, NOT_SUPPORTED and NEVER. The important choices are what you want to happen when a transaction exists, and whether an inner failure should undo the outer work. REQUIRES_NEW needs another connection; NESTED uses a savepoint on the current one.

Read-only declarations, timeouts and explicit rollback rules are supported. Isolation-level selection is not. An asynchronous task does not inherit its caller’s transaction, and a database transaction cannot undo an email or an HTTP request. The data chapter spells out these boundaries, including what happens when code touches more than one connection pool.

Handle more waiting requests without a thread per connection

If your handler spends most of its time waiting for another server, an OS thread per connection is expensive. You want straightforward blocking code without making each wait occupy a host thread.

On the Linux native HTTP path, each connection has a ParparVM virtual thread: a stack retained for the life of that connection. Host threads run those stacks. A host owns its connections and their epoll registrations; a virtual thread stays with that host. When the handler needs bytes that have not arrived, the runtime parks its stack and lets the host run another connection.

[

](https://www.codenameone.com/developer-guide/img/backend-architecture.svg)

That applies beyond the incoming socket. PostgreSQL and MySQL queries use the same parking mechanism. Outbound HTTP, including its TLS handshake, can park too. Your service can wait for a query in ordinary sequential Java while other connections continue on the same host.

Background tasks now participate in this model too. A virtual task has no incoming connection descriptor, so the host uses a wake pipe to notice newly submitted work. Future.get() on a virtual thread yields cooperatively while waiting for the task. Blocking the host there could otherwise stall the very task whose result the handler needs.

This work also fixed a subtle scheduler failure: each yield site must report whether it is runnable or waiting for I/O. A stale reason could leave a handler stuck after yieldNow() or send an I/O wait back through the runnable path after garbage-collector backpressure. A virtual-thread API is only useful when those transitions remain correct under load.

You still need to choose the right executor for your work:

Your operation Native virtual-thread behavior Practical choice Wait for PostgreSQL, MySQL or outbound HTTP Parks at supported socket waits Virtual threads suit this work Wait on an asynchronous task’s Future Yields cooperatively A virtual handler can await virtual work SQLite, file access, DNS resolution or Object.wait() Can block the host thread Put blocking local work on a platform executor Incoming TLS server connection Uses the platform-thread pool Account for pool capacity JVM development run Uses platform threads, including VIRTUAL tasks Test native concurrency before deployment

These are ParparVM’s virtual threads, not the JDK implementation. ThreadKind.PLATFORM remains the default for @Async and @Scheduled; VIRTUAL requests the native facility where available, and AUTO selects it when the server has virtual hosts. The scheduling chapter documents fallback behavior and named executors.

Schedule work without accidental duplicate runs

A scheduled method runs outside the request thread. Use a fixed rate when you want starts at regular intervals, or a fixed delay when you want a pause after the previous run finishes. The distinction becomes visible as soon as the job takes longer than expected:

[

](https://www.codenameone.com/developer-guide/img/backend-schedule-timelines.svg)

One job does not overlap itself within a process. If a fixed-rate job is still running at its next start, that start is skipped. The build validates the method signature and six-field cron expressions; configuration can supply the actual schedule.

When you deploy several server instances, each instance has a scheduler. A database lock lets them coordinate one job across replicas. For example, @Scheduled(fixedDelay = 60000, lock = "purge") requests a shared lock. The lease must exceed the job's maximum runtime, since expiry permits another instance to claim it. You can inspect job state and skipped runs through the management endpoints.

Keep configuration and state explicit as your service grows

The Spring-style surface extends beyond the three annotations in a demo:

What you need API and behavior Select an implementation @Primary and @Qualifier resolve competing dependencies Bind deployment settings @Value and @ConfigurationProperties bind configuration Enable an environment-specific bean @Profile and @ConditionalOnProperty control activation Construct a library object A @Bean factory supplies it explicitly Keep state for one request or session @Scope("request") and @Scope("session") locate the current instance through generated stand-ins Initialize and shut down resources @PostConstruct and @PreDestroy hooks participate in lifecycle management Measure or manage a service method @Timed, @Counted, @ManagedResource and related annotations generate adapters

The build catches unresolved wiring, but runtime configuration can still deactivate a required bean or omit a necessary value. Request, session and lazy stand-ins need a non-final class and an accessible no-argument constructor. That constructor runs for the stand-in too. The beans chapter explains the supported combinations and their restrictions.

Sessions use an in-memory or database store. They are created on demand, so an API that never asks for a session does not set a session cookie. Rotate the identifier at sign-in with changeSessionId(), and use the database store when multiple instances need to share session state. Session beans run their @PreDestroy or configured destroy method when the session is invalidated, found expired or closed at server shutdown. Expiry cleanup happens when a request encounters the expired session or triggers the periodic purge, rather than at the exact timeout instant.

[

](https://www.codenameone.com/developer-guide/img/backend-session-lifecycle.svg)

There is no general ApplicationContext lookup, and an arbitrary JAR on the classpath does not become a compatible Spring bean library. Native backend sources currently use Java 8 language level against the supported runtime library. Packaged deployment targets Linux. Those boundaries help you decide whether a small service fits this backend before attempting a migration.

Keep your service visible across your enterprise

An order can cross a client app, your native backend and several existing services. The backend can continue the incoming trace and propagate it on outbound HTTP calls so your operations team can follow that work in its existing observability system. Optional OpenTelemetry tracing and metrics are compiled into the executable, alongside management endpoints for health, jobs and application resources.

The generated server has a defined request chain. Its own endpoints run before application routes, and static files come last. A wrapper handles request scope, session persistence and request metrics:

[

](https://www.codenameone.com/developer-guide/img/backend-request-lifecycle.svg)

MCP gives your development tools a way to inspect the running service. An agent can list routes and beans, call an endpoint, inspect recent requests, and query database state through the development tools. You can publish application tools with @McpTool; the build generates their argument schemas and direct dispatch.

Development tools are excluded from packaged servers by default. A production MCP endpoint requires a token. Tuesday’s article connects the client and backend to an enterprise trace, then covers metrics and the MCP development workflow.

To try the backend, start with the backend guide and a small endpoint, then add a database operation and verify its rollback behavior. The implementation behind PR #5908 is the basis for this week’s expanded API.

More This Week

That is the backend story. The rest of the release reaches your app’s UI, project structure and submission process. Here is a closer look at each upcoming post, plus a small maps improvement.

How your Java server uses less RAM

**Saturday: **

The server comparison above puts CN1’s peak RSS at 57.8 MiB, against 117.0 MiB for Spring/GraalVM. Saturday explains the runtime work behind that smaller footprint: four-byte object headers, tighter fields, fewer temporary objects and changes to garbage collection. We will also look at the compiler translating itself faster than JDK 25, and explain how ParparVM's layout differs from HotSpot's compact headers and Leyden's AOT work. Headers are part of the saving; the whole server measurement includes code, stacks and libraries too.

Can your users spot the custom-rendered tab bar?

**Sunday: **

Last week’s iOS 27 theme still had motion I wasn’t happy with. This comparison shows the refinement under taps, holds, and drags. Watch the original video; the small changes in timing and glass detail are the point.

Watch the tab bar comparison.

UIKit is above Codename One in this side-by-side simulator recording.

Sunday’s post follows the reverse engineering from frame measurements to spring equations, vibrancy and lens rendering. You can judge the remaining differences and choose when to adopt the theme in your app.

Choose Gradle and start with fewer files

**Monday: **

You can now start a smaller Gradle project and add platform directories when needed. A standalone backend no longer requires a client project alongside it. That makes the tree easier to navigate and leaves less boilerplate in an LLM’s context. I still prefer Maven XML, for reasons involving the make files I lived with at Sun, but your preference should not block either project shape.

We converted the repository’s HelloCodenameOne sample: 358 files became 305, and nine POMs became two Gradle Kotlin files. That is 53 fewer files around the same application. The count includes sources and resources, excludes generated build output, and comes from the actual converter.

The generated settings.gradle.kts selects the build plugin:

plugins {
    id("com.codenameone") version "8.0-SNAPSHOT"
}
rootProject.name = "HelloCodenameOne"

This is an excerpt; the generated file also configures plugin repositories. Use the release version containing Gradle support when it is published. Monday shows the full setup and conversion commands.

The new backend Javadocs also separate server APIs from the client reference, with shared classes identified between them. Monday covers that split and the separate, experimental Gradle 9 Android build option. Choosing Gradle for your project and changing the Android builder’s Gradle version are independent choices.

Bring your app into your enterprise traces

**Tuesday: **

Your mobile or web app can be the start of a trace that crosses a native CN1 backend, existing Java services and a database. The client and server propagate the same trace context, so compiling the backend to native code need not leave a gap in your enterprise observability. You can use your existing OTel collector and tracing system, with collector credentials kept on the server.

Tuesday explains the setup, sampling and metric labels that keep telemetry manageable as traffic grows, plus MCP tools for checking the service during development. Downstream services must participate in trace propagation too.

Make your browser app feel like a native desktop app

**Wednesday: **

Your web app can now use native desktop OS styling: macOS (Aqua), Windows (Fluent) or Linux (Adwaita). An optional HTML title and menu bar puts commands above the application. Additional OS windows remain unsupported in the JavaScript port because of browser popup restrictions; that does not exclude Windows browsers. The Certificate Wizard adopts the same desktop theme families, continuing last week’s Settings work.

[

](https://www.codenameone.com/blog/desktop-theme-collage.jpg)

The Settings app shows the three desktop theme families now available in the JavaScript port.

Read street names along the road

There is a smaller maps improvement too: names now follow the road geometry, with curved glyph placement on bends and upright text along straighter sections. Labels remain above route overlays, so the route does not hide the street you need to follow.

From the Maps guide. The renderer rejects placements that bend too sharply or collide with other labels.

This is part of the continuing vector-map work in PR #5902. The Maps guide covers the renderer and deeper zooming without stretching raster tiles.

Your release also has to survive submission

**Thursday: **

A working simulator or device build can still import an API that Apple rejects at submission. In this case, the unwanted imports appeared only when particular optional APIs were enabled, so most apps and our usual test configuration missed them. The new check looks for imported SDK symbols without public declarations, exercises optional feature combinations and inspects a linked Release device app. It catches a class of mistake that another happy-path test would miss.

This was a rough week of regressions around the optional Xcode 27 path, push, and windows. Some overlapped, so we thought we had fixed a bug only to discover its symptoms had moved. Thursday’s post explains one of those failures, why we release on Friday despite the obvious cost to our weekends, and how better gates can protect your release from ours. The Apple check has a defined scope; it cannot guarantee App Store acceptance.

There is a lot to try this week. There is also work to do on the reliability of getting it into your hands. I would like you to spend the next release testing something useful in your app, rather than helping us untangle a regression. That is why the gate work matters as much as the new features.

A Smaller, Faster Java Server with a Spring-Style API was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

The current Linux ARM64 performance baseline has ParparVM translating its own compiler in 37.5% less elapsed time and 45.8% less peak memory than JDK 25. Across all 16 recorded machine configurations, self-translation takes 22.5% to 56.6% less elapsed time. The gains vary by OS and processor; the chart and table include every configuration. Your Java source does not need to change to benefit from a smaller runtime and a compiler that removes more work.

[

](https://www.codenameone.com/blog/runtime-diagrams/translation-baselines.png)

These are the repository’s checked-in performance baselines, read on October 1. They are recorded reference results used to detect regressions, not new measurements made for this article. Each comparison runs the same translator classes on the two runtimes and verifies the generated files byte for byte.

Self-translation baseline Elapsed time, ParparVM / JDK 25 Peak memory, ParparVM / JDK 25 Recorded calibration runs Linux ARM64, Neoverse N2 0.625 0.542 7 Linux x64, EPYC 7763 0.484 0.519 3 Linux x64, EPYC 9V45 0.495 0.539 1 Linux x64, EPYC 9V74 0.516 0.522 2 Linux x64, Xeon 6973P-C 0.537 0.520 1 Linux x64, Xeon Platinum 8370C 0.434 0.509 3 Linux x64, Xeon Platinum 8573C 0.505 0.517 1 macOS ARM64 0.539 0.739 1 Windows ARM64, model D49 0.751 0.539 7 Windows ARM64, model D84 0.775 0.570 1 Windows x64, AMD family 25/model 1 0.606 0.542 7 Windows x64, AMD family 25/model 17 0.636 0.551 2 Windows x64, AMD family 26/model 2 0.611 0.546 1 Windows x64, Intel family 6/model 106 0.627 0.536 1 Windows x64, Intel family 6/model 173 0.677 0.549 1 Windows x64, Intel family 6/model 207 0.602 0.526 1

Lower is better in both columns. JDK 25 is 1.0. Each baseline is the median of the recorded runs’ median ratios, with each platform using its available CPUs and runtime defaults. Translation time includes the whole process; Linux and macOS memory is peak RSS; Windows memory is peak working set. Some configurations have only one calibration run, as shown. They are separate machines, not a core-count scaling test.

A couple of weeks ago I wrote about making ParparVM compile itself. HotSpot beat us on elapsed time. That was disappointing, though hardly surprising. Since then we have worked on object layout, collections, generated C and garbage collection. The results above are a much better place to be.

The smaller objects matter beyond the compiler benchmark. In Friday’s server comparison, CN1’s native backend peaks at 57.8 MiB RSS, against 117.0 MiB for Spring/GraalVM, and rests at 29.8 MiB after load against 79.6 MiB. That compares complete HTTP stacks. Here we will look at the runtime changes that help make a smaller Java process possible.

What gets faster, and what still needs work?

Self-translation is a substantial Java workload: allocating objects, walking collections, resolving methods and writing generated C. It is also our own compiler, so we should check other workloads before treating it as a verdict on Java performance.

The complete Linux ARM64 baseline contains 13 workloads. ParparVM uses less peak memory in all 13 and less elapsed time in eight. Sequential array access takes 0.362 times the JDK’s measured time; hash-map churn uses 0.121 times its peak process memory. Allocation remains an important weakness: that workload takes 3.043 times the JDK’s time, even while using 0.239 times its peak memory.

[

](https://www.codenameone.com/blog/runtime-diagrams/arm64-baselines.png)

Each row combines seven calibration runs; each run compares the two runtimes in alternating order. Translation rows measure the complete process. The smaller workloads time repetitions inside the process after their own warmup, so JVM startup does not count against HotSpot. Memory is whole-process peak RSS in every row, not live heap.

The performance harness checks workload results as well as time and memory. The original self-hosting post measured 1.56 seconds for HotSpot against 1.84 seconds for ParparVM. The opening charts show the later checked-in baselines after the optimization work; they are separate measurements, not a reinterpretation of that earlier result.

Elapsed time and CPU time also answer different questions. Parallel JIT compilation and collection can reduce the wait while consuming more CPU across threads. That distinction helped guide the investigation, but it does not establish a battery saving: energy depends on the machine’s power use over time. The current baseline records elapsed time and peak memory, so those are the claims we can make from it.

Why a tiny Java object needs a header

An object header is runtime metadata stored alongside your fields. It lets the runtime identify the object’s class and track information needed for collection and other operations. On a typical 64-bit HotSpot configuration, the header occupies 12 bytes; without compressed class pointers it can occupy 16. JDK 25’s optional compact object headers reduce that to 8 bytes. Oracle’s JDK 25 GC guide documents the sizes and the -XX:+UseCompactObjectHeaders switch.

This is the work associated with Project Lilliput. Project Leyden addresses startup, warmup and footprint through ahead-of-time work, including AOT caches. The names are easy to mix up, but shrinking each object’s header and caching class-loading work solve different problems. See the Leyden project for that distinction.

Runtime layout Object header metadata What the number excludes HotSpot, compressed class pointers 12 bytes Fields, alignment and backing storage HotSpot, JDK 25 compact headers enabled 8 bytes Fields, alignment and backing storage ParparVM release layout 4 bytes Fields, alignment, side tables and backing storage

These are layout sizes, not a prediction of process memory. A small HTTP server can spend more of its resident memory on stacks, code, allocator pages and library state than on live Java object headers. The server comparison measures the whole process separately.

The release object header carries a 16-bit class index, an 8-bit collection epoch and an 8-bit heap state. The class index addresses a closed-world class table instead of storing a pointer in every object. Objects requiring a legacy heap index use a side table keyed by address.

[

](https://www.codenameone.com/blog/runtime-diagrams/object-header.svg)

The runtime header is explicit about the distinction between metadata and allocation. The C header struct remains eight-byte aligned. Small objects live in allocator size classes, and fields need alignment too. A four-byte header does not make an empty object a four-byte allocation.

The translator packs eligible fields into the gap after the metadata. It stores fields at their real widths and orders them to reduce padding. A subclass must preserve its superclass layout as a prefix, so it cannot arbitrarily reach back and fill a hole belonging to an ancestor. That restriction sharply reduced the savings predicted by an early census.

Object in the experiment Before After four-byte header and root-field packing VarOp 32 bytes 24 bytes ArrayList 32 bytes 24 bytes ByteCodeMethodArg 32 bytes 24 bytes BasicInstruction 40 bytes 32 bytes

Object sizes from the layout experiment. Backing storage is additional.

The header-layout experiment measured one-core container RSS moving from 618 MB to 605 MB across five interleaved runs. That is useful, but much smaller than “we halved the header” might suggest. The page allocator and native collection buffers still occupy memory.

There was a second trap. A static class table that named every class also kept those classes reachable to the native linker. The current implementation registers most entries as classes are used. Shrinking object metadata should not accidentally force otherwise unused classes into the executable.

Get less overhead from the same Java loop

ParparVM translates bytecode to C. “Lowering” is the step that turns a higher-level operation into a representation the native compiler can optimize directly. We do not get that benefit merely by giving Clang a large pile of C functions.

Consider a collection traversal. The ordinary implementation has an iterator object and virtual calls for hasNext() and next(). When the translator proves the exact collection layout, it can emit a native cursor loop. When it cannot prove the receiver, it can check the exact class once and retain the ordinary iterator as a fallback.

The owner must remain a GC root until the final native-buffer access. A raw pointer into a malloc block does not keep the Java owner alive. The emitted lifetime fence is therefore part of correctness, not optional bookkeeping to strip from a fast loop.

Several related changes attack allocation and dispatch:

• Collection storage: hash tables combine key, value and metadata slices into one native allocation. Reference slices still need tracing and write barriers. Moving them outside the managed heap does not make their Java references invisible to the collector.
• Strings and builders: StringBuilder keeps Latin-1 bytes until it needs UTF-16. Proven temporary builders can use native storage while preserving ownership across helper calls and exceptions. StringBuffer retains its synchronization.
• Short string equality: bounded loads compare short strings without an ordinary Java method call. Longer ranges still use memcmp; mixed encodings preserve their own comparison rules. The implementation must not read past the logical range just because a wide load would be convenient.
• Immediate array streams: supported Stream.of(array) pipelines with known lambda callbacks can become one C loop. Escaping streams, unknown callbacks, sorted, distinct and unsupported terminals keep the lazy implementation.

For example, this shape is eligible for the stream work when the surrounding method satisfies the proof:

long count = java.util.stream.Stream.of(names)
        .filter(name -> name.length() > 3)
        .count();

Here names is a String[]. Eligibility is narrower than “streams allocate nothing.” Nor does seeing a loop in emitted C prove that the linked binary vectorizes it. The lowering audit checks generated code and linked instructions separately from elapsed-time measurements.

Keep your program correct when removing work

A declared List type does not prove an ArrayList layout. LocalReceiverTypes tracks allocation provenance, and unknown parameters or factory results retain guards. Analysis is restricted to methods that need it, and the compiler drops the temporary frame information after capturing the proof. Optimizing the translated program should not require keeping an unnecessary analysis graph alive throughout translation.

Direct calls also gain small C intrinsics for operations such as list access, string length, hashing and builder appends. They apply to calls whose target is resolved statically, with the ordinary implementation available off the fast path. Together with traversal lowering, this lets the C compiler see useful operations inside a loop instead of opaque calls at every step.

Another pass removes instance fields the closed program never reads. It checks native-source references and conservatively keeps runtime fields and unresolved cases. Removing a dead reference field can save both its storage and the object it would otherwise retain. This pass is disabled for JavaScript output and on-device debugging.

There is a semantic edge worth stating: the current dead-field pass documents that assigning to a removed field on a null receiver no longer produces the JVM’s NullPointerException. Its treatment of an unused store is therefore not a claim of identical behavior for every Java program. An application depending on that exception needs to account for this difference.

Fit the collector to the cores you have

The small-object allocator groups objects into pages by size, often called BiBOP, short for “big bag of pages.” A nonmoving collector cannot return a page while one live object still occupies it. Free slots inside a partial page can be reusable capacity without being releasable memory.

The experiments found 50 to 60 MB of free slots inside partial pages around one peak. Those slots were reused before new pages were allocated. Calling all of that a leak would send the investigation in the wrong direction.

On one core, the generational collector can stop application work and collect young objects. With spare cores, the concurrent collector overlaps tracing with the application. The concurrent path needs grace for allocations that appear after a snapshot. That can retain dead objects longer, and shortening that lifetime requires preserving everything the snapshot could not yet see.

We tried reclaiming dead large objects every single-core cycle. The first attempts were unsound. A growing output buffer could be allocated after the extent snapshot and remain live only in a thread’s local state. If the collector could not resolve that pointer, it could free a live buffer.

The fix registers those large objects from allocation and rebuilds the relevant snapshot at each thread’s pause in that mode. The concurrent collector keeps its different grace rules. Applying one mode’s shortcut to the other added locking to a hot path without providing a benefit.

One-core translation, five interleaved rounds Minimum elapsed Maximum RSS JDK 25 13.74 s 557 MB Four-byte header before reclamation change 10.29 s 608 MB With large-object reclamation change 9.84 s 503 MB

A separate Linux container experiment isolating the reclamation change: minimum elapsed and maximum RSS from five interleaved runs. Lower is better. Its four-byte-header control peaked at 608 MB; the header-layout experiment reported 605 MB in a different set of runs. The reclamation experiment record describes this later comparison. The opening charts show the current baseline.

We then reduced work in minor collections: skip an already-old page object before expensive conservative resolution, and consult the monitor table only for pages that have had monitors. The experiment record includes the unsuccessful alternatives too. Fewer object bytes help memory use. Avoiding thousands of unnecessary collector operations helps execution time too.

What changes for your app?

If your application creates large graphs of small objects, the smaller headers and field packing can reduce their cost without a source rewrite. Proven collection traversals and stream pipelines can avoid temporary objects and dispatch. These are compiler and runtime changes, so you get them by rebuilding with a release that includes this work.

The benefit depends on what your app spends time and memory doing. A form with a large model, an importer that walks collections, and a service that allocates objects continuously stress different parts of the runtime. The allocation result above is a reason to check a busy handler before assuming it will behave like the compiler benchmark.

For an existing Codename One app, rebuild and compare a real interaction on your target device: startup, a large list or model load, and a sustained operation that creates objects. For a backend, compare resident memory at rest and under representative traffic, plus throughput and latency. Keep the input and build settings the same between releases. The backend guide covers packaging a small service you can test this way.

There is more room to improve. Our measurements point toward shorter-lived garbage in the concurrent collector and less overhead in small native collection buffers. A stop-the-world strategy saves memory on one core, but forcing it everywhere can lose too much execution time. The next step is to reduce that retention while preserving useful concurrency. That is an optimization direction, not a promise that one collector will win on every application.

Honey, I Shrunk Java was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

Watch how the two tab bars respond to the recorded taps, holds, drags and changes of direction. Can you tell which one is UIKit and which one is drawn by Codename One?

That is a more useful test than a still image. Your users feel the delay before a selection moves, the way the glass follows a finger and the settling motion after release. A tab bar can have the right colors and still feel wrong in your hand.

Last week’s iOS 27 theme was close, but I still wasn’t happy with those interactions. Getting closer meant recording UIKit’s presentation layers during real touches, fitting the motion to spring equations and reconstructing the glass effects. Here is the result, followed by the measurements and formulas behind it.

Watch the same gestures twice

Download the light comparison video.

UIKit is on top and Codename One below. These committed iOS 27 simulator recordings use the same touch sequence: six taps, a held press, a tap on the selected tab, a slow drag and a flick. Each gesture occupies a 4.2-second slot aligned on the touch.

Download the dark comparison video.

The dark appearance exposes the edge, vibrancy and refraction differences more clearly. UIKit is above Codename One in both simulator recordings.

The recording script and video notes make the provenance inspectable. The remaining differences are part of the comparison: the lifted lens, its rounded ends and the saturation still deserve work.

Why your tab bar can look right and feel wrong

Setting the selected tab in code did not produce the complete native interaction. UIKit performs that motion for genuine touches on a controller-managed bar. The probe therefore uses XCUITest taps, holds, and drags.

There was another complication: UIKit did not attach a simple CAAnimation containing the whole trajectory. It updated layer values frame by frame. The useful record was the presentation geometry at each display refresh: position, bounds, transform, opacity and the touch timestamps that explained them.

Capturing an image on every frame changes the timing enough to contaminate the measurement. The probe separates geometry logging from optional frame snapshots. Snapshot runs are useful for comparing the lens at the same motion state, not for fitting its timing. Likewise, lossless screenshots over known backdrops reveal the blur; compressed video smears the very edges we need to inspect.

Those constraints are documented in the native probe. They explain why “looks close in a recording” was not enough.

Make taps, holds and drags respond differently

For a fixed target, a damped spring follows this equation:

Here x is position, xₜ is the target, ω controls the natural frequency and ζ the damping. Dots denote derivatives with respect to time. A critically damped spring has zeta = 1; lower damping allows an overshoot. The implementation uses the measured constants rather than retuning the entire animation by eye:

Channel Model in the current source Selection travel omega = 2*pi/0.4, zeta = 0.85 Lens lift Critical damping, omega = 2*pi/0.25 Platter return Critical damping, omega = 2*pi/0.4 Whole-bar press growth omega = 17.6, zeta = 0.59 Lens following a drag omega = 32, zeta = 0.90

The travel stops once the remaining distance after the overshoot is below about 0.195 points. The drag and press models include a measured 20 ms touch lag. These small details are visible because your finger gives the animation a moving reference point.

The current TabGlassMotion and TabGlassGesture contain the formulas, retained tables and stopping rules. The regeneration tool checks the closed forms against captures and rewrites the channels that remain tabulated.

Let users drag across tabs without selecting each one

During a drag the lens follows the finger on its own spring, so it can lag behind. On release, UIKit selects the tab under the finger, not the one nearest the lagging lens. The lens then settles toward that tab from its current position and velocity.

Resetting velocity at that handoff creates a visible interruption. Snapping to the nearest lens position after a fast flick creates another discontinuity. A press on the already selected tab must also lift and pulse without inventing travel to another tab. A held press has to keep its lifted state until release rather than play a fixed-duration tap and finish underneath your finger.

The release adds a small wobble. Our model uses a common starting point for it even though the captures show slightly different onset times across gesture types. That approximation is one reason to keep the full gesture suite alongside the short demo.

Keep icons legible as the backdrop changes

A vibrant tab icon is not simply painted with an alpha color. Its result depends on the glass behind it. The probe reads UIKit’s color matrices across tint sweeps, and VibrancyMatrix reconstructs the transform.

For a non-gray dark tint vector t, the measured form is:

e = 0.5 * min(t) / max(t)
M = e*I + (0.5 - e) * (ones * transpose(t)) / dot(t,t)
offset = t
output = M * backdrop + offset

I is the identity matrix and ones is a column of three ones. Gray tints have their own formula, so this expression is not a universal branch to paste over the implementation. Light appearance uses a different form. The vibrancy source and recorded fixture hold those cases together.

The selection platter also transforms the bar’s existing glass. Graphics.colorMatrixRegion applies that operation within a shape and optional mask. The lifted lens needs a separate operation: refraction around a circular bevel, color dispersion, an outline, rim light and shadow. glassLensRegion supplies that rendering path.

This is why adjusting the opacity of a rounded rectangle could only take us so far. The effect changes the content underneath it.

Keep the glass animation on the GPU

A more accurate motion model is wasted if the renderer misses the frames that distinguish it. The iOS bar glass now runs on the GPU instead of passing through a CPU blur with GPU synchronization around it. Mutable images reuse their stencil texture. The tab animation avoids asking for a second whole-component repaint, and the lens scratch texture is released after use.

The portable color-matrix operation reaches the JavaScript port too. The browser lens still lacks the full optics implementation. A shared API does not mean every rendering backend implements every effect today.

Choose the appearance, then test your screen

In the Settings app’s Build Hints, select:

ios.themeMode=modern
ios.themeGeneration=27

For the cloud toolchain, ios.xcode_version=27 is a separate setting. In codenameone_settings.properties, prefix build-hint keys with codename1.arg.. A local Xcode build uses the Xcode installation selected on your Mac.

Codename One draws these controls itself. The theme and its motion ship with the app, so adopting this appearance remains your decision. That control also gives us the responsibility to measure the behavior we reproduce.

Try the animation over a photograph, a scrolling list and a plain dark background. Hold it. Drag past the middle and release. The implementation in PR #5906 and the fixtures behind it make those interactions repeatable instead of leaving fidelity to memory.

Can You Tell the Difference Between These iOS Tab Bars? was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

You can now choose Gradle for a Codename One project. Start with fewer files, add platform directories when you need native code, or create a standalone backend without a mobile app attached. A smaller project is easier to browse and leaves less scaffolding competing for space in an LLM’s context.

I like Maven XML. I know it is verbose. I also spent enough time at Sun Microsystems staring at deeply scripted, heavily patched make files to develop a lasting suspicion of clever build systems.

Someone starts with a reasonable shortcut. Someone else needs one more condition. A few years later the build has its own undocumented programming language and nobody wants to touch it. I would rather a build system be strict and limited. Give people enough power and, with the best intentions, they build a Frankenstein build.

That is a personal preference. Plenty of developers I respect love Gradle, or at least appreciate what it lets them do. This week we added optional Gradle support because it lets us offer something useful: a smaller Codename One project, including a standalone backend with no client scaffolding.

Start with fewer files

The Maven app layout has a root POM and platform modules ready for native code. That makes the structure explicit, but a new app often has no code in most of those places.

A Gradle app starts with the sources and configuration it needs. Native directories appear when you generate native interfaces. A backend subproject appears when you add a backend.

For a concrete example, we converted the checked-in HelloCodenameOne sample with the current converter:

Project files Maven sample Converted Gradle sample Total files, including app sources and resources 358 305 Maven POMs 9 0 Gradle Kotlin configuration files 0 2

That removes 53 files, about 15% of the tree. We counted the tracked sample before conversion and all files in the converter’s new directory afterward, excluding build output and caches. This is the existing demonstration app, with its resources and Kotlin source, rather than a comparison of two different Hello World programs.

The generated settings.gradle.kts is small enough to show in full, with its explanatory comments removed:

pluginManagement {
    repositories {
        maven("https://repo.codenameone.com/maven2")
        gradlePluginPortal()
    }
}
plugins {
    id("com.codenameone") version "7.0.274"
}
rootProject.name = "HelloCodenameOne"

The example selects release 7.0.274, which includes Gradle support. The app's own dependencies and Kotlin plugin go in build.gradle.kts; the framework's platform builders come from the Codename One plugin.

MyApp/
  settings.gradle.kts
  gradle.properties
  gradlew
  gradle/wrapper/
  codenameone_settings.properties
  icon.png
  src/main/java/
  src/main/css/theme.css
  src/main/resources/

Add build.gradle.kts when you have dependencies or build configuration of your own. Kotlin source belongs in src/main/kotlin when the project applies the Kotlin plugin.

That smaller tree helps a human understand an unfamiliar project. It can also reduce the irrelevant files an agent sees when building its context. The file reduction is measurable; the context saved depends on which files your agent reads.

Keep the same builds when you switch

We did not implement a second set of platform builders. The Gradle plugin calls the shared engine used by Maven. That includes upload staging, local builders, CSS compilation and bytecode compliance checks.

From a generated Gradle app:

./gradlew run
./gradlew cn1Test
./gradlew buildJavascriptLocal
./gradlew buildIosXcodeProject -Popen=false

run starts the simulator. cn1Test uses the simulator test runner. The last two commands build the JavaScript port locally and generate an Xcode project. Tasks that submit cloud builds are available too, with the same service requirements as Maven.

There are limits. Running Gradle requires JDK 17 or newer and Gradle 8.5 or newer; the generated wrapper supplies Gradle. These projects target Java 17. They do not support legacy .cn1lib files or the old resource Designer task. The OpenAPI, gRPC and GraphQL generators and on-device debugging helpers still have Maven goals without equivalent Gradle tasks. The workflow chapter lists the supported surface.

Build a standalone Java backend

In the Initializr, choose Gradle as the build tool and Backend only as the project type. The server lives at the root, with its Java source and application properties. There is no client theme, simulator module or collection of empty native directories.

For a generated project named MyService:

CN1_PROFILE=dev ./gradlew runBackend

That runs the development server on the JVM. Stop it before changing the backend code; this is a restart workflow, not hot reload. To build and run the native executable:

./gradlew backendPackage
CN1_PROFILE=dev PORT=9000 ./build/MyService

The development profile uses the generated in-memory SQLite configuration. Without it, the starter reads its production settings and expects DATABASE_URL. The executable's name follows the project name.

An existing Gradle app can gain a server with:

./gradlew addBackend
CN1_PROFILE=dev ./gradlew :backend:runBackend
./gradlew :backend:backendPackage

I hope people will try the backend on its own. It is still experimental, but a small independent service can reveal useful constraints without requiring a mobile application first. The weekly overview shows the Spring-style programming model it now supports.

Try Gradle alongside your Maven project

The converter leaves the original project in place and writes a sibling project. Replace VERSION with the Codename One plugin release containing this feature:

mvn com.codenameone:codenameone-maven-plugin:VERSION:convert-to-gradle \
  -Dcn1.sourceProject=/path/to/MyApp \
  -Dcn1.outputDir=/path/to/MyApp-gradle

The destination must be empty or absent. The conversion carries sources, resources, CSS and platform implementations into the new layout, and raises the application’s bytecode target to Java 17. A customized backend comes across; the untouched backend skeleton is optional. Legacy .cn1lib dependencies stop conversion with their names rather than silently disappearing.

Open the converted project and run its tests before switching the team’s build. Your old checkout remains available for comparison.

Find the API for the code you are writing

Last week we split the Developer Guide into chapters. Before that, we rebuilt the Javadocs. A backend-only project made the next problem obvious: a client API page is the wrong answer when you are writing a server.

PR #5918 separates the client API from the backend API. The references label their audience and link shared classes to their counterpart. Backend classes belong in the backend reference; a UI implementation package does not belong there just because it exists in the repository.

What you are writing Reference to start with A form, component or device integration Client Javadocs A controller, database service or scheduled job Backend Javadocs Shared models and mapping code The shared class page, with its counterpart link

The distinction helps readers and code-generation tools for the same reason: it reduces the chance of choosing an API that exists in the wrong runtime. Both references are checked with doclint, so malformed documentation has a build-time consequence too.

Try Gradle 9 for your Android build

The optional Gradle project layout and the Gradle version used inside a generated Android project are different choices. You can keep your Codename One app on Maven and still test the newer Android builder.

In Settings, under Build Hints:

android.gradleVersion=9

Or in codenameone_settings.properties:

codename1.arg.android.gradleVersion=9

The current builder pairs Gradle 9.8.0 with Android Gradle Plugin 9.4.1. It adjusts the generated project for removed DSL elements and AGP’s built-in Kotlin support. This selects the experimental Gradle 9 / Android Gradle Plugin 9 path from PR #5919. It is opt-in. Much of the surrounding tooling and library configuration still assumes Gradle 8. Test your actual native dependencies and generated Android project before adopting it; a successful empty app is not the same test.

I expect to keep using Maven for plenty of projects. Supporting Gradle gives teams another way into the same build machinery, and gives a small server a project tree that looks like a small server.

Do You Prefer Gradle? was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.