This is an automated email from the ASF dual-hosted git repository. leginee pushed a commit to branch bazel-migration in repository https://gitbox.apache.org/repos/asf/openoffice.git
commit 66157c2157822e794b34d2b75e82e05db03f93a7 Author: Peter Kovacs <[email protected]> AuthorDate: Wed Aug 5 08:08:50 2026 +0200 docs(stoc,frontier): record x64 green + scope the classes/ staging step //main/staging:install confirmed GREEN on x64 by user build with javaloader.uno + javavm.uno staged and services.rdb pointing at them instead of the old bootstrap.uno.dll placeholder. Scoping the next step turned up three things that make it more than "add a classes/ destination to stage_install.bzl", all verified by reading the rules and the checked-in manifests: (a) Bazel jar names are not runtime jar names. java_library(name="x") emits libx.jar, while javavm.cxx looks up bare "unoloader.jar" by literal string. Every entry needs an explicit destination name — stage_install's manifest already has that third column (the .rdb entries use it). Full mapping table in main/stoc/readme.md. (b) ridl.jar must be MERGED, not copied. Upstream's holds the generated UDK types AND the 27 hand-written sources; here they are two targets, and exports=[":udkapi_java"] is COMPILE-time only, so libridl.jar contains no com.sun.star.uno.* at all. Staging it as-is would ship a broken ridl.jar. Fix is the java_binary(create_executable=False) deploy-jar trick already used for cppuhelper_qa_propertysetmixin. (c) The jars need MANIFESTS that nothing currently emits. Upstream keeps them checked in (jurt/util/manifest, javaunohelper/util/manifest, ridljar/.../unoloader/manifest) carrying Sealed:, RegistrationClassName: and UNO-Type-Path:. UnoClassLoader.getClassLoader() reads UNO-Type-Path off the jar's main attributes, so they are load-bearing, not cosmetic — but jar_from_directory runs a bare `jar cf` and java_library sets none. OPEN QUESTION recorded for the next session, to resolve BEFORE wiring: how jurt/ridl/unoil actually reach the class loader, given URE_INTERNAL_JAVA_CLASSPATH expands empty and juh's UNO-Type-Path is empty. Read UnoClassLoader.getClassLoader() and javavm.cxx's UnoClassLoader construction first. No build changes in this commit — documentation only. Co-Authored-By: Claude Opus 5 <[email protected]> --- CLAUDE.md | 33 +++++++++++++++++++++++++++++++++ main/stoc/readme.md | 48 ++++++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 77 insertions(+), 4 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 884cb11637..3a6d4486c2 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -254,6 +254,39 @@ qadevOOo 🔨 OOoRunner.jar built (//main/qadevOOo:OOoRunner — qadevOOo testgraphical ⬜ (graphical/visual regression tests; needs instsetoo_native + qadevOOo) ── Remaining: Java-based ──────────────────────────────────────────────── +JAVA2 LOADER — STARTED 2026-08-05. The bucket's real first blocker was NOT +javamaker (already built): com.sun.star.loader.Java2 had NO IMPLEMENTATION. +javaloader.uno.dll + javavm.uno.dll were never built while BOTH were registered +in services.rdb MAPPED TO bootstrap.uno.dll as a placeholder — unworkable, since +neither impl is in that DLL. Now built (//main/stoc), staged, and registered at +their real DLLs; x64 //main/staging:install GREEN per user build 2026-08-05. +TWO LANDMINES: (1) SOLAR_JAVA is LOAD-BEARING — jvmaccess/virtualmachine.hxx +pulls the real <jni.h> only under it, else stubs, so every JNIEnv-> call is +C2027 even in javaloader.cxx which #includes "jni.h" ITSELF (the stub is already +in scope); (2) javavm needs /Zc:wchar_t- (passes sal_Unicode ptr into NewString/ +GetStringRegion; on Windows sal_Unicode IS wchar_t, distinct from jchar unless +wchar_t is unsigned short), javaloader does NOT (only NewStringUTF). +NEXT STEP IS STAGING, NOT COMPILATION — and it is not just a classes/ dest: +(a) Bazel jar names ≠ runtime names (java_library "x" → libx.jar, runtime wants +bare unoloader.jar/jurt.jar/juh.jar/unoil.jar/java_uno.jar by EXACT string) so +each needs an explicit destname (stage_install's manifest already has that 3rd +column); (b) ridl.jar must be MERGED not copied — upstream's holds generated UDK +types + 27 hand-written sources, but here exports=[":udkapi_java"] is +COMPILE-time only, so libridl.jar has no com.sun.star.uno.* (fix = the +java_binary(create_executable=False) deploy-jar trick from propertysetmixin); +(c) the jars need MANIFESTS nothing currently emits (checked-in at +jurt/util/manifest, javaunohelper/util/manifest, ridljar/.../unoloader/manifest +— Sealed:, RegistrationClassName:, UNO-Type-Path:), and UnoClassLoader reads +UNO-Type-Path off the main attributes, so they are load-bearing; neither +jar_from_directory (bare `jar cf`) nor java_library sets one. OPEN QUESTION to +resolve FIRST: how jurt/ridl/unoil actually reach the class loader given +URE_INTERNAL_JAVA_CLASSPATH expands empty and juh's UNO-Type-Path is empty — +read UnoClassLoader.getClassLoader() + javavm.cxx's UnoClassLoader construction +before wiring. Also still needed: URE_INTERNAL_JAVA_DIR in +program/fundamental.ini (NOT uno.ini — theMacroExpander resolves against the +URE_BOOTSTRAP file; uno.ini already has it, fundamental.ini does not), and a +jvmfwk JRE config (javavendors.xml + jvmfwk3) or jvmfwk finds no JRE. +See main/stoc/readme.md. NOTE: rules_java 8.11.0 IS now wired (MODULE.bazel) and the core Java UNO runtime is migrated & green — ridljar/jurt/jvmaccess/javaunohelper/jvmfwk/ bridges (incl. the java_uno JNI bridge: java_uno.dll + java_uno.jar, done diff --git a/main/stoc/readme.md b/main/stoc/readme.md index e52908376e..ff6dfce734 100644 --- a/main/stoc/readme.md +++ b/main/stoc/readme.md @@ -97,10 +97,50 @@ Having the DLLs is necessary but not enough. The remaining chain, in the order 2. **`program/classes/` staging does not exist.** `getJavaVM` bootstraps from `$URE_INTERNAL_JAVA_DIR/unoloader.jar` → `URLClassLoader` → `com.sun.star.lib.unoloader.UnoClassLoader`, which then builds the real - classpath. Every jar target already exists — `//main/ridljar:unoloader`, - `//main/jurt:jurt`, `//main/javaunohelper:juh_jar`, - `//main/bridges:java_uno_jar`, `//main/unoil:unoil` — but - `stage_install.bzl` has no `classes/` destination for them. + classpath. Every jar target already exists, but this is **not** just a new + `classes/` destination in `stage_install.bzl` — three things bite: + + **(a) Bazel jar names are not runtime jar names.** `java_library(name = "x")` + emits `libx.jar`, and the runtime looks up bare `unoloader.jar` etc. by exact + name (`javavm.cxx` passes the literal string). So every entry needs an + explicit destination name — `stage_install`'s manifest already supports a + third `<destname>` column, as the `.rdb` entries use: + + | target | Bazel output | must stage as | + | --- | --- | --- | + | `//main/ridljar:unoloader` | `libunoloader.jar` | `unoloader.jar` | + | `//main/ridljar:ridl` | `libridl.jar` | `ridl.jar` — **but see (b)** | + | `//main/jurt:jurt` | `libjurt.jar` | `jurt.jar` | + | `//main/javaunohelper:juh_jar` | `libjuh_jar.jar` | `juh.jar` | + | `//main/unoil:offapi_java_jar` | `offapi_java_jar.jar` | `unoil.jar` | + | `//main/bridges:java_uno_jar` | `libjava_uno_jar.jar` | `java_uno.jar` | + + **(b) `ridl.jar` has to be MERGED, not copied.** Upstream's `ridl.jar` + contains the generated UDK types *and* the 27 hand-written sources; here + those are two targets, and `java_library(name = "ridl", exports = + [":udkapi_java"])` exports the generated types only at COMPILE time — the + jar itself holds just the hand-written classes. Staging `libridl.jar` + as-is would ship a `ridl.jar` with no `com.sun.star.uno.*` in it. Fix is the + same `java_binary(create_executable = False)` deploy-jar trick used for + `//main/cppuhelper:cppuhelper_qa_propertysetmixin`. + + **(c) The jars need MANIFESTS, which nothing currently produces.** Upstream + keeps them as checked-in files and `jar cfm`s them in: + - `main/ridljar/java/unoloader/.../manifest` — `Sealed: true` + - `main/jurt/util/manifest` — `Sealed: true`, un-sealing + `com/sun/star/lib/util/` and `com/sun/star/uno/` + - `main/javaunohelper/util/manifest` — `Sealed: true`, + `RegistrationClassName: com.sun.star.comp.JavaUNOHelperServices`, + `UNO-Type-Path:` with a deliberately empty value + + `UnoClassLoader.getClassLoader()` reads `UNO-Type-Path` off the jar's main + attributes, so these are load-bearing, not cosmetic. Neither + `jar_from_directory` nor `java_library` currently sets a manifest — + `jar_from_directory` runs a bare `jar cf`. **Open question for the next + session:** exactly how `jurt.jar` / `ridl.jar` / `unoil.jar` reach the class + loader, given `URE_INTERNAL_JAVA_CLASSPATH` expands empty and juh's + `UNO-Type-Path` is empty — read `UnoClassLoader.getClassLoader()` and + `javavm.cxx`'s `UnoClassLoader` construction before wiring anything. 3. **`jvmfwk` needs a JRE to find.** `javavendors.xml` plus the `jvmfwk3` config decide which JVM is selected; without them `jvmfwk` reports no JRE and `javavm` throws. Not yet staged.
