Vanilla Java in 2024: What It Means in the Modern Development Landscape
Is Vanilla Java still about simplicity, or has the definition evolved with enterprise development?
This question comes to my mind when I started working in a small java program* that could show some metrics using Micrometer. Micrometer provides a set of binders that extract meaningful metrics from your JVM and push them to a vast variety of monitoring systems such as Prometheus, Datadog, Elastic and so on.
This is quite simple to do. Micrometer documentation has tons of examples to integrate it with the major Java Frameworks (Spring boot and Quarkus). However, my goal was to do that with plain Java.
Java program* - I love to call my applications, programs. It sounds more classic, even a bit nostalgic, and somehow more grounded and real—not overly polished or trendy. Nowadays everything is called API, Service or an Application. To be honest, it sounds boring. So I would like to invite everyone the readers to start using program. Make Program Great Again?
Note: This image isn’t AI-generated. It was uncovered via an ancient search engine called Google, by typing 'Vanilla Java Beans.'. Ah! By clicking in the image, you will be taken to the owner store, but I don’t really know them, I just used their image.
How can I implement an HTTP server using only Java's standard libraries, without relying on frameworks?
This is something that your learn in your University degree. I learnt it and then jumped to a framework. At the time, I learned Apache Struts2. A structured MVC web framework, interesting but quite old fashioned because it renders all the web pages in the server-side.
Anyways, returning to my University degree, I had the basic course of Java Standard Edition where I learned the language syntax, the Object Oriented Programming principles, Sockets (explained in detailed during the networking course) and so on.
Later on, I had another course about Java Enterprise Edition and it was introduced the client-server architecture, the application platform, the MVC pattern, JPA, Hibernate and a few other things that I dont rekon.
As I said, before learning Struts2 framework, I learned Servlets and how they could be used inside a container like Tomcat or server by HttpServer. In this program implementation, I decided to no use Tomcat. It would be easier to use the embedded but it would require more dependencies and my goal is to keep it as much Vanilla as possible!
After searching and talking with chatGPT, I found out the HttpServer was provided by jdk.httpserver. According to the Java Docs, a HttpServer has a set of HttpHandlers (and their respective context).
This class implements a simple HTTP server. A HttpServer is bound to an IP address and port number and listens for incoming TCP connections from clients on this address. (…)
One or more HttpHandler objects must be associated with a server in order to process requests. (…)
Any request for which no handler can be found is rejected with a 404 response.
With these two classes, HttpServer and HttpHandler, I create MyHttpServer class. It exposes a mock endpoint called orders and it handles the request by returning a 200 status code and a response body saying Order created.
public class MyHttpServer {
public static void main(String[] args) throws Exception {
HttpServer server = HttpServer.create(new InetSocketAddress(8081), 0);
init();
server.createContext("/orders", new HttpHandler() {
@Override
public void handle(HttpExchange exchange) throws IOException {
String response = "Order created";
exchange.sendResponseHeaders(200, response.length());
OutputStream os = exchange.getResponseBody();
os.write(response.getBytes());
os.close();
}
});
// Start the server
server.start();
System.out.println("Server started on http://localhost:8081/orders");
}
}
Integrating Micrometer with this HttpServer was very easy. It only requires the micrometer-registry-prometheus dependency which can bind a set of metrics from the Micrometer core and convert them to prometheus format.
Check out vanilla-java-metrics on my Github.
This can be called a web server made from Vanilla Java, correct? But this thought lead me to another question. In the enterprise software development world, nobody uses Java SE, they use at least Java Enterprise Edition.
Could Java EE be considered the modern equivalent of 'Vanilla Java'?
Nowadays, Enterprises rely on frameworks such as Spring boot and Quarkus because the set of features, integrations, support and community they have. It seems that Java Enterprise Edition is no longer used but in fact is the standard library for building enterprise-grade programs. There are loads of libraries and frameworks that rely on interfaces like JMS, JPA, EJB, CDI and so on. If we weight this argument well, could Java EE and its components be considered as part of what defines 'Vanilla Java' in the modern enterprise context?