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

PR #5554 adds com.codename1.home, a portable model for listing accessories, reading and writing traits, watching changes, running scenes, and commissioning Matter devices.

The API also reports cases where the platforms cannot give the same answer. For the other work that shipped this week, see the weekly release overview.

Traits describe the device, not the platform

A HomeStructure contains rooms and accessories. Each accessory contains services, and each service exposes traits such as ON_OFF, BRIGHTNESS, or TARGET_TEMPERATURE.

The port owns conversions that are easy to get wrong. Matter brightness uses a 0 to 254 level. Covering position runs in the opposite direction on some backends. Matter has no single thermostat setpoint in automatic mode. Air quality has a different number of levels in HomeKit and Matter.

TraitValue exposes the canonical value and retains the platform ordinal where a conversion loses detail. Proportional values become percentages. Temperature getters require the expected unit, preventing a Celsius value from being read as Fahrenheit by accident.

Availability has more than two states

SmartHome.getInstance() never returns null. Unsupported ports return a fallback that reports NOT_SUPPORTED. Supported ports use more specific states so an empty accessory graph is not mistaken for a configured home with no devices.

SmartHome home = SmartHome.getInstance();
home.refresh().onResult((structures, error) -> {
    HomeAvailability availability = home.getAvailability();

    if (availability == HomeAvailability.PROVIDER_NOT_INSTALLED
            || availability == HomeAvailability.PROVIDER_UPDATE_REQUIRED) {
        home.openProviderSetup();
        return;
    }
    if (availability == HomeAvailability.PERMISSION_REQUIRED) {
        home.requestAuthorization();
        return;
    }
    if (availability == HomeAvailability.PERMISSION_DENIED) {
        home.openHomeSettings();
        return;
    }
    if (availability == HomeAvailability.NOT_CONFIGURED) {
        home.openEcosystemApp();
        return;
    }
    if (error != null) {
        Log.e(error);
        return;
    }
    if (availability == HomeAvailability.COMMISSIONING_ONLY) {
        showAddDeviceOnlyUI();
    }
});

Read availability from the completion path even when refresh() fails. On iOS, the initial value is NOT_STARTED because connecting to HomeKit is what reveals the authorization and home state.

COMMISSIONING_ONLY is the normal Android result without Google Home developer setup. Play services can add a Matter accessory to the user's Google Home. Reading or controlling the accessory graph requires Google Home APIs, a Google Cloud project, and a Home Developer Console registration containing the application's signing-key SHA-1. Codename One cannot create those credentials for an application.

The Google Home accessory graph is not part of this release. Reporting full availability would make the same enum value mean different things on Android and iOS.

Reads and writes can partly succeed

A batch read returns one TraitReading per requested value. A reading can contain a value, contain an error, or contain neither. The third state is valid when a sensor has not measured yet or a light in white mode has no meaningful hue.

A batch write follows the same rule. Turning off every light can succeed for three accessories and fail for one unreachable bulb. The result carries each row instead of collapsing the operation into one boolean.

TraitReadRequest request = new TraitReadRequest()
        .add(thermostat, thermostatService, Trait.CURRENT_TEMPERATURE)
        .add(thermostat, thermostatService, Trait.CURRENT_HUMIDITY);

home.read(request).onResult((readings, error) -> {
        if (error != null) {
            Log.e(error);
            return;
        }
        for (TraitReading reading : readings) {
            if (reading.isFailed()) {
                showUnavailable(reading.getTrait());
            } else if (!reading.hasValue()) {
                showNoReadingYet(reading.getTrait());
            } else {
                show(reading.getTrait(), reading.getValue());
            }
        }
    });

Build controls from each service's TraitConstraint. A dimmer with a ten-percent floor reports that floor. Writing below it is refused rather than silently clamped.

Changes are state updates, not an event log

HomeKit can push trait changes while the application is in the foreground. Other backends require polling. TraitSubscription.isPushDelivery() tells the application which model it received.

Where push delivery is unavailable, call drainChanges() when the application returns to the foreground. Changes are coalesced by accessory, service, and trait. Dragging a dimmer can therefore produce one update with the final value instead of forty intermediate events.

Nothing in this release wakes a stopped application for an accessory change. The home hub owns background automation. The phone application owns a foreground view of current state.

Commissioning uses the operating system's setup flow

Both mobile ports hand Matter commissioning to a system-owned flow. The user may need to power on the accessory, hold a physical button, scan a label, and join Wi-Fi. The application receives no determinate progress to display.

SmartHome home = SmartHome.getInstance();
Commissioner commissioner = home.getCommissioner();
SetupPayload payload = SetupPayload.parse(scannedCode);

commissioner.commission(new CommissioningRequest()
        .setSetupPayload(payload)
        .setSuggestedName("Kettle"))
    .onResult((result, error) -> {
        if (error != null) {
            Log.e(error);
            return;
        }
        if (home.getAvailability() == HomeAvailability.COMMISSIONING_ONLY) {
            showAddedToHome(result.getAccessoryName());
            return;
        }

        home.refresh().onResult((structures, refreshError) -> {
            if (refreshError != null) {
                Log.e(refreshError);
                return;
            }
            showUpdatedHome(structures, result.getAccessoryId());
        });
    });

Success can mean the device joined the user's home without becoming addressable by the application. That is the normal result on an Android build with commissioning alone. On graph-capable builds, refresh after every successful flow. The default iOS Matter sheet does not return an accessory ID even though the new device appears in HomeKit, so the application must inspect the refreshed graph. wasCommissionedToThisApp() is useful when a backend returns a directly addressable ID, but it is not a substitute for that refresh.

The iOS build adds HomeKit entitlements only when application code touches accessories. Commissioning lives in its own package because it adds a generated app-extension target. An application that never references com.codename1.home gets no framework, entitlement, Play services dependency, or extension.

The simulated house contains the awkward cases

The simulator, desktop ports, and JavaScript expose a local house with a two-gang switch, bridged lights, an unreachable socket, a thermostat in automatic mode, and a dimmer with a nonzero floor.

Those cases make the application handle missing values, partial failures, constraints, and delayed callbacks before it meets real hardware. The simulator does not push changes and never completes an operation inline, which prevents desktop-only timing assumptions from becoming device bugs.

Automations, triggers, background events, topology writes, camera streams, alarm panels, and Matter events remain outside this release. By default Codename One also commissions through the Apple Home or Google Home ecosystem rather than becoming a Matter controller with its own fabric.

Application code can work with brightness, temperature, locks, and scenes without carrying HomeKit characteristic strings or Matter cluster IDs. Capability queries still expose the platform differences the product must handle.

The next post adds tapjacking protection to the security work.

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

PR #5552 keeps the canvas renderer and promotes eligible visible text into a DOM layer. Codename One still measures and places every run. The browser handles the part it is better at: text rasterization, selection, search, accessibility, input metadata, and device-pixel resolution.

For encrypted SQLite and the rest of this week's work, see the weekly release overview.

A DOM component tree was the wrong trade

Replacing each Codename One component with a DOM element would hand layout and paint ordering to the browser. It would also create two UI implementations to keep consistent.

We kept application components on the canvas and projected only the text and accessibility data the browser needs:

The page now has a shape similar to this:

<canvas role="presentation" aria-hidden="true"></canvas>
<div id="cn1-text-layer" aria-hidden="true">
    <span style="position:absolute; white-space:pre">Account balance</span>
</div>
<div id="cn1-accessibility-tree" aria-label="Account balance"></div>

The text run arrives already broken and positioned. white-space: pre prevents the browser from wrapping it. Text measurement stays on the worker's OffscreenCanvas, so promoting a run does not alter layout.

Rebuilding the overlay broke the browser features

The accessibility projection previously cleared its container and recreated every element on each invalidation. Scrolling changes component bounds repeatedly, which meant scrolling also destroyed DOM focus and any active text selection.

The overlay now diffs the semantic tree. Stable nodes keep their element identity and listeners while their bounds or content change. The browser can maintain focus and selection because the application is no longer replacing the element under it.

The real-browser verification tags semantic elements with a JavaScript property, triggers invalidation, then reads the property again. Rebuilding the tree would lose the tag and fail the test. That makes incremental behavior part of the port contract rather than a performance assumption.

High-DPI displays use their native resolution

The old host code pinned devicePixelRatio to one. A 375 by 667 CSS box therefore had a 375 by 667 backing canvas even on a display with a pixel ratio of two. The browser enlarged that bitmap to the physical pixels.

The new path uses a 750 by 1334 backing surface behind the same 375 by 667 CSS box at a device-pixel ratio of two. Coordinates are converted at the DOM boundary, while Codename One continues to address device pixels internally.

CSS layout:      375 x 667
devicePixelRatio:        2
backing surface: 750 x 1334

The port also refreshes the ratio when browser zoom changes or a window moves between displays. Screenshot tests can still pin a specific ratio through the existing query parameter.

Inputs now tell the browser what they mean

Text editing already used a positioned native input. The new work fixes and extends the metadata the browser reads:

• inputmode selects the appropriate on-screen keyboard.

• autocomplete connects password managers and autofill.

• autocapitalize and spellcheck follow the Codename One constraints.

• The component name becomes the field name.

• cn1$autocomplete can override the autocomplete token.

A password field bug also disappeared. PASSWORD is a bit flag, but the old code compared the entire constraint value. PASSWORD | EMAILADDR missed the password case and fell through to a clear-text input.

Several browser APIs had silently broken when the port moved into a worker. A @JSBody executes in that worker, so direct access to history, matchMedia, or other window-owned objects fails. Host bindings now restore browser history, dark-mode detection, reduced-motion and forced-color queries, and cursor support.

Some text stays on the canvas

The DOM layer is targeted. Text stays on the canvas when the DOM cannot reproduce the paint operation without changing its meaning:

• Offscreen targets, transition buffers, ComponentImage, and screenshot rendering

• Cell renderers whose single component instance is stamped at several positions

• Text outside the displayed form when a dialog paints another form as its backdrop

• Shape clips, transformed text, and bitmap fonts

Drag selection is also disabled for now. The text layer takes no pointer events so the canvas keeps owning hit testing. Find-in-page and keyboard selection work without that change. Mouse drag selection needs pointer routing that can distinguish text selection from component gestures.

Vertical placement can differ from browser font metrics by roughly one pixel. A sheet covering text inside the same form can also leave that text represented in the DOM until same-form occlusion is modeled.

Search works without handing layout to the browser

The JavaScript port still ships the Codename One UI. A browser cannot reflow a label, substitute a component, or change a layout after an OS update. The application owns those decisions.

The browser now sees enough structure to do what users expect from a web page. Search finds text. Assistive technology receives stable semantic nodes. Password managers recognize fields. High-DPI screens render at their actual pixel density.

The next post maps HomeKit, Matter, and Google Home without flattening their differences.

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

PR #5487 now builds an Apple Watch companion from codename1.watchMain. On Wear OS, the same entry point becomes the Android product when codename1.watchStandalone=true; a companion Wear APK beside the phone application is not generated yet. The release also adds one phone-to-watch API that maps to WCSession on Apple platforms and the Wearable Data Layer on Android.

For encrypted SQLite and the rest of this week's work, see the weekly release overview.

One entry point builds the watch application

The watch application starts from a fully qualified class name:

codename1.watchMain=com.example.MyWatchApp

# For a standalone Wear OS product:
codename1.watchStandalone=true

On Apple platforms, watchMain adds a companion target to the phone build. On Android, watchStandalone=true replaces the phone product with the Wear OS application rooted at watchMain. Without that flag, the Android build remains the phone application. The build logs that no companion Wear artifact was produced instead of quietly implying otherwise.

The Apple build derives the watch bundle identifier, deployment target, signing team, and display name from settings the project already has.

The phone and watch share source files, resources, CSS, and themes. They do not share runtime state. Each has its own Storage, Preferences, and SQLite files.

Wear OS reuses the Android port. watchOS uses a separate Core Graphics renderer because it has no UIKit view hierarchy, OpenGL ES, or Metal. The watch runtime sits inside a SwiftUI shell and runs its own ParparVM translation rooted at the watch entry point.

A message and a value solve different problems

The platforms offer several transports because a watch spends much of its life asleep.

Use putData() for state that should converge when the watch next wakes:

WearableConnection.putData(new WearableMessage("/steps")
        .put("count", stepCount)
        .put("goalReached", stepCount >= 10000));

Register the listener during init(). A payload can be the reason the platform started the process, so listeners attached from a later form may miss the replay window.

WearableConnection.addDataListener(new WearableDataListener() {
    public void dataChanged(WearableMessage data) {
        if ("/steps".equals(data.getPath())) {
            stepsLabel.setText("" + data.getInt("count", 0));
        }
    }

    public void dataRemoved(String path) {
        if ("/steps".equals(path)) {
            stepsLabel.setText("--");
        }
    }
});

Each data path holds the latest value. Two rapid writes can arrive as one update. That is correct for a step count and wrong for a queue of events.

Use sendMessage() when both applications must be awake and the sender needs an answer now:

WearableConnection.sendMessage(
        new WearableMessage("/workout/start"),
        new WearableReplyHandler() {
            public void replyReceived(WearableMessage reply) {
                showWorkout(reply.getString("id", null));
            }

            public void replyFailed(String message) {
                showReplicatedWorkoutState();
            }
        });

Failure is a normal branch. The phone may be asleep, out of range, or running an older version that does not know the message path. Do not use isReachable() as a preflight for a request with a fallback. Reachability can change after it is checked, and its first value during a cold start may still be unknown. Let replyFailed() select the replicated state instead. transferFile() covers files and large payloads that can arrive later.

The simulator runs two processes

The Watch > Launch Watch App command starts the watch beside the phone. The applications run in separate processes and connect through the desktop bridge, so sendMessage() and putData() take the same asynchronous route the application code expects on a device.

The simulator includes Apple Watch 41 mm and 45 mm skins, plus round and square Wear skins. Test the round skin even if the first target is Apple Watch. It catches layouts that depend on rectangular corners.

CN.isWatch() selects the form-factor-specific UI. The watch theme override changes styling without forking the rest of the theme:

Form form = new Form(BoxLayout.y());
if (CN.isWatch()) {
    form.add(new Label("Hi Watch"));
    form.getToolbar().setVisible(false);
} else {
    form.add(new SpanLabel("Welcome to the phone application"));
}
form.show();

Complications reuse the surfaces model

A complication is a small system-rendered surface driven by a timeline. That is the same model Codename One uses for widgets, Live Activities, and Dynamic Island content.

WidgetKind steps = new WidgetKind("steps")
        .setDisplayName("Steps")
        .addSupportedSize(WidgetSize.WATCH_CIRCULAR)
        .addSupportedSize(WidgetSize.WATCH_RECTANGULAR);

The watch sizes belong to WidgetSize instead of a second complication API. Application content can therefore share the same surface descriptors and timeline logic.

The system targets that render those watch families are not generated yet. watchOS still needs its WidgetKit extension target, and Wear OS still needs complication or tile services. The API establishes the common model without claiming those final platform adapters have shipped.

Android has one more current limit. Standalone Wear applications build today. A companion configuration does not yet produce a second Wear APK beside the phone APK. Apple Watch supports both companion and standalone targets, although standalone App Store submission still needs a manual archive step in Xcode.

Share code without pretending the watch is a phone

The watch and phone are separate products. They can still share application rules, visual assets, and surface descriptions. WearableConnection keeps the connection between them visible in ordinary Java code.

Write once, run anywhere does not require pretending every screen has the same lifecycle. A phone message can fail. A replicated value can arrive after a relaunch. A complication can render while neither application is active. The shared code handles those cases without hiding them.

The next post keeps the Codename One renderer while restoring browser-native text behavior.

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

On Windows and Linux, Database.openOrCreate() returned null. JavaScript depended on WebSQL, which Chrome removed and Firefox never implemented. An iOS cursor could report success on an empty result set, then read unset memory. The simulator counted rows from one while the other ports counted from zero. Encryption had no sensible place to live because there was no single database contract underneath it.

PR #5526 follows that rabbit hole to the end. It replaces the platform-dependent implementations with one specified and tested SQLite contract. It also resolves the long-standing encrypted database request. The same encrypted file can move between ports and open in a standard SQLCipher 4 client.

TL;DR

• SQLite now has one tested contract, including native Windows and Linux implementations, SQLite compiled to WebAssembly for JavaScript, and encryption with three key models.

• The watch apps deep dive treats the phone and watch as separate applications with separate lifecycles. WearableConnection gives them one asynchronous API for messages, replicated state, and files.

• JavaScript text now appears as real DOM text above the canvas. Browser search, selection, accessibility, autofill, and native-resolution rendering work without handing layout to the browser.

• Smart home support maps HomeKit, Matter, and Google Home concepts onto com.codename1.home, including a simulated house for desktop development.

• Tapjacking protection detects and can reject Android gestures that begin behind another app's overlay.

• Camera and vision regain the one-call ergonomics that were lost when the old scanner libraries were replaced by lower-level on-device analyzers.

• App Intents expose a Java handler to Siri, Spotlight, Shortcuts, Android launcher shortcuts, and an internal command layer.

Each port had different SQLite behavior

The old API looked uniform because every port implemented the same Java methods. That said nothing about the result.

execute(sql) ran every statement on iOS, but silently stopped after the first statement in the simulator. getBlob() returned nil on iOS. The JavaScript cursor's position(n) always landed on row zero. The simulator leaked a prepared statement per query. ThreadSafeDatabase.close() returned before the close happened, so an immediate delete could race it.

These were not edge cases around a working abstraction. They meant a query tested in the simulator could have different transaction, cursor, or binding behavior on a device.

The new DatabaseConformanceSuite defines the contract once. Seven device tests exercise lifecycle, statements, cursors, transactions, encryption, and legacy behavior on every port-status target. The current reports show those tests passing on Android, both iOS renderers, JavaScript, native Linux, native Windows, macOS, tvOS, and watchOS.

Cursor navigation now derives from two primitives, rewind() and stepForward(), instead of being reimplemented on every port. Transactions return to autocommit after either commit or rollback. Blobs and typed parameters behave consistently. Windows and Linux finally open a database instead of returning null.

Fixing these inconsistencies changes behavior that some existing applications may rely on. A cursor index or transaction quirk can become part of application code even when the behavior was accidental. The db.legacy build hint keeps the previous implementations available during migration.

Older Ant projects default to legacy mode. They may be stable applications that only need another maintenance release, and forcing a database migration on them would be reckless. Newer Maven projects default to the corrected contract so new code does not inherit the old problems. Either project type can set db.legacy=true for the old behavior or db.legacy=false for the corrected contract.

DatabaseConfig opens the same encrypted format everywhere

Encryption is selected by passing a DatabaseConfig when the database opens:

if (Database.isEncryptionSupported()) {
    DatabaseConfig config = DatabaseConfig.managed();
    Database db = null;
    try {
        db = Database.openOrCreate("secure.db", config);
        // Read and write through db.
    } finally {
        config.wipe();
        if (db != null) {
            db.close();
        }
    }
}

There are three key models:

A passphrase compiled into the application is recoverable from the shipped binary. It is not a useful secret. A managed key avoids that mistake, but it also changes the recovery story: if the key-store entry is lost, the database is unreadable. Use a user-held or server-held passphrase when the data must survive a device loss.

Existing plaintext databases can be converted without replacing the API:

if (!Database.isEncrypted("customer.db")) {
    Database.encrypt("customer.db", DatabaseConfig.managed());
}

The on-disk parameters are fixed to the SQLCipher 4 format: AES-256-CBC, PBKDF2-HMAC-SHA512 with 256,000 iterations, 4,096-byte pages, and per-page HMAC-SHA512. CI writes a database with the Codename One engine and reads it with the stock sqlcipher client, then reverses the direction. That cross-engine test catches a class of failure where every port can read its own incompatible file.

Encryption protects data at rest. It does not protect an open database from a debugger, a memory dump, or code already running on a compromised device. That boundary is why this work sits beside App Shield and App Hardening instead of replacing either one.

JavaScript gets SQLite instead of a removed browser API

The JavaScript port used WebSQL because browsers once exposed it as a convenient SQL-shaped store. Chrome removed WebSQL in version 119. Firefox never shipped it. A portable API cannot depend on a feature that no longer exists in one browser and never existed in another.

JavaScript now runs SQLite compiled to WebAssembly and stores the database in the browser's storage pool. It passes the same statement, cursor, transaction, encryption, and compatibility tests as the native ports.

The new engine cannot read an old WebSQL store. openOrCreate() refuses to create an empty database when it detects that old data, because silently replacing a user's database with an empty state is worse than a visible migration. An application with WebSQL-era users must export from a build that can still read the old store, or deliberately opt into a new empty database with cn1.db.ignoreLegacyWebSql=true.

The build also remains pay-for-what-you-use. An application that never references com.codename1.db gets no database engine. A plain JavaScript database adds roughly 1.5 MB of WebAssembly. Referencing DatabaseConfig adds the cipher implementation where the platform needs it.

On Android, encryption raises the minimum SDK to 23 and requires AndroidX because those are SQLCipher's requirements. The unencrypted database path keeps the older floor.

That covers the database work. Six more changes shipped this week, each with its own detailed post.

The watch and phone now run as separate applications

A watch is not a small second window owned by the phone process. It has its own executable, storage, startup sequence, and failure modes. The watch applications post covers the complete model introduced by PR #5487.

One codename1.watchMain setting adds the Apple Watch companion entry point. On Android, codename1.watchStandalone=true builds that entry point as the Wear OS product instead of the phone application; a companion Wear artifact beside the phone APK is not generated yet. The simulator can launch the phone and watch as separate processes and connect them on the desktop. The pair shares source, resources, CSS, and the surfaces model. It does not share Storage, Preferences, or SQLite.

WearableConnection models the three transports the platforms actually provide. sendMessage() asks a live peer for an immediate reply. putData() replicates the latest state and survives sleep or relaunch. transferFile() moves a larger payload in the background. The API uses WCSession on Apple platforms and the Wearable Data Layer on Android.

WearableConnection.putData(new WearableMessage("/steps")
        .put("count", stepCount)
        .put("goalReached", stepCount >= 10000));

Complications join the existing surfaces vocabulary through watch-specific WidgetSize families. This reuses the same content and timeline model already used for widgets and Live Activities. The generated watchOS complication target and Wear OS complication service are not part of this release yet. Android also supports standalone Wear apps today, but does not yet generate a companion Wear artifact beside a phone APK.

Browser search now works in the JavaScript port

The JavaScript port has always rendered through a canvas. That gives Codename One control over layout and keeps the UI consistent, but it also turned visible text into pixels. Browser search could not find it. Users could not select it. The browser could not rasterize it at native resolution or expose it as ordinary text.

The JavaScript text post explains how PR #5552 keeps the canvas renderer and adds two targeted DOM layers above it. The text layer holds visible text runs at the positions Codename One already calculated. The accessibility layer holds the ARIA projection and updates it incrementally.

<canvas role="presentation" aria-hidden="true"></canvas>
<div id="cn1-text-layer" aria-hidden="true">Selectable, searchable text</div>
<div id="cn1-accessibility-tree" aria-label="..."></div>

The browser never gets to reflow a line or decide where a component belongs. It gets text that is already measured, broken, and positioned. Find-in-page, text selection, accessibility, native input metadata, password-manager hints, and high-DPI rendering can then use browser machinery without changing application layout.

Drag selection is still off because the text layer cannot take pointer events without changing canvas hit testing. Shape-clipped and transformed text stays on the canvas. Same-form occlusion, such as a sheet over text in the underlying form, also needs more work.

One API for HomeKit, Matter, and Google Home

The smart-home post introduces com.codename1.home from PR #5554, a common model for HomeKit, Matter, and Google Home. An accessory contains services. Services expose canonical traits such as ON_OFF, BRIGHTNESS, and TARGET_TEMPERATURE. Platform identifiers and unit conventions stay in the port.

That sounds like a normal abstraction until the platforms disagree. Matter and HomeKit express covering position in opposite directions. Matter has no single thermostat setpoint in automatic mode. Android can commission a Matter accessory into Google Home with little setup, but reading the accessory graph requires Google Home developer registration that Codename One cannot create for you.

The API reports that default Android state as COMMISSIONING_ONLY, not AVAILABLE. On iOS it can read and write HomeKit traits, run scenes, and commission Matter accessories. The simulator, desktop ports, and JavaScript run a deliberately awkward synthetic house so missing values, partial failures, and polling behavior can be tested without hardware.

Automations, background accessory events, camera streams, alarm panels, and the Google Home accessory graph on Android are outside this release. Each gap has a capability query or a specific availability state instead of turning into an empty list that looks like a real answer.

Tapjacking protection continues our security hardening work

We are continuing the push to make Codename One the secure default for application developers. The tapjacking protection post covers the input side of that work. Tapjacking happens when another Android application draws over a sensitive screen and changes what the user believes a tap will do. PR #5553 adds a TapjackingPolicy to DeviceIntegrity.

DeviceIntegrity.setTapjackingProtection(TapjackingPolicy.BLOCK);
DeviceIntegrity.addTapjackingListener(event -> {
    if (Boolean.TRUE.equals(event.getSource())) {
        showOverlayWarning();
    }
});

if (DeviceIntegrity.isHideOverlayWindowsSupported()) {
    DeviceIntegrity.setHideOverlayWindows(true);
}

REPORT observes without changing input. BLOCK drops a gesture that begins fully obscured. STRICT also drops partially obscured gestures, which can include ordinary system UI and therefore carries a real false-positive cost.

Detection is touch-driven because Android supplies the obscured state on MotionEvent. An overlay that appears without a touch is not detected by polling. On Android 12 and newer, setHideOverlayWindows(true) prevents overlay windows instead of reacting to their touches. iOS does not let one application draw over another, so the policy is an Android-only control rather than a fake cross-platform checkbox.

Scan a barcode without rebuilding the camera pipeline

The on-device vision work added barcode recognition, face and pose detection, text recognition, segmentation, document scanning, and image labeling. It also exposed every piece of the camera-to-analyzer pipeline. That was useful for custom camera products and needlessly low-level for common cases.

The camera and vision post covers the higher-level APIs in PR #5575. CodeScanner.scan() owns a complete scanner screen and returns one asynchronous result:

CodeScanner.scan().ready(code -> {
    if (code != null) {
        urlField.setText(code.getValue());
    }
}).except(error -> Log.e(error));

VisionCameraView packages the same pipeline as a component for a form you own. Typed BarcodeFormat, FaceLandmarks, and PoseLandmarks constants replace string literals. VisionRect.toBounds(...) and VisionPoint.toPoint(...) convert normalized analyzer geometry into component coordinates. SegmentationMask.cutOut(...) turns selfie segmentation into a usable image operation.

The preview remains a native peer. Components cannot be painted over it uniformly on every target, so controls and reticles should sit around it. One camera session can be open at a time. The simulator now scripts vision results, which lets the flow, overlay geometry, cancellation, and error paths run before the application reaches a device.

Expose an intent to Siri, Spotlight, and Shortcuts

The App Intents post shows how to expose a Java method to Siri, Spotlight, Shortcuts, or an Android launcher shortcut. PR #5559 puts the declaration in Java:

@AppIntent(value = "log_workout", title = "Log a workout",
        phrases = {"Log a workout in ${applicationName}"}, headless = true)
public static IntentResult logWorkout(
        @IntentParam("minutes") int minutes) {
    WorkoutStore.append(minutes);
    return IntentResult.spoken("Logged " + minutes + " minutes.");
}

The Maven plugin reads the compiled bytecode and generates a reflection-free dispatch table plus the native declarations. The direct static call matters on iOS, where runtime annotation lookup is unavailable and dead-code elimination can remove a handler that has no Java caller.

Entities let the platform ask the user which application object they meant. Intents.index(...) publishes those objects to device search. opensRoute connects an intent to the existing route table when the result should foreground a screen.

Android is not presented as Siri parity. It gets launcher shortcuts, donation, indexing, and headless execution. Voice invocation, system disambiguation, and spoken assistant results are iOS capabilities. Intents.invoke(...) still works on every port as an internal command layer, even when the operating system exposes no intent surface.

Security now covers storage, code, backend trust, and input

This week closes several gaps that used to be explained away as platform differences. SQLite now has one documented contract and one portable encrypted format. The watch and phone are separate applications with a defined channel. Smart-home traits and app intents project one application model onto native system services without pretending those services are identical. The web port keeps our renderer while restoring browser behavior users expect.

App Shield moves trust decisions to the backend. App Hardening raises the cost of reading and modifying the shipped binary. Encrypted SQLite protects stored data. Tapjacking protection rejects a class of misleading input on Android. None of these controls makes a compromised device trustworthy. Together they cover more of the path from stored bytes to the tap that authorizes an operation.

We want Codename One to lead cross-platform development on security. That requires more than adding isolated security switches. The safe path must be available from ordinary application code, included only when used, and tested on every target we claim to support. This week's encrypted database and tapjacking work move two more boundaries into that default path.

Start with the database guide if you have data at rest to migrate. Existing Ant applications should set db.legacy explicitly before moving to Maven. Applications with WebSQL-era browser data need an export plan before taking the new JavaScript engine.

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

We set the target at DexGuard-class resistance: rename useful symbols, remove plaintext application strings where the target permits it, distort selected control flow, and keep crash reports readable. This is not a claim that reverse engineering becomes impossible. It is a commitment to make the same security decision cover the whole application instead of leaving every port to a different tool and configuration.

This post continues this week's release overview and GUI Builder rewrite and last week's App Shield release.

One transform before six platform builds

App Hardening runs on the merged application JAR inside the cloud build service. That placement matters. The engine sees application classes and bundled libraries before ParparVM translates bytecode to C, before R8 handles Android, and before the JavaScript or native desktop backends consume the program.

PR #5527 carries the open-source engine, retrace support, client API, build preflight, crash payload changes, and documentation. BuildDaemon PR #173 wires the engine into the cloud builders and enforces the Enterprise entitlement on the server.

The server gate is intentional. A non-Enterprise build that requests hardening fails with an explanation. It never returns an ordinary binary that looks protected because the client asked for protection.

Turn it on with one level

For most projects the only setting is:

codename1.arg.harden.level=standard

The levels are cumulative:

You can override the individual transforms with harden.rename, harden.strings, and harden.controlFlow. A per-platform harden.<platform>.enabled=false hint opts one target out. An unknown level fails the build instead of becoming off.

Classes resolved by name need a keep rule:

codename1.arg.harden.keep=-keep class com.example.payment.NativeGateway { *; }

The engine already keeps the application entry point, generated bootstraps, and native-interface peers. Codename One does not use runtime reflection to resolve ordinary application classes, which removes a large source of keep-rule guesswork. A third-party library that loads package-relative resources can still need an explicit rule because its package name changes while the resource path does not.

The port matrix is deliberately uneven

Applying every transform everywhere would produce a larger binary without adding protection, or break a backend optimizer. App Hardening uses one policy but adapts the mechanics:

The renaming dictionary uses a zq prefix rather than the familiar a, b, and c. Short names can appear inside ParparVM's generated native identifiers and confuse dead-code elimination. The longer prefix keeps the names opaque without disabling that optimizer.

A mapping looks like this in the retrace tests:

com.example.MyForm -> zqaaaa:
    10:10:void onSave():42:42 -> zqa
com.example.util.Helper -> zqaaab:

The mapping gets a build-specific ID and stays on the server for Crash Protection. Hardened stack traces carry that ID, the raw stack, trace format, and hardening level. The server retraces the report before filing the GitHub issue.

String encryption has sharp edges

Renaming hides labels. String encryption removes eligible application literals from the shipped binary and synthesizes a decoder inside each class with a per-class key. There is no single framework decoder for an attacker to hook.

The engine handles both ordinary LDC literals and static final String values stored in the class-file ConstantValue attribute. It also reports strings it cannot transform.

Three boundaries matter:

1. Annotation values remain in annotation metadata and stay readable.

2. JDK 9 style invokedynamic string-concatenation recipes can keep literal fragments outside ordinary LDC instructions. The build report counts those sites. Compiling with -XDstringConcat=inline moves them back into instructions the engine can transform.

3. An encrypted literal is value-equal to the same unencrypted framework string but may not be the same object. Compare strings with .equals(), not ==.

None of this turns a client-side constant into a secret. If the app can decrypt a value, an attacker controlling the process can eventually observe it. Credentials and signing secrets still belong on a server or in platform-backed secure storage.

Control flow is a cost, not a badge

Aggressive and paranoid levels add opaque predicates to eligible methods. A decompiler must keep branches that the application can resolve at runtime but static analysis cannot fold away.

The engine skips constructors and checks method growth before adding bytecode. It verifies the transformed classes with ASM's CheckClassAdapter before any platform builder sees them. The build report identifies methods or literals that were skipped instead of claiming a transform covered bytes it did not touch.

paranoid doubles the eligible control-flow guards. It also increases size and analysis complexity inside your own build. Start with standard, test a release build, then raise the level for code where the added cost has a reason.

Crash reports remain part of the contract

Obfuscation without retrace trades one security problem for an operational one. A production crash that says zqaaaa.zqa() does not help the team responsible for fixing it.

App Hardening and Crash Protection share the mapping lifecycle. Mapping upload is required by default. If upload fails, the build fails rather than ship an artifact whose future crashes cannot be decoded.

Application code can inspect the stamped result:

if (Hardening.isHardened()) {
    Log.p("Hardening level: " + Hardening.getLevel());
    Log.p("Mapping: " + Hardening.getMappingId());
}

The simulator and local source builds report false and off because they are never hardened. A local target fails preflight unless you explicitly set harden.allowUnhardenedLocalBuild=true. That escape hatch permits the build; it does not pretend to protect it.

Hardening, Shield, and encrypted data stop different attacks

Last week's App Shield release gives a backend a server-verified attestation token. Patching a local boolean is no longer enough to impersonate a trusted app when the server enforces that token.

App Hardening works earlier in the attack. It raises the cost of finding the code and constants an attacker wants to patch. App Shield makes a successful local patch insufficient for protected server calls. The open portable encrypted database PR adds the data-at-rest layer with interoperable encrypted SQLite files and keystore-managed keys. That database work is not merged yet, so it is direction rather than part of this release.

The security lead we are building comes from covering these boundaries together. Release builds already obfuscate by default. Enterprise teams can now add one cross-platform hardening policy, server-enforced attestation, Crash Protection retrace, and, once PR #5526 finishes review, portable database encryption. Each layer has a named failure mode and a testable output.

App Hardening still cannot stop a determined attacker who controls the device. It does not replace authorization, rate limits, secure key custody, or review of the operation your backend performs. It makes static analysis and casual tampering more expensive across every artifact you ship, which is the job an obfuscation layer can defend.

Start with standard, submit a release cloud build, and check the hardening report before moving to a stronger profile. The App Hardening guide documents every hint, exclusion, and local-build boundary.

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

This is a smaller rewrite than the second generation Steve Hannah built. His guided layout work remains the foundation. PR #5523 replaces the surrounding shell with a Maven-first Codename One application that moves between forms, CSS, and Java without leaving the workspace.

This week in one page

• The third-generation GUI Builder is now a project workspace launched with mvn cn1:guibuilder.

• App Hardening applies renaming, string encryption, and selected control-flow transforms before the platform builds split. The follow-up publishes Saturday.

• The iOS on-device debugger no longer crashes when a reused local slot is mistaken for an object.

• Port status and Linux video now report skipped tests instead of counting them as passes. The same work fixed three GStreamer defects.

• Google Sign-In moved to version 7.1 so Apple Silicon simulators get a real arm64 simulator slice.

• ParparVM memory reclamation now returns surplus BiBOP pages to the operating system after a small-object peak.

• Missing and legacy URLs now lead to recovery pages instead of a bare 404.

Three builders, three different projects

The first GUI Builder grew out of tooling we built at Sun Microsystems. It stored forms inside the resource file and generated a central state machine. That model made sense when Codename One still targeted feature phones with roughly 2 MB of RAM.

The second generation separated a form into readable .gui XML and companion Java. Steve built auto layout on top of LayeredLayout, including smart insets, sibling references, matching sizes, baseline alignment, and multi-selection. It was a much better model for a modern application, but the editor still opened from a selected form.

That last assumption became painful after the Maven migration. A Maven project has forms under src/main/guibuilder, Java under src/main/java, and styling in src/main/css/theme.css. Launching a separate editor for every generated form turned navigation into the slow part of a visual tool.

The third generation changes the unit of work from a file to a project. It scans every .gui file, keeps them in the left panel, renders the selected form in the center, and shows its properties, layout, and events on the right.

One Maven goal opens the project

Create a form and open the editor from the project root:

mvn cn1:create-gui-form -DclassName=com.example.ProfileForm
mvn cn1:guibuilder -DclassName=com.example.ProfileForm

The first goal creates the pair that belongs in version control:

common/src/main/guibuilder/com/example/ProfileForm.gui
common/src/main/java/com/example/ProfileForm.java

The second goal resolves com.codenameone:codenameone-guibuilder through Maven and passes a project binding to the editor. IntelliJ IDEA, NetBeans, Eclipse, and Visual Studio Code now ship shortcuts that invoke the same goal. The editor itself remains a Java 8 artifact, so it runs on the JDK that already builds the application.

Switching forms no longer starts another process. The Forms tab is backed by a recursive scan of src/main/guibuilder, so a project with twenty forms behaves like a project with twenty forms, not twenty unrelated editor sessions.

Guided layout survived the rewrite

We did not replace Steve's layout model with absolute coordinates. A component dropped in auto layout mode still becomes a LayeredLayout child whose insets can refer to the parent or another named component.

Here is a trimmed form from the builder's demo project:

<component name="GuidedLayoutForm" type="Form" layout="LayeredLayout">
    <component name="heroTitle" type="Label"
        layeredinsets="24px auto auto 24px"
        text="Guided Layout" />
    <component name="description" type="SpanLabel"
        layeredinsets="12px 24px auto 0px"
        guidedreferences="heroTitle|-|-|heroTitle"
        guidedhorizontalsize="fill" />
    <component name="secondary" type="Button"
        guidedreferences="primary|primary|-|primary"
        guidedhorizontalsize="match"
        guidedmatchwidth="primary" />
</component>

Those names matter. A guide stored as an object pointer would disappear after a save and reload. A guide stored by component name survives on disk, which means the model must reject duplicate names and update references when you rename, delete, or paste a component.

The canvas adds the relationship while you drag. It can align edges, centers, and text baselines. Resizing can keep a preferred size, fill the parent, stay fixed, or match another component. The same canvas can switch from phone portrait to desktop width, which makes a bad relationship visible before it reaches a device.

The move above is not stored as a new set of absolute coordinates. It changes the relationship between primary and description, then lets LayeredLayout resolve the result for the current canvas.

CSS belongs beside the canvas

The second-generation builder and the old resource editor were separate tools. A user comment on our 2016 GUI Builder post asked for the editor to read the project CSS and render it directly. The third generation finally treats that as the normal workflow.

Click CSS and the project stylesheet opens beside the live form:

The pane edits the real src/main/css/theme.css. After the edit debounce, the CSS compiler installs the new theme and rebuilds the preview. A selector change is visible where it matters:

Button {
    background-color: white;
    color: #2459b8;
    border: 1px solid #315fce;
    border-radius: 2mm;
    padding: 2mm 4mm;
}

There is no second theme model to keep in sync. The stylesheet that colors the canvas is the stylesheet Maven compiles for the application.

Generated Java is visible, but not disposable

The Code button opens the companion Java source in the same workspace:

Generated code and user code have different ownership:

// <gui-builder-generated>
private Button signIn;

private void buildUI() {
    signIn = new Button("Sign in");
    signIn.setName("signIn");
    add(signIn);
}
// </gui-builder-generated>

// <gui-builder-user-code>
protected void onSignIn(ActionEvent event) {
    authenticate();
}
// </gui-builder-user-code>

The embedded editor protects the generated region instead of waiting for Save to overwrite it. Event handlers stay in the user region and survive regeneration. This removes an old timing problem where one IDE generated source on save while another waited for the next build.

The .gui file remains plain XML. You can review it in a pull request and recover it without a proprietary database. The current editor does not watch a hand-edited .gui file while it is open, so use Refresh after an external edit.

One hardening policy before the platform split

PR #5527 adds an open-source hardening engine that runs on the merged application before it becomes Android, iOS, JavaScript, Windows, Linux, or JavaSE output. The goal is DexGuard-class resistance without protecting one port and leaving the others exposed.

The policy is intentionally port-aware. Android keeps R8 as its sole renaming tool. JavaScript skips string encryption because its native bridge can hold live string references. ParparVM skips control-flow transforms that would fight its optimizer. The common pipeline still gives one build hint, one report, and a build-specific mapping connected to Crash Protection.

Saturday's App Hardening deep dive covers the exact port matrix, string-encryption exclusions, keep rules, retrace lifecycle, and local-build boundary. It also separates hardening from App Shield and the encrypted database work still under review.

A breakpoint no longer dereferences a random local

PR #5536 fixes the signal 11 crash that could take down an iOS app when NetBeans asked for locals at a breakpoint. One debugger table had one address per JVM slot but one row per declared local. Reusing a slot for an int and later an object could pair the object row with four bytes of integer storage, then dereference it as an eight-byte object pointer.

The generated table now stores one address per row. Frame entry clears stale debugger side channels, and object references pass through a Darwin memory-read check before native code dereferences them. The same PR adds real thread enumeration, deferred breakpoint replay, scoped locals, and ready-made on-device debug actions.

The PR added 66 tests around the generated C and JDWP proxy. It did not include a tethered-device debugging session, so the merge proves the policies and generated code, not every IDE and device combination.

A skipped test is not a pass

PR #5538 found that screenshot skip markers used output names while the report parser looked only at Java class names. The marker disappeared, and the surrounding start and finish lines counted the test as a pass.

Correcting that mapping exposed 11 hidden skips on watchOS, six on tvOS, and two or three on every other port. An unknown marker now fails the reporting contract instead of disappearing.

The same investigation fixed Linux VideoIO. The CI image lacked the codec plugins it claimed to test. GStreamer returned a partial pipeline plus an error for a missing element, but the port ignored the error. The reader also asked a paused pipeline for a normal sample when the decoded frame was still the pre-roll buffer. Linux now installs the codecs, rejects partial pipelines, pulls the pre-roll frame correctly, and reports only encoders and decoders present in the GStreamer registry.

Google Sign-In now runs in an arm64 simulator

PR #5544 moves the iOS Google Sign-In integration from the old bundled 5.x framework to GoogleSignIn 7.1. The old framework had an arm64 device slice but no arm64 simulator slice. On an Apple Silicon Mac, the linker selected the device slice and rejected it.

Version 7.1 builds from source for the selected SDK. The native bridge now uses completion handlers and the current token API. We stopped at 7.1 because later versions introduce Swift dependencies that would force modular headers into every generated Podfile, including projects unrelated to Google Sign-In.

Small-object pages can return to the OS

ParparVM's BiBOP allocator segregates small objects by size class. Before PR #5540, empty pages stayed in that allocator forever. A temporary peak in small objects could therefore crowd out a later image buffer, Metal texture, or glyph atlas even after the small objects were collected.

The collector now keeps a 4 MB warm pool and releases the slot area of surplus pages. On Apple platforms it uses MADV_FREE_REUSABLE, which reduces the phys_footprint value used for memory pressure. A controlled integration test warmed 192 MB of 256-byte objects and then allocated two identical large-buffer sets. The measured peak fell from 466,224 KB to 287,824 KB, while the benchmark geomean stayed at 1.0031 relative to the no-release control.

Arm64 retains roughly one quarter of each 64 KB allocator page because its 16 KB system page also contains the allocator header. Moving that header would require a larger allocator redesign.

A retired URL now has somewhere useful to go

PR #5546 adds a /download/ compatibility page for old plugin and Ant-era links. New projects go to Initializr and Getting Started. Existing legacy projects go to the Maven migration guide.

The general 404 page now offers search plus direct routes to setup, documentation, demos, pricing, community, and legacy downloads. It is marked noindex, nofollow; normal pages remain indexable. The constrained _redirects file did not change.

Initializr now generates projects on Codename One 7.0.265 through PR #5533.

The work around the app is part of the app

The GUI Builder rewrite is about keeping control close to the artifact you ship. Forms, CSS, generated Java, and responsive behavior now share one inspectable workspace. The debugger, port reports, memory allocator, login bridge, and recovery pages all remove places where the toolchain previously hid the real state.

Security follows the same direction. Last week App Shield moved the final trust decision from the phone to the backend. Saturday's App Hardening post covers the binary layer. The open portable encrypted database PR addresses data at rest and is still under review.

These controls solve different problems. Together they move Codename One toward a secure default at each boundary: readable code in the binary, modified clients calling a server, and plaintext data on disk. That is a more useful security lead than one large checkbox with an impressive name.

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

Greetings from Thailand. My family dragged me here for a forced vacation. It is a lovely country, but beaches, sunshine, and the sea aren't really my thing. The GitHub Actions downtime didn't help either, so progress was slower than usual this week. Several interesting PRs are still in progress, and we chose not to rush them.

This week in one page

• App Shield connects device integrity, certificate pinning, and your backend instead of asking the app to trust its own verdict.

• OpenType fonts now work as .otf files across the supported ports. The CSS compiler also catches several font failures before they reach a device.

• Windows desktop builders are moving to newer machines. This is the older JavaSE Windows target, not the native Win32 target.

• The Maven repository migration has entered phase two. Newly generated projects now point dependencies and plugins at our R2 repository.

• push.codenameone.com redirects to the new cloud service on Saturday, August 8.

A local check is not a security boundary

Codename One App Shield is an Enterprise application-attestation layer. It asks Apple App Attest or Google Play Integrity for a hardware-backed statement, verifies that statement through the Codename One service, and gives the app a short-lived ES256 token. Your backend verifies that token before it performs a sensitive operation.

We already serve several banking customers, and high-security requirements have shaped Codename One for years. Java is part of that fit. These teams get mature analysis tooling, a familiar type system, and one application codebase to review instead of separate iOS and Android implementations.

Java is not a security boundary by itself. The build pipeline adds useful friction for an attacker, but determined attackers can still reverse engineer a client they control.

The distinction in the last row is the point. A modified app can force a local isDeviceCompromised() call to return false. It cannot mint a valid token signed by a key your server trusts.

From hardware statement to protected API

App Shield joins the platform attestation provider, the Codename One verification service, and your backend:

The nonce prevents a captured platform statement from becoming a permanent replay credential. The token identifies the expected package and platform, carries the policy decision, and can bind to one request body. The service can also include signals for root, jailbreak, hooking frameworks, emulators, debuggers, repackaging, or untrusted accessibility services.

Your backend remains the enforcement point. The client reports what it sees. The service evaluates the attestation and policy. Your API decides whether to move money, return personal data, request step-up authentication, or reject the call.

The app-side setup is a host list

Enable the injected engine in codenameone_settings.properties:

codename1.arg.shield.enabled=true

Then register the hosts that should receive a token:

AppShield.init(new ShieldConfig()
        // A request without a token must not leave the device.
        .protect("api.mybank.example", HostPolicy.ENFORCED)
        // Other subdomains get a token when one is available.
        .protect("*.mybank.example", HostPolicy.PROTECTED));

ConnectionRequest request = new ConnectionRequest(
        "https://api.mybank.example/transfer", true);
NetworkManager.getInstance().addToQueueAndWait(request);

When App Shield owns the application's network guard, ConnectionRequest, Rest, RequestBuilder, and other code built on NetworkManager pass through it automatically. App Shield attaches X-CN1-Attest on the network thread and checks the certificate chain against the current SPKI pin set. An unregistered host is untouched.

The two policies encode different outage choices:

If your application already has a network guard

NetworkManager accepts one NetworkGuard and seals that slot after the first call to setNetworkGuard(). In the usual setup, call AppShield.init() at the top of your application's init(Object) method, before any library or application code installs a guard.

If another guard is installed first, App Shield cannot replace it. Initialization continues, but ordinary requests receive neither the attestation token nor App Shield's certificate-pin check. This includes hosts marked ENFORCED: without the shield guard, nothing sees that policy before the request leaves the device.

An application that needs its own guard must install one composite guard and forward every callback to App Shield's guard:

final NetworkGuard shield = AppShield.getNetworkGuard();

NetworkManager.setNetworkGuard(new NetworkGuard() {
    public void beforeRequest(ConnectionRequest request) throws IOException {
        request.addRequestHeader("X-My-Trace", newTraceId());
        shield.beforeRequest(request);
    }

    public boolean isCertificateCheckRequired(String url) {
        return shield.isCertificateCheckRequired(url);
    }

    public void checkCertificates(ConnectionRequest request,
            ConnectionRequest.SSLCertificate[] certificates) throws IOException {
        shield.checkCertificates(request, certificates);
    }

    public String[] interestingResponseHeaders() {
        return shield.interestingResponseHeaders();
    }

    public void afterResponse(ConnectionRequest request, int responseCode,
            String[] headers) {
        shield.afterResponse(request, responseCode, headers);
    }
});

AppShield.init(new ShieldConfig()
        .protect("api.mybank.example", HostPolicy.ENFORCED));

AppShield.getNetworkGuard() is safe to call before init() because the guard reads the configuration when it handles a request. Forwarding only beforeRequest() is not enough. The certificate callbacks enforce the pin set, while the response callbacks let App Shield discard a rejected token. If your guard also captures response headers, return the union of both guards' header names and preserve that order when passing App Shield its values.

The simulator now has Simulate > App Shield controls for rejected attestations, expired tokens, compromised-device signals, and forced certificate-pin mismatches. That makes the failure path testable without misconfiguring a live server.

The public API lives in the open-source core. A build without the Enterprise engine degrades to a documented no-op, so shared code still compiles and runs. A cloud build that explicitly requests shield.enabled=true without entitlement fails with an explanation instead of silently producing an unprotected binary.

What App Shield does not protect

App Shield does not make an application unhackable. It raises the cost of calling a protected backend from a modified app and gives the server a cryptographically verifiable input for its policy.

A genuine attested device can still relay requests for an attacker. Short token lifetimes and payload binding reduce replay, but they do not replace backend authorization, rate limits, or checks on the business operation itself.

It also cannot cover traffic it cannot see. ConnectionRequest-based APIs get automatic tokens and pinning. A third-party native HTTP client needs a token attached manually. A BrowserComponent can receive a token for its initial navigation, but requests made by the loaded page remain outside the framework. WebSocket handshake headers are not available through the platform socket on iOS or in the browser, and WebSocket certificate pinning is not exposed.

Certificate pinning has its own operational risk. App Shield pins public keys rather than whole certificates, so a certificate renewal on the same key does not break the app. You should still roll out the server policy in monitor mode first, measure the would_deny traffic, and only then reject requests.

The complete wire format, failure statuses, transport boundaries, pin lifecycle, and backend examples are in the App Shield developer guide.

OpenType fonts now work without renaming

PR #5508 makes .otf a supported font extension across iOS, tvOS, watchOS, Android, JavaSE, JavaScript, Windows, and Linux. This corrects an inconsistent path where some tools could parse an OpenType font but device packaging ignored its extension.

You can now keep the original file in or below the directory containing your CSS:

@font-face {
    font-family: "Brand Display";
    src: url("fonts/BrandDisplay.otf");
}

Title {
    font-family: "Brand Display";
}

The CSS compiler reads local fonts during the build. It now reports a missing file, an unreadable font, a missing PostScript name, a path outside the CSS directory, or two different files that would collide after packaging. Web font formats such as .woff remain unsupported.

New builders for the JavaSE Windows target

We are bringing down the old Windows desktop build machines and replacing them with newer servers. These machines build the older JavaSE-based Windows desktop target. They are separate from the new native Win32 target.

The old builders crashed too often and held this target behind the rest of the toolchain. We expect the replacements to reduce those failures and finally make Java 17 projects available for this desktop build path. That work is still a server rollout, so treat JDK 17 as the intended result until we finish validation on real builds.

New projects now resolve Codename One through R2

Phase two of the Maven repository migration merged today. The application archetype, library archetype, and Initializr now put https://repo.codenameone.com/maven2 in both repository lists.

Maven keeps ordinary dependencies and build plugins in separate lists. Both blocks matter:

<repositories>
    <repository>
        <id>codenameone</id>
        <url>https://repo.codenameone.com/maven2</url>
        <releases><enabled>true</enabled></releases>
        <snapshots><enabled>false</enabled></snapshots>
    </repository>
</repositories>

<pluginRepositories>
    <pluginRepository>
        <id>codenameone-plugins</id>
        <url>https://repo.codenameone.com/maven2</url>
        <releases><enabled>true</enabled></releases>
        <snapshots><enabled>false</enabled></snapshots>
    </pluginRepository>
</pluginRepositories>

Newly generated builds now resolve Codename One releases through R2. Existing projects can add the same blocks before the planned August 28 cutover. We will stop publishing new versions to Maven Central on that date if the observation period remains clean. The archetype lookup itself still starts on Central; moving that lookup is phase three.

The repository migration post explains the dates, artifact retention, signatures, and safeguards against partial releases.

The push hostname switch happens Saturday

On Saturday, August 8, we will redirect push.codenameone.com to cloud.codenameone.com. We announced the new service and compatibility endpoint in the Push V3 release post.

Existing push code should continue to work because the new service accepts the classic request format. Before the redirect, you can test the exact path by changing only the hostname on your server:

-https://push.codenameone.com/push/push
+https://cloud.codenameone.com/push/push

Send a real notification to every platform you support. Test a visible notification, a data payload, and a cold start. If the result differs from the old host after Saturday's switch, open an issue or contact us through the website as soon as possible.

App Shield is the larger direction behind this release: security controls should compose across the app, the build, and the server. OpenType support, new Windows builders, the R2 migration, and the push cutover are smaller changes, but they follow the same rule. The dependable path should be the normal path, and failures should surface where we can act on them.

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

This is not a story about Maven Central being bad. Sonatype runs expensive public infrastructure and has every right to define usage limits or sell a commercial service. Our release shape is simply a bad fit for those limits, and passing that infrastructure bill to Codename One users would make less sense than serving the same signed Maven layout ourselves.

PR #5497 implements phase one. It reduces what each release publishes and adds dual publication to R2. Maven Central remains authoritative during this phase.

We first talked about the repository move in Friday's release post.

Our dashboard is not a near miss

The current Central Publishing usage dashboard reports:

That screenshot also explains Sonatype's position. It says the guidelines are soft, describes adjustments for qualifying open-source projects, and offers a commercial Publisher Pro route. We are an unusually heavy publisher, not an innocent bystander being charged for one small JAR.

The question is who should carry the cost. In Open Source Bait and Switch, I argued that monetization pressure often lands on small open-source vendors while the largest companies capture much of the value. Maven hosting is a different product and Sonatype is not changing our license. The same asymmetry is still relevant: charging a small framework company does not necessarily collect from the enterprise organizations receiving the largest downstream benefit.

We can provide package hosting free to Codename One developers on infrastructure that matches our release process. That is the more sustainable answer for us.

The migration has three visible dates

Dates are more useful than “next week” in a migration document. If validation changes the schedule, we will update this post before changing the source of new releases.

The POM change

Existing projects do not need to change during phase one. To prepare a project for new releases after the cutover, add both a repository and a plugin repository:

<repositories>
    <repository>
        <id>codenameone</id>
        <url>https://repo.codenameone.com/maven2</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
</repositories>

<pluginRepositories>
    <pluginRepository>
        <id>codenameone-plugins</id>
        <url>https://repo.codenameone.com/maven2</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </pluginRepository>
</pluginRepositories>

The plugin repository is not redundant. Maven resolves build plugins and ordinary dependencies through separate repository lists. A project with only <repositories> can download a runtime artifact and still fail to discover a future codenameone-maven-plugin.

Next week's Initializr and archetype change will generate this configuration. Existing projects can add it at any time; the repository uses standard Maven layout and does not change dependency coordinates.

We were publishing the same bytes repeatedly

The real Codename One 7.0.258 release published 44 artifacts and 127 JARs totaling 229.5 MB. The core JAR itself is only 4.49 MB. Most of the weight came from shaded fat JARs that republished the same third-party libraries each week.

Phase one reduces the measured release payload to 76.9 MB, a 66 percent reduction:

The changes are deliberately targeted:

• Five unused jar-with-dependencies attachments stop being published. Builder bundles still contain what they need.

• Stable designer, javase-svg, and sqlite-jdbc artifacts are frozen at pinned versions instead of being copied into every release.

• The headless CSS command moves out of the 43.5 MB Resource Editor fat JAR.

• A new css-cli module carries that command in a 28 KB JAR.

The CSS compiler itself had already been separated. Its command-line driver had not. Moving that driver avoids launching the complete Swing editor dependency graph for a headless build.

This optimization would not get us under the dashboard guidelines. It is still worth doing. It reduces upload time, metadata churn, retention pressure, and the number of bytes a failed release has to retry.

R2 is static hosting, which is what Maven needs

A release repository does not need a database-driven artifact server in the request path. Maven needs immutable files in a known directory layout, metadata, checksums, and signatures.

The release pipeline uploads:

maven2/com/codenameone/<artifactId>/<version>/...
maven2/com/codenameone/<artifactId>/maven-metadata.xml
maven2/com/codenameone/maven-metadata.xml
maven2/archetype-catalog.xml

The R2 publication reuses the tree already staged for Central. It includes MD5, SHA-1, SHA-256, SHA-512, and .asc signatures. There is no second Maven build that could produce different bytes.

Cloudflare's edge cache and object storage should reduce download latency and remove Central throttling from our release path. We also expect releases and CI to become faster and more stable because publication no longer depends on a second service accepting our volume at that moment. Those are expectations, not measurements yet. We will compare publish time, artifact resolution time, cache behavior, and failure rate during dual publication.

Static hosting still needs release semantics

Object storage will happily accept a partial or overwritten release unless the publishing scripts stop it. The phase-one tooling adds those rules:

1. Released bytes are immutable. An upload fails if the same path already contains different content.

2. A release is invisible until every core and editor artifact is present.

3. A per-release completion marker is written only after all uploads succeed.

4. maven-metadata.xml is rebuilt from the bucket listing, never from the one-version staging tree.

5. Metadata advertises only versions with a completion marker.

6. Upload uses a copy operation that cannot delete older versions.

7. Frozen dependencies are seeded from Central and verified against their checksums.

Cloudflare can cache a 404 just before a new artifact appears. The runbook therefore requires a cache rule that does not store 4xx and 5xx responses. Release polling also uses a cache-busting query so a stale negative cannot turn a successful upload into a false release failure.

Retention: the guarantee and the likely window

We will guarantee at least six months of historical Codename One versions in the new repository. The optimized payload currently fits roughly 106 releases in the planned capacity, which is about 1.6 years at the recent pace.

The guarantee is shorter than the estimate because release contents and frequency can change. We would rather guarantee a window we can defend and retain more in practice than publish a long promise that quietly fails.

Freezing stable packages also means “history” is no longer one full copy of every byte per weekly tag. A future version can depend on a pinned stable artifact while the frequently changing core keeps its own version cadence.

Versions already on Maven Central are not deleted by this move. The retention policy applies to the repository we operate and to future availability, not to removing the public history that Central already stores.

What can still go wrong

The red-team list is part of the design:

• A partial upload is advertised. Completion markers and metadata-last publication prevent it.

• A retry changes released bytes. The overwrite guard fails the release.

• A stale cached 404 hides a new file. The cache rule and cache-busted poll address it.

• A project adds only the dependency repository. Generated POMs include <pluginRepositories> too.

• A frozen artifact remains available only on Central. The seed step copies and verifies every pinned dependency before the final cutover.

• R2 is slower in a real region. The observation window measures this before Central publication stops.

• Three release tags arrive while one is running. GitHub Actions can replace a pending member of a concurrency group. The current runbook requires pushing release tags one at a time until dispatch is made durable.

The last item is not polished away. The repository removes one availability dependency, but it does not turn GitHub Actions into a release queue.

Why this should be mostly seamless

Coordinates, version numbers, signatures, checksums, and normal Maven resolution remain unchanged. New projects receive the repository automatically next week. Existing projects need one POM block before they request a post-cutover version.

That is the whole user-facing migration. The work underneath it is larger because package hosting is part of the product supply chain. If we do this well, developers will notice faster and more reliable resolution, not a new thing they have to learn.

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

PR #5480 adds com.codename1.maps.routing, a portable route model and service layer for road geometry, distance, duration, waypoints, alternatives, legs, steps, and encoded polylines.

We talked about routing in Friday's release post.

The two-line route

For the common case, give Routing a map and two coordinates:

MapView map = new MapView();
Routing.showRoute(
        map,
        new LatLng(38.8977, -77.0365),
        new LatLng(38.8894, -77.0352)
);

The call returns immediately. The routing service finds the best route, the API adds its polyline, and the map frames the result.

showRoute(...) is intentionally small. It is useful when the line itself is the result. An application that needs error UI, custom styling, ETA, or alternatives should use the callback route.

Own the result when it matters

RouteRequest request = new RouteRequest(origin, destination)
        .setTravelMode(TravelMode.DRIVING)
        .addWaypoint(coffeeStop)
        .setAlternatives(true)
        .setSteps(true);

Routing.findRoute(request, new RouteCallback() {
    public void routesFound(List routes) {
        Route best = (Route) routes.get(0);

        map.addPolyline(best.toPolyline()
                .setStrokeColor(0xff5722)
                .setStrokeWidth(6));
        map.fitBounds(best.getBounds(), 40);

        distanceLabel.setText(
                Math.round(best.getDistanceMeters() / 1000.0) + " km");
        etaLabel.setText(
                Math.round(best.getDurationSeconds() / 60.0) + " min");
    }

    public void routeFailed(String message, Throwable error) {
        ToastBar.showErrorMessage(message);
    }
});

The callback is invoked exactly once and always later on the Codename One EDT, even if a custom service responds synchronously, responds from a worker thread, responds twice, or throws after responding. The facade contains those service errors so application timing does not depend on the provider implementation.

The model exposes:

• One or more route alternatives

• Total distance and duration

• Geographic bounds

• Route geometry

• Legs between waypoints

• Step instructions and maneuver locations

• Provider metadata

PolylineCodec supports precision 5 and precision 6 encoded geometry. That lets a service retain the compact wire format and decode it only when a Polyline is needed.

OSRM makes the first run easy

The default RouteService is OsrmRouteService. It needs no API key, so the two-line example can work without provider signup.

That default points to the public OSRM demonstration server. The server has no production SLA and asks clients to keep usage light. It can reject large or abusive workloads, and its public profile is configured for cars.

This means:

• DRIVING is appropriate for a quick test.

• WALKING or CYCLING against the default demo can still return car routing.

• A shipping application should use a provider and capacity it controls.

• Offline routing requires another implementation.

Travel mode is a request, not a guarantee. A RouteService reports what it supports, and an application should not label a result “walking” when the active backend only has a car graph.

Point OSRM at infrastructure you control

OSRM is open source and can be self-hosted. If your server exposes an OSRM-compatible route endpoint, install it as the application service:

Routing.setService(new OsrmRouteService(
        "https://routing.example.com"
));

Use the exact constructor and endpoint configuration supported by your selected release. The architectural point is that application code still consumes Route, not provider JSON.

For a different provider, implement RouteService:

public final class CompanyRouteService implements RouteService {
    public String getId() {
        return "company-routing";
    }

    public boolean isAvailable() {
        return credentialsAreReady();
    }

    public void findRoutes(RouteRequest request, RouteCallback callback) {
        // Translate the portable request, call the provider,
        // then return portable Route objects through the callback.
    }
}

Routing.setService(new CompanyRouteService());

That seam supports commercial providers, a company gateway, an offline engine, or a route service with domain constraints such as truck height and hazardous materials.

The maps API and routing API stay separate

MapSurface displays geometry. RouteService discovers geometry. Keeping them separate avoids tying a route provider to one renderer.

The same route can be:

• Drawn on a native or vector map

• Styled according to traffic or accessibility

• Summarized as distance and ETA

• Saved as an encoded polyline

• Compared with alternatives

• Sent to another screen without retaining the map component

The API does not yet claim turn-by-turn navigation, rerouting, traffic prediction, offline map packages, or voice guidance. Those are stateful products with location updates and provider-specific rules. This release provides the route result that those systems need, without naming a static polyline “navigation.”

Production checklist

Before shipping:

1. Choose a routing service with terms, capacity, data coverage, and travel profiles that fit the application.

2. Report route failures to the user. The no-callback showRoute(...) convenience method cannot do that.

3. Verify units before displaying them. The model uses meters and seconds.

4. Test dateline crossing, unreachable points, ferries, tolls, and waypoint order for the markets you serve.

5. Keep provider keys out of client code when the provider expects a server-side secret.

6. Attribute map and routing data according to each provider's license.

A route is an answer from a changing road graph, not a decorative line. The new API finally represents it that way.

Next in the series: why Codename One is starting a staged move beyond Maven Central.

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

One puts the model inside the feature: OCR a receipt, identify a language, segment a person, or run an application-owned model.

The other lets an agent stand outside the application, inspect its semantic UI, and operate it while a developer watches. That second path is extraordinarily useful for debugging. It is also a control channel, so where it listens matters.

This week Codename One merged both parts: built-in on-device AI and MCP over a loopback socket on mobile and desktop ports.

We talked about both changes in Friday's release post.

The AI API is selective, local, and portable

The new core surface is split by job:

The public API exists on every target. A port that cannot perform an operation reports it as unsupported instead of sending data to a surprise cloud fallback.

Android uses ML Kit for the higher-level vision and language operations. Apple platforms use Vision, Core Image, and Natural Language by default where those frameworks provide the feature. Optional ML Kit support fills selected gaps on iOS. LiteRT and TensorFlow Lite execute application-owned models, with platform acceleration where available and CPU fallback.

Only referenced feature families bring their native dependencies into a build. An application using language identification does not need the document scanner, pose detector, and model runtime by association.

OCR should look like an asynchronous operation

The API owns native image conversion, lifecycle, and EDT delivery:

TextRecognizer recognizer = new TextRecognizer();
recognizer.process(VisionImage.encoded(jpegBytes))
        .ready(result -> textArea.setText(result.getText()))
        .except(error -> Log.e(error));

The result is structured, so an application can work with blocks and geometry instead of immediately flattening everything into one string.

Model inference uses a session because loading and compiling a model for every frame is expensive:

InferenceSession.open(
        ModelSource.file(modelFile),
        new InferenceOptions()
).ready(session -> {
    session.run(inputs)
            .ready(outputs -> renderPrediction(outputs))
            .except(error -> Log.e(error));
});

Close a session when the screen or feature that owns it is done. A model downloaded at runtime can go through ModelCache, which requires HTTPS and verifies the model's SHA-256 digest before the file becomes active. Model bytes are executable behavior in a different costume. Treating an unverified download as “just data” is a software supply chain mistake.

Local inference improves privacy, but does not solve it

These APIs do not upload images, text, or tensors to Codename One. That is a useful privacy property, especially for camera frames and documents.

It is not a complete privacy policy. A recognized receipt can still be logged. A translated medical note can still be copied into analytics. An application can still send an inference result to its own backend. On-device processing narrows the data path; the application remains responsible for what happens before and after the operation.

The backend capabilities also differ. Smart reply is not available through every native framework. Apple Vision support extends to Mac Catalyst for vision tasks, while unsupported desktop and browser operations fail rather than simulating an answer. Check capabilities at the feature boundary and design a real fallback.

MCP makes the running application legible to an agent

We introduced the Codename One MCP server on JavaSE first. It exposes the semantic UI tree instead of screenshots and guessed coordinates.

An agent can:

• Read ui_snapshot output

• Find a component by role, text, or semantic identifier

• Activate an action

• Set text through the component model

• Scroll the current viewport

• Observe the resulting UI state

The operations run on the Codename One EDT. A button press is a component action, not a coordinate that happens to land where the button was during one recording.

if (Display.getInstance().isDebuggableBuild()) {
    MCP.startSocketServer(8642);
}

With the new loopback transport, the same portable MCP server can run on Android, iOS, and other ports that implement loopback listening. A developer can connect through the platform's normal device or simulator forwarding path and let an agent reproduce a bug in the actual application.

This shortens a debugging conversation. Instead of “tap near the upper-right corner, unless the font is larger,” the agent can say “activate the button whose semantic text is Submit,” then inspect the error label that appeared.

Why wildcard listening was unacceptable

The existing general server socket API could listen on every network interface. On a phone connected to office Wi-Fi, that can expose a debugging control channel to the local network.

The new Socket.listenLoopback(...) contract is different:

• It binds only to the loopback interface.

• It never falls back to wildcard listening.

• An unsupported port fails on the calling thread.

• The server does not appear reachable merely because a start method returned.

That prevents accidental LAN exposure. It does not make the channel private.

Loopback is a host boundary, not an application identity boundary. Another process on the same device can try to connect. A compromised developer workstation can use an established port forward. Once connected, the client can read application UI state and invoke the actions the MCP server exposes.

The safe assumption is simple:

Starting MCP grants a local agent the ability to inspect and drive this application.

That is excellent in a debug session and a terrible surprise in a production build.

Release builds are blocked by default

MCP.startSocketServer(port) checks Display.isDebuggableBuild(). It refuses to start in release builds unless the application explicitly overrides the guard:

MCP.setAllowOnReleaseBuilds(true);
MCP.startSocketServer(8642);

That override exists for controlled test labs, managed fleets, and specialized internal deployments. Do not use it as a convenience flag in a consumer release.

JavaSE is a special case because the desktop port reports a development environment. If you package a desktop application for end users, add your own product-level gate and omit the MCP startup path from normal launch.

A defensible test-lab gate combines several conditions:

if (isInternalTestAccount()
        && isManagedTestDevice()
        && wasMcpEnabledForThisSession()) {
    MCP.setAllowOnReleaseBuilds(true);
    MCP.startSocketServer(8642);
}

The exact checks belong to the application. A hard-coded secret inside the binary is not an authentication system.

This is debugging access, not autonomous product behavior

On-device AI and MCP sit near each other in the release, but they should not be blurred together.

The AI API runs bounded application features with explicit inputs and results. MCP exposes a developer tool channel into the running UI. Neither automatically turns an application into an autonomous agent, and neither should silently send user data to a model provider.

The compelling workflow is smaller and more practical:

1. A developer launches a debuggable build.

2. MCP starts on loopback.

3. The development machine forwards the port.

4. An LLM reads the semantic UI and reproduces a reported path.

5. The developer sees the exact state transition and keeps control of the session.

6. The server disappears when the debug process ends.

That is enough to make mobile debugging dramatically more observable without pretending a control channel has no security cost.

Next in the series: road-following routes in the maps API.

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

PR #5475 merged a cross-platform health API for HealthKit, Health Connect, recorded workouts, nutrition, Bluetooth health sensors, and deterministic simulation into the core. The implementation has compile, link, and automated coverage. Real-device testing remains important for store permissions and sensor hardware.

We talked about this in Friday's release post, alongside Push V3 and the new cloud migration.

The API has four public layers

The packages are divided by the boundary they touch:

Health.getInstance() is the single entry point and never returns null. An unsupported port returns a fallback whose operations fail with HealthError.NOT_SUPPORTED. Application code branches on capabilities instead of operating-system names.

Health health = Health.getInstance();
HealthAvailability availability = health.getAvailability();
if (availability == HealthAvailability.PROVIDER_NOT_INSTALLED
        || availability == HealthAvailability.PROVIDER_UPDATE_REQUIRED) {
    health.openProviderSetup();
    return;
}
if (availability == HealthAvailability.NOT_SUPPORTED) {
    return;
}

HealthStore store = health.getStore();
store.requestAuthorization(
        HealthAccess.read(HealthDataType.STEPS),
        HealthAccess.read(HealthDataType.HEART_RATE)
).onResult((asked, err) -> {
    if (err != null) {
        Log.e(err);
        return;
    }
    // asked means the sheet completed. It does not mean read access was granted.
});

Every result, sensor sample, workout event, and change batch arrives on the Codename One EDT. That rule is the same on a phone, in the simulator, and in a local desktop store.

The strange permission answer preserves privacy

HealthKit does not tell an application whether the user denied read access. A denied read returns no data, which is indistinguishable from an empty store. That prevents an application from learning that a user chose to conceal a sensitive category.

This produces three rules that can look odd until the privacy boundary is understood:

1. A successful requestAuthorization(...) means the user was asked.

2. getReadAuthorizationStatus(...) remains UNKNOWN on iOS.

3. There is no hasReadPermission() method.

Android can report its runtime grant state, so the Android implementation answers that question. The shared API does not force HealthKit to tell a lie for symmetry.

Do not convert an empty read into “you denied access.” The accurate UI is “no data available,” with an option to open health settings. The simulator has a specific Grant Write, Deny Read Without Error mode because the happy path will not expose this mistake.

Samples keep their units and identity

The core model covers quantity, category, series, session, sleep, blood pressure, workout, and nutrition samples. A HealthQuantity has no zero-argument getValue(). The caller must name a unit:

double kilograms = sample.getQuantity().getValue(HealthUnit.KILOGRAM);

That extra word prevents a pound value from silently becoming kilograms in a chart or server payload.

Queries default to flattening Android heart-rate series into individual QuantitySample values so iOS and Android present the same common shape. Set flattenSeries to false when record identity matters, such as deletion. HealthKit has no equivalent series record, so it continues to return scalar samples.

Sample identifiers belong to the platform and the installation. They are not stable server primary keys. Arbitrary metadata currently round-trips through the local and simulator stores, but not through HealthKit or Health Connect. Keep application correlation identifiers in application storage.

High-frequency data must be paged. A year of frequent heart-rate samples can approach half a million values, so an unbounded read would be a memory bug disguised as convenience. The default cap is 10,000, and readSamplePage(...) exposes continuation.

An absent value is not zero

An aggregate bucket with no samples returns null, never zero. No reading and a measured value of zero are different facts.

Time intervals carry a similar distinction. If a chart is labeled with dates, use calendar intervals with an explicit time zone:

HealthInterval day = HealthInterval.calendarDays(1, userTimeZone);

A fixed 86,400,000 milliseconds is not a local day across daylight-saving changes. Reading the JVM default would also make a server or simulator silently file an evening walk under the wrong date.

There is one limitation developers need to see clearly: this release computes aggregates from shared raw samples. It does not use HealthKit's source-deduplicating statistics engine. If a phone and watch both record the same walk, the total can count both sources. Filter with addSource(...) and tell the user which source a number represents.

Change subscriptions are a cursor, not a wake-up service

HealthSubscription persists a cursor and restores it across launches. Reuse a stable ID such as steps-v1, then call drainChanges() when the application enters the foreground and from background fetch.

No supported platform wakes a closed application for health changes in this release. isPushDelivery() returns false everywhere.

Android uses Health Connect change tokens. It can report additions and deletions without replaying an already consumed change. A token can expire, in which case the batch reports that a full resynchronization is required.

iOS currently uses a timestamp window. It reports additions, not deletions. A backdated reading or a watch sample that syncs after the cursor has advanced can fall behind that window. Applications that require completeness must run a periodic full range query and treat the subscription as a refresh hint. A future anchored HealthKit query can close this gap without changing the public capability model.

The local and simulator stores persist subscription registration, but they do not synthesize store mutations as change events. Test phone delivery on a phone.

Workouts are recorded, not magically live

WorkoutManager can create a recorded workout session and accept samples supplied by the application or an attached sensor. isLiveSessionSupported() and isSensorCollectionSupported() are both false in this release.

That distinction matters. The framework does not claim that HKWorkoutSession or Wear OS Health Services is keeping the process alive. A recorded session lasts as long as the application process and stores only what the application feeds it.

WorkoutConfiguration config = new WorkoutConfiguration()
        .setActivityType(WorkoutActivityType.CYCLING)
        .setLocationType(WorkoutLocationType.OUTDOOR);

Health.getInstance().getWorkouts().startSession(config)
        .onResult((session, err) -> {
            if (err != null) {
                Log.e(err);
                return;
            }
            session.start();
        });

When a workout ends, its result reports what a platform would not persist. Some sensor values have no single-value Health Connect record, and this API does not pretend otherwise. The complete recorded workout remains available to the application for its own chosen storage or upload path.

Eight standard sensor profiles, without the health store

com.codename1.health.sensors covers the adopted Bluetooth SIG profiles for:

• Heart rate

• Cycling power

• Cycling speed and cadence

• Running speed and cadence

• Health thermometer

• Weight scale

• Blood pressure

• Glucose

This layer is built on com.codename1.bluetooth.le. An application can connect to a standard strap, scale, cuff, or meter without touching HealthKit or Health Connect. Sensor-only use therefore needs Bluetooth permissions, not health-store entitlements or a Play health permission review.

The implementation handles the unglamorous details that usually break field code: cumulative counter differences, timer rollover, IEEE 11073 floating-point values, reconnection, and GATT parsing.

Writing sensor measurements to the health store is off by default. A strap and the operating system might both record the same heart rate during a workout, and automatic write-through would double-count it. Attach the sensor to the recorded workout, or enable store writes only when that is truly the desired source.

Several limits are explicit:

• RR intervals are decoded, but not emitted as stored HRV samples.

• Live blood-pressure readings work, but phone-store persistence is not implemented.

• Stored glucose-record replay is not implemented.

• Sensor use on watchOS is more limited than phone and desktop support.

An explicit TYPE_NOT_SUPPORTED is less pleasant than a green check mark, but far safer than silently dropping a medical measurement.

Nutrition is sparse by design

Food contains some measured nutrients, not forty meaningful zeroes. NutritionSample therefore stores a sparse nutrient map. An absent sodium value remains null.

The complete nutrition record currently works in local and simulator stores. On phones, hydration is available on both platforms and dietary energy is available on iOS as ordinary quantity samples. Multi-nutrient phone records are rejected until their native mappings exist.

Sleep follows a similar rule. The model and local implementation are present, but phone reads are not supported in this release. A phone query fails with TYPE_NOT_SUPPORTED rather than returning an empty list that could be mistaken for a successful read.

Build configuration is intentionally strict

An iOS application that reads the store must provide a specific purpose:

ios.NSHealthShareUsageDescription=Reads step count to show weekly activity trends
ios.NSHealthUpdateUsageDescription=Saves workouts you choose to record

The HealthKit capability must also be enabled for the App ID and included in the provisioning profile.

Android requires an explicit type list and public privacy-policy URL:

android.health.read=STEPS,HEART_RATE
android.health.write=STEPS
android.health.privacyPolicyUrl=https://example.com/privacy

The build will not insert a generic purpose string. Apple reviews whether that text matches what the application does, and Google Play requires narrow permission declarations. A placeholder would defer a clear build failure into a confusing review rejection.

Health Connect also raises the Android minimum SDK to 26 and requires a target SDK of at least 30.

HIPAA is not a framework switch

This API does not make an application HIPAA compliant.

HIPAA applies to covered entities and business associates, not to every application containing health data. The relationship and data flow determine the obligation. HHS explicitly notes that an app can fall outside HIPAA after receiving data at an individual's direction, while an app acting for a covered entity may be a business associate. Read the HHS mobile health app guidance and get advice for the specific product and market.

Being outside HIPAA does not mean being outside health privacy law. The FTC's Health Breach Notification Rule guidance explains its reach into many health apps, connected devices, and related services that are not HIPAA covered.

If a cloud service creates, receives, maintains, or transmits electronic protected health information for a covered entity or business associate, HHS cloud guidance says a business associate agreement may be required even when the provider cannot decrypt the data.

The framework can enforce some useful boundaries:

• It never uploads health data.

• The simulator logs types and counts, not sample values.

• Synthetic datasets contain no person's history.

• It refuses missing purpose strings and unsupported writes.

Your application still owns access control, encryption, audit records, retention, account deletion, breach handling, backend contracts, minimum-necessary collection, consent, and store disclosures. Do not place health samples in unencrypted Storage.

Google Play separately requires a health apps declaration and privacy disclosures for health features. The current Health Content and Services policy treats Health Connect data as sensitive user data. Apple has its own HealthKit privacy and review requirements. Compliance is an application architecture, not a checkbox in a cross-platform API.

The simulator tests what a permissive fake cannot

The simulator includes a deterministic seven-day dataset, HealthKit and Health Connect permission modes, provider availability controls, one-shot failures, and the silent read-denial case.

The release test I care about most is:

1. Select Grant Write, Deny Read Without Error.

2. Request authorization.

3. Read a type that has data in the synthetic dataset.

4. Confirm the UI says “no data available.”

5. Confirm it does not accuse the user or show a technical error.

That scenario explains why parts of this API look so cautious. Health data punishes false certainty.

Next in the series: on-device AI and MCP over a guarded loopback transport.

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

This week we merged Push V3 into the Codename One core and completed its new cloud implementation. It gives an application a typed message model, managed provider credentials, subscriptions, server-side segments, campaigns, analytics, and a direct path into Surfaces.

There is also one thing every existing push developer should do now:

Change the push service URL from https://push.codenameone.com to https://cloud.codenameone.com and send a real notification through your existing code.

Next week we plan to bring down the old push service and direct push.codenameone.com traffic to the new implementation. The compatibility endpoint accepts the existing request format, so existing code should keep working. It is still a completely new server, and “should” is not a test result. Please test before the cutover while both routes are easy to compare.

TL;DR

Push is the lead story today. Over the next four posts, I will unpack the other changes in this release:

• Our own Maven repository: We are moving Codename One releases to repo.codenameone.com. New projects get the setting automatically next week. Existing projects will need a short POM block before new versions stop appearing on Maven Central.

• On-device AI and MCP: The core now has portable OCR, vision, language, and LiteRT APIs. The MCP server can inspect and operate a real application on mobile ports through loopback, with a release-build guard because another local process can also reach that socket.

• Health data: A new API covers HealthKit, Health Connect, workouts, nutrition, eight Bluetooth health sensor profiles, and a deterministic simulator. The design preserves denied reads, missing values, source overlap, and compliance boundaries instead of flattening them into convenient answers.

• Road-following map routes: Routing.showRoute(...) can now turn two coordinates into road geometry, distance, duration, legs, and steps. OSRM provides the default test path, while RouteService keeps production provider choice in application code.

Test the new push server now

If your server currently sends through the classic endpoint, keep the request exactly as it is and change only the host:

-https://push.codenameone.com/push/push
+https://cloud.codenameone.com/push/push

Send to test devices on every platform your application supports. Exercise a visible notification, a data payload, a cold start, and any badge, sound, category, image, or deep-link behavior you use. Compare the result with the old host and open an issue if the two disagree.

The new server contains a classic compatibility layer. Existing applications do not need to adopt the Java V3 client or the new REST API before the hostname switch. That separation matters: validating the new transport is a small operational change, while adopting the V3 model is an application change you can schedule.

The queue records a provider response for each target. “Accepted” means APNs, FCM, or another provider accepted the request. It does not prove that the operating system displayed the notification, that the user saw it, or that the application opened. The console keeps those states separate because a comforting number with the wrong definition is worse than no number.

V3 makes the message a real type

The classic API encoded behavior into numeric push types and positional strings. It worked, but it made provider differences and new destinations increasingly hard to express.

V3 uses an immutable schema:

PushMessage message = PushMessage.builder()
        .title("Boarding changed")
        .body("Flight CN1 42 now leaves from gate C7")
        .deepLink("myapp://trip/CN142")
        .data("tripId", "CN142")
        .ttlSeconds(900)
        .build();

The same envelope can carry visible content, application data, an image, a deep link, collapse and lifetime rules, provider-specific options, and a surface command. Incoming messages are parsed before reaching application code, exposed through immutable maps, and rejected when their schema is unsupported.

V3 also replaces the old PushCallback contract. Your main application class no longer implements the push interface. You create a PushClient and give it a PushListener:

This is more than a method rename. The listener receives a parsed PushMessage, registration returns a subscription object, and errors carry a code plus retry information.

private PushClient push;

public void init(Object context) {
    push = PushClient.builder("APP_KEY_FROM_CONSOLE")
            .listener(new PushListener() {
                public void onMessage(PushMessage message) {
                    Log.p("Push: " + message.getTitle());
                }

                public void onRegistration(PushSubscription subscription) {
                    Log.p("Registered " + subscription.getTransportId());
                }

                public void onError(PushError error) {
                    Log.p(error.getCode() + ": " + error.getMessage());
                }
            })
            .build();
}

public void start() {
    push.register();
}

Create one client in init(), retain it, and call register() from start(). Registration is idempotent. Do not unregister from stop(), because that removes the subscription rather than pausing it.

Applications that run their own push infrastructure are not trapped behind the managed service. PushTransport is a public seam for custom registration and delivery, while PushRegistrationSink lets an application mirror registration changes to its own backend.

One push can update a notification or a Surface

A lock-screen notification is only one destination. Widgets, Live Activities, the Dynamic Island, watch complications, and other Surfaces also need fresh state.

V3 reserves a typed surface object in the same envelope. Native bootstrap code can route a Surface command before the main application UI is running.

Consider a delivery application that is not running while the customer waits for a courier. A server push can update its Live Activity and Dynamic Island to say “Driver is 2 minutes away” without launching the main Codename One UI. On a platform without that Surface, the same campaign can deliver a normal notification instead.

The message view still shows whether APNs or another provider accepted each update. That is useful when the Surface changes while no PushListener is running inside the application.

The certificate stops being your server's problem

The old arrangement often made an application team generate a push certificate, place it on its own server, watch its expiry date, and repeat the process. That is fragile infrastructure disguised as setup.

The new console stores provider credentials for each application and environment. APNs can use a .p8 signing key, which does not have the annual expiry cycle of the old certificate workflow. The push service signs provider requests and isolates credentials from campaign users.

Credentials are encrypted at rest and treated as write-only secrets in the console. Reading application settings does not return the secret value. This removes certificate hosting from your application server, but it does not remove normal secret hygiene: use a narrowly scoped provider key, rotate it when a team member or system boundary changes, and separate production from development.

Segmentation without handing identity to a device

The console separates applications, environments, subscriptions, audiences, messages, campaigns, and analytics.

A device can register its provider token through the public client endpoint. It cannot declare an external user identity or attach arbitrary tags to itself. Those operations require the authenticated server API. Otherwise a modified client could simply label itself premium, administrator, or patient-high-risk and enter a segment it did not belong in.

Saved segments are evaluated on the server against application-scoped subscription data. A segment might select a locale, application version, platform, or a tag assigned by your backend. The audience is resolved when the message is sent, so a corrected tag does not require rebuilding a static mailing list.

This is segmentation for application behavior, not an advertising profile. Codename One does not sell the subscription data or combine it across customers. The service still has to retain what delivery requires: provider tokens, installation and optional external identifiers, server-assigned tags, message payloads, target status, and provider responses.

Never place a password, access token, medical result, or other secret in a notification payload. Providers and operating systems participate in delivery, lock screens can expose visible text, and notification data may outlive the screen where you intended to show it.

Monitoring that answers operational questions

The new message view exposes queued, accepted, failed, and dead targets, including provider error information.

This makes several operational checks possible:

• Is the queue moving?

• Did one provider fail while the others accepted the message?

• Are stale device tokens being removed?

• Did a rate limit delay a large audience?

• Which environment and campaign produced this message?

Analytics are retained for 30 days. They are operational delivery analytics, not proof of attention. Application opens or business outcomes still belong in consent-aware product analytics under your control.

What each plan includes

Push sending and managed provider credentials are available on every subscription level, including Free. The plans differ in monthly volume, rate limits, and persistent campaign tooling:

Free and Basic applications can send through the same durable provider pipeline. Pro adds saved templates, segments, campaigns, and analytics. Enterprise adds automation and higher operational limits. Quotas are organization and seat aware, so a team can see which allowance a notification run consumes.

These numbers are the initial policy, not a claim that every application needs a million notifications. Start with a small, explicit audience. A precise notification that helps 200 people is better than a vague blast that trains 200,000 people to turn notifications off.

Phase one of our Maven repository move

We have also merged phase one of a move from Maven Central to a Codename One repository on Cloudflare R2.

Maven Central has every right to set commercial usage limits and charge for infrastructure. Codename One also has a workload that is difficult to fit inside those limits. One release currently publishes enough duplicated fat-jar content that our dashboard reports 2.12 GB against an 80 MB storage guideline, 19,962 files against 1,000, and 27 releases against 7.

Those limits are soft guidelines, and the dashboard offers both open-source adjustments and a commercial plan. We are not leaving because Sonatype is doing something wrong. We are leaving because our weekly, multi-platform release shape is expensive to host there, while we can provide the same Maven layout free to users on infrastructure that fits it better.

Phase one reduced a measured release payload from 229.5 MB to 76.9 MB. The release pipeline now copies the signed Central staging tree to R2, so it does not perform a second build with potentially different bytes.

Existing projects can prepare for post-cutover versions by adding the repository to both Maven resolution paths:

<repositories>
    <repository>
        <id>codenameone</id>
        <url>https://repo.codenameone.com/maven2</url>
    </repository>
</repositories>

<pluginRepositories>
    <pluginRepository>
        <id>codenameone-plugins</id>
        <url>https://repo.codenameone.com/maven2</url>
    </pluginRepository>
</pluginRepositories>

The second block matters. Maven resolves build plugins separately from ordinary dependencies. Adding only <repositories> can leave a future codenameone-maven-plugin version undiscoverable.

New projects receive this automatically on August 7. Existing versions remain on Central. The new repository guarantees at least six months of history, while the optimized payload currently fits about 1.6 years at the recent release rate.

R2 object storage and Cloudflare's edge should improve dependency resolution and remove Central throttling from our release path. We also expect CI and releases to become faster and more stable. Those are expectations we will measure during dual publication, not results we have already proved.

The Maven article publishes on August 4 with the full payload audit, cutover plan, R2 release safeguards, retention policy, and failure modes we are testing during dual publication.

On-device AI and MCP on every port

PR #5467 brings vision, language, and LiteRT inference into the core. The API covers OCR, barcode recognition, face detection, image labels, pose detection, selfie segmentation, document correction, language identification, translation, smart reply, and application-owned .tflite models.

The public surface stays portable, but the work remains on the device. Android uses ML Kit for higher-level operations. Apple ports use Vision, Core Image, and Natural Language where they fit. Unsupported ports report an unsupported capability instead of silently uploading input to a cloud fallback.

OCR is deliberately asynchronous because native conversion and recognition cannot block the Codename One EDT:

TextRecognizer recognizer = new TextRecognizer();
recognizer.process(VisionImage.encoded(jpegBytes))
        .ready(result -> textArea.setText(result.getText()))
        .except(error -> Log.e(error));

Inference sessions keep an application-owned model loaded across multiple runs. Runtime model downloads can use ModelCache, which requires HTTPS and verifies the SHA-256 digest before activating the file. A model changes application behavior, so accepting unverified model bytes would be a software supply chain bug.

PR #5472 takes the existing semantic MCP server beyond JavaSE. On loopback-capable ports, an LLM can read the component tree, find a button by semantic identity, set text, activate an action, and inspect the resulting state in the actual application.

This replaces coordinate guessing with application semantics. It also creates a control channel. Binding to 127.0.0.1 prevents accidental exposure to the local network, but it does not authenticate other processes on the device or workstation.

if (Display.getInstance().isDebuggableBuild()) {
    MCP.startSocketServer(8642);
}

MCP refuses to start in a release build by default. An explicit override exists for controlled test labs, but it should not become a convenience flag in a consumer application.

The AI and MCP article publishes on August 2 with the capability matrix, portable inference model, semantic debugging loop, and the reasons loopback still needs a release-build gate.

Health data without fake certainty

PR #5475 adds a first-class API for HealthKit, Health Connect, recorded workouts, sparse nutrition data, deterministic simulation, and eight adopted Bluetooth health sensor profiles.

The public API is divided at the boundaries an application needs to reason about:

Simulator, desktop, and JavaScript builds return LOCAL_ONLY. That is a supported store with reads and writes, not a missing provider. Only Android provider failures should send the user to provider setup:

Health health = Health.getInstance();
HealthAvailability availability = health.getAvailability();
if (availability == HealthAvailability.PROVIDER_NOT_INSTALLED
        || availability == HealthAvailability.PROVIDER_UPDATE_REQUIRED) {
    health.openProviderSetup();
    return;
}
if (availability == HealthAvailability.NOT_SUPPORTED) {
    return;
}

HealthStore store = health.getStore();

Some of the API looks cautious because the platform contracts are cautious. HealthKit does not reveal whether a user denied read access. A completed authorization sheet means the user was asked, not that the application can read the category. The shared API therefore has no hasReadPermission() method that would lie on iOS.

The API preserves these distinctions throughout the model. An empty aggregate returns null, not zero. Calendar-day buckets require a time zone. Phone and watch sources remain distinguishable because silently adding overlapping samples can double-count a walk. Unsupported phone mappings fail with TYPE_NOT_SUPPORTED instead of returning an empty collection that looks successful.

The simulator includes a mode that grants writes while denying reads without an error. That lets you test the UI mistake that a permissive fake would miss: accusing a user of denying access when the only accurate statement is “no data available.”

This API does not make an application HIPAA compliant. It never uploads health data, and it can enforce specific purpose strings and reject unsupported writes. The application still owns access control, encryption, audit records, retention, consent, breach handling, backend contracts, and store disclosures.

The Health article publishes on August 1 with the platform matrix, authorization trap, sample model, change cursors, workouts, Bluetooth sensors, simulator failure modes, build configuration, and HIPAA boundary.

A polyline is not a route

A map polyline joins coordinates that already exist. It cannot discover the roads, travel time, maneuvers, or alternate paths between them.

PR #5480 adds com.codename1.maps.routing. The smallest useful path is two coordinates:

MapView map = new MapView();
Routing.showRoute(
        map,
        new LatLng(38.8977, -77.0365),
        new LatLng(38.8894, -77.0352)
);

The call returns immediately. The active RouteService finds a route, then the API draws its geometry and frames the map on the Codename One EDT.

The default service is OSRM, so the first driving route needs no provider signup. It points to the public OSRM demonstration server, which has no production SLA and uses a car profile. A WALKING request does not turn that graph into a pedestrian route.

Production applications can point OsrmRouteService at their own server or install another provider:

Routing.setService(new OsrmRouteService(
        "https://routing.example.com"
));

The application consumes portable Route objects rather than provider JSON. Those objects carry alternatives, distance, duration, bounds, geometry, legs, step instructions, maneuver locations, and provider metadata.

This is routing, not turn-by-turn navigation. The release does not claim rerouting, traffic prediction, offline map packages, or voice guidance. Those features need location updates, lifecycle state, and provider-specific rules.

The routing article publishes on August 3 with custom route styling, ETA handling, encoded polyline support, OSRM limits, travel modes, provider replacement, and the boundary between a route result and navigation.

Tomorrow I will start taking these changes one at a time with the new Health API. For today, please send a real notification through cloud.codenameone.com. This is the one week when you can compare the old and new push implementations side by side. If anything behaves differently, open an issue before we move the traffic next week.

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

ParparVM previously stored every Java String in a char[]. Class names, JSON keys, URLs, numbers, log messages, and much Western European text therefore used two bytes per code unit when one byte was enough.

The implementation follows the basic approach in JEP 254 for modern HotSpot. ParparVM also had to preserve fused allocation without adding another pointer to every string.

One field, two possible array types

Using one field for each array type would add a second reference to every string:

// We did not do this.
private byte[] latin1Value;
private char[] utf16Value;

Every string would pay for two references even though one is always null. On a heap full of short strings, that fixed cost can erase a meaningful part of the saving.

The actual shape keeps one backing reference:

@Fused
public final class String {
    // Holds either byte[] for Latin-1 or char[] for UTF-16.
    private Object value;
    private final int offset;
    private final int count;

    private char charInternal(int i) {
        Object v = value;
        return v instanceof byte[]
                ? (char) (((byte[]) v)[offset + i] & 0xff)
                : ((char[]) v)[offset + i];
    }
}

The concrete array type is the encoding marker. There is no second array reference and no separate coder field.

This does not halve the complete memory cost of every String. Object headers, the one backing reference, and the other fields remain. It halves the character-array storage when the value fits in Latin-1. Short strings save less in absolute terms; long Latin-1 strings approach the full 50 percent backing-store reduction.

Fused allocation made the layout harder

ParparVM can mark a class with @Fused. When the translator recognizes a suitable constructor, it allocates the owner and its child array in one BiBOP block. A String and its backing array can therefore need one allocation instead of two.

Before compact strings, the translator knew that String.value was a char[]. Changing the field to Object hid the child array type from the ordinary descriptor check. Dropping fusion would have kept the code simple, but it would have traded away an existing allocation and locality optimization on one of the most frequently created objects in a Java application.

The translator now handles String.value as a narrow special case. It accepts only a freshly created byte[] or char[], sizes the fused block for that concrete element type, and installs that array in the same value slot.

There is a garbage-collector constraint here too. The backing array must be initialized before the fused object becomes visible to the concurrent collector. A half-built string is not merely a performance bug; it can become a bad heap edge.

String operations keep the compact representation

Native string operations identify the backing array once and keep that check outside their character loops. They do not convert compact strings to char[] for each operation.

Numeric conversion has a direct Latin-1 path because decimal digits are known to fit. Common concatenation shapes with two to five string parts are lowered to helpers that first determine the result representation, allocate the result once, and fill it directly:

String path = "users/" + userId + "/settings";

When every part is already Latin-1, that result stays compact. If any part needs a wider code unit, the result uses char[].

Hand-written native code needed attention as well. Code that previously cast String.value directly to char[] had to go through coder-aware access. That audit matters because Java-level tests can pass while an old native cast quietly reads the wrong array layout.

Unicode still takes the correct path

Latin-1 covers code points from 0 through 255. It does not cover Hebrew, Arabic, most Asian scripts, emoji, or the rest of Unicode.

Those strings continue to use char[]:

String compact = "Résumé 2026"; // Latin-1: byte[] backing
String wide = "שלום";           // outside Latin-1: char[] backing

The representation changes storage inside the VM, not the supported character set. length(), charAt(), comparison, hashing, substring operations, encoding, and native interop retain their Java behavior.

Application code does not change. Latin-1 strings use less backing storage and remain compatible with fused allocation, native string operations, and the concurrent collector.

Start the release series with the free and open-source JavaScript port, or read about calendar synchronization, Bluetooth support, pure Codename One text editing, and lightweight rich text.

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

A SpanLabel applies one style to wrapped text. A BrowserComponent renders a complete web page. RichTextComponent covers formatted document content between those two cases and participates in ordinary Codename One layout.

Rich text inside a scrollable container

A common screen mixes formatted text with buttons, images, forms, and other Codename One components inside one scrollable container. A BrowserComponent is a poor fit for that layout because it owns a rectangular native surface and its own page viewport. The browser's document height does not naturally become the height of a child inside the parent Codename One layout.

RichTextComponent measures wrapped runs for the width it receives and reports the corresponding height. In the default SizeMode.SHRINK, it behaves like a SpanLabel: the parent container scrolls the rich text together with the surrounding components. SizeMode.SCROLL is available when the rich text should keep an assigned height and scroll its own content.

The read-only view and editor agree on paragraph attributes, inline styles, links, image runs, and wrapping because they do not maintain competing renderers.

Supply the format you already have

HTML is not the only input:

RichTextComponent view = new RichTextComponent();

view.setMarkdown("# Trip summary\n\n"
        + "Departs **09:40**, arrives *11:15*. "
        + "See the [itinerary](app://itinerary).\n\n"
        + "- Window seat\n"
        + "- Carry-on only");

form.add(view);

setContent(...) accepts RichTextFormat.HTML, MARKDOWN, ASCIIDOC, or RTF. The model covers headings, emphasis, inline code, links, images, lists, quotes, literal blocks, paragraph alignment, indentation, foreground colors, and highlights.

You can also assemble content without markup:

RichTextComponent status = new RichTextComponent();
status.append("Status: ", TextStyle.DEFAULT)
      .append("confirmed",
              TextStyle.DEFAULT
                      .withBold(true)
                      .withForeColor(0x1a7f37));

This path is useful when the content already arrives as structured application data. It avoids generating markup only to parse it again.

Links are application actions

A link target does not automatically leave the application:

view.addLinkListener(e ->
        Display.getInstance().execute((String) e.getSource()));

The event source is the target string. An https: URL can open a browser. An app: target can navigate to another form. The application owns the policy.

Images follow the same rule:

view.setImageResolver(src -> imageCache.get(src));

The component does not create a second network stack or choose a cache lifetime. The resolver returns the image for a source string, or null for a placeholder. That keeps loading, authentication, and caching in application code.

The editor supports the same formats in both directions

RichTextArea now imports and exports HTML, Markdown, AsciiDoc, and a practical RTF subset through direct model adapters. Markdown and AsciiDoc do not convert through HTML first.

RichTextArea editor = new RichTextArea();
editor.setContent(
        "# Release notes\n\nThis is **ready**.",
        RichTextFormat.MARKDOWN);
editor.insertContent(
        "{\\rtf1\\ansi {\\i pasted notes}}",
        RichTextFormat.RTF);
editor.insertContent(
        "== Details\n\n* Portable\n* Lightweight",
        RichTextFormat.ASCIIDOC);

Editing and reading the same format returns canonical output for that format. It preserves supported meaning, not the original whitespace, tag aliases, or attribute order.

Rich clipboard data uses the same negotiation. A copy can publish plain text, HTML, RTF, Markdown, and AsciiDoc together. The receiving component chooses the richest format it understands. Ports with only a plain-text system clipboard still keep the richer payload for transfers inside the application.

The importer handles document markup, not web pages

The HTML importer does not execute scripts. It supports the markup that maps to the lightweight document model. It does not implement a CSS cascade, arbitrary DOM layout, forms, video, or embedded JavaScript.

Use RichTextArea instead when the formatted document must be editable.

Validate link targets and image sources as application data. A script-free importer prevents script execution; it does not make an untrusted URL safe to open.

The viewer and editor use the same painter

The June editor implementation used a web view by default. The editor and a read-only Codename One rendering could therefore disagree on wrapping, font metrics, or supported markup.

The new path keeps editing and display on the same model and RichRunPainter. A note can move from RichTextArea to RichTextComponent without crossing a browser serialization and rendering boundary.

Yesterday's post described the operating system sending text operations into a portable document. RichTextComponent displays the same document model with the same painter and no editing session.

Try it where you currently use a BrowserComponent only to show formatted application text. Keep the browser for pages that are actually web content.

The last post in this week's series covers compact strings in ParparVM. You can also start with free and local JavaScript builds, calendar synchronization, Bluetooth support, or pure Codename One text editing.

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

Text input must handle virtual keyboards, hardware keys, autocorrect, dictation, marked text from an input method editor, bidirectional text, selection, clipboard formats, and accessibility geometry.

Codename One traditionally delegates that work to a native platform field placed over the lightweight component during editing. The overlay remains the default for TextField and TextArea. It can create a small visual jump, and it cannot participate in lightweight painting for syntax highlights, rich runs, masks, inline images, or a custom selection model.

The port sends text operations instead of key codes

A soft keyboard does not type keys. It commits words, replaces a marked composition range, deletes text around the caret, and changes selection. Dictation may insert a sentence without producing one key event.

The new TextInputClient contract models those operations:

• commitText(...) inserts final text.

• setComposingText(...) replaces the active marked-text range.

• finishComposing() accepts that range.

• deleteSurroundingText(...) implements virtual-keyboard deletion.

• onKeyCommand(...) carries navigation, selection, clipboard, undo, and redo.

• Geometry queries locate the caret and selection for candidate windows and accessibility.

All offsets use UTF-16 indices. That matches Java String, Android Editable, and Apple string APIs. The document normalizes line endings before it updates selection, undo history, formatting runs, or the state returned to the platform.

The port still owns the keyboard session. Codename One owns the document and what appears on screen.

EditField is the opt-in plain field

Existing TextField and TextArea code does not change. Use EditField when painting and editing must stay inside the Codename One component:

EditField title = new EditField("", "Title", TextArea.ANY);
title.setSingleLineTextArea(true);
title.setColumns(80);

EditField notes = new EditField();
notes.setSingleLineTextArea(false);
notes.setRows(5);
notes.setColumns(30);

Form form = new Form("Issue", BoxLayout.y());
form.add(title);
form.add(notes);
form.show();

EditField extends the shared EditorView. Caret movement, selection, scrolling, undo, clipboard commands, and input composition use the same mechanics as the rich-text and code editors.

Text input is now a port-level capability that does not require a visible native field.

The clipboard carries several representations at once

The old clipboard API usually moved a String. That remains valid, but it cannot preserve formatting or describe an image or file.

ClipboardContent represents one clipboard item through several MIME types. Include plain text as the fallback, then add the richer forms you can produce:

ClipboardContent content = new ClipboardContent()
        .setData(ClipboardContent.MIME_TEXT, "Codename One")
        .setData(ClipboardContent.MIME_HTML, "<b>Codename One</b>")
        .setData(ClipboardContent.MIME_MARKDOWN, "**Codename One**");

Display.getInstance().copyToClipboard(content);

The same container supports RTF, AsciiDoc, PNG, JPEG, GIF, and local file references. Each port maps the representations its system clipboard exposes. Code that still calls copyToClipboard("text") or expects plain text continues to work.

RichTextArea publishes five text representations when you copy a formatted selection: plain text, HTML, RTF, Markdown, and AsciiDoc. On paste, it selects the richest format it understands and imports the formatting into its document model. If the clipboard contains PNG, JPEG, or GIF bytes, the editor inserts the image inline as a self-contained data URI.

This is format negotiation, not a private editor clipboard. Other applications can paste the native formats a port publishes, and application code can inspect the available types through Display.getInstance().getClipboardContent().

Bidirectional text uses one layout for paint and hit testing

Mixed Hebrew, Arabic, numbers, and Latin text can produce a logical order different from the order on screen. It is not enough to shape the glyphs correctly. A click must land on the matching logical offset. Left and right movement must follow visual runs. A selection can span rectangles in both directions.

The editor engine uses the same bidirectional runs for painting, hit testing, caret movement, and selection geometry. The component's RTL flag sets the paragraph base direction.

That shared source of geometry also matters to native candidate windows. An East Asian IME needs to position its candidate list beside the composing range even though the visible field is not a native widget.

Rich and code editing stop being browser components

We introduced RichTextArea and CodeEditor in June with a bundled web-view backend. That got the API into applications quickly, but it kept the hardest state inside HTML and JavaScript.

The new implementation replaces the default web view with Java document and view objects:

EditorDocument
  normalized text and line offsets

EditorView
  caret, selection, composition, scrolling, clipboard, undo

CodeView
  incremental tokens, diagnostics, completion, gutter

RichView
  inline styles, blocks, links, image runs

The pure engine is now the default on every port. A port can still provide a native editor peer when it has a better specialized implementation. Application commands and asynchronous queries remain the same either way.

The JavaScript port benefits twice

The Java application runs in a Web Worker, while browser input events arrive on the main thread. The host creates an input surface for the keyboard and forwards semantic composition events across the worker boundary. The worker keeps the Java document, selection, and undo state.

That matches the architecture described in Friday's release post: Java state stays in the worker, browser behavior stays in the port layer, and the bridge carries a defined message instead of sharing a DOM object.

The Codename One Playground now uses the same CodeEditor available to applications. It does not install another editor engine. Java and CSS diagnostics enter through setDiagnostics(...), while text input uses the same worker-to-host contract as other lightweight fields.

When to keep the native overlay

The native route is mature and appropriate for ordinary forms. It receives platform text behavior directly and costs less framework code.

Use EditField or the pure editors when you need one of these:

• The glyphs must not jump when editing begins.

• Text contains several styles or inline objects.

• Selection and painting must use application-specific rules.

• The same document model must run on every target.

• A mask or diagnostic must be drawn inside the text surface.

There are tradeoffs. Each port must implement composition, state updates, command mapping, and caret geometry correctly. A missed IME edge case belongs to our binding rather than to the native field. This release adds the architecture and broad tests, not a claim that every keyboard on every device has already been exercised.

Use the native overlay for ordinary fields. Use the pure editing path when the Codename One component must own the text layout and painting.

Tomorrow's post covers a lightweight rich text component without a web view.

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

The old Cordova-derived cn1lib handled useful BLE cases on Android and iOS. The new implementation was written for Codename One and exposes the wider protocol surface through capability queries.

Each target supports the roles available from its operating system. Browsers do not expose classic Bluetooth or peripheral mode. iOS does not expose arbitrary RFCOMM. The API reports these limits instead of pretending every operation works everywhere.

Start with the role

Bluetooth is a family of protocols and roles:

The entry point never returns null:

Bluetooth bt = Bluetooth.getInstance();

if (!bt.isLeSupported()) {
    hideBluetoothFeature();
    return;
}

There are matching queries for peripheral mode, L2CAP, and classic Bluetooth. A target without a role fails with the typed BluetoothError.NOT_SUPPORTED.

Scan, connect, then discover

This scan looks for the standard Heart Rate service and a device name beginning with Polar:

Bluetooth bt = Bluetooth.getInstance();
bt.requestPermissions(
        BluetoothPermission.SCAN,
        BluetoothPermission.CONNECT
).onResult((granted, permissionErr) -> {
    if (permissionErr != null || !granted) {
        return;
    }

    ScanSettings settings = new ScanSettings()
            .addFilter(new ScanFilter()
                    .setServiceUuid(BluetoothUuid.fromShort(0x180D))
                    .setNamePrefix("Polar"));

    BleScan[] scan = new BleScan[1];
    scan[0] = bt.getLE().startScan(settings, sighting -> {
        scan[0].stop();
        sighting.getPeripheral().connect()
                .onResult((peripheral, connectErr) -> {
            if (connectErr == null) {
                peripheral.discoverServices();
            }
        });
    });
});

Filters inside one ScanFilter are combined with AND. Several filters in ScanSettings are combined with OR. Several scans can run at once, and the native scan stops when the final handle stops.

GATT operations return independent AsyncResource values. The implementation serializes them through one queue per peripheral because platform stacks allow one in-flight request per connection. A missing platform callback times out instead of wedging every later operation.

Web Bluetooth supports central GATT

On the JavaScript port, startScan(...) opens the browser's device chooser. The chooser uses your filters and returns the one device the user selects.

That call must happen from a user gesture, normally a button action. It requires HTTPS in a Chrome-family browser. The browser does not provide RSSI, repeated advertisement sightings, classic Bluetooth, L2CAP, or the peripheral role.

The same Java central-role code can still connect, discover services, read, write, and subscribe. The browser owns the permission prompt and device selection.

Display.getPlatformName().equals("js") tells you where the app runs. isPeripheralModeSupported() tells you whether the operation you need can work.

The simulator can fail on command

Hardware tests fail in the least convenient places. A device disappears between scan and connect. A GATT read never calls back. The radio turns off after a screen opens. Reproducing those cases with a physical sensor is slow.

The simulator now has a virtual Bluetooth stack:

You can stage peripherals, edit characteristic bytes, delay every callback, disconnect a device remotely, and arm the next scan, connect, read, write, discover, or subscribe operation to fail with a selected BluetoothError.

Portable tests can drive the built-in demo device without importing simulator classes:

CN.execute("bluetooth:item2"); // add SimulatedSensor
CN.execute("bluetooth:item3"); // send a notification
CN.execute("bluetooth:item8"); // fail the next GATT read

The native simulator backend takes the other route. It loads a Rust btleplug library and drives the host computer's real radio through CoreBluetooth, BlueZ, or WinRT. That gives you real central-role traffic without leaving the Codename One simulator.

Record and replay connects the two. A fixture capture scans real devices, records advertisements and GATT data, scrambles device identities, and saves JSON. The virtual stack can replay the timing and RSSI changes later in CI.

The builder injects only the roles you use

Referencing com.codename1.bluetooth is the build signal. The builders inspect which packages and types the application uses:

• A central-only Android app does not receive advertise permissions.

• A BLE-only app does not declare classic Bluetooth hardware.

• An app with no Bluetooth references gets no Bluetooth manifest, plist, framework, or native code changes.

This matters because modern Bluetooth permissions are not one checkbox. Android separates scan, connect, and advertise. iOS requires a reason string and has different background modes. Beacon applications must also opt out of Android's default neverForLocation declaration or Android 12+ can filter advertisements used for location.

The generated defaults get a build through the toolchain. Your application still needs a specific privacy explanation for Apple review.

Streams still block

Callbacks, scan results, notifications, and adapter changes arrive on the Codename One event dispatch thread. RFCOMM and L2CAP streams are the exception. Their reads and writes block, so they belong on a background thread.

Addresses have another limit. Android and desktop may expose a MAC address. iOS returns a CoreBluetooth identifier scoped to the application. Persist the value for reconnection on the same install, but do not treat it as a portable hardware identity.

The core API replaces the old cn1lib for new applications. It supports a wider set of Bluetooth roles, lets tests reproduce failures without a physical device, and keeps unused native pieces out of the build.

Tomorrow's post covers pure Codename One text editing without native overlays.

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

A request to “add this event to the calendar” often grows into editing, recurrence, provider synchronization, and conflict resolution. The new API handles those requirements through one data model instead of a platform-specific intent.

Events, recurrence, and tasks

An event can be timed or all-day. It can recur, invite attendees, carry alarms, link a conference, and belong to a provider with its own identifier and version.

CalendarEvent event = new CalendarEvent()
        .setCalendarId(calendarId)
        .setTitle("Architecture review")
        .setStart(CalendarDateTime.instant(
                start, ZoneId.of("Europe/Paris")))
        .setEnd(CalendarDateTime.instant(
                end, ZoneId.of("Europe/Paris")))
        .setRecurrence(new CalendarRecurrenceRule()
                .setFrequency(CalendarRecurrenceRule.Frequency.WEEKLY)
                .addDayOfWeek(2))
        .addAttendee(new CalendarAttendee()
                .setName("Ari")
                .setEmail("ari@example.com"))
        .addAlarm(new CalendarAlarm()
                .setTimeBefore(Duration.ofMinutes(15)));

local.saveEvent(event, CalendarMutationScope.ALL)
        .ready(saved -> Log.p("Created " + saved.getId()));

The API uses java.time. Timed values carry a zone. All-day values use a date with no invented midnight. That distinction prevents an all-day event from moving to the previous day when it crosses a time-zone boundary.

Tasks use the same source model without pretending they are events. Google Calendar and Google Tasks share one provider class. Microsoft calendars and Microsoft To Do share another.

Ask about capabilities, not platforms

LocalCalendarSource maps to Android's Calendar Provider and Apple EventKit on iOS and Mac Catalyst. The simulator gives tests an isolated in-memory calendar. It never writes to the developer's real calendar.

Online providers work anywhere the HTTP and OAuth layers work, including JavaScript and Linux:

Do not branch on Display.getPlatformName(). Ask the source:

LocalCalendarSource local = LocalCalendarSource.getInstance();
CalendarCapabilities capabilities = local.getCapabilities();

if (capabilities.supports(CalendarCapability.READ_EVENTS)) {
    local.requestAuthorization(CalendarAccess.EVENTS_READ_ONLY)
            .ready(status -> {
        if (status == CalendarAuthorizationStatus.FULL) {
            local.queryEvents(new CalendarQuery()
                    .setCalendarId("primary")
                    .setStartTime(Instant.now()))
                 .ready(page -> page.getItems()
                         .forEach(System.out::println));
        }
    });
}

Windows, native macOS desktop, Linux, and JavaScript currently report no built-in local calendar. They can still use Google, Microsoft, CalDAV, and .ics. An empty capability set is more useful than a method that compiles and fails after deployment.

A version token prevents silent overwrites

The version on a returned event is an optimistic concurrency token. Save the returned object when editing it. If somebody changed the provider copy after your read, the save returns CalendarError.CONFLICT instead of overwriting the newer change.

Offline mutation storage is opt-in:

CalendarSyncEngine sync = new CalendarSyncEngine(
        google, new StorageCalendarCache("google-account-1"));

sync.queueEventSave(event, CalendarMutationScope.ALL);
sync.sync().ready(result -> {
    for (CalendarConflict conflict : result.getConflicts()) {
        // Show local and remote versions, then choose
        // KEEP_LOCAL, KEEP_REMOTE, or MERGED.
    }
});

The cache stores calendar data and pending mutations. It does not store OAuth credentials. Your application decides when background work runs and how a person resolves a conflict.

Creating the event is one operation. The version and sync APIs preserve the user's changes when another device or provider edits the same record.

Provider sync is pull based

Local stores can emit CalendarChange callbacks. Online providers return sync or delta tokens. Store the token and pass it with the next query.

The API deliberately leaves Google and Microsoft webhooks to the application backend. Provider webhooks require a public endpoint, secret handling, renewal, and delivery policy that a client API cannot supply for every application.

Google and Microsoft OAuth credentials also belong to your application. The provider classes never embed a shared Codename One client secret and never persist credentials on your behalf.

CalDAV supports Basic, Bearer, and Digest authentication. Basic should only travel over HTTPS. Server implementations differ. Each asynchronous result can still report a collection-specific restriction.

Import and export use the same model

ICalendarCodec reads and writes RFC 5545 events, tasks, alarms, recurrence, attendees, time zones, URI attachments, and unknown X- properties:

String ics = ICalendarCodec.writeEvent(event);
CalendarEvent imported = ICalendarCodec.readEvent(ics);

The codec supports email attachments, backups, provider interop, and ports with no local calendar service. Imported objects enter the same save, query, and conflict flow as objects created through the Java API.

Unused applications carry none of it

The builders detect calls to the local calendar entry points. Android then adds calendar permissions. Apple builds add EventKit and the relevant privacy strings.

An application that never references local calendar integration gets no permission or entitlement change. Online providers do not require device-calendar permissions.

The portability boundary remains explicit:

• Local change notifications depend on the operating system.

• Online notification is token-based polling, not an installed webhook.

• OAuth setup and credential storage remain application responsibilities.

• Conflict resolution requires a product decision. The framework cannot decide which edit matters.

Use the platform intent when your requirement ends after creating one event. Use CalendarSource when your application must read, update, synchronize, or resolve conflicts.

Tomorrow's post covers Bluetooth support across every Codename One target.

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

PR #5389 turns those questions into the Codename One Port Status page. It maps 49 user-facing feature groups across 10 portability targets to current conformance results, environment data, skip reasons, and the date of the run.

The table is an output, not an opinion

The HelloCodenameOne suite already exercises APIs and screenshot goldens on Android, iOS, tvOS, watchOS, JavaScript, native Linux, native Windows, and Mac Catalyst. The missing part was a contract that translated thousands of test cases into a stable public vocabulary.

The new conformance mapping connects registered tests and screenshots to rows such as networking, media, databases, maps, notifications, input, accessibility, and 3D. CI normalizes each port's result into the same report format. A publishing workflow writes the latest reports to a data-only branch. The website consumes those reports and renders the matrix.

The page currently renders 490 feature cells. Ten targets appear because architectures and renderer variants matter. iOS Metal and legacy OpenGL are separate evidence paths. Windows x64 and ARM64 are separate. Linux x64 and ARM64 are separate.

JavaSE is deliberately excluded from the public portability matrix. It is the simulator and development runtime, not one of the deployed native targets the table is meant to prove.

A green cell has a chain of evidence

Each status report records the commit, environment, registered tests, outcome, duration, and skipped cases. The website data also records the runtime used for browser and platform evidence. For example, the current browser environment file names the Chromium, Firefox, and WebKit engine versions rather than saying “modern browsers.”

The contract itself is validated in CI:

python3 scripts/hellocodenameone/conformance/port_status.py validate
python3 -m unittest -v \
  scripts/hellocodenameone/conformance/test_port_status.py
node scripts/website/validate_port_status.mjs

Validation fails if a registered conformance test or screenshot golden is orphaned from the public mapping, if the mapping points to a test that no longer exists, or if the published reports do not satisfy the schema. That makes the page part of the test system instead of a second table someone has to remember to edit.

Skipped does not always mean unsupported

Some tests cannot run meaningfully on a target even when the API works. A device-only test may need hardware. A store API may require credentials. A screenshot can be irrelevant on watchOS because the phone-sized fixture is cropped before it tests the intended behavior.

The status page keeps skips visible and attaches a reason. It does not silently convert every skip to “unsupported,” and it does not turn every skip into a green claim either. This distinction is important when a feature is supported but its current CI proof covers only part of the behavior.

The deployment section applies the same standard to minimum versions. It separates the declared floor from the environment CI actually ran. An iOS build may compile with an iOS 14 deployment target while hosted CI runs the current Xcode 26 simulator. The page says both. A compiled floor is evidence, but it is not the same as running on an iOS 14 device.

Benchmarks use the same application

The page also carries ten common workloads through each generated application: integer and long arithmetic, transcendental math, sequential and random arrays, allocation, map churn, string building, recursion, and quicksort.

3 warm-up runs
5 measured runs
report the minimum measured time
verify the workload checksum

These are absolute per-target timings, not a claim that an ARM watch should beat a desktop CPU. Their value is trend detection and a common workload inside the actual generated port application.

Binary size and memory are intentionally absent. The current artifacts mix compressed Android and web packages with unpacked Apple bundles and native executables. The ports also report different memory concepts. Publishing those numbers in one comparison row would look precise while measuring different things. They will return when a dedicated release-mode fixture packages and samples every target consistently.

What a green test cannot prove

A green status means the mapped tests passed in the named environment at the recorded commit. It does not prove that no application can hit a bug. It does not extend the test to OS versions, devices, drivers, or permissions that the run did not exercise.

That boundary is why the page exposes details instead of collapsing everything to a marketing checkmark. You can inspect the target environment, last run, mapped coverage, and reason for an exception. If the proof is narrower than your requirement, the page should make that visible before you commit to a platform.

This also changes how we review a new API. Adding the Java class is no longer enough. A feature needs a conformance test, a mapping to a public capability, and green results on the ports we claim. If a port intentionally does not implement it, that scope must be explicit.

One place to start a platform decision

Use the Port Status page when you need the current deployment floors, architecture coverage, API evidence, browser engines, or common-workload results. Then follow the linked test detail for the part your application depends on.

This closes the week's series: measured native-theme fidelity, a standalone Settings tool, external surfaces, portable accessibility semantics, and an MCP server built on that semantic tree. The common thread is not the number of features. It is turning claims into artifacts you can inspect.

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

PR #5377 lets an agent consume it too.

The JavaSE port can expose a running simulator or Codename One desktop tool as a local Model Context Protocol server. Codex, Claude Code, Claude Desktop, opencode, or another MCP host can inspect the current form, find a field by label, enter text, activate a button, and call tools published by the application.

The agent reads meaning, not coordinates

Screenshot automation sees colored rectangles and guesses where to click. MCP exposes the same resolved semantics that accessibility technology receives:

{
  "id": "profile-save",
  "role": "button",
  "label": "Save",
  "enabled": true,
  "actions": ["activate"]
}

The agent can ask for ui_snapshot, find profile-save, then invoke activate. It does not need to assume the button stayed at yesterday's x and y coordinates.

The built-in tools are small on purpose:

Every action runs on the Codename One event dispatch thread. The agent never mutates the live component tree from the MCP transport thread. Each action returns a fresh snapshot so the next decision uses current state.

Starting a server is explicit

There is no build hint that quietly exposes an application. Calling the API is the switch:

MCP.startSocketServer(8765);

The socket mode is useful for a running simulator session a person can watch. A tool launched directly by an MCP host can use standard input and output instead:

MCP.startStdioServer();

The JavaSE port owns the stdio transport because process standard input is not available on every Codename One target. While the transport is active, normal application logging is redirected away from standard output so it cannot corrupt the newline-delimited JSON-RPC stream.

Desktop tools get a menu without application code

The JavaSE port adds an MCP menu to the simulator and Codename One desktop tools, including the new Settings editor. The menu can expose the running tool, detect installed MCP hosts, install or remove the local host registration, and control debug logging.

Registration uses a small bridge. Most local MCP hosts launch servers over stdio. The visible Codename One tool is already running and listens on a loopback socket. MCPStdioLauncher relays between the host's stdio connection and that socket.

Coding agent <-- stdio --> MCPStdioLauncher <-- loopback --> running tool

This is how an agent can drive the actual Certificate Wizard or Settings window in front of you instead of launching a hidden copy with different state.

Your app can publish domain tools

UI actions are useful, but some operations should not be simulated as clicks. An application can expose a typed Tool with a JSON schema and handler:

MCP.addTool(new Tool(
        "current_user",
        "Returns the signed in user",
        "{\"type\":\"object\",\"properties\":{}}",
        argumentsJson -> "{\"name\":\"" + signedInUser + "\"}"
));

The server merges application tools with the built-in UI tools. Codename One already uses the same com.codename1.ai.Tool contract for model tool calls inside an app, so one definition can serve an in-app model and an external MCP host.

Treat these tools as a privileged API. Do not publish a tool that returns signing passwords, API tokens, or unrestricted file contents because the handler happens to be local. The current server is local, but the agent still receives whatever the tool returns.

Screenshots remain available

The semantic tree means a vision model does not need a screenshot for routine navigation. Some UI facts remain visual, such as a chart shape or a rendering defect. The server therefore exposes the current form as an optional PNG resource too.

The two sources complement each other. The tree says “this is an enabled Save button with an activate action.” The PNG says “the button overlaps the footer.” A screenshot alone cannot reliably provide the first fact. A semantic tree cannot provide the second.

The scope is JavaSE today

This release supports the JavaSE port, which covers the simulator and JavaSE-hosted desktop tools. It does not make every packaged Codename One application an MCP server. Packaged executable jars, cloud desktop builds, mobile targets, the JavaScript port, and the native macOS, Linux, and Windows ports do not yet have the launcher and transport plumbing.

If you need MCP in one of those native targets, let us know which port and deployment model you need. The protocol engine and semantic tools are portable. The missing work is the transport, startup, registration, and security boundary for that target.

The PR includes 13 protocol and UI-driving tests plus an end-to-end run against the reference MCP Inspector client. It also builds the core into an iOS application to verify that unused MCP code is pruned and that referenced core classes stay within the ParparVM API surface.

Tomorrow's post covers another machine-readable view of Codename One. The new port status page turns the test suite into a dated support matrix instead of asking you to trust a manually maintained table.

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

I worked with accessibility experts at Sun Microsystems and learned how deep the problem goes. A label is the easy part. Real accessibility needs roles, values, ranges, actions, traversal order, live announcements, collections, focus, platform conventions, and a way to test all of it. That complexity is why full Codename One accessibility support sat dormant for a decade.

We eventually added setAccessibilityText(). It was useful, but it was the poor man's version. PR #5363 replaces that single-label model with a portable semantics tree we can be proud of.

Lightweight UI needs a second tree

Codename One paints lightweight components into its own native surface. VoiceOver cannot inspect a Button as a UIKit button because there is no UIKit button there. TalkBack cannot walk an Android View hierarchy because most of the painted controls are not Android views.

The new accessibility manager builds an immutable virtual tree beside the visual component tree. Standard controls infer their semantics. Custom controls can replace or extend them. Each port exposes that virtual tree through the platform accessibility API.

The visual and semantic hierarchies can differ. A card made from five labels might need to read as one item. A chart may paint 200 points from one component, but expose each meaningful point as a virtual child. A renderer-backed list can expose stable rows even though those rows are not component instances.

Standard components work without annotations

Buttons, checkboxes, radio buttons, sliders, text fields, lists, tables, tabs, labels, dialogs, and containers infer their normal roles, values, states, and actions. Existing setAccessibilityText() calls continue to work as a compatibility alias for the semantic label.

You only add code when the inferred result is incomplete or the UI represents something more specific:

Button save = new Button("Save");
save.getSemantics()
        .setHint("Saves the edited profile")
        .setIdentifier("profile-save");

A custom switch can supply its role and checked state:

wifiSwitch.getSemantics()
        .setRole(AccessibilityRole.SWITCH)
        .setLabel("Wi-Fi")
        .setChecked(AccessibilityCheckedState.CHECKED)
        .setEnabled(Boolean.TRUE)
        .setHint("Double tap to turn Wi-Fi off");

Identifiers are for tooling and stable tests. Labels are for people. Keeping them separate avoids tests that break when product copy changes.

Semantics are more than labels

The API covers the parts a label-only layer cannot express:

• AccessibilityRange describes minimum, maximum, current value, step size, and spoken value for sliders and progress controls.

• AccessibilityAction exposes standard activation plus named actions such as Archive or Delete.

• AccessibilityGrouping merges descendants, treats a container as a group, or hides decorative subtrees.

• Sort keys and traversal constraints change reading order without changing paint order.

• Collection metadata describes row and column counts, spans, position in a set, and selection behavior.

• Live regions announce status changes with polite or assertive priority.

• Virtual child providers expose semantic items that have no component instance.

Here is a chart exposing each data point as an accessible virtual child:

chart.getSemantics().setChildProvider(owner -> {
    List<AccessibilityNode> result = new ArrayList<>();
    for (ChartPoint point : points) {
        AccessibilityNode node = new AccessibilityNode(
                "point-" + point.getId());
        node.setRole(AccessibilityRole.IMAGE)
                .setLabel(point.getLabel())
                .setValue(point.getFormattedValue())
                .setBounds(point.getBounds());
        result.add(node);
    }
    return result;
});

That same tree can represent a list cell, a map marker, a game menu item, or any custom renderer where the meaningful objects do not map one-to-one to components.

Preferences can change the UI before a screen reader arrives

Accessibility includes users who never enable VoiceOver or TalkBack. The new APIs expose high contrast, reduce motion, reduce transparency, differentiate without color, and known color-vision deficiency preferences.

if (CN.isHighContrastEnabled()) {
    chart.setUIID("HighContrastChart");
}
if (CN.isReduceMotionEnabled()) {
    chart.putClientProperty("animate", Boolean.FALSE);
}
if (CN.isReduceTransparencyEnabled()) {
    chart.setUIID("OpaqueChart");
}
AccessibilityColorVisionDeficiency colorVision =
        CN.getColorVisionDeficiency();
if (CN.isDifferentiateWithoutColorEnabled()
        || (colorVision != AccessibilityColorVisionDeficiency.NONE
        && colorVision != AccessibilityColorVisionDeficiency.UNKNOWN)) {
    status.setText("Disconnected: action required");
}

Color must never be the only signal for important state. The preference is an extra input, not permission to hide the text or icon when the preference is absent.

The simulator now lets you force these states, including combinations that are awkward to reproduce on a physical device.

The inspector audits the resolved tree

The Component Inspector has an Accessibility tab that shows the tree the platform will receive. It flags unlabeled interactive nodes, duplicate identifiers, invalid ranges, contradictory state, traversal cycles, and other machine-detectable failures.

You can put the same checks in a unit or screenshot test:

AccessibilityTreeSnapshot tree =
        AccessibilityInspector.snapshot(form);

AccessibilityAssertions.assertNoErrors(tree);
AccessibilityAssertions.assertNoUnlabeledInteractiveNodes(tree);

AccessibilityNodeSnapshot save =
        tree.getNodeByIdentifier("profile-save");
if (save.getRole() != AccessibilityRole.BUTTON) {
    throw new AssertionError("profile-save must expose the button role");
}
if (save.getAction(AccessibilityAction.ACTIVATE) == null) {
    throw new AssertionError("profile-save must expose the activate action");
}

The snapshot is immutable and can be serialized as JSON. That makes failures reviewable in CI and gives a bug report something more precise than “VoiceOver skipped my button.”

Every platform still gets a human pass

An automated audit can prove that an interactive node has a label. It cannot prove that VoiceOver speaks the right sentence, that TalkBack focus recovers after a dialog closes, or that a Windows screen-reader user understands a custom collection.

The final check still uses VoiceOver, TalkBack, Narrator, Orca, Java Access Bridge, or browser accessibility tools. Navigate in both directions. Activate every action. Change adjustable values. Enter and leave collections. Trigger errors and live updates. Confirm focus after navigation, deletion, and modal dialogs.

That is the boundary. The portable semantics tree removes the architectural wall and makes most behavior testable once. Platform assistive technologies still apply their own presentation rules.

The surprise is that this tree also describes the screen to software. Tomorrow's post shows how the same immutable snapshot lets an AI agent inspect and drive the simulator over the Model Context Protocol without relying on screenshot coordinates.