adaptation of JDK-8 to build with in-tree freetype

[judovana]

Hello!

There is openjdk/jdk8u-dev#709 agreed to go to jdk8, so a change in temurin-build is necessary to continue tp support future jdk8/

This is minimalist change, which is allowing to build jdk8 as temurin, but I do not belive it is correct, enough, nor final.

What is supposed to be supported in this script? Older jdk8? Jdk9+10? And so on. If none, maybe whole freetype download and build can be remove? Due to nature of tis commit, the jdk8 build in CI is most liekly going to fail before openjdk/jdk8u-dev#709 is merged and used.

Any guidance or thoughts highly appreciated

[karianna]

For completeness it would be good to detect jdk8u_+

[judovana]

For completeness it would be good to detect jdk8u_+

You mean to distinguish the freshly released "jdk8 5b3" as it went out 2014 or to distinguish the particular u472 and older x future ones?

[karianna]

being able to still support older jdk8 would be useful for completeness.

[judovana]

That may be easier then to fully support the custom build of free type. If the tag will be present, which usually is, then it can be decided. If not, the future in-tree approach should take place. Or maybe add switch?

However to fully remove the custom freetype, would simplify the scripts a lot. I'm still just brainstorming. Am not sure which direction to take. Thanx a lot for inputs!

[judovana]

being able to still support older jdk8 would be useful for completeness.

@karianna WDYT now? It is based on tag, so pretty limited, but had not found a better way.

This do not work wit -l ... but not sure if it is worthy of fixing this case

[judovana]

I would like to use

temurin-build/sbin/prepareWorkspace.sh

Line 592 in f4bcbeb

if bash ./configure --help | grep "with-png"; then

like approach, but in this moment, the sources do not exists. Thoughts?

[judovana]

The openjdk/jdk8u-dev#709 was integrated

[karianna]

Should this be gt and equal to?

[karianna]

Can we just simplify the logic here to capture 8u<version> and see if <version> is >=482 and then apply the freetype from source? There seems to be excess logic here

[judovana]

Should this be gt and equal to?

Nope. The "eq" is handled in final else. More readable it is:

if  majorBuildVersion< 482  ; then  //always old
     return  "old"
 elif majorBuildVersion > 482] ; then    //always new
     return  "new"
else // that means ==
  decideByMinorBuildNumber()
fi

[judovana]

Can we just simplify the logic here to capture 8u<version> and see if <version> is >=482 and then apply the freetype from source? There seems to be excess logic here

Of course we can. I made it to the most precise granularity, and if "b" is unimportant (which I Actually doubt) then of course. But it was done in early stage of 482, so maybe there can be done one exact match to 482-b01 and 482-b02 to avodi math check on b's XY.

I would like to use

temurin-build/sbin/prepareWorkspace.sh

Line 592 in f4bcbeb

if bash ./configure --help | grep "with-png"; then

like approach, but in this moment, the sources do not exists. Does anybody have any ideas? I will connect t some upcoming call due of this. @jiekang any idea who to ping/when to join a call?

[judovana]

@karianna Thanx for eyball, highly appreciated!

[andrew-m-leonard]

@judovana Is there a way to tell from the actual "source" what it is doing/supports? I don't know... but say if (some make file exists?!)

[andrew-m-leonard]

although not ideal, you could gate this logic on the existance or not of .github/workflows/freetype.vcxproj ,
which has been deleted as the submit workflow does not support building freetype src with this update?

[judovana]

hi! I would love to, But jdk sources do not exists in this moment. Otherwise check like

temurin-build/sbin/prepareWorkspace.sh

Line 592 in f4bcbeb

if bash ./configure --help | grep "with-png"; then

would always work, and would be much much better.

The only other way is to deference all this after jdk sources are built, which may not be trivial, as in "legacy" mode, the certificates are prepared long before jdk.

Tbh I would love to get rid of tag check, because the tag do not cover eg the build from tarball and maybe more.

I'm proposing to merge this, so jdk8 remain buildable, but would elaborate, on change of order.
That woudl mean to get rid of tag parsing, and try to reorder cloning the jdk, and building of cacerts. I already looked into it, and it seems doable. Only I got scared of such big change.
Or I will try to do so asap.

[judovana]

@andrew-m-leonard @sxa thoughts please?

[sxa]

Noting that I have managed to build the 8u482-b02 version with the original build scripts (not from the temurin tags) without any problem so it's not necessarily clear (unless I made a mistake in my build) what error I should expect.

Noting also that if we change the version of freetype in the build the SBOM validation script will also need to be updated to match what gets produced.

[andrew-m-leonard]

fyi, jdk8u482-b02_adopt will be appearing shortly once i've resolved : adoptium/mirror-scripts#76

[adamfarley]

@sxa - Does removing/changing the "--with-freetype=/usr/local/" bit in solaris.sh fall under the scope of this PR?

https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-solaris-sparcv9-temurin-simple/120/console

configure: error: Valid values for --with-freetype are 'system' and 'bundled'

[judovana]

Noting that I have managed to build the 8u482-b02 version with the original build scripts (not from the temurin tags) without any problem so it's not necessarily clear (unless I made a mistake in my build) what error I should expect.

Hi @sxa thats exceptionally weird, it can not work via temurin scripts, unless you are setting up freetype manually, you will always get configure: error: Valid values for --with-freetype are 'system' and 'bundled' bbecause its reading had chnaged:

$$ cd ~/git/temurin-build/
$$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
$$ git status
On branch master
Your branch is up to date with 'origin/master'.
$$ git pull
remote: Enumerating objects: 4, done.
...
   a3adb91..c6c180f  noMoreFreeTypeFor8 -> origin/noMoreFreeTypeFor8
Already up to date.
$$ git log
commit 1159fa56119232e8588a174de80d51a1158d8691 (HEAD -> master, origin/master, origin/HEAD)
Author: Adam Farley <[email protected]>
Date:   Fri Oct 24 17:36:30 2025 +0100

    Update expected build gcc for linux platforms to 14.2.0 (#4283)
    
    Except for Alpine and risc, which stay the same.
    
    Signed-off-by: Adam Farley <[email protected]>
    
$$  sh  makejdk-any-platform.sh  --tag jdk8u482-b02  jdk8u
Starting makejdk-any-platform.sh to configure, build (Adoptium)OpenJDK binary
Parsing opt: --tag
...
checking for cups/ppd.h... yes
configure: error: Valid values for --with-freetype are 'system' and 'bundled'
No configurations found for /home/jvanek/git/temurin-build/workspace/build/src/! Please run configure to create a configuration.
Makefile:55: *** Cannot continue.  Stop.
OpenJDK make failed, archiving make failed logs
Archiving and compressing with pigz

real	0m0.001s
user	0m0.000s
sys	0m0.002s
Your archive was created as /home/jvanek/git/temurin-build/workspace/build/src/build/linux-x86_64-normal-server-release/OpenJDK.tar.gz
Moving the artifact to location /home/jvanek/git/temurin-build/workspace/target//OpenJDK-makefailurelogs.tar.gz
archive done.
Failed to make the JDK, exiting

After the fix:

$$ git checkout noMoreFreeTypeFor8
Switched to branch 'noMoreFreeTypeFor8'
Your branch is behind 'origin/noMoreFreeTypeFor8' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)
$$ git pull
Updating a3adb91..c6c180f
Fast-forward
 sbin/build.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$$ git log
commit c6c180f6a015113395a03ee2a2878ccb20b484ef (HEAD -> noMoreFreeTypeFor8, origin/noMoreFreeTypeFor8)
Author: judovana <[email protected]>
Date:   Mon Nov 17 10:45:48 2025 +0100

    Update sbin/build.sh
    
    Co-authored-by: Martijn Verburg <[email protected]>

commit a3adb91b195deb0039c8f1555ac0400132af9465
Author: Jiri Vanek <[email protected]>
Date:   Thu Nov 13 11:57:56 2025 +0100

    The in-tree freetype will appear in 482-b02

$$  sh  makejdk-any-platform.sh  --tag jdk8u482-b02  jdk8u
Starting makejdk-any-platform.sh to configure, build (Adoptium)OpenJDK binary
Parsing opt: --tag
...
Using freetype: bundled
checking fontconfig/fontconfig.h usability... yes
...
## Starting langtools
Compiling 2 files for BUILD_TOOLS

[judovana]

@sxa - Does removing/changing the "--with-freetype=/usr/local/" bit in solaris.sh fall under the scope of this PR?

https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-solaris-sparcv9-temurin-simple/120/console

configure: error: Valid values for --with-freetype are 'system' and 'bundled'

Thats it. The patch is adjusting exactly this. Tahnx @adamfarley

[judovana]

Noting also that if we change the version of freetype in the build the SBOM validation script will also need to be updated to match what gets produced.

Thats a lot of EXPECTED_FREETYPE versions. In theory, once this effort is finished, all jdks (except 26) will have same, bundeld version. Isnt that correct?

[judovana]

Noting also that if we change the version of freetype in the build the SBOM validation script will also need to be updated to match what gets produced.

Thats a lot of EXPECTED_FREETYPE versions. In theory, once this effort is finished, all jdks (except 26) will have same, bundeld version. Isnt that correct?

I did some reading, and some experiments. Can I deffere this to separate PR?
How to test that file?

It do not seem correct to me. I thought, that everywhere except 8, the bundled freetype is used - that means, single version, as all jdks except tip (and for now 8) are on 2.13.3, no metter of OS. And jdk8 willb e on 2.9.0 now, 2.10.4 soon, and hopefully 2.13.3 before CPU...

[judovana]

@andrew-m-leonard

hi! I was partially wrong. Or better confused myself. Jdk exists in the moment of those checks, so I will switch to somehting like

isFreeTypeInSources() {
 if [ ! -e  build/src ] ; then
    echo "No jdk found to determine libfreetype/src presence"
    exit 1
 fi
 find build/src | grep  -q libfreetype/src
 return $?
}

That will simplify the whole code a lot. Howver, waht I want to do, and what made me to write that "jdk sources do nto exists in that moment" is this

 function configureWorkspace() {
   if [[ "${BUILD_CONFIG[ASSEMBLE_EXPLODED_IMAGE]}" != "true" ]]; then
     createWorkspace
+    checkoutAndCloneOpenJDKGitRepo
     downloadingRequiredDependencies
     downloadDevkit
     relocateToTmpIfNeeded
-    checkoutAndCloneOpenJDKGitRepo
     applyPatches
     if [ "${BUILD_CONFIG[CUSTOM_CACERTS]}" = "true" ] ; then
       prepareMozillaCacerts

Without it, the freetype would be downloaded, and build, but later not used. Thats why I moved to the cryptic tag parsing.

I will now elaborate on this, and will stop building and downloading (and of course using) the freetype if isFreeTypeInSources will be true.

[sxa]

Guess I correctly it is 8 only?

Yeah Solaris is only built on jdk8. Adoptium doesn't have a suitable compiler for building 11 which is the only other LTS version that works on Solaris from the upstream codebase.

[sxa]

@andrew-m-leonard Are there any implications of us having --skip-freetype in the BUILD_ARGS?
(Which I think just involves us downloading and building our own from source before the build)

EDIT: It looks like when we run through our make-adopt-build-farm.sh (tested on my laptop with the centos6 build image) it's coming up with

Using freetype: system

instead of what I'm getting from makejdk-any-platform.sh:

Using freetype: bundled

which we might need to do some checking of before merging this

[sxa]

Running checks in the following jobs (Solaris ones needed this playbook fix too) so we can see what the build output looks like on our systems with the full build Adoptium scripts:

• Windows Server 2022: FAILED on the VS2013 install (Unrelated to this PR) Re-running with FASTMODE
• CentOS6/x64: PASSED
• Solaris: FAILED

Solaris build failed with:

ld: fatal: file /usr/sfw/lib/libfreetype.so: wrong ELF class: ELFCLASS32
ld: fatal: file /usr/sfw/lib/libfreetype.so: wrong ELF class: ELFCLASS32
ld: fatal: file processing errors. No output written to /export/home/local/vagrant/openjdk-build/workspace/build/src/build/solaris-x86_64-normal-server-release/jdk/lib/amd64/libfontmanager.so
gmake[2]: *** [lib/Awt2dLibraries.gmk:958: /export/home/local/vagrant/openjdk-build/workspace/build/src/build/solaris-x86_64-normal-server-release/jdk/lib/amd64/libfontmanager.so] Error 2

[sxa]

Also noting that the for the regular temurin builds of jdk8u482-b02_adopt before this fix is applied the Linux platforms ran through ok but Win64, Win32, mac/x64 and AIX all had issues relatign to Freetype.

Most of those failed the build step (not always for the same reason!) but AIX failed the SBOM validation step:

ERROR: FreeType version not 2.8.0 (SBOM has Unknown)
FREETYPE is Unknown

[judovana]

@andrew-m-leonard Are there any implications of us having --skip-freetype in the BUILD_ARGS? (Which I think just involves us downloading and building our own from source before the build)

It should still be valid for older jdk8 (and possibly 9 and 10, although they do not build anyway), or not? Am moreover trying to understand what all I could miss.

EDIT: It looks like when we run through our make-adopt-build-farm.sh (tested on my laptop with the centos6 build image) it's coming up with

That script do not seem to adjust freetype:( Unless ${CONFIGURE_ARGS} brings it from elsewhere?

Using freetype: system

instead of what I'm getting from makejdk-any-platform.sh:

Using freetype: bundled

which we might need to do some checking of before merging this

THat would be major divergence which should not be there. Thanx for noticing it.

[judovana]

Also noting that the for the regular temurin builds of jdk8u482-b02_adopt before this fix is applied the Linux platforms ran through ok but Win64, Win32, mac/x64 and AIX all had issues relatign to Freetype.

Most of those failed the build step (not always for the same reason!) but AIX failed the SBOM validation step:

ERROR: FreeType version not 2.8.0 (SBOM has Unknown)
FREETYPE is Unknown

The logs throws 404. I would b ver interested in final arguments. The sbom failure is expected, as the build should pick up bundled 2.9. But the fact that build passed keeps me wondering where is the catch. Were there any built artifacts at all? I guess yes, but false positivum may be also the reason. I'm still very nervous from swapping the two work-flow lines.

[sxa]

The logs throws 404.

Can you clarify which link is giving a 404 - all the ones in my previous comment should be publicly accessible 🤔

Were there any built artifacts at all?

From Linux? Yep! https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-linux-aarch64-temurin/521/artifact/workspace/target/ is an example of the job with artifacts from a successful jdk8u482-b02 on Linux/aarch64

I haven't gone through it in detail but noting that we set BUILD_ARGS to have --skip-freetype in the Temurin build scripts on Linux which may be impacting the behaviour here
Ref:

temurin-build/build-farm/platform-specific-configurations/linux.sh

Line 26 in a44863d

export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"

[judovana]

The logs throws 404.

Can you clarify which link is giving a 404 - all the ones in my previous comment should be publicly accessible 🤔

https://ci.adoptium.net/job/build-scripts/job/openjdk8-pipeline/3040/console => 404 others works

Were there any built artifacts at all?

From Linux? Yep! https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-linux-aarch64-temurin/521/artifact/workspace/target/ is an example of the job with artifacts from a successful jdk8u482-b02 on Linux/aarch64

Good :)

I haven't gone through it in detail but noting that we set BUILD_ARGS to have --skip-freetype in the Temurin build scripts on Linux which may be impacting the behaviour here Ref:

temurin-build/build-farm/platform-specific-configurations/linux.sh

Line 26 in a44863d

export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"

Investigating. Thanx!

[sxa]

The logs throws 404.

Can you clarify which link is giving a 404 - all the ones in my previous comment should be publicly accessible 🤔

https://ci.adoptium.net/job/build-scripts/job/openjdk8-pipeline/3040/console => 404 others works

Thanks - raised adoptium/ci-jenkins-pipelines#1327 to investigate

[judovana]

Investigating. Thanx!

Ok, the conclusion is quite interesting. When you use --skip-freetype it is changing the build to use defaults, thats why it passed on the systems which were using it. It would build both pre bundled_freetype and also post one.
In the scope of temurin build "configure" it is "jsut" BUILD_CONFIG[FREETYPE]="true/false" , however the output is much more interesting:

no switch; old jdk:

configure run with --with-freetype=/home/jvanek/git/temurin-build/workspace/./build//installedfreetype
resulting to

checking for cups/ppd.h... yes
configure: Found freetype include files at /home/jvanek/git/temurin-build/workspace/./build//installedfreetype/include using --with-freetype
checking for freetype includes... /home/jvanek/git/temurin-build/workspace/build/installedfreetype/include
checking for freetype libraries... /home/jvanek/git/temurin-build/workspace/build/installedfreetype/lib
checking if we can compile and link with freetype... yes
checking if we should bundle freetype... yes
checking fontconfig/fontconfig.h usability... yes

--skip-freetype switch; old jdk

configure run without any freetype, so run to defaults, which is

checking for cups/ppd.h... yes
checking for FREETYPE... yes
checking for freetype... yes (using pkg-config)
checking if we can compile and link with freetype... yes
checking if we should bundle freetype... no
checking fontconfig/fontconfig.h usability... yes

no switch; new jdk

configure run with --with-freetype=bundled
leading of course to

......
checking for cups/ppd.h... yes
Using freetype: bundled
checking fontconfig/fontconfig.h usability... yes
......

--skip-freetype switch; new jdk

configure run without any freetype, so run to defaults, which is, however

checking for cups/ppd.h... yes
checking for FREETYPE... yes
checking for freetype... yes (using pkg-config)
Using freetype: system
checking fontconfig/fontconfig.h usability... yes

where new jdk refers to anything newer then 482-b01

So although it looks scary, when summed up:

• external; built by temurin-build or cached - set for no switch; old jdk
• system; for --skip-freetype switch; old jdk
• bundled; for no switch; new jdk
• system; for --skip-freetype switch; new jdk
  (please review above)

It seems, that this behavior is correct, as for jdk21 with --skip-freetype can see:
BUILD_CONFIG[FREETYPE]="false"
Using freetype: system
and no "freetype" in configure .

Jdk21 without it, I can see:
BUILD_CONFIG[FREETYPE]="true"
Using freetype: bundled
and with --with-freetype=bundled in configure

So - in my opinion - no action is needed for this patch, but every wrapper of build.sh (eventually ./makejdk-any-platform.sh/prepareWorkspace.sh) should drop the --skip-freetype :

build-farm/platform-specific-configurations/mac.sh:    export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/alpine-linux.sh:  export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/solaris.sh:export BUILD_ARGS="${BUILD_ARGS} --skip-freetype --make-args SHELL=/bin/bash"
build-farm/platform-specific-configurations/aix.sh:  export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/windows.sh:      export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/windows.sh:      export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/windows.sh:      export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/windows.sh:      export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/linux.sh:  export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
CHANGELOG.md:1. `-sf` changes to `-F`, (long form `--skip-freetype` stays the same).
makejdk-any-platform.1:.BR \-F ", " \-\-skip-freetype
README.md:-F, --skip-freetype
sbin/common/config_init.sh:        "--skip-freetype" | "-F" )
cyclonedx-lib/build.xml:                  <arg value="--clean-git-repo --jdk-boot-dir /usr/lib/jvm/jdk-16 --configure-args  --disable-warnings-as-errors --enable-ccache --enable-dtrace --target-file-name OpenJDK17-jdk_x64_linux_hotspot_17_35.tar.gz --release --clean-libs --tag jdk-17+35_adopt --skip-freetype --use-jep319-certs --create-debug-image --build-variant hotspot jdk17"/>
cyclonedx-lib/build.xml:                  <arg value="--clean-git-repo --jdk-boot-dir /usr/lib/jvm/jdk-16 --configure-args  --disable-warnings-as-errors --enable-ccache --enable-dtrace --target-file-name OpenJDK17-jdk_x64_linux_hotspot_17_35.tar.gz --release --clean-libs --tag jdk-17+35_adopt --skip-freetype --use-jep319-certs --create-debug-image --build-variant hotspot jdk17"/>

In addition the --skip-freetype in README.md and makejdk-any-platform.1 should be adjusted, as it actually swap bundled/system freetype, and thus (probably) deprecated, as the image would not be portable.

WDYT?

[judovana]

Investigating. Thanx!

While studying above, I had noticed one more possible issue. The --freetype-dir do not seem to work as expected.

• On "old-jdk8" the docs man/readme lies - as using the --skip-freetype leads to use system freetype, the --freetype-dir is ignored (which is in ooposite to docs, which says

       -f, --freetype-dir <path>
              specify the location of an existing FreeType  library.   This  is
              typically used in conjunction with <-F>.
...
       -F, --skip-freetype
              skip building Freetype automatically.  This is typically used  in
              conjunction with <-f>.

When --skip-freetype is omitted, the --freetype-dir works as expected.

• On "new-jdk8" and on 11+the usage of -freetype-dir is leading to imminent configure error
  • with added --skip-freetype its useless as before, as system is used.

My proposal is to terminate build asap, once --freetype-dir in jdk with in-tree freetype is used, fix the docs (replace This is typically used in conjunction with <-f>. by This will lead to dynamic linking of system freetype and deprecate -f as it is only for non-freetype-bundling jdks.
Similarly, it if the "old jdk8" will detect usage of --skip-freetype and --freetype-dir it will halt, with verbose explanation. And + the --skip-freetype explaining system/bundled as mentioned earlier.

Unlike various platform-specific-configurations, CHANGELOG.md and build.xml` changes, where I hesitate, this should be part of the pr.. WDYT?

[judovana]

So - in my opinion - no action is needed for this patch, but every wrapper of build.sh (eventually ./makejdk-any-platform.sh/prepareWorkspace.sh) should drop the --skip-freetype :

build-farm/platform-specific-configurations/mac.sh: export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/alpine-linux.sh: export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/solaris.sh:export BUILD_ARGS="${BUILD_ARGS} --skip-freetype --make-args SHELL=/bin/bash"
build-farm/platform-specific-configurations/aix.sh: export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/windows.sh: export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/windows.sh: export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/windows.sh: export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/windows.sh: export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
build-farm/platform-specific-configurations/linux.sh: export BUILD_ARGS="${BUILD_ARGS} --skip-freetype"
CHANGELOG.md:1. -sf changes to -F, (long form --skip-freetype stays the same).
makejdk-any-platform.1:.BR -F ", " --skip-freetype
README.md:-F, --skip-freetype
sbin/common/config_init.sh: "--skip-freetype" | "-F" )
cyclonedx-lib/build.xml:
cyclonedx-lib/build.xml:

In addition the --skip-freetype in README.md and makejdk-any-platform.1 should be adjusted, as it actually swap bundled/system freetype, and thus (probably) deprecated, as the image would not be portable.

For tuning, initiated: #4320

[judovana]

docs (replace This is typically used in conjunction with <-f>. by This will lead to dynamic linking of system freetype and deprecate -f as it is only for non-freetype-bundling jdks. Similarly, it if the "old jdk8" will detect usage of --skip-freetype and --freetype-dir it will halt, with verbose explanation. And + the --skip-freetype explaining system/bundled as mentioned earlier.

hints welcomed! #4321

[sxa]

In addition the --skip-freetype in README.md and makejdk-any-platform.1 should be adjusted, as it actually swap bundled/system freetype, and thus (probably) deprecated, as the image would not be portable.

I would tentatively agree with all of your analysis :-)

I note that it looks like we use --skip-freetype on all versions before 21. Would it be correct to make this change only on jdk8 or would we be looking at it for 8 and 11 too? I guess we'd need to be certain on why we initially added this option in. Looking back, @andrew-m-leonard did some analysis in #3504 (and his associated PR added the bits to make it act differently on jdk21+) so I suggest he takes another look at this PR in the context of the changes he made at that time.

I feel we should definitely adjust the build-farm/platform-specific-configurations files under this PR too to ensure that Temurin is building for each version/platform with the options we want it it.

[judovana]

In addition the --skip-freetype in README.md and makejdk-any-platform.1 should be adjusted, as it actually swap bundled/system freetype, and thus (probably) deprecated, as the image would not be portable.

I would tentatively agree with all of your analysis :-)

I note that it looks like we use --skip-freetype on all versions before 21. Would it be correct to make this change only on jdk8 or would we be looking at it for 8 and 11 too? I guess we'd need to be certain on why we initially added this option in. Looking back, @andrew-m-leonard did some analysis in #3504 (and his associated PR added the bits to make it act differently on jdk21+) so I suggest he takes another look at this PR in the context of the changes he made at that time.

Thanx for the info!
The https://bugs.openjdk.org/browse/JDK-8193017 is before jdk17 forked. You may see that eg https://bugs.openjdk.org/browse/JDK-8348596 is backoprted everywhere, except 8, were I had jsut not yet requested it (waiting for openjdk/jdk8u-dev#720 to be merged before requesting it)

So I think this change should be global. But there may of course be a reasons I'm not awaere off:(

I feel we should definitely adjust the build-farm/platform-specific-configurations files under this PR too to ensure that Temurin is building for each version/platform with the options we want it it.

I had opened it in separate PR (#4320) , but i have no objections to includ eit here. I put it separately, because it is affecting also 11 and 17.

[andrew-m-leonard]

The move to "bundled" I did back in 2023, was to support reproducible builds, so as to ensure deterministic freetype binary.

[sxa]

The move to "bundled" I did back in 2023, was to support reproducible builds, so as to ensure deterministic freetype binary.

Is there a particular reason that change wasn't done across all versions (even though they wouldn't have been reproducible)? That would have seemed the obvious thing to do which makes me nervous that there was some specific problem that was potentially going to be caused.

[andrew-m-leonard]

The move to "bundled" I did back in 2023, was to support reproducible builds, so as to ensure deterministic freetype binary.

Is there a particular reason that change wasn't done across all versions (even though they wouldn't have been reproducible)? That would have seemed the obvious thing to do which makes me nervous that there was some specific problem that was potentially going to be caused.

From the PMC minutes discussing this back in Nov 22nd 2023:
For reproducible and consistency purposes we would prefer to go with bundling the freetype library. If a user is used to using fonts provided by their system freetype they may notice a difference with this change
Plan to start with JDK21 on moving to bundled fontlib before rolling out to earlier versions.
Don’t expect to see problems with OpenJDK support of the latest version of fontlib.
Question if this lack of reproducibility is known upstream, and if the fontlib is bundled by default. If not this should be raised there too.
DECISION: PMC agreed to start bundling fontlib as part of the build from JDK21 immediately, then backporting to earlier JDK version builds if this is successful.

[andrew-m-leonard]

So the plan originally was to backport to earlier versions... but that was not done yet... So seems reasonable to do that now

[judovana]

Thanx a lot for all that insight. Highly appreciated!

[judovana]

hi! Did run quite a few tests around the freetype switches on both freetype bundled and external-needed jdks, and it seems it behave as it should now.

Ok t go by me ;)

Please, state your wish how to handle all related PRs: #4306 (comment)

I do not mind to include them in this, or as separate. Being separate have afaik many benefits, but it is up to you. W can even discuss them in separate PRs, and then move to this one. Maybe even some logic (liek the checks may move elsewhere (eg to the man/reasme one, but for that I'm more against, then for) . Note, that the configuration one, probably can not pass until this one is finished. Similarly the sbom one can not pass before 2.13.3 reaches jdk8u (already under review)

[sxa]

I do not mind to include them in this, or as separate. Being separate have afaik many benefits, but it is up to you.

I'm OK with the multi-PR approach :-) Thanks for all your work on this.