JavaSE: upstream JCEF (fixes maps #5290) + bundled-ffmpeg default media#5294
Draft
shai-almog wants to merge 7 commits into
Draft
JavaSE: upstream JCEF (fixes maps #5290) + bundled-ffmpeg default media#5294shai-almog wants to merge 7 commits into
shai-almog wants to merge 7 commits into
Conversation
Reproduces the salvageable parts of PR #4630 (branch new-jcef-support) on a clean branch off current master: - replace the home-built Chromium-84 com.codenameone:jcef system jar with upstream prebuilt me.friwi JCEF artifacts (new maven/cn1-binaries module) - add FFMPEGMedia as a media backend + the JavaSE CEF/ffmpeg smoke test Seed commit only. The new-direction changes (bundled self-contained ffmpeg as the default media engine, no proprietary-codec CEF, current Chromium) follow as separate commits. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
With upstream codec-free CEF, the CN1 Media API (which in the simulator plays through a hidden CEFBrowserComponent) can no longer decode H.264/AAC/MP3. Route the Media API to the ffmpeg backend instead: - FFMPEGMedia.resolveExecutable now falls back to the ffmpeg/ffprobe binaries bundled by the org.bytedeco:ffmpeg-platform dependency (resolved reflectively via Loader.load), so no externally installed ffmpeg is needed. ffmpeg's native decoders cover H.264/AAC/MP3 -- those need no GPL/x264 encoder -- which is exactly what codec-free upstream CEF dropped. - Media routing flips from opt-in (-Dcn1.javase.mediaImplementation=ffmpeg) to default-on, with -Dcn1.javase.mediaImplementation=cef as the escape hatch. This also removes the PATH-installed-ffmpeg dependency that broke #4630's windows-latest smoke test. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
| import platform | ||
| import shutil | ||
| import subprocess | ||
| import sys |
| print(f"[javase-cef-ffmpeg-smoke] {message}", flush=True) | ||
|
|
||
|
|
||
| def run(cmd, cwd=None, env=None, log_name=None, timeout=None): |
Collaborator
Author
|
Compared 11 screenshots: 11 matched. |
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Collaborator
Author
|
Compared 139 screenshots: 139 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Collaborator
Author
|
Compared 131 screenshots: 131 matched. |
Collaborator
Author
|
Compared 214 screenshots: 214 matched. |
Collaborator
Author
|
Compared 134 screenshots: 134 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 136 screenshots: 136 matched. |
Collaborator
Author
|
Compared 137 screenshots: 137 matched. Benchmark Results
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 138 screenshots: 138 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
setupFFmpeg copied a PATH ffmpeg/ffprobe into ffmpeg.dir. On Windows that picks up a chocolatey shimgen shim which does not work once copied out of place, so the video process produced zero decoded frames silently -- and because resolveExecutable checks ffmpeg.dir first, the bundled bytedeco binaries were never reached (this was the windows-latest smoke failure). Drop the PATH staging entirely; the runtime resolves ffmpeg/ffprobe from the bundled org.bytedeco:ffmpeg-platform binaries, with ffmpeg.dir kept only as an explicit user override. Removes the now-unused findExecutableOnPath helper. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Updates jcef.version from Chromium 95 to the current upstream me.friwi release (Chromium 135; all six native classifiers verified on Maven Central) and adapts the custom CEF glue to the org.cef API changes between 95 and 135: - CefBrowser_N's constructor gained a trailing CefBrowserSettings parameter - CefRequestHandler.onPluginCrashed was removed - onRenderProcessTerminated gained (int errorCode, String errorString) All other overridden handler signatures are unchanged between the two versions. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
JCEF 135 added addOnPaintListener/setOnPaintListener/removeOnPaintListener to CefRenderHandler, and me.friwi's CefRenderHandlerAdapter leaves them abstract. CN1's anonymous render handler must therefore implement them; CN1 renders directly in onPaintImpl and does not use the listener convenience API, so they are no-ops. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Ant build of the JavaSE port compiles against cn1-binaries/javase/jcef.jar (the legacy home-built Chromium-84 API jar) while Maven now uses me.friwi. At Chromium 95 the two APIs were compatible, but the 135 bump diverged and broke the Ant-based jobs (build-test, javase-simulator-tests). Add scripts/ci-install-upstream-jcef-jar.sh, which installs the me.friwi jcef-api jar matching maven/pom.xml's jcef.version as cn1-binaries/javase/jcef.jar (from the local ~/.m2 if present, else Maven Central), and invoke it before each Ant JavaSE compile (pr.yml build-test, run-javase-simulator-integration-tests.sh, run-javase-device-tests.sh). Keeps both build systems on the same JCEF; the Ant build only needs the API jar for compilation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The build-port job skipped setup-workspace whenever the prebuilt-jars cache (cn1-built) hit, assuming the separately-keyed codenameone-tools cache was also present. Under cache pressure GitHub can evict cn1-tools while cn1-built survives; setup-workspace is then skipped and tools/env.sh never gets created, breaking every dependent app job (build-ios*, native-ios, packaging, mac-native), which only restore caches and never run setup-workspace themselves. Give the codenameone-tools cache an id and also run setup-workspace when that cache misses. 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
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.
What
Updates the JavaSE simulator's embedded browser from the home-built Chromium 84 JCEF to upstream prebuilt JCEF (
me.friwi, currently pinned to Chromium 95), and replaces the simulator's media engine accordingly.Fixes #5290 — the simulator's Chromium 84 lacks
Element.replaceChildren(added in Chromium 86), which breaks the current Google Maps JS (markers fail withTypeError: this.replaceChildren is not a function). Any Chromium ≥ 86 resolves it.Supersedes #4630 (closed). This is a fresh branch off current master that reuses the salvageable parts of that PR and changes direction on media.
Why the media rework
In the simulator the CN1 Media API plays through CEF —
JavaCEFSEPort.CodenameOneMediaPlayerloads an HTML<video>/<audio>page into a hiddenCEFBrowserComponent. The home-built CEF carried proprietary codecs, so it was effectively the media engine. Upstream JCEF ships no proprietary codecs, so swapping it in would break H.264/AAC/MP3 for the whole Media API, not just in-page video.Rather than rebuild CEF with
proprietary_codecs/x264 in CI (expensive, fragile), this routes the Media API onto ffmpeg:FFMPEGMediaresolvesffmpeg/ffprobefrom the bundledorg.bytedeco:ffmpeg-platformbinaries viaLoader.load(reflectively, so the dep stays optional). No externally installed ffmpeg required.-Dcn1.javase.mediaImplementation=cefis the escape hatch.This also removes the PATH-installed-ffmpeg dependency that broke #4630's
windows-latestsmoke test.Scope decision
In-browser H.264
<video>inside aBrowserComponentis out of scope (it's the only thing that would require a proprietary-codec CEF). Free codecs (WebM/VP9/AV1/Opus) still play in-page; the CN1 Media API handles everything via ffmpeg. On real devices nothing changes (native WebView / native maps).Commits
Deferred (follow-ups)
org.cefglue is validated separately.jcef.versionproperty whenme.friwipublishes a newer build. With this architecture "update CEF" is a one-line version bump — no CEF build pipeline.ffmpeg-platformto the current platform to cut simulator download size, and remove the now-redundant ffmpeg-install steps from the smoke workflow.🤖 Generated with Claude Code