![]() ![]() rw-r-r- 1 boxcat staff 1503 14 May 12:54 ASSEMBLY_EXCEPTION Once we have our Java 1.5 JDK, we can then build OpenJDK 7. A problem with the OpenJDK 7 release is that Sun did not have the legal authority to release all of the Java source code as part of the OpenJDK release, meaning that the OpenJDK 7 release is incomplete and cannot be built on its own to produce a complete JDK. To overcome this problem, the GNU Classpath project produced a new project which combined their own GNU Classpath source code with the source code of OpenJDK: the IcedTea distribution. This provided replacements of the embargoed components of Java, allowing a complete build of Java 7 from source.įrom there, the bootstrap process is fairly straightforward: we use the OpenJDK 7 package we built to then go build OpenJDK 8. We then use OpenJDK 8 to build OpenJDK 9, OpenJDK 9 to build OpenJDK 10, but then we hit a problem in glibc on x86_64 systems with the AVX512VL extension: string concatenation is implemented using AVX512 instructions on these systems, and something about the OpenJDK 9 JVM tickled the AVX512 implementation in just the right way to cause memory corruption:įrom there, the bootstrap process is fairly straightforward: we use the OpenJDK 7 package we built to then go build OpenJDK 8.After the initial clone, the local repo will look like this: With the understanding of the components needed to build a freely redistributable replacement for the Sun Java 1.5 JDK, we can start to understand the steps we need to take in order to build them and put them together. That part is fairly straightforward: the necessary GNU Classpath components were bundled together with GCC until they were removed from GCC 7, and the Eclipse Compiler for Java can be downloaded from the Eclipse Foundation website.īut Wolfi ships with GCC 13, which is much newer than GCC 7, so we had to introduce a gcc-6 package to Wolfi for the sole purpose of leveraging the GNU Compiler for Java and GNU Classpath infrastructure to build the Eclipse Compiler for Java and act as a JVM, which is then stitched together into something resembling a standard Java 1.5 JDK in the aforementioned java-gcj-compat package. In order to build GCC 6 with modern libraries, we had to include a few patches, which were taken from Alpine’s GCC 6 tree. To build the java-gcj-compat package, we make use of software from the GNU Classpath project, such as the GNU Compiler for Java, and software from the Eclipse Foundation, such as the Eclipse Compiler for Java. The GNU Classpath project provides a mostly complete implementation of the Java 1.5 class libraries, while the GNU Compiler for Java is used to build the Eclipse Compiler for Java, which itself provides a Java compiler capable of compiling source code leveraging Java 1.5 features. Accordingly, if you start from OpenJDK 8, the oldest LTS version of OpenJDK, you would have to build OpenJDK 9 through 16 to get to OpenJDK 17.īut OpenJDK 8 itself has to be built with OpenJDK 7, which itself has to be built with Java 1.5.0 or newer. Sun never provided freely redistributable source code for Java 1.5.0 (later renamed Java 5 retroactively), so how do we overcome that? The answer is complicated: we must assemble a JDK from various pieces of source code which reimplements Sun’s Java 1.5. In other words, OpenJDK 17, the current LTS version, must be built by OpenJDK 16, which itself is not an LTS version. As is common when bootstrapping programming languages, each release of the OpenJDK must be built by the previous release. Our journey begins with OpenJDK, which is the official source release of Java managed by Oracle. Because of Oracle’s restrictions on their own binary distribution of Java, many alternative distributions of Java based on OpenJDK have popped up. This enables us to provide full provenance from pure source code for the entire Java ecosystem in Wolfi. ![]() Providing proof of the origin of Java distributions, from the source code all the way to the final binary package, is a significant challenge for projects that produce distributions of OpenJDK. As a company that focuses on software supply chain security, and also produces distributions of OpenJDK, we have been working to create a chain of OpenJDK packages which originates from an alternative JDK built from GNU Classpath, the GNU Compiler for Java, and the Eclipse Compiler for Java.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |