Javalin 2.0 is here: This lightweight web framework for Kotlin and Java developers just got better
Javalin, a very lightweight web framework for Kotlin and Java, has just reached a very important milestone: 2.0.0 stable is out. This release brings a lot of improvements and major changes. Let’s have a look!
We first laid eyes on Javalin last year, when it reached v1.0.0 stable. The first Javalin version was released in May 2017 so they are moving pretty fast!
This very lightweight web framework for Kotlin and Java was inspired by Sparkjava and koa.js, according to the blog post announcing the 1.0 release. Javalin is written in Kotlin “with a few functional interfaces written in Java. This was necessary to provide an enjoyable and near identical experience for both Kotlin and Java developers.”
All of these web frameworks are inspired by the modern micro web framework grandfather: Sinatra, so if you’re coming from Ruby then Javalin shouldn’t feel too unfamiliar.
If you want to read more about its features or see how it works, read this article.
Javalin 2.0
A lot has changed since Javalin 1.7; First, you should know that most of the changes are internal, according to the blog post announcing the new version. Second, “some abstraction layers have been removed and the WebSocket implementation and the test-suite have been completely rewritten.”
- They’ve added ETag support and a method for auto-generating ETags
- They’ve added a RequestLogger interface (
{ ctx, executionTime -> ...}) - They’ve added the option to return 405 instead of 404, listing available methods for the path
- They’ve added a set of default responses, so you can
throw BadRequestResponse()(optional message) - They’ve added a
CrudHandlerto remove some boilerplate from creating standard CRUD APIs - They’ve added support for WebJars (https://www.webjars.org)
- They’ve improved support for Single Page Applications
- They’ve improved exception handling for async requests
- All JSON and Template functionality has been modularized so you can easily plug in your own mappers/rendering engines.
- All Template functionality has been moved into a single
ctx.render()function which uses the correct engine based on the file extension - All requests run through an AccessManager now (the default implementation is NOOP)
- URL matching is now case-insensitive by default (call
app.enableCaseSensitiveUrls()if you must) - Javalin now has a pac4j implementation
- Some default values have been changed
But that’s not all. The list of quality of life improvements is pretty impressive and includes the following: functions returning List instead of Array, returning empty collections instead of null, better default values and package structure, fixing visibility from Java, etc.
If you’d like to migrate from Javalin 1.x to 2.0, you’ll need this guide.
Last but not least, if you want to contribute to the project, head on over to GitHub.
Beyond Continuous Delivery: Learn, adapt, improve
Michiel Rook
Containers on AWS: What to use and when?
Philipp Garbe
asap
