Is it okay to use com.sun.net.httpserver.HttpServer?
Tags: java
Published: 2022-11-12 15:29:50

---
title: Is it okay to use com.sun.net.httpserver.HttpServer?
published: true
description: Java ships with a HTTP Server since Java 6. But is it okay to use from package com.sun?
tags: Java
# cover_image: https://direct_url_to_image.jpg
# Use a ratio of 100:42 for best results.
# published_at: 2022-11-12 14:24 +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](https://spring.io/projects/spring-boot), [Quarkus](https://quarkus.io/) or [Micronaunt](https://micronaut.io/). 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](https://docs.oracle.com/en/java/javase/17/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpServer.html) readily available. It's pretty much low level but apart from that straightforward to use:

```java
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](https://www.oracle.com/java/technologies/faq-sun-packages.html). 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](https://openjdk.org/jeps/403) 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,
> * <mark>The HTTP Server API in the `jdk.httpserver` module</mark>,
> * 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](https://sonarsource.github.io/rspec/#/rspec/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](https://sonarsource.atlassian.net/browse/SONARJAVA-4382) (S1191 should not raise issues on imports from `com.sun.*` packages).