What’s new int Java 18 ?

Java 18 is a technical release and would only have short-term support of 6 months. Next LST release will be Java 21.

JEP 408: Simple Web Server

The command jwebserver enables you to start a HTTP server on specific folder on a specific port (default 8080). You can hava a static website.

    public static void main(String[] args) {
        // Create a simple file server, given the socket address, path and output level
        var server = SimpleFileServer.createFileServer(
                new InetSocketAddress(8000),
                Path.of("your-folder"),
                SimpleFileServer.OutputLevel.VERBOSE);

        // Starting the server
        server.start();

        // A friendly message to get started.
        System.out.println( "We are getting started..." );
        System.out.println("Check http://localhost:8000/index.html");
    }

JEP 413: Code Snippets in Java API Documentation

Java 18 has introduced a @snippet tag to add a code snippet in Java Doc. The snippet tag supports code indentation.

    /**
     * {@snippet :
     *      if (name == "Ahmed") {
     *          return true ;
     *      }
     *      return false ;
     * }
     * @param args arguments
     */
    public static void main(String[] args) {

    }

JEP 400: UTF-8 by Default

Starting Java 18, Java will be setting its default charset as UTF-8. The motivation behind this is to have a consistent result on various platforms, operating systems, locales, and configurations for the APIs that depend on the default charset.

JEP 421: Deprecate Finalization for Removal

The finalize method is removed. This method caused many memory leaks when developers are using native bloc code/file.

Resource leaks can be surprisingly common. Consider the following code that copies data from one file to another. In early versions of Java, developers typically used the try-finally construct to ensure that resources were released even if an exception occurred while copying:

FileInputStream  input  = null;
FileOutputStream output = null;
try {
    input  = new FileInputStream(file1);
    output = new FileOutputStream(file2);
    //... copy bytes from input to output ...
    output.close();  output = null;
    input.close();   input  = null;
} finally {
    if (output != null) output.close();
    if (input  != null) input.close();
}

This code is erroneous: If copying throws an exception, and if the output.close() statement in the finally block throws an exception, then the input stream will be leaked. Handling exceptions from all possible execution paths is laborious and difficult to get right. (The fix here involves a nested try-finally construct, and is left as an exercise for the reader.) Even if an unhandled exception occurs only occasionally, leaked resources can build up over time.

Source : JEP-421s

JEP 416: Reimplement Core Reflection with Method Handles

The JEP 416, hasn’t added or removed any methods, it simply reimplemented it. The reason behind this is that there were various ways it handled the reflection to handle better peak performances. Now when there were any changes on underlying methods, the Java team needed to change a lot of things. With this implementation, the maintainability and the cost of development are reduced.

This change is not something you will notice, or observe in your day-to-day coding. But I just wanted to highlight the fact that when building something you not only have to see if it is working but also how it affects the future maintainability and development cost.