How do I collect stream results into an immutable collection?

In Java, you can use the Stream API’s Collectors to gather stream results into an immutable collection. Since Java 10, you can use Collectors.toUnmodifiableList(), Collectors.toUnmodifiableSet(), and other similar methods to collect the results into unmodifiable collections.

Here’s how you can collect the stream results into an immutable collection:

1. Immutable List

To collect the results of a stream into an immutable list:

package org.kodejava.util.stream;

import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.Stream;

public class ImmutableCollectionExample {
    public static void main(String[] args) {
        List<String> immutableList = Stream.of("apple", "banana", "cherry")
                .collect(Collectors.toUnmodifiableList());

        System.out.println(immutableList);

        // Attempting to modify the list will throw UnsupportedOperationException
        // immutableList.add("date"); // Throws UnsupportedOperationException
    }
}

2. Immutable Set

To collect the results into an immutable set:

package org.kodejava.util.stream;

import java.util.Set;
import java.util.stream.Collectors;
import java.util.stream.Stream;

public class ImmutableCollectionExample {
    public static void main(String[] args) {
        Set<String> immutableSet = Stream.of("apple", "banana", "cherry")
                .collect(Collectors.toUnmodifiableSet());

        System.out.println(immutableSet);

        // Attempting to modify the set will throw UnsupportedOperationException
        // immutableSet.add("date"); // Throws UnsupportedOperationException
    }
}

3. Immutable Map

To collect results into an immutable map:

package org.kodejava.util.stream;

import java.util.Map;
import java.util.stream.Collectors;
import java.util.stream.Stream;

public class ImmutableCollectionExample {
    public static void main(String[] args) {
        Map<String, Integer> immutableMap = Stream.of("apple", "banana", "cherry")
                .collect(Collectors.toUnmodifiableMap(
                        fruit -> fruit,         // Key mapper: the fruit itself
                        fruit -> fruit.length() // Value mapper: the length of the fruit name
                ));

        System.out.println(immutableMap);

        // Attempting to modify the map will throw UnsupportedOperationException
        // immutableMap.put("date", 4); // Throws UnsupportedOperationException
    }
}

Notes:

  • Unmodifiable vs Immutable: Collections created with Collectors.toUnmodifiableList(), Collectors.toUnmodifiableSet(), and Collectors.toUnmodifiableMap() are unmodifiable. While they cannot be changed (add, remove, replace), immutability might imply further guarantees (e.g., deeply immutable objects inside the collection, which this does not enforce).
  • Introduced in Java 10: toUnmodifiableList(), toUnmodifiableSet(), and toUnmodifiableMap() were introduced in Java 10. If you’re using Java 8 or Java 9, you’ll need a custom approach for creating immutable collections (like Collections.unmodifiableList).

In Java 8:

If you’re stuck on Java 8, you can achieve something similar using Collections.unmodifiableList() or other Collections.unmodifiableXxx methods:

package org.kodejava.util.stream;

import java.util.Collections;
import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.Stream;

public class ImmutableCollectionExample {
    public static void main(String[] args) {
        List<String> immutableList = Collections.unmodifiableList(
                Stream.of("apple", "banana", "cherry").collect(Collectors.toList())
        );

        System.out.println(immutableList);
        // immutableList.add("date"); // Throws UnsupportedOperationException
    }
}

This approach, however, wraps an existing modifiable collection, so try to update your project to take advantage of Java 10+ features.

How do I use Map.copyOf() for Immutable Maps?

In Java, the Map.copyOf() method, introduced in Java 10, is a factory method used to create an unmodifiable (immutable) copy of a given Map. This method ensures that the resulting Map cannot be modified, and attempting to do so throws an UnsupportedOperationException.

Here’s how to use it effectively:

Syntax:

public static <K,V> Map<K,V> copyOf(Map<? extends K,? extends V> map)
  • Parameters: A single map (Map<? extends K, ? extends V> to copy).
  • Returns: An unmodifiable copy of the given map.
  • Throws:
    • NullPointerException if the provided map or any of its keys/values is null (this method does not allow null as keys or values).
    • IllegalArgumentException if there are duplicate keys in the map.

Examples

1. Creating an Immutable Map from an Existing Map

package org.kodejava.util;

import java.util.Map;

public class MapCopyOfExample {
    public static void main(String[] args) {
        // Original mutable map
        Map<Integer, String> originalMap = Map.of(1, "One", 2, "Two", 3, "Three");

        // Creating an immutable copy
        Map<Integer, String> immutableMap = Map.copyOf(originalMap);

        // Attempting to modify will throw UnsupportedOperationException
        System.out.println(immutableMap); // Output: {1=One, 2=Two, 3=Three}

        // Uncommenting the following line will throw an error
        // immutableMap.put(4, "Four");
    }
}

2. Avoiding Redundant Copies

Map.copyOf() avoids redundant copying. If the input Map is already unmodifiable (e.g., created using Map.copyOf() or Map.of()), it simply returns the same instance.

Map<String, String> immutableMap1 = Map.of("Key1", "Value1", "Key2", "Value2");

// Reusing the immutable instance
Map<String, String> immutableMap2 = Map.copyOf(immutableMap1);

System.out.println(immutableMap1 == immutableMap2); // Output: true

3. Copying a Mutable Map

A mutable map can be made immutable using Map.copyOf().

package org.kodejava.util;

import java.util.HashMap;
import java.util.Map;

public class MutableToImmutable {
    public static void main(String[] args) {
        // Create a mutable map
        Map<String, String> mutableMap = new HashMap<>();
        mutableMap.put("A", "Apple");
        mutableMap.put("B", "Banana");

        // Make an immutable copy
        Map<String, String> immutableMap = Map.copyOf(mutableMap);

        // Attempting to modify the copy throws an exception
        System.out.println(immutableMap); // Output: {A=Apple, B=Banana}

        // mutableMap.put("C", "Cherry"); // Allowed for mutableMap
        // immutableMap.put("C", "Cherry"); // Throws UnsupportedOperationException
    }
}

Notes about Map.copyOf()

  1. Null Values/Keys:
    • Both keys and values must be non-null; otherwise, a NullPointerException will be thrown.
  2. Immutable Nature:
    • The map returned is truly immutable. Not only are modifications disallowed, but if the input map is mutable, changes to the input do not affect the immutable map.
  3. Alternative Methods:
    • Map.of() can also be used to create immutable maps directly, but it requires you to specify the entries upfront.

Key Differences: Map.copyOf() vs Map.of()

Feature Map.copyOf() Map.of()
Input Accepts an existing map Accepts individual key-value pairs
Suitability for Copy Used to copy an existing map Used to create new map
Duplicates Rejects duplicates in the source map Doesn’t allow duplicates
Empty Map Works with an empty map Use Map.of() for emptiness

Summary

The Map.copyOf() method is a lightweight way to create immutable maps, especially from existing maps. It’s perfect for ensuring immutability and avoiding unintentional modifications to data structures. Use it where immutability is key, such as shared configurations, constants, or thread-safe data sharing!

How to leverage Java 10’s Thread-Local Handshakes for performance tuning

Java 10 introduced Thread-Local Handshakes as a powerful feature in the JVM, designed to improve the performance and responsiveness of applications, especially in scenarios involving thread-based operations and garbage collection.

Here’s what you need to know about Thread-Local Handshakes and how to leverage them for performance tuning:


1. What are Thread-Local Handshakes?

Thread-Local Handshakes allow a thread to execute a callback function locally without stopping all threads. This contrasts with traditional global safepoints in Java, where all threads must come to a safe state before any work can be done, such as garbage collection or code deoptimization.

In other words:

  • A handshake is a mechanism to perform operations on a subset of threads (or even individual threads) without stopping the entire JVM.
  • This is useful for operations that don’t require a global JVM safepoint, improving responsiveness and reducing latency.

2. Benefits of Thread-Local Handshakes

  • Avoids Global Safepoints: Operations can target some threads or a single thread, meaning other threads continue their work unaffected.
  • Reduces Latency: No need to pause all threads, improving performance for multithreaded applications.
  • Fine-Grained Control: Perform thread-specific tasks like flushing thread-specific memory buffers, deoptimizing code for just one thread, or collecting specific thread-local objects without interrupting the entire JVM.

3. Use Cases

Here are some scenarios where Thread-Local Handshakes can be beneficial:

  • Garbage Collection
    Garbage collectors rely on safepoints to pause threads while managing memory. Thread-Local Handshakes can isolate such operations to only the threads that need it, reducing pause times and improving application throughput.

  • Code Deoptimization
    This happens during just-in-time (JIT) compilation when compiled code needs to revert to interpreted mode. Utilizing handshakes allows deoptimization to occur on specific threads, minimizing the impact on other threads.

  • Thread-Specific Profiling and Debugging
    A developer or monitoring agent can perform profiling or diagnostic tasks on a single thread without disturbing other threads.

  • Thread-Specific Resource Cleanup
    Thread-local data structures can be cleaned up or flushed for specific threads, optimally managing system resources.


4. How Thread-Local Handshakes Work Internally

Thread-Local Handshakes introduce thread-specific “safepoints.” When a request is initiated:

  1. The JVM signals specific threads to execute a callback function (like releasing resources or processing pending tasks).
  2. Unlike global safepoints, only the targeted thread(s) pause and execute the operation.
  3. Once the operation is complete, the thread resumes execution.

This makes operations more granular and non-blocking at the JVM level.


5. Leveraging Thread-Local Handshakes in Performance Tuning

Although Thread-Local Handshakes are implemented at the JVM level, you can indirectly leverage them for performance tuning in the following ways:

  1. Tuning for Garbage Collection
    If you’re using a garbage collector like G1GC or ZGC, you can reduce garbage collection pauses since these collectors take advantage of handshakes to avoid halting all threads during certain operations.

    • How to Monitor: Use tools like Java Mission Control (JMC), VisualVM, or JVM logging to monitor GC pause times and ensure thread-local synchronization is being effectively utilized.

    Relevant JVM Options:

    • -XX:+UseG1GC (or any GC of choice) to enable advanced garbage collection strategies.
    • Use -Xlog:gc to monitor GC logs and observe pauses.
  2. Reducing Latency in Thread-Sensitive Applications
    If your application uses many threads (e.g., for handling requests or background tasks), Thread-Local Handshakes reduce overall latency by targeting specific threads instead of pausing all threads unnecessarily.

    Best practices:

    • Profile your application for thread contention and safepoints using tools like Async Profiler or JFR (Java Flight Recorder).
    • Optimize thread management through thread pools (using ForkJoinPool, ThreadPoolExecutor, etc.) to prevent thread starvation and maximize throughput.
  3. Tuning Thread-Specific Tasks
    For tasks that manipulate thread-local data or thread-specific settings:

    • Optimize performance by ensuring the work is allocated to specific threads that need operations (e.g., specific callbacks).
    • Reduce contention by designing operations that leverage locality (thread-local memory, caches, etc.).

6. Practical Tips for Developers

While Thread-Local Handshakes are managed by the JVM, the following tips help you align your code and architecture to take full advantage:

  1. Choose Modern JVMs: Use JDK 10 or later for applications where fine-grained thread optimization matters. Newer garbage collectors like ZGC or Shenandoah optimize handshakes even further.

  2. Monitor Safepoints and Utilization:

    • Safepoint statistics can be enabled using -XX:+PrintSafepointStatistics to understand how your threads interact with JVM-managed resources.
    • Use tools like JFR to detect safepoint delays or thread-local handshake activity.
  3. Minimize Global Syncs in Application Code:
    • Avoid global thread synchronization where possible.
    • Use thread-local structures (e.g., ThreadLocal API) for thread-scoped data.
  4. Benchmark Your Application:
    Profile how your code interacts with the JVM and threads. Use tools like JMH (Java Microbenchmark Harness) for thread and synchronization benchmarking.


7. Example: Monitoring Thread Safepoints

java -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+LogVMOutput -XX:LogFile=safepoints.log -jar YourApp.jar

This will output safepoint-related logs, showing where Thread-Local Handshakes may improve performance by reducing pauses.


8. Conclusion

Thread-Local Handshakes represent an evolutionary step in how the JVM manages thread interactions, replacing costly global operations with thread-targeted approaches. While you may not directly invoke or control handshakes, you can optimize your application and JVM configuration to reap their benefits:

  • Select JVM options and garbage collection strategies that leverage handshakes.
  • Profile and diagnose thread safepoints to find opportunities for performance tuning.

These adjustments ensure better efficiency, reduced latency, and improved performance in multithreaded applications.

How to Use Container-Aware JVM Features in Java 10 for Docker

Java 10 introduced new container-aware JVM features that greatly improve how Java applications run in Docker environments. These features provide enhanced automatic detection and utilization of container-based limits for memory and CPU resources, allowing Java applications to respect the constraints of containers better.

Here’s a step-by-step guide to using the container-aware JVM features in Java 10 for Docker:


1. Understand the Features

Before Java 10, the JVM didn’t recognize container resource limits (like those set by Docker). With Java 10, the JVM can now:

  • Detect container memory limits (e.g., --memory or -m in Docker).
  • Detect container CPU limits (e.g., --cpus in Docker).
  • Adjust garbage collection (GC) behavior based on allocated container resources.

2. Key JVM Options

Java 10 enables container awareness by default, but you can check and fine-tune these settings using certain JVM options:

  • -XX:MaxRAMPercentage
    Allows you to define the maximum available heap memory as a percentage of the container’s total memory limit (default: 25%).

  • -XX:InitialRAMPercentage
    Sets the initial heap size as a percentage of the container’s memory limit.

  • -XX:MinRAMPercentage
    Specifies the minimum heap size as a percentage of the container’s memory.

  • -XX:ActiveProcessorCount
    Lets you manually define the number of CPUs the JVM should consider if it doesn’t automatically detect container limits or you want to override them.


3. Check Container-Aware JVM Behavior

You can check if the JVM recognizes the container limits by running a simple Java program inside a Docker container. Below is an example:

Java Code:

public class ContainerAwarenessTest {
    public static void main(String[] args) {
        System.out.println("Available processors: " + Runtime.getRuntime().availableProcessors());
        System.out.println("Max memory: " + Runtime.getRuntime().maxMemory() / 1024 / 1024 + " MB");
    }
}

4. Test in Docker

  1. Write a Dockerfile
    Create a Dockerfile using a Java 10 JDK image for testing:

    FROM openjdk:10-jdk
    COPY ContainerAwarenessTest.java /usr/src/myapp/
    WORKDIR /usr/src/myapp
    RUN javac ContainerAwarenessTest.java
    CMD ["java", "ContainerAwarenessTest"]
    
  2. Build and Run the Docker Container
    • Build the Docker image:
    docker build -t java-container-awareness .
    
    • Run the container with memory and CPU limits:
    docker run --memory="512m" --cpus="1" java-container-awareness
    
  3. Expected Output
    • The Runtime.getRuntime().maxMemory() will show 512 MB or close to it.
    • The Runtime.getRuntime().availableProcessors() will report 1 processor.

5. Fine-Tune with JVM Options

To customize the JVM’s behavior further using Java 10’s new options, add the JVM options with the java command. For example:

docker run --memory="1g" --cpus="2" java-container-awareness java \
 -XX:MaxRAMPercentage=50.0 \
 -XX:InitialRAMPercentage=25.0 \
 -XX:ActiveProcessorCount=1 \
 ContainerAwarenessTest

This manually adjusts:

  • The maximum heap to 50% of the container memory limit (1 GB).
  • The initial heap to 25% of the container memory limit.
  • The active processor count to override to only 1.

6. Verify

For detailed resource information, you can also enable verbose GC logging to monitor heap and memory usage in real-time:

docker run --memory="512m" --cpus="1" java-container-awareness java \
 -Xlog:gc \
 ContainerAwarenessTest

7. Move Beyond Java 10 [Optional]

If you’re using newer Java versions (like Java 11 or later), these container-aware features are still present, and additional enhancements have been made to how Java applications behave in containers. Make sure your base image and application are updated as needed.


By using these container-aware JVM features, your Java applications will better respect container resource constraints, leading to improved efficiency and performance in Dockerized environments.

How to Work with the Root Certificates Included in Java 10

In Java 10, root certificates are included as part of the cacerts file in the Java Runtime Environment (JRE) to establish trust for security protocols like TLS/SSL. Java includes a default set of trusted Certificate Authorities (CAs) in this file. Here’s how you can work with the root certificates in Java 10:


Accessing the Root Certificates

Root certificates in Java 10 are found in the cacerts file, which is located in the lib/security directory in your JRE or JDK installation:

  • Path for JDK: <JAVA_HOME>/lib/security/cacerts
  • Path for JRE: <JAVA_HOME>/jre/lib/security/cacerts (if the setup includes a separate JRE)

Managing Root Certificates Using the keytool Utility

Java provides the keytool command-line utility to manage keystores such as cacerts. You can use it to list, add, or remove root certificates. Here’s how:

1. List Certificates

To view the existing certificates in the cacerts keystore, use the following command:

keytool -list -keystore <JAVA_HOME>/lib/security/cacerts

By default, the password for the cacerts keystore is changeit.

2. Import a New Root Certificate

If you have a custom root certificate (e.g., mycert.crt) that needs to be trusted by Java, import it as follows:

keytool -import -trustcacerts -file mycert.crt -keystore <JAVA_HOME>/lib/security/cacerts -alias myalias
  • Replace mycert.crt with the file path of your certificate.
  • Replace myalias with a unique alias for the certificate.
  • Note: If no password change has been applied, the default password is changeit.

3. Remove a Certificate

If you need to remove a root certificate from the cacerts keystore:

keytool -delete -alias myalias -keystore <JAVA_HOME>/lib/security/cacerts

Replace myalias with the alias of the certificate you want to remove.

4. Change Keystore Password

To change the default password (changeit) for the keystore:

keytool -storepasswd -keystore <JAVA_HOME>/lib/security/cacerts

Exporting Certificates

To export a certificate from the keystore:

keytool -export -alias myalias -file mycert.crt -keystore <JAVA_HOME>/lib/security/cacerts

Troubleshooting and Tips

  1. Backup Before Modifying: Always create a backup of the cacerts file before making changes. If something goes wrong, you can restore the original file.
    cp <JAVA_HOME>/lib/security/cacerts <JAVA_HOME>/lib/security/cacerts.bak
    
  2. Certificate Format: Ensure that the certificates you are working with are in the correct format. Java usually requires certificates in PEM or DER format.

  3. Java Home Environment Variable: Ensure the JAVA_HOME environment variable is set correctly to point to your Java 10 installation.

  4. Truststore for Applications: Applications that need a specific set of certificates can use a custom keystore/truststore by specifying the following JVM arguments:

    -Djavax.net.ssl.trustStore=/path/to/custom/truststore
       -Djavax.net.ssl.trustStorePassword=yourpassword
    

Switching to a Custom Truststore

If you prefer to use a custom truststore instead of altering the cacerts file:

  1. Create a new keystore file:
    keytool -genkey -alias myalias -keyalg RSA -keystore mytruststore.jks
    
  2. Add certificates to this custom truststore using the steps outlined above.

  3. Point the application or JVM to your custom truststore using the -Djavax.net.ssl.trustStore parameter.

Conclusion

Working with the root certificates in Java 10 provides more control over establishing trust with certificate authorities. Tools like keytool simplify this management process, whether you’re adding, removing, or listing certificates in the cacerts keystore. Always follow security best practices when modifying trust settings, and ensure critical backups are in place.