Is it okay to use com.sun.net.httpserver.HttpServer?

Thomas Küstermann — Sat, 12 Nov 2022 15:29:50 +0000

I've been recently working on a simple CRUD microservice implemented in Java. You may immediately think of using frameworks such as Spring Boot, Quarkus or Micronaunt. However, no frameworks were allowed, and libraries were only permitted, if the functionality provided is not natively available or too complex to build. Long story short, I had to find a HTTP server implementation.

After searching around a bit, I eventually found com.sun.net.httpserver.HttpServer readily available. It's pretty much low level but apart from that straightforward to use:

public class HelloWorldServer {
    public static void main(String[] args) throws IOException {
        String payload = "It works!";
        HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);
        server.createContext("/", exchange -> {
            byte[] body = payload.getBytes(StandardCharsets.UTF_8);

            Headers responseHeaders = exchange.getResponseHeaders();
            responseHeaders.add("Content-Type", "text/plain; charset=UTF-8");

            exchange.sendResponseHeaders(200, body.length);

            OutputStream responseBodyStream = exchange.getResponseBody();
            responseBodyStream.write(body);
            responseBodyStream.flush();
            responseBodyStream.close();
        });

        server.start();
    }
}

But wait a sec, it's from package com.sun and we were told it's not correct to use it, right? You may remember Why Developers Should Not Write Programs That Call 'sun' Packages. On the other hand, it talks about sun packages and not com.sun - confusing!

So, is it actually safe to use com.sun.net.httpserver.HttpServer? Luckily, it is, and the answer is finally given in JEP 403: Strongly Encapsulate JDK Internals targeting Java 17.

Exported com.sun APIs

Most com.sun.* packages in the JDK are for internal use, but a few are supported for external use. These supported packages were exported in JDK 9 and will continue to be exported, so you can continue to program against their public APIs. They will, however, no longer be open. Examples include

The Compiler Tree API in the jdk.compiler module,

The HTTP Server API in the jdk.httpserver module,

The SCTP API in the jdk.sctp module, and

JDK-specific extensions to the NIO API in the com.sun.nio.file package of the jdk.unsupported module.

SonarLint and java:S1191

SonarLint (and SonarQube) issuea a major code smell warning when code from package com.sun is used (java:S1191):

Classes from "sun.*" packages should not be used

Classes in the sun.* packages are considered implementation details, and are not part of the Java API.

They can cause problems when moving to new versions of Java because there is no backwards compatibility guarantee. Similarly, they can cause problems when moving to a different Java vendor, such as OpenJDK.

Luckily, a ticket has been filed to relax this rule: SONARJAVA-4382 (S1191 should not raise issues on imports from com.sun.* packages).

Downloading Files With Groovy and Authentication

Thomas Küstermann — Fri, 30 Aug 2019 12:38:49 +0000

Downloading a file from a URL requiring user authentication with Groovy is as easy as:

java.net.Authenticator.setDefault (new Authenticator() {
    protected PasswordAuthentication getPasswordAuthentication() {
        return new PasswordAuthentication(username, password.toCharArray());
    }
});

destinationFile.withOutputStream { it << new URL(downloadUrl).newInputStream() }

Links

Stackoverflow: groovy - Download file with authentication
Stackoverflow: Connecting to remote URL which requires authentication using Java

DEV Community: Thomas Küstermann

Is it okay to use com.sun.net.httpserver.HttpServer?

SonarLint and java:S1191

Downloading Files With Groovy and Authentication