Codename One's GUI Builder has been rebuilt for a third time, shifting from a single-form editor to a project-wide workspace launched via a Maven goal (mvn cn1:guibuilder). It preserves the second generation's LayeredLayout-based guided layout system while adding live CSS editing against the real theme.css, a Java code view that protects generated regions, and IDE integrations for IntelliJ, NetBeans, Eclipse, and VS Code. Alongside the builder rewrite, several other changes ship: a cross-platform app hardening engine (port-aware renaming, string encryption, control-flow obfuscation) ahead of platform-specific builds; a fix for an iOS on-device debugger crash caused by mismatched debug-table addressing; corrected skipped-test reporting that had been miscounting skips as passes on watchOS, tvOS, and other ports plus GStreamer fixes on Linux; a move to GoogleSignIn 7.1 to support arm64 iOS simulators; ParparVM memory allocator changes that return surplus small-object pages to the OS; and new redirect/recovery pages for retired legacy URLs.
Table of contents
This week in one pageThree builders, three different projectsOne Maven goal opens the projectGuided layout survived the rewriteCSS belongs beside the canvasGenerated Java is visible, but not disposableOne hardening policy before the platform splitA breakpoint no longer dereferences a random localA skipped test is not a passGoogle Sign-In now runs in an arm64 simulatorSmall-object pages can return to the OSA retired URL now has somewhere useful to goThe work around the app is part of the appQuestions this post answers
How do I launch the Codename One GUI Builder for a Maven project?
Run mvn cn1:guibuilder -DclassName=com.example.ProfileForm from the project root, after creating the form pair with mvn cn1:create-gui-form -DclassName=com.example.ProfileForm. This opens a project-wide workspace showing every .gui file under src/main/guibuilder, rather than a separate editor session per form. IntelliJ IDEA, NetBeans, Eclipse, and VS Code all ship shortcuts that invoke the same goal. daily.dev helps Java developers track tooling changes like Codename One's Maven-based GUI Builder workflow.
Why did Google Sign-In on iOS fail to build in an Apple Silicon simulator in Codename One apps?
The bundled GoogleSignIn 5.x framework only shipped an arm64 device slice, not an arm64 simulator slice, so the linker on Apple Silicon Macs selected the device slice and rejected it. Codename One moved the integration to GoogleSignIn 7.1, which builds from source for the selected SDK and uses completion handlers with the current token API. Later GoogleSignIn versions were avoided because they pull in Swift dependencies that would force modular headers into every generated Podfile. Teams shipping iOS sign-in flows can follow dependency version tradeoffs like this one on daily.dev.
How much memory can ParparVM's BiBOP allocator reclaim after a temporary spike in small object allocations?
In a controlled integration test, warming 192 MB of 256-byte objects and then allocating two identical large-buffer sets peaked at 466,224 KB before the fix versus 287,824 KB after ParparVM began releasing surplus small-object pages back to the OS, using MADV_FREE_REUSABLE on Apple platforms. The benchmark geomean stayed at 1.0031 relative to the no-release control, indicating negligible performance cost. Developers tuning mobile memory footprints can track allocator changes like this via daily.dev.