Pros of temurin-build

• Focuses on building and packaging OpenJDK, making it easier for users to obtain ready-to-use JDK builds
• Provides a more streamlined process for creating consistent, cross-platform JDK distributions
• Includes additional tools and scripts for testing and quality assurance

Cons of temurin-build

• Less comprehensive than the full OpenJDK codebase, as it primarily deals with build processes
• May have a steeper learning curve for contributors not familiar with the build system
• Potentially slower to incorporate upstream changes from the main OpenJDK repository

Code Comparison

temurin-build (build script excerpt):

#!/bin/bash
set -eu
SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
source "$SCRIPT_DIR/sbin/common/constants.sh"

jdk (Java source code excerpt):

public class String implements java.io.Serializable, Comparable<String>, CharSequence {
    /** The value is used for character storage. */
    private final byte[] value;
    /** The identifier of the encoding used to encode the bytes in {@code value}. */
    private final byte coder;
}

Pros of OpenJ9

• Better memory efficiency, especially for cloud and containerized environments
• Faster startup times due to its shared classes cache feature
• Advanced garbage collection algorithms optimized for modern hardware

Cons of OpenJ9

• Smaller community and ecosystem compared to OpenJDK
• Less widespread adoption in enterprise environments
• Potential compatibility issues with some Java applications optimized for HotSpot

Code Comparison

OpenJ9 (JITServer feature):

-XX:+UseJITServer
-XX:JITServerAddress=<server_address>
-XX:JITServerPort=<port_number>

OpenJDK (GraalVM JIT compiler):

-XX:+UnlockExperimentalVMOptions
-XX:+UseJVMCICompiler
-XX:+EnableJVMCI

Both projects aim to improve Java performance, but they take different approaches. OpenJ9 focuses on memory efficiency and startup times, making it suitable for cloud environments. OpenJDK, with its larger community and ecosystem, offers broader compatibility and is more widely adopted in enterprise settings. The code examples showcase unique features of each project: OpenJ9's JITServer for distributed compilation and OpenJDK's integration with GraalVM for advanced JIT compilation.

Pros of GraalVM CE Builds

• Supports multiple programming languages (Java, JavaScript, Python, Ruby, R, etc.)
• Offers ahead-of-time compilation for faster startup and lower memory usage
• Provides native image generation for creating standalone executables

Cons of GraalVM CE Builds

• Smaller community and ecosystem compared to OpenJDK
• May have compatibility issues with some Java libraries and frameworks
• Requires additional configuration for certain Java features (e.g., reflection)

Code Comparison

GraalVM CE Builds (Native Image):

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

OpenJDK:

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

The code itself is identical, but GraalVM allows compilation to a native executable:

native-image HelloWorld
./helloworld

This results in faster startup and lower memory usage compared to running the same code with OpenJDK's Java runtime.

Pros of Dragonwell8

• Optimized for large-scale, mission-critical deployments
• Includes additional features for improved stability and performance
• Tailored for cloud-native and containerized environments

Cons of Dragonwell8

• Limited to Java 8, while JDK supports newer Java versions
• Smaller community and ecosystem compared to OpenJDK
• May have compatibility issues with some standard Java applications

Code Comparison

Dragonwell8:

public class ElasticHeap {
    private static native void enableElasticHeap(boolean enable);
    public static void enable() {
        enableElasticHeap(true);
    }
}

JDK:

public final class System {
    public static void gc() {
        Runtime.getRuntime().gc();
    }
}

The Dragonwell8 example shows a custom elastic heap feature, while the JDK example demonstrates a standard garbage collection method. This illustrates how Dragonwell8 includes additional optimizations for specific use cases, whereas JDK provides more general-purpose functionality.