Switch initializr JavaScript build to local ParparVM target#5200
Open
shai-almog wants to merge 14 commits into
Open
Switch initializr JavaScript build to local ParparVM target#5200shai-almog wants to merge 14 commits into
shai-almog wants to merge 14 commits into
Conversation
The initializr javascript module previously built via the remote `javascript` build target (cloud build server). Switch it to the local `local-javascript` target, which routes through CN1BuildMojo#doJavaScriptLocalBuild -> JavaScriptBuilder (ParparVM bytecode -> JavaScript translator). Automate mode still authenticates with the server secret, so the build pipeline is unaffected. Changes (all under scripts/initializr/): - javascript/pom.xml: codename1.defaultBuildTarget javascript -> local-javascript - build.sh / build.bat: explicit -Dcodename1.buildTarget -> local-javascript (these override the pom default) - README.adoc and bundled skill docs (SKILL.md, build-and-run.md, native-interfaces.md): document the JS build as local ParparVM, with the cloud `javascript` target noted as the fallback Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The local-javascript build failed in the initializr/website pipeline because JavaScriptBuilder.checkUserLevel() only accepted an explicit javascript.userLevel / CN1_USER_LEVEL / codename1.userLevel property. The website build (build_initializr_for_site -> set_cn1_user_token) authenticates by writing the CN1 user+token to the /com/codename1/ui preferences node (SetUserTokenMojo / cn1:set-user-token), not by setting a userLevel property, so the gate rejected an authenticated build. Honor that login directly: if a CN1 user+token is present in prefs the local JS build is authorized, the same way the cloud build is. The explicit userLevel property remains a fallback for logged-out CLI use. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Compared 128 screenshots: 128 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
The website CI builds the initializr against the released codenameone
plugin (cn1.plugin.version=7.0.250), whose JavaScriptBuilder license
gate only reads the javascript.userLevel / CN1_USER_LEVEL /
codename1.userLevel inputs -- it does not yet honor the logged-in CN1
account. set_cn1_user_token performs the login, but the released gate
still rejected the build ("JavaScript build failed").
Declare codename1.arg.javascript.userLevel=Enterprise in the shared
initializr settings so the released plugin's gate is satisfied. The
javascript module's getCN1ProjectDir() resolves to ../common, so this
flows into the build request as the javascript.userLevel arg. The
companion plugin change lets newer plugins accept the login directly,
at which point this declaration is redundant but harmless.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
With codename1.buildTarget=local-javascript the ParparVM builder emits a zip whose entries are nested under a single top-level directory (e.g. Initializr-js/index.html), whereas the cloud result.zip is flat with index.html at the root. The website extraction therefore failed its "missing index.html after extraction" check. After unzip, if index.html isn't at the root, flatten a single top-level wrapper directory so the served initializr-app layout is identical for both the local and cloud builders. No-op for the flat cloud bundles (Playground/Skin Designer still build via the cloud javascript target). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Compared 128 screenshots: 128 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
The Initializr page template references /initializr-app/icon.png. The
cloud build's bundle shipped that icon; the local ParparVM bundle does
not, so the link/image validator failed ("Cannot find file ...
initializr-app/icon.png").
Copy scripts/initializr/common/icon.png into the extracted bundle when
it is absent, so the served layout matches the cloud build.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Compared 77 screenshots: 77 matched. Benchmark Results
|
Contributor
Cloudflare Preview
|
Collaborator
Author
|
Compared 124 screenshots: 124 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 121 screenshots: 121 matched. |
Native-interface stubs (com_<pkg>_<Class>.js) generated by StubGenerator end with `})(cn1_get_native_interfaces());` and self-register into that registry. The accessor is defined only in fontmetrics.js, which loads on the main thread; the worker imports the stubs via importScripts but never loads fontmetrics.js, so the IIFE throws "ReferenceError: cn1_get_native_interfaces is not defined" and aborts worker startup before jvm.start(). Any app with a JS-port NativeInterface (e.g. the Initializr's WebsiteThemeNative) therefore never boots; HelloCodenameOne has none, so the screenshot suite never caught it. Define a worker-local registry before the imports, mirroring the existing getParameterByName worker-local shim. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
✅ ByteCodeTranslator Quality ReportTest & Coverage
Benchmark Results
Static Analysis
Generated automatically by the PR CI workflow. |
The local ParparVM JavaScript builder (codename1.buildTarget= local-javascript) and its fixes live in the repo's 8.0-SNAPSHOT plugin, not the pinned 7.0.250 release the initializr was building against. So the preview never exercised the repo's builder/translator/JS-port — the native-interface worker fix, the login-aware license gate, etc. could not take effect. Mirror the Playground/Skin Designer path for the initializr: - cn1-local-workspace profile now overrides cn1.version AND cn1.plugin.version to 8.0-SNAPSHOT (was a vestigial 7.0.250 re-pin). - build_initializr_for_site bootstraps the local snapshots and builds with -Dcn1.localWorkspace=true under the bootstrapped JDK 17. - bootstrap_local_cn1_snapshots is now idempotent (the full reactor build runs once even though all three site apps call it). - website-docs.yml sets WEBSITE_BOOTSTRAP_CN1_SNAPSHOTS=true so the preview builds the site apps against repo HEAD. Validated locally: the initializr JS bundle builds against 8.0-SNAPSHOT and its worker.js carries the cn1_get_native_interfaces registry shim. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
NativeLookup.create() returned null on the ParparVM JS port: there was
no <Iface>Impl, the cn1_native_interfaces registry was never read, and
the worker imported the JS stub (which crashed on the undefined
cn1_get_native_interfaces). Native interfaces simply weren't wired.
Implement them end to end, modeled on the cloud builder's
JSStubGenerator/NativeLookup.register flow but adapted to the
worker/host-call model so the developer's JS impl runs on the MAIN
thread (DOM access), as it must:
- JavaScriptBuilder: scan staged classes for NativeInterface subtypes
and generate a <Iface>Impl per interface whose methods box their args
and delegate to NativeInterfaceBridge.call*. The launcher emits
NativeLookup.register(iface, impl) so create() resolves and the
optimizer keeps the impl (otherwise reached only reflectively).
- NativeInterfaceBridge (com.codename1.impl.platform.js -> HOST_HOOK):
call{Boolean,Int,...,String,Object,Void}(iface, method, args). The
worker suspends and the call replays on the main thread.
- browser_bridge.js: main-thread handlers look up
cn1_native_interfaces[iface][method_], invoke it with (args..., {
complete, error }) and resume the worker via the host callback.
- JavascriptBundleWriter: native-interface stubs (identified by the
cn1_get_native_interfaces marker) load on the MAIN thread (index.html)
and are excluded from the worker importScripts.
- parparvm_runtime: marshal Java String -> JS string in
toHostTransferArg so the iface/method names reach the host correctly.
- worker.js: drop the earlier worker-local registry shim (the
degrade-in-worker approach); stubs no longer load in the worker.
The existing JS impl format (cn1_native_interfaces["<pkg>_<Iface>"]
["<method>_<paramTypes>"](args..., callback)) is preserved so stubs
work as-is. Validated locally: the initializr bundle's
WebsiteThemeNativeImpl is reachable and emits callBoolean/callVoid
host-hooks; browser_bridge registers the handlers; index.html loads the
stub and the worker does not. boolean/void/numeric returns are complete;
String/Object/long return wrapping is a follow-up.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collaborator
Author
Native Windows portCompared 125 screenshots: 124 matched, 1 updated.
|
Extend native-interface support to every NativeInterface type (all
primitives, String, the primitive arrays byte[]/int[]/long[]/double[]/
float[]/boolean[]/char[]/short[], and String[]) in both directions.
- NativeInterfaceBridge: per-primitive call* + callString/callVoid/
callObject, plus a typed callArray(iface, method, args, componentToken)
for array returns.
- JavaScriptBuilder: <Iface>Impl return-type dispatch routes arrays to
callArray with the element's component token (JAVA_INT.../
java_lang_String) and boxes primitive args into the Object[].
- JavascriptNativeRegistry: the call* symbols are RUNTIME_IMPLEMENTED so
the translator defers to the worker-side wrappers.
- parparvm_runtime.js: bindNative wrappers funnel through the single
__cn1_native_interface_call__ host hook and coerce the resolved JS
value to the declared Java type -- createJavaString (String/String[]),
_LfromNumber (long/long[]), jvm.newArray(token) (typed arrays),
int/short/byte/char/float/double normalisation. toHostTransferArg now
unboxes argument values too (boxed Integer/Long/.../Boolean -> JS
primitive, long {__l} -> number) so primitive/long/array arguments
marshal correctly to the host.
- browser_bridge.js: one __cn1_native_interface_call__ handler dispatches
to cn1_native_interfaces[iface][method](args..., callback).
Verified in the local initializr bundle: no "Missing javascript native
method" stubs remain, the bindNative wrappers/array builder are present,
and WebsiteThemeNativeImpl is reachable. PeerComponent returns route
through callObject (best-effort) pending dedicated peer wrapping.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Complete the supported-type set with com.codename1.ui.PeerComponent in both directions: - Return: the generated <Iface>Impl wraps the call result with PeerComponent.create(callObject(...)). The host returns the native element; cn1InvokeNativeInterface now host-ref-wraps any non-array object result (hostResult) so the un-cloneable DOM element survives postMessage to the worker and works as an HTMLElement JSO receiver (the JSO bridge dispatches on __cn1HostRef). PeerComponent.create routes to HTML5Implementation.createNativePeer -> new HTML5Peer((HTMLElement)..). - Argument: a PeerComponent param is passed as peer.getNativePeer() (the underlying native element / host-ref), not the Java peer wrapper; toHostTransferArg already marshals the host-ref. The method key uses the _com_codename1_ui_PeerComponent suffix. Validated by temporarily adding int[]/String[]/PeerComponent methods to a native interface and rebuilding: the generated impl compiles (callArray with JAVA_INT/java_lang_String tokens, PeerComponent.create, getNativePeer) -- malformed codegen would have failed javac. Reverted the temp methods; the initializr's WebsiteThemeNative (boolean/void) still builds clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The translator emits translated_app.js one statement per line with generous indentation for readability; in a deployed bundle that indentation + blank lines is ~20% dead weight the browser must download and (more importantly) parse. Strip per-line leading/trailing whitespace and drop blank lines before writing each chunk -- safe regardless of ASI or // comments since newlines are preserved (one statement per line). Initializr translated_app.js: 11.93 MB -> 9.58 MB raw (-2.36 MB, ~20%), cutting parse time. Set -Dparparvm.js.pretty=true to keep the readable form for debugging the generated code. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…thods Per-suspension-boundary emission step: in methods with no exception wrapper (~91% of methods), a throwing instruction (method call, field/ array access, NEW, ...) no longer forces its own case + pc=N+1; break; tail. That break+redispatch existed only so exception unwind could resume at the right frame pc; with no handler wrapper a thrown error propagates straight out of the generator and yield* resumes inline via delegation, so it's pure overhead. - computeJumpTargets takes forceThrowingTargets; only adds the post-throw i+1 target when the method has an exception wrapper. - mergeThrowing (gated !hasTryCatch, kill switch parparvm.js.merge.throwing.off) extends the safe-strip to throwing ops. Modest on its own (~0.21MB; case scaffolding is only ~7% of the bundle -- the bulk is per-bytecode statement emission, addressed by the expression-folding work that follows) but a correct foundational step. node --check clean; CI JS screenshot suite is the functional gate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add buildBasicBlocks() (instruction list -> basic blocks + successor edges) and isAcyclicForward() as the foundation for the structured control-flow (relooper) emitter that will replace the verbose while(true) switch(pc) state machine with if/else (and later while/for) for reducible CFGs -- keeping the generator threading model but emitting far more compact JS. Pure analysis: nothing consumes it for emission yet, so output is unchanged. The acyclic-if/else emitter (slice 1) lands on top next, gated behind a flag with switch(pc) as the irreducible fallback. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
Switches the initializr's JavaScript build from the remote cloud build target to the local ParparVM-based translator.
CN1BuildMojoalready routes anylocal--prefixed target locally:local-javascript→doJavaScriptLocalBuild()→JavaScriptBuilder(ParparVM bytecode → JavaScript). The plainjavascripttarget went remote (AntcodeNameOnetask → build server → downloadresult.zip). The local path was already fully wired, so this change is purely a build-target switch in the initializr — no Mojo/builder changes.Automate mode still logs in with the server secret, so the pipeline behaves the same as before.
Changes (all under
scripts/initializr/)javascript/pom.xml—codename1.defaultBuildTarget:javascript→local-javascriptbuild.sh/build.bat— these pass-Dcodename1.buildTarget=javascriptexplicitly (overriding the pom default), so both flipped tolocal-javascriptREADME.adoc+ bundled skill docs (SKILL.md,references/build-and-run.md,references/native-interfaces.md) — document the JS build as the local ParparVM target, with the cloudjavascripttarget noted as the fallbackNotes
maven/cn1app-archetypetemplate (shipped to generated user projects) is intentionally not changed here — it still defaults to the cloudjavascripttarget.🤖 Generated with Claude Code