Update to jdk8u504-b01 and FreeType 2.14.3 - #743
Merged
Merged
Conversation
Moves OpenJdkUpdateVersion from 482 to 504, OpenJdkBuildNumber from b08 to b01, and the ext/openjdk submodule to 5c75a45a, the tip of ikvm-jdk8u504-b01. Upstream has moved on twice since 8u482, so this skips past 8u492 to the current GA. Ancestry is linear (482, 492, 502, 504), so merging the newest tag subsumes the older ones. 8u504 is an out-of-band release: six commits on top of the 8u502 July CPU. The fork branch was cut from the jdk8u504-b01 tag and ikvm-jdk8u482-b08 merged into it. The merge was clean. All fifteen carried source forks came across byte-identical, and upstream touched none of those paths in this range, so there was nothing to reconcile. Nothing else in the tree needs to change. The delta is CPU security backports, bundled library refreshes and test work, with no new API. Of the sixty-three changed Java files under jdk/src, only two collide with an OpenJdkSource Remove rule: ZipFile.java, which we replace wholesale, and Metacity.java, in the GTK look and feel package we drop entirely. None has a counterpart under IKVM.Runtime Java/Externs. The one signature change worth naming is ZipFile.getEntry, which drops its addSlash parameter in JDK-8370995. That is the kind of change that turns a native into a stub that throws at runtime, but our ZipFile is a pure Java implementation with no natives, and its getEntry already does the unconditional trailing slash fallback that 8u504 restores. It is also the only native declaration change in the range. The new ChunghwaTLSPolicy class, the two new WISeKey roots, tzdata 2026b and the java.security changes for CHUNGHWA_TLS and com.sun.security.crl.maxSize all arrive through existing globs. zlib 1.3.2, libpng 1.6.57, giflib 6.1.2 and LCMS 2.19.1 add and remove no files, and libzip globs its sources. Eighteen jtreg tests were added and one removed, IllegalRecordVersion.java, superseded by HandshakeWithInvalidRecordVersion.java. None of the nineteen appears in ExcludeList.txt, so there is no stale entry to drop, and any new exclusions should wait for CI rather than be guessed at here. One thing this deliberately leaves alone: ext/freetype is pinned at VER-2-13-2, which matched 8u482. 8u502 took the JDK to FreeType 2.14.2 and 8u504 to 2.14.3. We build FreeType from the submodule rather than the JDK copy, so nothing breaks, but the gap opens here. 2.14 changed enough that upstream needed -Dinline=__inline for 32 bit MSVC, so bumping it is its own change with its own risk. Verified by building IKVM.Java narrowed to win-x64: javac compiles the merged source set and ikvmc imports it for net472, net6.0 and net8.0 with no errors and no importer diagnostics.
8u482 bundled FreeType 2.13.x, which is what VER-2-13-2 matched. 8u502 took the JDK to 2.14.2 and 8u504 to 2.14.3, so moving to jdk8u504-b01 opened a gap between the FreeType we build and the one the JDK expects. This closes it. The version macros in the submodule now read 2.14.3, identical to the copy bundled under jdk/src/share/native/sun/awt/libfreetype. No project changes were needed. All forty-five paths listed in libfreetype.clangproj still exist in 2.14.3, and everything 2.14 added arrives through the amalgamated module files we already compile: autofit.c picked up ft-hb.c, ft-hb-ft.c, afadjust.c and afgsub.c, and sfnt.c picked up ttgpos.c. The removed ttsubpix.c dropped out of truetype.c's includes at the same time, so there is no stale reference either. HarfBuzz stays out. FT_CONFIG_OPTION_USE_HARFBUZZ is commented out in ftoption.h and we do not define it, so the new ft-hb.c compiles inert and no dependency is added. Only Windows and macOS are affected. libfontmanager references the submodule under win- and osx- conditions only; on Linux it takes freetype from the SDK sysroot, and IKVM.Image ships freetype.dll for exactly the Windows and macOS runtimes. Verified by compiling libfreetype for win-x64 and win-x86 and libfontmanager for win-x64 with its object directory cleared first, so freetypeScaler.c genuinely recompiled against the 2.14 headers rather than being skipped as up to date. No errors, and no diagnostic from freetypeScaler.c or from anything under ext/freetype. The sixteen warnings in the fontmanager build are longstanding clang pedantry in fontpath.c and lcdglyph.c, about deprecated Win32 calls and pointer signedness, unrelated to FreeType. The 32 bit build is the one worth calling out: 2.14 is what forced upstream to add -Dinline=__inline for 32 bit MSVC, and win-x86 compiled clean without it, since we build with clang at c17.
All three come from this upgrade, all three fail identically on net472 win-x64, net8.0 win-x64 and net8.0 linux-x64, and all three failed on both CI attempts rather than intermittently, so the scope is generic-all. Partition 4, the two CAInterop cases. JDK-8372351 added two WISeKey roots, and CAInterop.java gained a test id for each. They fail the same way every other CAInterop case in that block already does, with a FileNotFoundException on jre/lib/security/cacerts, which is the layout problem the block's "needs JRE subfolder" comment describes. They were not excluded only because they did not exist when the block was written. Partition 2, BulkSoundBank. This one is not a layout quirk. It is the regression test for JDK-8350813, and the fix it covers computes a budget from Runtime.maxMemory() minus the used heap, throwing InvalidMidiDataException when the audio data will not fit. Our Runtime.maxMemory returns Long.MAX_VALUE, which is what the spec asks for from a runtime with no inherent limit, so the budget is effectively infinite, the guard never fires, and the read continues until the CLR throws OutOfMemoryError. The test also asks for -Xmx1g, which we log as an unrecognized option. Both facts are the same underlying one: we do not model a heap cap. The test cannot pass until that changes, so the exclusion carries the reasoning rather than a bare line. Not excluded here: TextAreaTextEventTest failed once on partition 14 net8.0 win-x64 in the first attempt and passed in the second. It is a robot driven AWT test, predates this upgrade and is unrelated to it, so one occurrence is left as evidence for a separate decision rather than folded into this change.
This was referenced Aug 25, 2026
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.
Moves the JDK from 8u482-b08 to 8u504-b01 and
ext/freetypefrom 2.13.2 to 2.14.3.This replaces #722, which bumped
OpenJdkUpdateVersionto 492 and left the submodule where it was. Upstream has since released twice more, so this goes to the current GA rather than to 492. Ancestry is linear (482, 492, 502, 504), so merging the newest tag subsumes the older ones. 8u504 is an out-of-band release: six commits on top of the 8u502 July CPU.Changes
Directory.Build.props:OpenJdkUpdateVersion482 to 504,OpenJdkBuildNumberb08 to b01, matchingJDK_UPDATE_VERSION=504in the tag'scommon/autoconf/version-numbersext/openjdk: to5c75a45a, the tip of the newikvm-jdk8u504-b01branch on ikvmnet/jdk8uext/freetype: to0a0221a1, tagVER-2-14-3The fork branch
ikvm-jdk8u504-b01was cut from thejdk8u504-b01tag withikvm-jdk8u482-b08merged into it, the same shape as the 472 merge. The merge was clean. All fifteen carried source forks came across byte-identical, and upstream touched none of those paths in this range, so there was nothing to reconcile.Why nothing else changed
The delta is 115 commits of CPU security backports, bundled library refreshes and test work, with no new API.
Of the sixty-three changed Java files under
jdk/src, two collide with anOpenJdkSource Removerule, and neither needs anything:ZipFile.javais removed unconditionally and replaced by our own pure Java implementation.Metacity.javasits in the GTK look and feel package, which is removed only whenIkvmJavaRuntimeIdentifieriswinorref. Thelinuxandosxbuilds compile it, along with the GTK icons, the metacity fallback theme and the GTK resource bundles. So this change does reach those two runtimes. It is JDK-8382471, wrapping the gconf reader in try-with-resources to fix a stream leak, with no API or behaviour change to accommodate.None of the sixty-three has a counterpart under
IKVM.Runtime/Java/Externs.The one signature change worth naming is
ZipFile.getEntry, which drops itsaddSlashparameter in JDK-8370995. That is the kind of change that turns a native into a stub that throws at runtime, but ourZipFileis a pure Java implementation with no natives, and itsgetEntryalready does the unconditional trailing slash fallback that 8u504 restores. It is also the only native declaration change in the range.ChunghwaTLSPolicy, the two new WISeKey roots, tzdata 2026b, and thejava.securityadditions forCHUNGHWA_TLSandcom.sun.security.crl.maxSizeall arrive through existing globs. zlib 1.3.2, libpng 1.6.57, giflib 6.1.2 and LCMS 2.19.1 add and remove no files, and libzip globs its sources.FreeType
8u482 bundled 2.13.x, which VER-2-13-2 matched. 8u502 took the JDK to 2.14.2 and 8u504 to 2.14.3, so this bump closes a gap the JDK move would otherwise open. No project changes were needed: all forty-five paths in
libfreetype.clangprojstill exist, and everything 2.14 added arrives through the amalgams we already compile,autofit.cpicking upft-hb.c,ft-hb-ft.c,afadjust.candafgsub.c, andsfnt.cpicking upttgpos.c. HarfBuzz stays out, sinceFT_CONFIG_OPTION_USE_HARFBUZZis not defined. Only Windows and macOS are affected; on Linux libfontmanager takes freetype from the SDK sysroot.Verification
Local, Windows only, compile and link. Nothing was executed.
IKVM.Javanarrowed to win-x64: javac compiles the merged source set and ikvmc imports it for net472, net6.0 and net8.0 with no errors and no importer diagnosticslibfreetypefor win-x64 and win-x86: no errors. The 32 bit build is the one worth calling out, since 2.14 is what forced upstream to add-Dinline=__inlinefor 32 bit MSVC, and win-x86 compiled clean without it, as we build with clang at c17libfontmanagerfor win-x64 with its object directory cleared first, sofreetypeScaler.cgenuinely recompiled against the 2.14 headers: no errors, and no diagnostic fromfreetypeScaler.cor from anything underext/freetypemacOS is the other consumer of
ext/freetypeand was not built locally. Thelinuxandosxvariants of IKVM.Java, which are the ones that compile the GTK sources, were not built locally either. jtreg triage is left to CI.Tests
Eighteen jtreg tests were added upstream and one removed,
IllegalRecordVersion.java, superseded byHandshakeWithInvalidRecordVersion.java. None of the nineteen appears inExcludeList.txt, so there is no stale entry to drop, and no exclusions are added here. Any that turn out to be flaky should be added once CI has evidence, with the scope kept as narrow as that evidence supports.Note that
VerifyCACerts.javais not excluded and does run. It hard codes a count, a SHA-256 of the whole generated store, and per-alias fingerprints; upstream moved the count from 109 to 111 and updated the checksum in this range. We generate cacerts from the samejdk/make/data/cacertsdata the test tracks, so those stay consistent.