Over a million developers have joined DZone.

The Spark micro framework

DZone 's Guide to

The Spark micro framework

· Java Zone ·
Free Resource
Web programming is the science of coming up with increasingly complicated ways of concatenating strings. -- Greg Brockman
In the description of its authors, Spark is a Sinatra inspired micro web framework for quickly creating web applications in Java with minimal effort. Indeed, the minimalist sense is conveyed by the project's homepage, which contains an hello world example and links to all the relevant resources.

Jump into a code sample

This is an Hello world web application realized with Spark. Loading http://localhost:4567/hello will display Hello World! (without any HTML code).
import static spark.Spark.*;
import spark.*;

public class SparkExample {
    public static void main(String[] args) {
        get(new Route("/hello") {
            public Object handle(Request request, Response response) {
                return "Hello World!";

Features (or lack thereof)

Spark's API contains few features, but very focused ones.

Request and Response objects provide full control over HTTP headers and functionalities. You can access query and URL parameters; specific headers like Content-Length and Content-Type are provided by a dedicated method, while you can always access any header from the parametric interface. This interface is really equivalent to the Servlet API.

Routes can be provided in a sequential order, each specified for a particular HTTP method (GET or POST usually, but not exclusively) and linking to a callback which will be executed. The callback is the point of conjunction between your application and the HTTP world: separation of concerns is easy to maintain.

Filters are a series of hooks that can be inserted before or after the execution of a request; they can optionally match only certain routes. Filters, which are small objects where a single method should be implemented, are the most coupled mechanism introduced by the Spark framework.

How it works: containers

Spark is a bit different from the classic Java frameworks. It starts itself and configure the application with a main() method, not with the classic inversion of control mechanism where some servlets are deployed into a container.

The advantages of this approach are that it simplifies end-to-end testing, and gives you back the control over the lifecycle of your objects. An hexagonal application uses a few servlets just to wrap its own code, so why bother playing with servlets when you can have your own main?

The disadvantages of the approach are that you won't get ant functionality from the container, which does not exist here; and you won't be able to access the standard Servlet API but only Spark's one (may be a sacrilege).

Actually Spark features Jetty as an embedded container, so the Servlet API is just wrapped by it. You can even run Spark applications in Tomcat or other web servers supporting servlets, and it will integrate like many other frameworks by providing a fixed web.xml. But in my opinion you can just go for Spring in that case.

How it works: configuration

Another pecularity of Spark is that configuration (like routes) are mapped via Java code: there are no XML files, no annotations, and no INIs.

Rather you can use a DSL written in Java, with quite a bit of easy to read static imports (and indeed used at the highest level of abstraction, not inserted in your domain objects.)

This syntax is inspired by Sinatra, a similar DSL for Ruby applications; in interpreted languages is quite common to use the language itself for configuration. After all, this choice forces you to treat configuration that may break the application as code; and when was the last time you changed a route specified in XML without changing any of the Java classes?

Is this a trend?

In general, in my little area of the programming world I'm noticing a softer approach to frameworks, where most of the functionality is provided via libraries instead of as invasive components inserted in the flow of control.

This is also where the PHP world is heading (I know Java developers won't care, but still it's interesting):

If you look around, every single framework seems to implement the MVC pattern. And most of them are advertised as MVC frameworks... but not Symfony2. Have a look at the documentation, and you will see that the MVC pattern is only mentioned once or twice, but Symfony2 is never defined as being an MVC framework. Why? [..] I don't like MVC because that's not how the web works. Symfony2 is an HTTP framework; it is a Request/Response framework. That's the big deal. The fundamental principles of Symfony2 are centered around the HTTP specification. -- Fabien Potencier


The Java platform is not necessarily tied to the mindset of giant enterprise frameworks; see also how beautifully the Play framework manages HTTP actions (although still with configuration over convention).

Moreover, it does not matter in which language you do develop web applications: at least you can embrace HTTP as the lowest common denominator instead of the MVC machine of a framework. You may not need it, and you may also start not to like it anymore.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}