FreeType version used across Temurin versions is inconsistent

[andrew-m-leonard]

Issue: #3493
highlighted the various Freetype versions used for Temurin versions, and the various different versions Temurin is built and linked with.
Should we look to provide a more consistent set of versions, and possibly use "Bundled" where possible?

[sxa]

Running the tooling produced as part of #3484 against JD11.0.21+9 the following was noted (using data from the SBOMs:

Platform	version
Linux/arm32	2.6.1
Linux/ppc64le	2.8.0
Linux/s390x	2.8.0
Linux/x64	2.3.11
Mac/aarch64	2.13.0
Mac/x64	2.13.0
Windows/x64	2.13.0
Windows/x86-32	2.13.0
AIX/ppc64	2.8.0
Alpine/x64	2.11.1
Linux/aarch64	2.8.0

[andrew-m-leonard]

Trying to test whether using a different FreeType "system" version seems not easy. When using the build image and trying to reference a different FreeType other than the glibc 2.17 compatible one in the build container image, results in linking issues due to glibc linking. Similarly trying to build outside of docker it’s quite hard to replace a System FreeType due to it’s dependency links to other system components.

From a Reproducible Build perspective, using a different system FreeType would probably not alter the binary. It is also going to be not relevant when moving to using a specific DevKit, where the system FreeType is in the DevKit.

[sxa]

it’s quite hard to replace a System FreeType

Not sure why we'd want to do that - the goal ought to be to use the bundled freetype and ship that library with the JDK. We absolutely should not be interfering with OS-installed libraries.

From a Reproducible Build perspective, using a different system FreeType would probably not alter the binary.

I'd dispute that - the headers are #included in the code so there's definitely a chance that different versions could make a difference to the binaries.

[andrew-m-leonard]

it’s quite hard to replace a System FreeType

Not sure why we'd want to do that - the goal ought to be to use the bundled freetype and ship that library with the JDK. We absolutely should not be interfering with OS-installed libraries.

I am trying to simply "prove" if using a different system FreeType would produce different binaries... so far I have not been able to do that..I can only use FreeType 2.8.0 which is the latest. It does not seem possible to go backwards... any ideas?

[andrew-m-leonard]

From a Reproducible Build perspective, using a different system FreeType would probably not alter the binary.

I'd dispute that - the headers are #included in the code so there's definitely a chance that different versions could make a difference to the binaries.

@sxa Yes, I was absolutely wrong!
So I've eventually managed to do a dual build with different versions of FreeType using the following method:

1. On a aarch64 linux (Ubuntu 20.04) VM do a release type build of Temurin jdk-21.0.1+12, this used FreeType 2.10.1
   • Copy built build/*/images/jdk to a JDK1 folder
2. Created a DevKit on the the same VM targetting aarch64 CentOS7, this creates a sysroot including FreeType 2.8.0
3. Perform a new build using the exact same configure command as (1), but add:

--with-freetype-include=/home/andrew/jdk21u/build/devkit/result/aarch64-linux-gnu-to-aarch64-linux-gnu/aarch64-linux-gnu/sysroot/usr/include/freetype2
--with-freetype-lib=/home/andrew/jdk21u/build/devkit/result/aarch64-linux-gnu-to-aarch64-linux-gnu/aarch64-linux-gnu/sysroot/usr/lib64

- Copy built build/*/images/jdk to a JDK2 folder

5. Perform a diff of JDK1 and JDK2:

~$ diff -r jdk1 jdk2
Binary files jdk1/jdk/jmods/java.desktop.jmod and jdk2/jdk/jmods/java.desktop.jmod differ
Binary files jdk1/jdk/lib/libfontmanager.debuginfo and jdk2/jdk/lib/libfontmanager.debuginfo differ
Binary files jdk1/jdk/lib/libfontmanager.so and jdk2/jdk/lib/libfontmanager.so differ

As can be seen libfontmanager.so differs due to the use of different "system" FreeType

[sxa]

As can be seen libfontmanager.so differs due to the use of different "system" FreeType

Which would lead me to say that we should be using the bundled freetype everywhere to get a consistent experience. Of course, we'd still need to check whether it builds reproducibly - hopefully it does ...

[andrew-m-leonard]

As can be seen libfontmanager.so differs due to the use of different "system" FreeType

Which would lead me to say that we should be using the bundled freetype everywhere to get a consistent experience. Of course, we'd still need to check whether it builds reproducibly - hopefully it does ...

Yes I would agree, we'd be best using "bundled".

I have just check some other Vendors, and jdk-21.0.1+12 for both Red Hat and Zulu both use "Bundled" FreeType:

Red Hat % ls java-21-openjdk-21.0.1.0.12-1.portable.jdk.x86_64/lib/libfreetype.so
java-21-openjdk-21.0.1.0.12-1.portable.jdk.x86_64/lib/libfreetype.so
 
Zulu % ls zulu21.30.15-ca-jdk21.0.1-linux_x64/lib/libfreetype.so 
zulu21.30.15-ca-jdk21.0.1-linux_x64/lib/libfreetype.so

[andrew-m-leonard]

As confirmed in the PMC, Temurin will change to use "bundled" FreeType from jdk-21.0.2 +