Skip to content

ORM: map java.time Instant, LocalDate and LocalDateTime; samples store Instant - #6094

Merged
shai-almog merged 8 commits into
masterfrom
orm-java-time
Oct 25, 2026
Merged

ORM: map java.time Instant, LocalDate and LocalDateTime; samples store Instant#6094
shai-almog merged 8 commits into
masterfrom
orm-java-time

Conversation

@shai-almog

@shai-almog shai-almog commented Oct 24, 2026

Copy link
Copy Markdown
Collaborator

ORM

  • Instant, LocalDate and LocalDateTime entity fields map with no annotation, to Date's portable default: epoch milliseconds (wall clock for LocalDateTime) or epoch days for LocalDate, in an integer column. An Instant therefore reads the column a long of currentTimeMillis() or a Date wrote, with no migration.
  • @Temporal opts them into native TIMESTAMP/DATE columns through TemporalConverter's UTC ISO text. LocalDate takes only DATE, the others only TIMESTAMP.
  • Implemented as built-in converters (JavaTimeConverter, shared with the backend), so query parameters, the builder, and aggregates all convert like a @Convert field.
  • Refused with a clear build error: java.time identifiers/versions, Property<java.time.*>, element collections, mismatched @Temporal kind. LocalDateTime values beyond a long of milliseconds are refused rather than wrapped.
  • Developer guide and @Temporal docs updated.

Samples

Wayline, Savor, Parley and Skirmish entities store timestamps as Instant. Columns are unchanged (same BIGINT millis); NOT NULL "unset" sentinels are Instant.EPOCH; wire DTOs keep epoch milliseconds. Day buckets that hold millis or sit in composite ids stay long.

Testing

  • OrmAnnotationProcessorTest: 130/130, including round trips of every type on client and backend models, embedded fields, ordering, parameters, aggregates and error cases.
  • Sample backend tests (JVM, SQLite) unchanged: wayline 108, savor 126, parley 59, skirmish 31 - all green before and after.
  • SpotBugs: 0 findings on build-engine and core-unittests.

🤖 Generated with Claude Code

shai-almog and others added 3 commits October 24, 2026 05:11
@shai-almog @claude
ORM: map java.time Instant, LocalDate and LocalDateTime fields
e5353e4 
Without an annotation they take Date's portable default, a number in an
integer column (epoch millis, or epoch days for a LocalDate), so an Instant
reads what a long or a Date of milliseconds wrote. @TeMPOraL opts them into
native TIMESTAMP/DATE columns through TemporalConverter's UTC ISO text.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Samples: store entity timestamps as java.time.Instant
f39fd3c 
Wayline, Savor, Parley and Skirmish entities hold Instant instead of epoch
millisecond longs. The ORM's default Instant mapping is the same BIGINT, so
no migration changes; NOT NULL "unset" sentinels are Instant.EPOCH and the
wire DTOs keep epoch milliseconds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
ORM: harden java.time mapping after review
3bd574a 
Refuse a LocalDateTime past a long of milliseconds instead of wrapping it,
report java.time identifier/version/@TeMPOraL misuse once rather than also
as a relationship, refuse Property<java.time> with a clear error instead of
generated code that fails to compile, and test embedded Instants and
max/min aggregates.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Oct 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Developer Guide build artifacts are available for download from this workflow run:

Developer Guide quality checks:

  • AsciiDoc linter: No issues found (report)
  • Vale: No alerts found (report)
  • Paragraph capitalization: No paragraph capitalization issues (report)
  • LanguageTool: No grammar matches (report)
  • Image references: No unused images detected (report)

@github-actions

github-actions Bot commented Oct 24, 2026

Copy link
Copy Markdown
Contributor

Cloudflare Preview

@shai-almog

shai-almog commented Oct 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 191 screenshots: 191 matched.

Native Android coverage

  • 📊 Line coverage: 19.18% (48148/251040 lines covered) [HTML preview] (artifact android-coverage-report, jacocoAndroidReport/html/index.html)
    • Other counters: instruction 17.88% (228763/1279760), branch 12.19% (16778/137674), complexity 9.81% (12875/131234), method 14.81% (9094/61424), class 25.73% (1769/6875)
    • Lowest covered classes
      • kotlin.collections.kotlin.collections.ArraysKt___ArraysKt – 0.00% (0/6367 lines covered)
      • kotlin.collections.unsigned.kotlin.collections.unsigned.UArraysKt___UArraysKt – 0.00% (0/2384 lines covered)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.ClassReader – 0.00% (0/1524 lines covered)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.MethodWriter – 0.00% (0/922 lines covered)
      • kotlin.sequences.kotlin.sequences.SequencesKt___SequencesKt – 0.00% (0/736 lines covered)
      • com.google.common.cache.com.google.common.cache.LocalCache$Segment – 0.00% (0/726 lines covered)
      • okio.okio.Buffer – 0.00% (0/687 lines covered)
      • kotlin.text.kotlin.text.StringsKt___StringsKt – 0.00% (0/625 lines covered)
      • com.codename1.androidcompat.rt.com.codename1.androidcompat.rt.TextXmlPullParser – 0.00% (0/623 lines covered)
      • com.codename1.androidcompat.androidx.constraintlayout.core.widgets.com.codename1.androidcompat.androidx.constraintlayout.core.widgets.Flow – 0.00% (0/576 lines covered)

✅ Native Android screenshot tests passed.

Native Android coverage

  • 📊 Line coverage: 19.18% (48148/251040 lines covered) [HTML preview] (artifact android-coverage-report, jacocoAndroidReport/html/index.html)
    • Other counters: instruction 17.88% (228763/1279760), branch 12.19% (16778/137674), complexity 9.81% (12875/131234), method 14.81% (9094/61424), class 25.73% (1769/6875)
    • Lowest covered classes
      • kotlin.collections.kotlin.collections.ArraysKt___ArraysKt – 0.00% (0/6367 lines covered)
      • kotlin.collections.unsigned.kotlin.collections.unsigned.UArraysKt___UArraysKt – 0.00% (0/2384 lines covered)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.ClassReader – 0.00% (0/1524 lines covered)
      • org.jacoco.agent.rt.internal_0e20598.asm.org.jacoco.agent.rt.internal_0e20598.asm.MethodWriter – 0.00% (0/922 lines covered)
      • kotlin.sequences.kotlin.sequences.SequencesKt___SequencesKt – 0.00% (0/736 lines covered)
      • com.google.common.cache.com.google.common.cache.LocalCache$Segment – 0.00% (0/726 lines covered)
      • okio.okio.Buffer – 0.00% (0/687 lines covered)
      • kotlin.text.kotlin.text.StringsKt___StringsKt – 0.00% (0/625 lines covered)
      • com.codename1.androidcompat.rt.com.codename1.androidcompat.rt.TextXmlPullParser – 0.00% (0/623 lines covered)
      • com.codename1.androidcompat.androidx.constraintlayout.core.widgets.com.codename1.androidcompat.androidx.constraintlayout.core.widgets.Flow – 0.00% (0/576 lines covered)

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend scalar fallback (no native SIMD)
SIMD int-add (64K x300) java 198ms / native 165ms = 1.2x speedup
SIMD float-mul (64K x300) java 114ms / native 104ms = 1.0x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode 72.000 ms
Base64 CN1 decode 84.000 ms
Base64 native encode 440.000 ms
Base64 encode ratio (CN1/native) 0.164x (83.6% faster)
Base64 native decode 273.000 ms
Base64 decode ratio (CN1/native) 0.308x (69.2% faster)
Image encode benchmark status skipped (SIMD unsupported)

@shai-almog

shai-almog commented Oct 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 227 screenshots: 227 matched.
✅ JavaScript-port screenshot tests passed.

@github-actions

github-actions Bot commented Oct 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

✅ Continuous Quality Report

Test & Coverage

Static Analysis

  • SpotBugs [Report archive]
    • ✅ ByteCodeTranslator: 0 findings (no issues)
    • ✅ android: 0 findings (no issues)
    • ✅ android-compat: 0 findings (no issues)
    • ✅ android-res-compiler: 0 findings (no issues)
    • ✅ backend: 0 findings (no issues)
    • ✅ backend-test: 0 findings (no issues)
    • ✅ build-engine: 0 findings (no issues)
    • ✅ build-hint-catalog: 0 findings (no issues)
    • ✅ build-hint-tools: 0 findings (no issues)
    • ✅ codenameone-gradle-plugin: 0 findings (no issues)
    • ✅ codenameone-maven-plugin: 0 findings (no issues)
    • ✅ core-unittests: 0 findings (no issues)
    • ✅ desktop-compat-runtime: 0 findings (no issues)
    • ✅ fxml-compiler: 0 findings (no issues)
    • ✅ ios: 0 findings (no issues)
    • ✅ javac: 0 findings (no issues)
    • ✅ javafx-compat: 0 findings (no issues)
    • ✅ project-model: 0 findings (no issues)
    • ✅ swing-compat: 0 findings (no issues)
  • ✅ PMD: 0 findings (no issues) [Report archive]
  • ✅ Checkstyle: 0 findings (no issues) [Report archive]

Generated automatically by the PR CI workflow.

@shai-almog

shai-almog commented Oct 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 206 screenshots: 206 matched.
Native Windows port (x64 / Intel-AMD): full hellocodenameone screenshot suite rendered offscreen with Direct2D/DirectWrite, plus the real benchmarks (base64 native/CN1/SIMD, image createMask/applyMask/modifyAlpha/PNG/JPEG, SSE2 SIMD kernels). Compared against the in-repo baseline in scripts/windows/screenshots.

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 32ms / native 2ms = 16.0x speedup
SIMD float-mul (64K x300) java 30ms / native 2ms = 15.0x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 native bridge unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode 37.000 ms
Base64 CN1 decode 47.000 ms
Base64 SIMD encode 56.000 ms
Base64 encode ratio (SIMD/CN1) 1.514x (51.4% slower)
Base64 SIMD decode 51.000 ms
Base64 decode ratio (SIMD/CN1) 1.085x (8.5% slower)
Image encode benchmark iterations 100
Image createMask (SIMD off) 7.000 ms
Image createMask (SIMD on) 4.000 ms
Image createMask ratio (SIMD on/off) 0.571x (42.9% faster)
Image applyMask (SIMD off) 19.000 ms
Image applyMask (SIMD on) 26.000 ms
Image applyMask ratio (SIMD on/off) 1.368x (36.8% slower)
Image modifyAlpha (SIMD off) 25.000 ms
Image modifyAlpha (SIMD on) 17.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.680x (32.0% faster)
Image modifyAlpha removeColor (SIMD off) 19.000 ms
Image modifyAlpha removeColor (SIMD on) 14.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.737x (26.3% faster)

ParparVM vs HotSpot (JDK 25): Windows x64

Runner CPU: AMD64 Family 26 Model 2 Stepping 1, AuthenticAMD (baseline windows-x64@amd64-family-26-model-2-authenticamd)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (WinHelloMain) 4 1.54x (base 1.41x, +9.1%) 0.55x (base 0.68x, -19.0%) ok
translator (self) 4 0.85x (base 0.90x, -4.7%) 0.46x (base 0.47x, -2.2%) ok
intArithmetic 4 1.00x (base 0.99x, +0.7%) 0.06x (base 0.05x, +2.9%) ok
longArithmetic 4 0.99x (base 0.99x, +0.5%) 0.06x (base 0.05x, +3.2%) ok
mathTranscendental 4 0.93x (base 0.94x, -0.4%) 0.06x (base 0.06x, +2.3%) ok
arraySequential 4 1.67x (base 1.75x, -4.2%) 0.38x (base 0.38x, +0.5%) ok
arrayRandom 4 1.02x (base 1.00x, +1.8%) 0.23x (base 0.23x, +0.8%) ok
objectAllocation 4 1.58x (base 1.65x, -4.2%) 0.21x (base 0.21x, +1.0%) ok
valueEscape 4 0.10x (base 0.10x, -0.3%) 0.05x (base 0.04x, +3.3%) ok
hashMapChurn 4 1.71x (base 1.59x, +7.3%) 0.09x (base 0.09x, -3.0%) ok
stringBuilding 4 1.40x (base 1.39x, +1.0%) 0.27x (base 0.27x, +2.1%) ok
recursion 4 1.43x (base 1.44x, -1.0%) 0.06x (base 0.06x, +3.2%) ok
quicksort 4 1.07x (base 1.06x, +1.6%) 0.12x (base 0.12x, +1.5%) ok

Result: no regression

@github-actions

github-actions Bot commented Oct 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Flutter vs Codename One

Same application, built both ways: Flutter's AOT compile of the gallery, and the identical Dart source transpiled to Java on Codename One. Lower is better for every metric, so a ratio above 1.00x means Codename One is ahead by that factor.

android

9 interleaved rounds; host load 0.83, 2.06, 1.66

Metric Codename One Flutter Ratio Winner
Installed size 78.2 MB 95.8 MB 1.22x Codename One
Executable code 4.6 MB 20.6 MB 4.42x Codename One
Download size (zipped) 78.2 MB 95.8 MB 1.22x Codename One
Cold start to first frame on screen 514 ms 1663 ms 3.24x Codename One
Memory at rest 44.5 MB 77.3 MB 1.73x Codename One

Start-up and memory at rest are judged round by round: the ratio is the median of the per-round ratios, each from two launches made back to back, and the times and sizes shown are each side's median, so the ratio need not equal their quotient. Codename One was ahead in 9 of 9 rounds on cold start to first frame on screen; 9 of 9 rounds on memory at rest.

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 97 ms 256 ms 2.64x
longArithmetic 63 ms 67 ms 1.06x
mathTranscendental 197 ms 330 ms 1.68x
arraySequential 37 ms 47 ms 1.27x
arrayRandom 288 ms 348 ms 1.21x
objectAllocation 104 ms 60 ms 0.58x
valueEscape 8 ms 14 ms 1.75x
hashMapChurn 191 ms 292 ms 1.53x
stringBuilding 118 ms 133 ms 1.13x
recursion 115 ms 249 ms 2.17x
quicksortBench 165 ms 175 ms 1.06x
Geometric mean 1.36x

Gate: within tolerance against scripts/flutter-bench/baseline.

Android sizes are for the arm64-v8a slice a phone is delivered, on both sides; Flutter's release apk carries three ABIs and would otherwise count its engine about three times.
Android start-up and memory come from an x86_64 emulator with a software GPU. They compare the two runtimes on one machine; they are not phone timings, and a renderer that leans on the GPU is penalised more there.
This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

ios

9 interleaved rounds; host load 19.33, 23.71, 18.73

Metric Codename One Flutter Ratio Winner
Installed size 108.1 MB 110.5 MB 1.02x Codename One
Executable code 17.1 MB 19.1 MB 1.11x Codename One
Download size (zipped) 80.0 MB 81.9 MB 1.02x Codename One
Cold start to first frame on screen -- -- -- not measured
Memory at rest -- -- -- not measured

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Not measured: iOS compute is not measured: a device build needs signed hardware, and on the simulator Flutter runs its JIT debug engine rather than AOT code. The macOS row runs the same ParparVM and Dart AOT compilers on the same Apple silicon.

Gate: within tolerance against scripts/flutter-bench/baseline. Smaller than its baseline, which does not fail the gate: Executable code -7.50% -- rebaseline to tighten. To accept the move, download this platform's baseline-<platform>.json artifact and run python3 scripts/flutter-bench/flutter_baseline.py calibrate --pr 6094 --reason "<why these moved>" baseline-ios.json, then commit the overlay it writes.

iOS start-up and memory are not measured here: Flutter cannot AOT-compile for the simulator, so a simulator run would time a JIT debug build against a release build. Sizes come from release device bundles; timings need signed hardware.
This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

javascript

9 interleaved rounds; host load 2.54, 1.45, 0.62

Metric Codename One Flutter Ratio Winner
Installed size 103.9 MB 122.5 MB 1.18x Codename One
Executable code 12.9 MB 25.2 MB 1.96x Codename One
Download size (zipped) 76.3 MB 84.1 MB 1.10x Codename One
Cold start to first frame on screen -- -- -- not measured
Memory at rest -- -- -- not measured

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 650 ms wrong result Flutter: wrong result
longArithmetic 4962 ms did not run Flutter: did not run
mathTranscendental 570 ms did not run Flutter: did not run
arraySequential 228 ms 82 ms 0.36x
arrayRandom 949 ms wrong result Flutter: wrong result
objectAllocation 39 ms 28 ms 0.72x
valueEscape 110 ms 7 ms 0.06x
hashMapChurn 1135 ms 245 ms 0.22x
stringBuilding 523 ms 107 ms 0.20x
recursion 509 ms 489 ms 0.96x
quicksortBench 407 ms wrong result Flutter: wrong result
Geometric mean 0.30x

Gate: within tolerance against scripts/flutter-bench/baseline; BEHIND FLUTTER on Compute (geomean of the VM workloads) (reported, not gated: a loss to Flutter on the web is currently accepted).

the JavaScript adapter needs a Chrome DevTools driver; sizes are reported and timings are not
This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

linux

9 interleaved rounds; host load 0.19, 2.31, 1.72

Metric Codename One Flutter Ratio Winner
Installed size 111.4 MB 143.8 MB 1.29x Codename One
Executable code 14.1 MB 16.1 MB 1.15x Codename One
Download size (zipped) 80.9 MB 92.9 MB 1.15x Codename One
Cold start to first frame on screen 105 ms 167 ms 1.61x Codename One
Memory at rest 86.4 MB 236.9 MB 2.75x Codename One

Start-up and memory at rest are judged round by round: the ratio is the median of the per-round ratios, each from two launches made back to back, and the times and sizes shown are each side's median, so the ratio need not equal their quotient. Codename One was ahead in 9 of 9 rounds on cold start to first frame on screen; 9 of 9 rounds on memory at rest.

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 49 ms 124 ms 2.53x
longArithmetic 36 ms 36 ms 1.00x
mathTranscendental 158 ms 167 ms 1.06x
arraySequential 11 ms 22 ms 2.00x
arrayRandom 171 ms 186 ms 1.09x
objectAllocation 15 ms 21 ms 1.40x
valueEscape 4 ms 5 ms 1.25x
hashMapChurn 25 ms 202 ms 8.08x
stringBuilding 19 ms 71 ms 3.74x
recursion 49 ms 175 ms 3.57x
quicksortBench 117 ms 119 ms 1.02x
Geometric mean 1.89x

Gate: within tolerance against scripts/flutter-bench/baseline.

This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

macos

9 interleaved rounds; host load 2.83, 19.07, 23.03

Metric Codename One Flutter Ratio Winner
Installed size 124.1 MB 139.4 MB 1.12x Codename One
Executable code 33.0 MB 47.9 MB 1.45x Codename One
Download size (zipped) 85.5 MB 93.3 MB 1.09x Codename One
Cold start to first frame on screen 201 ms 291 ms 1.37x Codename One
Memory at rest 36.8 MB 51.9 MB 1.42x Codename One

Start-up and memory at rest are judged round by round: the ratio is the median of the per-round ratios, each from two launches made back to back, and the times and sizes shown are each side's median, so the ratio need not equal their quotient. Codename One was ahead in 8 of 9 rounds on cold start to first frame on screen; 9 of 9 rounds on memory at rest.

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 102 ms 231 ms 2.27x
longArithmetic 64 ms 63 ms 0.98x
mathTranscendental 254 ms 296 ms 1.17x
arraySequential 10 ms 40 ms 4.00x
arrayRandom 241 ms 290 ms 1.20x
objectAllocation 21 ms 26 ms 1.24x
valueEscape 5 ms 12 ms 2.40x
hashMapChurn 33 ms 150 ms 4.54x
stringBuilding 20 ms 97 ms 4.85x
recursion 119 ms 249 ms 2.09x
quicksortBench 109 ms 125 ms 1.15x
Geometric mean 1.99x

Gate: within tolerance against scripts/flutter-bench/baseline. Smaller than its baseline, which does not fail the gate: Executable code -6.57% -- rebaseline to tighten. To accept the move, download this platform's baseline-<platform>.json artifact and run python3 scripts/flutter-bench/flutter_baseline.py calibrate --pr 6094 --reason "<why these moved>" baseline-macos.json, then commit the overlay it writes.

This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

windows

9 interleaved rounds

Metric Codename One Flutter Ratio Winner
Installed size 107.8 MB 121.1 MB 1.12x Codename One
Executable code 11.3 MB 14.1 MB 1.25x Codename One
Download size (zipped) 77.8 MB 86.4 MB 1.11x Codename One
Cold start to first frame on screen 158 ms 255 ms 1.63x Codename One
Memory at rest 58.4 MB 92.9 MB 1.59x Codename One

Start-up and memory at rest are judged round by round: the ratio is the median of the per-round ratios, each from two launches made back to back, and the times and sizes shown are each side's median, so the ratio need not equal their quotient. Codename One was ahead in 9 of 9 rounds on cold start to first frame on screen; 9 of 9 rounds on memory at rest.

Compute -- the VM workloads (vm/benchmarks), run inside each app; time is the best of the app's own repetitions, higher ratio means Codename One is faster.

Workload Codename One Flutter Ratio
intArithmetic 90 ms 241 ms 2.68x
longArithmetic 58 ms 65 ms 1.12x
mathTranscendental 197 ms 212 ms 1.08x
arraySequential 12 ms 43 ms 3.58x
arrayRandom 277 ms 330 ms 1.19x
objectAllocation 36 ms 46 ms 1.28x
valueEscape 1 ms 13 ms 13.00x
hashMapChurn 54 ms 286 ms 5.30x
stringBuilding 29 ms 119 ms 4.10x
recursion 206 ms 238 ms 1.16x
quicksortBench 170 ms 164 ms 0.96x
Geometric mean 2.19x

Gate: within tolerance against scripts/flutter-bench/baseline. Smaller than its baseline, which does not fail the gate: Executable code -10.80%; Download size (zipped) -0.78% -- rebaseline to tighten. To accept the move, download this platform's baseline-<platform>.json artifact and run python3 scripts/flutter-bench/flutter_baseline.py calibrate --pr 6094 --reason "<why these moved>" baseline-windows.json, then commit the overlay it writes.

This platform's adapter has not been exercised end to end before; treat the first published run as the thing under review.

Codename One wins 26 of 26 measured metrics across 6 platform(s).

@shai-almog

shai-almog commented Oct 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 206 screenshots: 206 matched.
Native Linux port (x64), GTK3/Cairo/Pango, ParparVM bytecode-to-C (no JVM): the hellocodenameone screenshot suite rendered by a native ELF built + run on the GitHub x64 runner. Baseline: scripts/linux/screenshots.

ParparVM vs HotSpot (JDK 25): Linux x64

Runner CPU: AMD EPYC 7763 64-Core Processor (baseline linux-x64@amd-epyc-7763-64-core-processor)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (LinuxHelloMain) 4 0.90x (base 0.85x, +6.3%) 0.71x (base 0.83x, -14.9%) ok
translator (self) 4 0.53x (base 0.64x, -17.7%) 0.45x (base 0.52x, -12.9%) ok
intArithmetic 4 1.10x (base 1.12x, -1.2%) 0.06x (base 0.06x, +0.6%) ok
longArithmetic 4 1.08x (base 1.08x, +0.0%) 0.06x (base 0.05x, +5.5%) ok
mathTranscendental 4 1.09x (base 1.08x, +0.2%) 0.06x (base 0.07x, -22.1%) ok
arraySequential 4 2.07x (base 2.00x, +3.0%) 0.36x (base 0.36x, -0.1%) ok
arrayRandom 4 1.04x (base 0.91x, +14.3%) 0.23x (base 0.21x, +9.6%) ok
objectAllocation 4 1.67x (base 1.65x, +1.1%) 0.30x (base 0.35x, -15.1%) ok
valueEscape 4 0.10x (base 0.10x, -0.2%) 0.04x (base 0.04x, +0.3%) ok
hashMapChurn 4 1.48x (base 1.48x, -0.4%) 0.09x (base 0.09x, -1.1%) ok
stringBuilding 4 1.42x (base 1.39x, +2.2%) 0.26x (base 0.31x, -16.6%) ok
recursion 4 1.18x (base 1.25x, -5.6%) 0.06x (base 0.08x, -24.8%) ok
quicksort 4 1.10x (base 1.07x, +2.6%) 0.11x (base 0.11x, -0.3%) ok

Result: no regression

@shai-almog

shai-almog commented Oct 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 206 screenshots: 206 matched.
Native Linux port (arm64), GTK3/Cairo/Pango, ParparVM bytecode-to-C (no JVM): the hellocodenameone screenshot suite rendered by a native ELF built + run on the GitHub arm64 runner. Baseline: scripts/linux/screenshots-arm.

ParparVM vs HotSpot (JDK 25): Linux arm64

Runner CPU: Neoverse-N2 (baseline linux-arm64@neoverse-n2)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (LinuxHelloMain) 4 0.94x (base 1.02x, -7.4%) 0.68x (base 0.93x, -26.7%) ok
translator (self) 4 0.75x (base 0.70x, +8.1%) 0.45x (base 0.43x, +5.1%) ok
intArithmetic 4 1.04x (base 1.04x, -0.0%) 0.03x (base 0.03x, +4.2%) ok
longArithmetic 4 0.79x (base 0.79x, -0.1%) 0.03x (base 0.03x, +5.0%) ok
mathTranscendental 4 1.09x (base 1.10x, -0.3%) 0.04x (base 0.03x, +9.4%) ok
arraySequential 4 0.35x (base 0.36x, -2.4%) 0.37x (base 0.37x, +0.4%) ok
arrayRandom 4 0.93x (base 0.94x, -0.6%) 0.20x (base 0.20x, +0.7%) ok
objectAllocation 4 1.98x (base 1.77x, +11.8%) 0.36x (base 0.37x, -2.8%) ok
valueEscape 4 0.51x (base 0.51x, -0.1%) 0.03x (base 0.03x, +5.2%) ok
hashMapChurn 4 0.84x (base 0.84x, -0.3%) 0.12x (base 0.12x, -4.5%) ok
stringBuilding 4 1.36x (base 1.57x, -13.2%) 0.32x (base 0.26x, +20.7%) ok
recursion 4 1.45x (base 1.43x, +1.2%) 0.04x (base 0.04x, +3.2%) ok
quicksort 4 1.00x (base 0.99x, +0.9%) 0.09x (base 0.09x, +1.1%) ok

Result: no regression

@shai-almog

shai-almog commented Oct 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 206 screenshots: 206 matched.
Native Windows port (arm64 / Apple Silicon - Arm): full hellocodenameone screenshot suite rendered offscreen with Direct2D/DirectWrite, plus the real benchmarks (base64 native/CN1/SIMD, image createMask/applyMask/modifyAlpha/PNG/JPEG, NEON SIMD kernels). Compared against the in-repo baseline in scripts/windows/screenshots.

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 53ms / native 3ms = 17.6x speedup
SIMD float-mul (64K x300) java 53ms / native 3ms = 17.6x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 native bridge unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode 60.000 ms
Base64 CN1 decode 70.000 ms
Base64 SIMD encode 77.000 ms
Base64 encode ratio (SIMD/CN1) 1.283x (28.3% slower)
Base64 SIMD decode 73.000 ms
Base64 decode ratio (SIMD/CN1) 1.043x (4.3% slower)
Image encode benchmark iterations 100
Image createMask (SIMD off) 5.000 ms
Image createMask (SIMD on) 2.000 ms
Image createMask ratio (SIMD on/off) 0.400x (60.0% faster)
Image applyMask (SIMD off) 21.000 ms
Image applyMask (SIMD on) 21.000 ms
Image applyMask ratio (SIMD on/off) 1.000x (0.0% slower)
Image modifyAlpha (SIMD off) 19.000 ms
Image modifyAlpha (SIMD on) 14.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.737x (26.3% faster)
Image modifyAlpha removeColor (SIMD off) 23.000 ms
Image modifyAlpha removeColor (SIMD on) 15.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.652x (34.8% faster)

ParparVM vs HotSpot (JDK 25): Windows arm64

Runner CPU: ARMv8 (64-bit) Family 8 Model D49 Revision 0, MICROSOFT CORPORATION (baseline windows-arm64@armv8-64-bit-family-8-model-d49-microsoft-corporation)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (WinHelloMain) 4 1.01x (base 1.11x, -8.6%) 0.60x (base 0.75x, -20.3%) ok
translator (self) 4 0.88x (base 0.84x, +5.0%) 0.48x (base 0.51x, -4.9%) ok
intArithmetic 4 1.04x (base 1.04x, +0.0%) 0.06x (base 0.06x, +2.9%) ok
longArithmetic 4 0.80x (base 0.80x, +0.0%) 0.06x (base 0.06x, +3.3%) ok
mathTranscendental 4 0.72x (base 0.72x, -0.3%) 0.07x (base 0.06x, +1.9%) ok
arraySequential 4 0.38x (base 0.46x, -17.5%) 0.39x (base 0.39x, +0.1%) ok
arrayRandom 4 0.94x (base 0.94x, -0.1%) 0.23x (base 0.23x, +0.3%) ok
objectAllocation 4 1.78x (base 1.82x, -2.2%) 0.33x (base 0.43x, -23.8%) ok
valueEscape 4 0.76x (base 0.76x, +0.0%) 0.05x (base 0.05x, +3.6%) ok
hashMapChurn 4 1.00x (base 0.98x, +1.5%) 0.11x (base 0.12x, -5.2%) ok
stringBuilding 4 1.61x (base 1.43x, +12.6%) 0.27x (base 0.27x, -0.5%) ok
recursion 4 1.55x (base 1.46x, +6.2%) 0.07x (base 0.07x, +1.1%) ok
quicksort 4 1.00x (base 1.00x, +0.3%) 0.12x (base 0.12x, +0.5%) ok

Result: no regression

@shai-almog @claude
Initializr: resync sample templates after the Instant conversion
6871860 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog

shai-almog commented Oct 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 192 screenshots: 192 matched.
✅ Native Mac screenshot tests passed.

Benchmark Results

  • VM Translation Time: 0 seconds
  • Compilation Time: 407 seconds

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 75ms / native 6ms = 12.5x speedup
SIMD float-mul (64K x300) java 49ms / native 3ms = 16.3x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 native bridge unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path active (NEON-accelerated)
Base64 CN1 encode 52.000 ms
Base64 CN1 decode 56.000 ms
Image encode benchmark iterations 100
Image createMask (SIMD off) 6.000 ms
Image createMask (SIMD on) 2.000 ms
Image createMask ratio (SIMD on/off) 0.333x (66.7% faster)
Image applyMask (SIMD off) 39.000 ms
Image applyMask (SIMD on) 40.000 ms
Image applyMask ratio (SIMD on/off) 1.026x (2.6% slower)
Image modifyAlpha (SIMD off) 39.000 ms
Image modifyAlpha (SIMD on) 32.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.821x (17.9% faster)
Image modifyAlpha removeColor (SIMD off) 39.000 ms
Image modifyAlpha removeColor (SIMD on) 33.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 0.846x (15.4% faster)

ParparVM vs HotSpot (JDK 25): macOS arm64

Runner CPU: Apple M1 (Virtual) (baseline macos-arm64)

Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in vm/selfhost/perf-baseline/ is a regression and fails; one that far below is an improvement, reported but not failed (a row whose calibration runs were noisier carries a wider tolerance), and for RAM the change must also exceed 0.05x in absolute terms. Both run unpinned on all of the runner's CPUs, with their own default thread counts.

Benchmark Cores Time RAM Status
hello (HelloCodenameOne) 3 0.84x (base 0.96x, -12.2%) 0.90x (base 0.93x, -3.0%) ok
translator (self) 3 0.64x (base 0.62x, +2.6%) 0.72x (base 0.78x, -7.6%) ok
intArithmetic 3 1.01x (base 1.03x, -2.0%) 0.12x (base 0.12x, +1.9%) ok
longArithmetic 3 1.01x (base 1.03x, -1.1%) 0.11x (base 0.07x, +59.7%) ok
mathTranscendental 3 0.94x (base 1.01x, -6.4%) 0.12x (base 0.12x, +0.3%) ok
arraySequential 3 0.44x (base 0.42x, +5.1%) 0.53x (base 0.53x, +0.3%) ok
arrayRandom 3 0.99x (base 0.99x, -0.1%) 0.32x (base 0.32x, +0.3%) ok
objectAllocation 3 1.03x (base 1.11x, -6.8%) 0.57x (base 0.72x, -20.8%) ok
valueEscape 3 0.51x (base 0.51x, -0.2%) 0.09x (base 0.09x, +2.6%) ok
hashMapChurn 3 1.10x (base 1.18x, -6.7%) 0.07x (base 0.07x, +6.0%) ok
stringBuilding 3 0.93x (base 0.84x, +10.6%) 0.44x (base 0.46x, -5.9%) ok
recursion 3 1.23x (base 1.24x, -0.8%) 0.12x (base 0.12x, +0.8%) ok
quicksort 3 1.00x (base 1.01x, -0.9%) 0.11x (base 0.11x, +0.2%) ok

Result: no regression

@github-actions

github-actions Bot commented Oct 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

✅ ByteCodeTranslator Quality Report

Test & Coverage

  • ✅ Tests: 880 total, 0 failed, 55 skipped

Benchmark Results

  • Execution Time: 9500 ms

  • Hotspots (Top 20 sampled methods):

    • 11.36% com.codename1.tools.translator.IteratorEscape.ctorOnlyStoresParamsIntoThis (165 samples)
    • 6.47% java.util.ArrayList.indexOf (94 samples)
    • 6.06% java.lang.Object.hashCode (88 samples)
    • 5.85% java.lang.System.identityHashCode (85 samples)
    • 4.61% com.codename1.tools.translator.BytecodeMethod.equals (67 samples)
    • 4.13% com.codename1.tools.translator.IteratorEscape.mangle (60 samples)
    • 3.58% com.codename1.tools.translator.classfile.analysis.Frame.execute (52 samples)
    • 2.41% java.lang.StringBuilder.append (35 samples)
    • 1.79% com.codename1.tools.translator.JavascriptReachability.enqueueResolved (26 samples)
    • 1.79% com.codename1.tools.translator.bytecodes.Invoke.findMethodUp (26 samples)
    • 1.38% com.codename1.tools.translator.bytecodes.Invoke.resolveDirectTarget (20 samples)
    • 1.24% com.codename1.tools.translator.ByteCodeClass.hasDeclaredMethod (18 samples)
    • 1.17% java.util.HashMap.putVal (17 samples)
    • 1.17% com.codename1.tools.translator.Parser.cullMethods (17 samples)
    • 1.10% java.io.FileOutputStream.writeBytes (16 samples)
    • 1.10% java.util.AbstractCollection.containsAll (16 samples)
    • 1.03% java.lang.String.equals (15 samples)
    • 1.03% com.codename1.tools.translator.BytecodeMethod.updateInlinableFieldDependencies (15 samples)
    • 0.96% com.codename1.tools.translator.ReachabilityCull.run (14 samples)
    • 0.83% com.codename1.tools.translator.NativeSymbolIndex.<init> (12 samples)

  • ⚠️ Coverage report not generated.

Static Analysis

  • ✅ SpotBugs: no findings (report was not generated by the build).
  • ⚠️ PMD report not generated.
  • ⚠️ Checkstyle report not generated.

Generated automatically by the PR CI workflow.

shai-almog and others added 2 commits October 24, 2026 18:48
@shai-almog @claude
perf: raise the macos-arm64 translator RAM row the nightly fold set t…
f1abfe0 
…oo low

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
Samples: keep the demos on long timestamps until a release maps java.…
b79d558 
…time

The Initializr templates are built against the released framework, whose
annotation processor rejects java.time fields. The demo conversion moves to
its own pull request, for the release that includes this mapping.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
shai-almog added a commit that referenced this pull request Oct 24, 2026
@shai-almog @claude
Samples: store entity timestamps as java.time.Instant
f8aafc4 
Restores the demo conversion held back from #6094, for the release that maps
java.time entity fields, and resyncs the Initializr templates.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog shai-almog mentioned this pull request Oct 24, 2026
Open
@shai-almog

shai-almog commented Oct 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Compared 206 screenshots: 206 matched.
Native Windows port, REAL shipping pipeline: the hellocodenameone screenshot suite rendered by a binary CROSS-COMPILED on Linux (clang-cl + xwin, WebView2 linked) and RUN on a Windows x64 runner. Compared against the in-repo baseline in scripts/windows/screenshots.

Benchmark Results

Detailed Performance Metrics

Metric Duration
SIMD kernel backend SSE2 (x64) / NEON (arm64) native kernels
SIMD int-add (64K x300) java 63ms / native 5ms = 12.6x speedup
SIMD float-mul (64K x300) java 57ms / native 5ms = 11.4x speedup
SIMD kernel correctness PASS (native result == scalar reference)
Base64 native bridge unavailable (CN1 + SIMD + image benchmarks only)
Base64 payload size 8192 bytes
Base64 benchmark iterations 6000
Base64 SIMD byte path gated to scalar (CPU autovectorizes scalar; explicit SIMD not beneficial here)
Base64 CN1 encode 83.000 ms
Base64 CN1 decode 96.000 ms
Base64 SIMD encode 113.000 ms
Base64 encode ratio (SIMD/CN1) 1.361x (36.1% slower)
Base64 SIMD decode 99.000 ms
Base64 decode ratio (SIMD/CN1) 1.031x (3.1% slower)
Image encode benchmark iterations 100
Image createMask (SIMD off) 8.000 ms
Image createMask (SIMD on) 4.000 ms
Image createMask ratio (SIMD on/off) 0.500x (50.0% faster)
Image applyMask (SIMD off) 26.000 ms
Image applyMask (SIMD on) 28.000 ms
Image applyMask ratio (SIMD on/off) 1.077x (7.7% slower)
Image modifyAlpha (SIMD off) 28.000 ms
Image modifyAlpha (SIMD on) 18.000 ms
Image modifyAlpha ratio (SIMD on/off) 0.643x (35.7% faster)
Image modifyAlpha removeColor (SIMD off) 29.000 ms
Image modifyAlpha removeColor (SIMD on) 63.000 ms
Image modifyAlpha removeColor ratio (SIMD on/off) 2.172x (117.2% slower)

shai-almog and others added 2 commits October 24, 2026 21:24
@shai-almog @claude
perf: raise the windows-x64 translator time row the nightly fold set …
c4fa4ca 
…too low

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog @claude
perf: raise the second windows-x64 translator time row
0f1daaa 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@shai-almog
shai-almog merged commit ea7ec99 into master Oct 25, 2026
115 of 119 checks passed
@shai-almog
shai-almog deleted the orm-java-time branch October 25, 2026 01:52
shai-almog added a commit that referenced this pull request Oct 25, 2026
@shai-almog @claude
Samples: store entity timestamps as java.time.Instant
55bc9ba 
Restores the demo conversion held back from #6094, for the release that maps
java.time entity fields, and resyncs the Initializr templates.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@shai-almog