Blog: developer workflow (on-device debugging + JUnit 5)#5086
Merged
Conversation
Consolidated follow-up to the May 29 weekly index. Combines what were previously two separate posts into one themed post about how the dev iteration loop changes this release: - On-device debugging (PRs #4999 iOS + #5012 Android): JDWP through to real devices and the iOS / Android simulators, so jdb, IntelliJ, VS Code, Eclipse, and NetBeans attach against Java source. The three iOS pieces (translator instrumentation, device runtime, JDWP proxy) and the smaller adb-orchestration Android half. - JUnit 5 against the JavaSE simulator (PR #5032): @CodenameOneTest, @RunOnEdt, @SimulatorProperty, and the visual-config annotations (@theme, @DarkMode, @LargerText, @orientation, @rtl). junit-jupiter scope change so JUnit does not leak onto the simulator runtime for apps that do not opt in. Both together push the dev loop on device closer to what it looks like on a regular JVM application.
- "I" voice replaced with "we" or "Codename One"-flavoured phrasing throughout. Opening hook, "this is the Java code I wrote" line, the "thing that surprised me" section, the wrap-up. - Heading and prose for "the thing that surprised me" reworked so the surprise is framed as something the team noticed rather than a personal anecdote. - Wrap-up rephrased so the "two pieces of paving" sentence reads as a team observation rather than a personal opinion.
- New opening that does not start with the "Two things this post" fragment. - Supported targets clarified: iOS = simulator or real iPhone over Wi-Fi from a Mac (the "USB pairing" language is gone). Android = USB, wireless adb, or the emulator (all three). - New paragraph spelling out that iOS still needs a Mac in the pipeline because the bits come from Xcode (locally or via the build server). - Dev-guide references go to the HTML version on the website (/developer-guide/#_on_device_debugging_ios etc.), not to the asciidoc source. - Step-by-step IntelliJ tutorial for iOS: enable the four build hints (using the in-settings names, no codename1.arg. prefix), recommend leaving the block-on-load option on so the on-device-debug variant is visible, run the proxy, attach the debugger, launch the app. - Same shape Android tutorial. - Device-console behaviour and its caveat called out explicitly. - Capability note up front: Android can step through native C/C++ via Android Studio's LLDB alongside the JDWP attach; iOS cannot. - "The thing that surprised us" section removed. - "Why the two changes pair" section removed. - JUnit section rewritten: explicit that it is standard JUnit 5 (not a fork), com.codename1.testing.junit holds annotations + CodenameOneExtension, AbstractTest stays for on-device tests. - Tutorial: file location, minimal example, plain-validator variant, visual-config variant, @SimulatorProperty variant. - Testcontainers / WireMock no longer in the example list. - Hero image lands at /blog/developer-workflow-debug-and-junit.jpg. - IntelliJ debugger screenshot lands at /blog/developer-workflow-debug-and-junit/intellij-debugger-on-device.png. - "Back to the weekly index" link to the intro post in the wrap-up.
Contributor
Cloudflare Preview
|
Two reviewer-driven fixes.
1. The "iOS still needs a Mac somewhere in the pipeline" framing
was technically true but misleading -- the build cloud has a Mac,
so a developer working on Linux or Windows does not need a local
one to debug a real iPhone. The supported-targets section now
says that explicitly: the Mac is only required for the local
Xcode build path and for the iOS Simulator. The Build Cloud
handles the iOS build and the JDWP attach works over Wi-Fi from
any OS.
2. The Android paragraph no longer talks about not-needing-a-Mac
(redundant). It now talks about needing the Android SDK platform
tools (adb) on the developer machine, and that those are
available on macOS, Linux, and Windows.
3. Replaced both ASCII data-flow boxes with real Mermaid diagrams.
New {{< mermaid >}} shortcode + an inline ESM loader (gated by
window.__cn1MermaidLoaded so multiple diagrams on one page only
initialise once).
The loader can't live in extend_footer.html because PaperMod calls
that partial via partialCached keyed on layout/kind, so any per-page
conditional content there ends up shared across every page sharing
the same cache key. Inlining the loader in the shortcode dodges
that completely; pages without a mermaid shortcode never see the
loader.
Verified locally with `hugo --buildFuture`: the developer-workflow
post is the only page on the site that emits the loader.
The Cloudflare PR preview build was hiding the new on-device-debug post because its front-matter date (2026-05-30) is one day past the current build date. Hugo skips future-dated posts unless --buildFuture is set. - scripts/website/build.sh now reads HUGO_BUILD_FUTURE (default "false") and HUGO_BUILD_DRAFTS (default "false") and passes --buildFuture / --buildDrafts to Hugo when set. Production behaviour unchanged. - .github/workflows/website-docs.yml sets HUGO_BUILD_FUTURE=true on pull_request runs and "false" on the merged-to-master deploy. So reviewers see staged posts on the *.pages.dev preview; the live site still only shows posts on or after their publish date.
- JUnit example now boots the project's app class through init() / start() instead of constructing a Form in the test. Asserts against the form the app actually opens; that exercises the same startup path the simulator runs, which is what most apps want to test. - Maven command is "mvn -Ptest test" (the project's test profile), not "mvn -pl javase test". - Added IntelliJ-gutter screenshot and JUnit-results screenshot to the test tutorial. The screenshots make the IDE flow the primary example; the command-line version is below. - The "fastest iteration loop" remark on the local-Xcode-build bullet is removed; both build paths are presented as equivalent. - Block-on-load reasoning rewritten. The concern is not "an app that does nothing"; it is (a) launching an on-device-debug build while the proxy is not running and not realising it is silently waiting, and (b) mistaking the on-device-debug build for a release build and being surprised when it does not perform as smoothly. - Native-interface capability section rewritten. The previous "Android Studio's LLDB lets you step into C / C++" framing was wrong; Codename One native interfaces are Java on Android, so the JDWP attach steps through them like any other class. On iOS the Impl is Objective-C; JDWP can't step through it, but framework code, your own Java, and the values the call returns are all still available, so most workflows still hold. Attach Xcode in parallel for the Objective-C body if you need it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
adb-orchestration story.@CodenameOneTest,@RunOnEdt,@SimulatorProperty/@SimulatorProperties, and the visual-config annotations (@Theme,@DarkMode,@LargerText,@Orientation,@RTL); thejunit-jupiterscope change so JUnit does not leak onto the simulator runtime for apps that do not opt in.File
docs/website/content/blog/developer-workflow-debug-and-junit.md— single new file.Sequencing
Branches off
master; intended to publish the day after the weekly index (#5074). Front matter date is2026-05-30.Supersedes the closed PRs #5075 (on-device debugging) and #5079 (JUnit) which I had originally written as separate posts.
Test plan
docs/websitesucceeds./static/blog/developer-workflow-debug-and-junit.jpg.