DEV Community: Shai Almog

Why Codename One Is Moving Beyond Maven Central

Shai Almog — Tue, 11 Aug 2026 14:16:04 +0000

Codename One is starting a staged move from Maven Central to a repository we operate on Cloudflare R2.

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:

Measure	Codename One	Dashboard guideline	Reported use
Storage	2.12 GB	80 MB	2,652%
Files	19,962	1,000	1,996%
Releases	27	7	386%

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

Date	Phase	User impact
July 31, 2026	Reduce release payload and start dual publishing	None. Central remains authoritative.
August 7, 2026	Generated projects and Initializr add the Codename One repository	New projects receive the repository automatically. Existing projects can add it manually.
August 28, 2026	Stop publishing new Codename One versions to Central, if the dual-publish period is clean	Existing projects need the Codename One repository to discover future versions.

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:

	Per release	Versions in 8 GB	Approximate history at 65 versions per year
Before	229.5 MB	35	6 months
After	76.9 MB	106	1.6 years

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:

Released bytes are immutable. An upload fails if the same path already contains different content.
A release is invisible until every core and editor artifact is present.
A per-release completion marker is written only after all uploads succeed.
maven-metadata.xml is rebuilt from the bucket listing, never from the one-version staging tree.
Metadata advertises only versions with a completion marker.
Upload uses a copy operation that cannot delete older versions.
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.

A Polyline Is Not a Route

Shai Almog — Mon, 10 Aug 2026 14:43:58 +0000

A polyline can draw the points you give it. It cannot discover the road between 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.

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:

Choose a routing service with terms, capacity, data coverage, and travel profiles that fit the application.
Report route failures to the user. The no-callback showRoute(...) convenience method cannot do that.
Verify units before displaying them. The model uses meters and seconds.
Test dateline crossing, unreachable points, ferries, tolls, and waypoint order for the markets you serve.
Keep provider keys out of client code when the provider expects a server-side secret.
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.

On-Device AI and MCP on Every Port

Shai Almog — Sun, 09 Aug 2026 13:43:42 +0000

There are two very different ways to connect AI to an application.

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

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:

Package	Capabilities
`com.codename1.ai.vision`	OCR, barcode recognition, face detection, image labels, pose detection, selfie segmentation, and document correction
`com.codename1.ai.language`	Language identification, translation, and smart reply
`com.codename1.ai.inference`	Reusable application-owned `.tflite` inference sessions and verified model downloads

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:

A developer launches a debuggable build.
MCP starts on loopback.
The development machine forwards the port.
An LLM reads the semantic UI and reproduces a reported path.
The developer sees the exact state transition and keeps control of the session.
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.

Health Data Without Fake Certainty

Shai Almog — Sat, 08 Aug 2026 13:40:17 +0000

The hardest part of a health API is not reading a heart-rate number. It is knowing what that number means, which store supplied it, whether anything is missing, and what the application is legally allowed to do next.

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:

Package	Responsibility
`com.codename1.health`	Health stores, permissions, samples, units, queries, aggregates, sources, change subscriptions, and errors
`com.codename1.health.workout`	Recorded workout sessions, events, configuration, and collected samples
`com.codename1.health.sensors`	Live standard Bluetooth health devices, independent of HealthKit or Health Connect
`com.codename1.health.nutrition`	Sparse nutrient records and nutrition-specific types

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:

A successful requestAuthorization(...) means the user was asked.
getReadAuthorizationStatus(...) remains UNKNOWN on iOS.
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:

Select Grant Write, Deny Read Without Error.
Request authorization.
Read a type that has data in the synthetic dataset.
Confirm the UI says “no data available.”
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.

Push V3: One Message From Your Server to Every Surface

Shai Almog — Fri, 07 Aug 2026 14:08:16 +0000

Push notifications should be application infrastructure, not a pile of expiring certificates and provider-specific JSON.

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:

Previous API	V3 API
`PushCallback.push(String value)`	`PushListener.onMessage(PushMessage message)`
`registeredForPush(String deviceId)`	`onRegistration(PushSubscription subscription)`
`pushRegistrationError(...)`	`onError(PushError error)`

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:

Plan	Monthly deliveries per seat	Requests per minute	Recipients per minute	Persistent audiences and campaigns	Automation
Free	1,000	30	100	No	No
Basic	5,000	120	1,000	No	No
Pro	1,000,000	600	10,000	Yes	No
Enterprise	10,000,000	3,000	100,000	Yes	Yes

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:

Package	Responsibility
`com.codename1.health`	Stores, permissions, samples, queries, aggregates, sources, and change cursors
`com.codename1.health.workout`	Recorded workout sessions, events, configuration, and collected samples
`com.codename1.health.sensors`	Live standard Bluetooth health devices without requiring a phone health store
`com.codename1.health.nutrition`	Sparse nutrient records where an absent value remains absent

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.

Compact Strings Cut Character Storage in Half

Shai Almog — Wed, 05 Aug 2026 15:10:15 +0000

PR #5421 adds compact strings to ParparVM. Strings that fit in Latin-1 now use a byte[]; strings that need wider code units continue to use char[].

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.

A Lightweight Rich Text Component Without a Web View

Shai Almog — Tue, 04 Aug 2026 15:30:13 +0000

PR #5421 adds RichTextComponent, a read-only component for formatted application text. It supports headings, inline styles, lists, links, and images without embedding 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.

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.

Content and layout	`Label` / `SpanLabel`	`RichTextComponent`	`BrowserComponent`
Simple text	✓ Best fit	Works, but unnecessary	Works, but adds a browser
Mixed with other Codename One content	✓	✓	Separate browser surface
Child of a scrollable Codename One container	✓ Participates in parent layout	✓ Measures its content and participates in parent layout	Owns a separate viewport and scrolling surface
Simple HTML or formatted document content	Convert to plain or uniformly styled text	✓ HTML, Markdown, AsciiDoc, and RTF	✓ HTML
Complex HTML, CSS, forms, video, or 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.

Pure Codename One Text Editing Without Native Overlays

Shai Almog — Mon, 03 Aug 2026 15:39:51 +0000

PR #5386 adds a pure Codename One text-editing path. EditField, RichTextArea, and CodeEditor can now keep their document, selection, and painting inside the lightweight UI while each port supplies keyboard and input-method events.

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.

Bluetooth Support Across Every Codename One Target

Shai Almog — Sun, 02 Aug 2026 14:25:14 +0000

PR #5399 moves Bluetooth into the Codename One core and adds implementations for every target, including JavaScript. The API covers BLE central and peripheral roles, GATT, L2CAP, classic RFCOMM, simulator fixtures, and native desktop radios.

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:

Role	What it does	Main targets
BLE central	Scan, connect, discover GATT, read, write, subscribe	Android, iOS, desktop, JavaScript
BLE peripheral	Advertise and serve a local GATT database	Android, iOS, simulator
L2CAP	Bidirectional byte streams with more throughput than GATT chunks	Android 10+, iOS 11+, simulator
Classic RFCOMM	Serial streams for printers, scanners, and industrial devices	Android, desktop, simulator
Native simulator backend	Drive the computer's real Bluetooth radio	macOS, Linux, Windows simulator

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.

Calendar API: Local Calendars, Cloud Sync, and Conflict Handling

Shai Almog — Sat, 01 Aug 2026 14:23:54 +0000

PR #5413 adds com.codename1.calendar, a cross-platform API for local calendars and cloud providers. It covers events, tasks, recurrence, incremental sync, offline changes, and conflict handling.

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.

The Codename One JavaScript Port Is Now Free and Open Source

Shai Almog — Fri, 31 Jul 2026 15:13:59 +0000

The Codename One JavaScript port is now open source and available on every plan, including Free. You can also build the JavaScript target locally without a Codename One account.

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 #5423 makes our ParparVM-based port the default and moves its source under the same GPLv2 with Classpath Exception license as the rest of Codename One. TeaVM remains available as a fallback.

TL;DR

JavaScript: The ParparVM JavaScript port is now open source, free on every plan, and buildable locally without an account.
Android API level 36: API 36 becomes the default next week, and you can test or temporarily override it with build hints.
ParparVM garbage collection: A real application exposed a benchmark gap, redundant collection cycles, and a broken first fix.
Calendar: The new API covers device and cloud calendars, recurrence, tasks, incremental sync, offline mutations, and conflict handling.
Bluetooth: Bluetooth moved into the core with BLE, GATT, L2CAP, RFCOMM, Web Bluetooth, desktop radios, and a scriptable simulator.
Text editing: EditField, RichTextArea, and CodeEditor can edit and paint text without placing a native field over the component. The new clipboard model carries rich text, images, and file references alongside a plain-text fallback.
Rich text: RichTextComponent renders HTML, Markdown, AsciiDoc, RTF, and styled Java runs without a web view.
Compact strings: Strings now use a byte[] when every character fits, cutting their character storage in half without adding a second backing-array pointer.
Account, website, and videos: The authorization migration is complete, the redesigned site is live, and the weekly posts now generate explainer videos.

Why we built the ParparVM JavaScript port

Our original web port used TeaVM, which is a fantastic project. TeaVM took Java bytecode, supported the threading model Codename One needed, and produced a browser application at a time when that combination looked close to impossible.

ParparVM already powered other Codename One targets when we built a second JavaScript route on top of it. If we had understood how much work this would require, we might have spent that effort improving the TeaVM integration instead. The finished port gives us direct control over the VM, runtime, browser integration, and test infrastructure.

VM-level APIs can now reach the web target through the same translator and Java runtime work used by our native ports. We no longer need a separate implementation in a third-party runtime before the browser can use a new VM API.

Shared framework and runtime changes also trigger the ParparVM browser suite. Pull requests render and compare the Codename One test application in Chromium. A nightly job starts generated applications in Chromium, Firefox, and WebKit.

The port also keeps Java and browser code separate:

The old route ran translated Java beside its JavaScript integration on the browser's main thread. The ParparVM route puts the translated Java application in a background Web Worker instead. The Java code has no document, no DOM, and no dependency on global browser objects.

A thin message bridge connects the worker to the standard front-end JavaScriptPort, which runs on the browser's main thread. The port handles the canvas, DOM, clipboard, media, Web Bluetooth, and other browser APIs. Application-specific browser code stays under native/JavaScript.

Browser APIs still impose browser rules. Web Bluetooth requires HTTPS and a user gesture, for example. Those requirements stay in the port layer instead of affecting ordinary Java code.

Build the web target without our cloud

Generated Maven projects now include a local JavaScript command:

mvn -pl javascript package \
  -Dcodename1.platform=javascript \
  -Dcodename1.buildTarget=local-javascript

The build uses the bundled ParparVM compiler and JavaScriptPort resources. It produces a static browser application on your machine. The same command is wired into generated IntelliJ, Eclipse, NetBeans, and VS Code projects.

Cloud builds also use ParparVM by default. If you encounter a regression, compare it with the original TeaVM route by adding one build hint:

javascript.port=teavm

The full selector is:

Build hint	Result
`javascript.port=parparvm`	Current JavaScriptPort builder and the default.
`javascript.port=teavm`	Original TeaVM builder for compatibility and diagnosis.

TeaVM is not being removed. It remains useful for compatibility testing while ParparVM gains more production use.

The proxy is part of deployment now

A browser application can call its own origin directly. Calls to another origin depend on that server's CORS policy. Codename One has traditionally handled the second case with a servlet proxy bundled into the TeaVM WAR.

That proxy came from an older Java EE stack. It calls a servlet API removed from current Jakarta containers, so changing javax.servlet imports to jakarta.servlet would not fix it.

The ParparVM builder now creates a proxy wrapper for the deployment target you choose:

javascript.proxy.target=cloudflare-workers
javascript.proxy.allowedTargets=https://api.example.com,*.services.example.org

Available targets are jakarta-servlet, javax-servlet, node, php, aws-lambda, google-cloud-functions, cloudflare-workers, and none. Jakarta Servlet is the default.

Set javascript.proxy.allowedTargets before public deployment. An omitted allowlist produces a build warning because an open forwarding proxy is not a safe default for production. You can also point at an existing proxy with javascript.proxy.url or disable generation with javascript.proxy.target=none.

Why we are making JavaScript available to everyone

JavaScript builds were previously an Enterprise feature and a significant reason to purchase that plan. We expect this change to reduce some of that revenue. For a small company, that matters, and this was a difficult decision for me to make.

Paid plans continue to fund the cloud build machines, push service, Crash Protection, support, version retention, and the people doing this work. If your team relies on the paid services, keep supporting the work through the plan that fits your needs.

We do not know whether wider adoption will replace the revenue we lose. We do know that making the port easier to use and test is the right technical direction.

Android API 36 becomes the default next week

Some developers are already receiving Google Play notices about Android 16 and API level 36. Issue #4466 gave us time to test edge-to-edge behavior, resizing, permissions, and native integrations before changing the default.

Try the new target now:

android.targetSDKVersion=36

Please send a build and exercise the parts of your application that touch system UI, background behavior, Bluetooth, notifications, and native libraries. Once 36 becomes the default, you can temporarily pin the previous toolchain while a regression is investigated:

android.buildToolsVersion=35
android.targetSDKVersion=35

Issues like #4466 are how a small team keeps pace with Apple, Google, browser vendors, desktop platforms, and hardware changes. If you see a platform announcement that could affect Codename One, open an issue early. A short warning months ahead is far cheaper than an emergency migration after a store deadline.

Issue #5425: Dave was right about our collector

In issue #5425, Dave reported an iOS workload that took roughly five minutes while the same code finished in seconds on Android and on the older ParparVM collector. I focused on the allocation-heavy application code and dismissed the regression. Dave reduced the temporary allocation, kept measuring, and showed that my explanation did not fit the result.

He was right. Our recent BiBOP collector work made short-lived small objects much cheaper, but the benchmark set did not cover a large retained population followed by larger allocations. The fixed trigger could run collection far too often even when the retained set gave it little to reclaim.

PR #5436 added an issue-shaped benchmark and adaptive pacing. The first fix also introduced a fresh-object tracing bug that could free a live child and leave its parent pointing at reused memory. Dave's repeated build against master exposed corrupted dictionary words and an impossible null pointer. PR #5442 fixed that correctness regression and added a focused audit.

Versioned builds against the current development head made that feedback loop possible:

build.cn1Version=master

Dave could test each collector revision in his real application while we changed it.

Thanks, Dave. I needed the bump on the head.

Calendar API: local calendars, cloud sync, and conflicts

TL;DR: com.codename1.calendar provides one API for device calendars, Google, Microsoft, CalDAV, and .ics files. It includes recurrence, tasks, provider versions, incremental sync, offline mutation queues, and conflict handling.

A request to add an event often grows into recurrence, edits from another device, offline changes, and a stale write that could overwrite a newer provider copy. The new API keeps those cases in one model and exposes the operations supported by each source.

LocalCalendarSource source = LocalCalendarSource.getInstance();
CalendarCapabilities capabilities = source.getCapabilities();
if (capabilities.supports(CalendarCapability.READ_EVENTS)) {
    source.queryEvents(query).ready(page ->
            page.getItems().forEach(System.out::println));
}

The simulator uses an isolated in-memory calendar, so tests never touch the developer's real schedule. PR #5413 contains the implementation. Read the calendar API article for recurrence, OAuth boundaries, conflict resolution, and provider synchronization.

Bluetooth is now part of the core

TL;DR: The new core Bluetooth API supports every Codename One target, including JavaScript. It covers BLE central and peripheral roles, GATT, L2CAP streams, classic RFCOMM, browser Web Bluetooth, real desktop radios, and a scriptable simulator.

Bluetooth is larger than BLE scanning. A medical sensor might need notifications over GATT. A scanner or printer might use classic RFCOMM. Tests need to reproduce a failed connection or a callback that never arrives.

The API reports capabilities instead of pretending every role works everywhere. Browsers provide central GATT through a user-controlled chooser. iOS does not expose arbitrary RFCOMM. Applications that do not reference Bluetooth receive none of its permissions or native code.

PR #5399 is a ground-up replacement for the Cordova-derived cn1lib. Read the Bluetooth article for the role model, platform matrix, GATT queue, simulator, and builder behavior.

Pure Codename One text editing

TL;DR: EditField, RichTextArea, and CodeEditor can now edit and paint text entirely inside the Codename One component layer. The operating system supplies keyboard and input-method operations without placing a native field over the component.

Codename One traditionally places a native text field over a lightweight field while the user edits. That route remains the default for TextField and TextArea. It works well for ordinary forms, but it cannot paint syntax colors, inline objects, application-defined masks, or custom selections inside the Codename One surface.

The new TextInputClient contract sends semantic operations such as commitText(...), setComposingText(...), and deleteSurroundingText(...). The portable editor owns the document, caret, selection, bidirectional layout, undo state, and pixels.

EditField notes = new EditField();
notes.setSingleLineTextArea(false);
notes.setRows(5);
form.add(notes);

This work also replaces the text-only clipboard assumption. A ClipboardContent can carry several representations of one item: plain text, HTML, RTF, Markdown, AsciiDoc, PNG, JPEG, GIF, and file references. The port publishes the formats its system clipboard supports while retaining plain text for older code and applications that do not understand the richer payload.

RichTextArea uses that negotiation directly. Copying a formatted selection publishes plain text, HTML, RTF, Markdown, and AsciiDoc together. Pasting chooses the richest text representation it understands, while a clipboard image becomes an inline image instead of a filename or discarded payload.

PR #5386 adds the port bindings and portable editor engine. Read the text-input article for composition, UTF-16 offsets, bidirectional hit testing, rich clipboard negotiation, and the native-overlay tradeoff.

Lightweight rich text without a web view

TL;DR: RichTextComponent renders HTML, Markdown, AsciiDoc, RTF, and styled Java runs inside ordinary Codename One layouts. It shares its document model and painter with RichTextArea but has no editing session or browser peer.

A SpanLabel gives wrapped text one style. A BrowserComponent provides a complete browser. RichTextComponent fills the space between them for formatted application content.

RichTextComponent view = new RichTextComponent();
view.setMarkdown("# Trip summary\n\n"
        + "Departs **09:40**. See the [itinerary](app://itinerary).");
form.add(view);

The component measures its content inside the Codename One layout. Link handling, image loading, authentication, and caching remain under application control. The HTML importer handles document markup but does not execute scripts or implement a CSS page layout.

PR #5421 contains the viewer and shared painter. Read the rich-text article for supported formats, link and image policies, clipboard negotiation, and when to keep BrowserComponent.

Compact strings in ParparVM

TL;DR: Strings now store their characters in a byte[] when every character fits. Text that needs wider code units continues to use char[]. This halves the character storage for common strings without adding a second array pointer to every String.

URLs, JSON keys, class names, numbers, log messages, and much Western European text need one byte per character. ParparVM previously stored all of them in a two-byte char[].

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

The implementation keeps one Object value field whose concrete array type identifies the representation. The translator also preserves fused allocation, where the String fields and backing storage occupy one BiBOP block. Application code does not change.

Read the compact-strings article for the object layout, fused-allocation changes, native-operation audit, and Unicode behavior.

Account, website, and video updates

Authorization migration

We finished the account authorization migration started last week. We shut the old authorization server down too early, brought it back while we fixed the remaining paths, then shut it down again.

You may need to sign in again the next time you send a build. If a fresh login does not work, contact us through the website chat. It is still the fastest route to the team.

New website design

PR #5402 shipped a new website design and rewrote several core pages. Tell us what works, what gets in the way, and what we should improve.

Videos generated from these posts

The Codename One YouTube channel now has explainer videos generated from these posts. PR #5441 adds the video builder, written in Codename One, that turns a reviewed script into timed scenes, narration, code, subtitles, and a final video.

Video editing is not my cup of tea. The generated voice does not bother me, and removing hours of narration and timeline work means we can cover more of what ships. The question is whether those videos help you. Should we invest in this format and use it to replace the aging courses, or would you rather see fewer videos with human narration? Please tell us.

Port Support You Can Trace Back to a Green Test

Shai Almog — Wed, 29 Jul 2026 15:06:17 +0000

“Supported on iOS, Android, desktop, and web” sounds useful until you need one method on one target. Does WebSocket work on watchOS? Which Linux architectures do we build? Was the JavaScript media test green this week, or did somebody update a table six months ago and forget it?

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

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.

DEV Community: Shai Almog

Why Codename One Is Moving Beyond Maven Central

Our dashboard is not a near miss

The migration has three visible dates

The POM change

We were publishing the same bytes repeatedly

R2 is static hosting, which is what Maven needs

Static hosting still needs release semantics

Retention: the guarantee and the likely window

What can still go wrong

Why this should be mostly seamless

A Polyline Is Not a Route

The two-line route

Own the result when it matters

OSRM makes the first run easy

Point OSRM at infrastructure you control

The maps API and routing API stay separate

Production checklist

On-Device AI and MCP on Every Port

The AI API is selective, local, and portable

OCR should look like an asynchronous operation

Local inference improves privacy, but does not solve it

MCP makes the running application legible to an agent

Why wildcard listening was unacceptable

Release builds are blocked by default

This is debugging access, not autonomous product behavior

Health Data Without Fake Certainty

The API has four public layers

The strange permission answer preserves privacy

Samples keep their units and identity

An absent value is not zero

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

Workouts are recorded, not magically live

Eight standard sensor profiles, without the health store

Nutrition is sparse by design

Build configuration is intentionally strict

HIPAA is not a framework switch

The simulator tests what a permissive fake cannot

Push V3: One Message From Your Server to Every Surface

TL;DR

Test the new push server now

V3 makes the message a real type

One push can update a notification or a Surface

The certificate stops being your server's problem

Segmentation without handing identity to a device

Monitoring that answers operational questions

What each plan includes

Phase one of our Maven repository move

On-device AI and MCP on every port

Health data without fake certainty

A polyline is not a route

Compact Strings Cut Character Storage in Half

One field, two possible array types

Fused allocation made the layout harder

String operations keep the compact representation

Unicode still takes the correct path

A Lightweight Rich Text Component Without a Web View

Rich text inside a scrollable container

Supply the format you already have

Links are application actions

The editor supports the same formats in both directions

The importer handles document markup, not web pages

The viewer and editor use the same painter

Pure Codename One Text Editing Without Native Overlays

The port sends text operations instead of key codes

EditField is the opt-in plain field

The clipboard carries several representations at once

Bidirectional text uses one layout for paint and hit testing

Rich and code editing stop being browser components

The JavaScript port benefits twice

When to keep the native overlay

Bluetooth Support Across Every Codename One Target

Start with the role

Scan, connect, then discover

Web Bluetooth supports central GATT

The simulator can fail on command

The builder injects only the roles you use

Streams still block

Calendar API: Local Calendars, Cloud Sync, and Conflict Handling

Events, recurrence, and tasks

`EditField` is the opt-in plain field