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 thejdk.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).
Top comments (0)