The hyped, happening and happened application frameworks and Java runtime @ bol.com (Part 5)
We asked 25 developers, five tech leads and someone “who does unspeakable things with technology” - more commonly known as our principle tech lead which technologies (tools, libraries, language or frameworks) they believe are hyped, happening or happened:
- hyped - which new technologies are you eager to learn more about this year?
- happening - are there any exciting technologies you used last year that we should learn this year?
- happened - did you walk away from any technologies last year?
This is what we got back:
This blog post, which is part of a series of six blog posts in total, we have a closer look at application frameworks and Java runtime:
Go to The hyped, happening and happened tech @ bol.com for a complete overview of all the hyped, happening and happened tech at bol.com.
Why write tons of boilerplate code, when you can abstract them away and use interfaces? Or waste time choosing libraries and tools when you can automatically use sensible defaults instead? Why instantiate objects and manage dependencies manually, when you can do it using a simple annotation?
There are many frameworks out there that provide these features for us, and a whole lot more! Spring is probably the most popular of these frameworks, so let’s start with that. But don’t stop reading after Spring, because there is more out there.
Being the 6th most loved framework by the developer community Spring does not need much of an introduction, so let’s move on to some popular Spring projects used within bol.com.
Spring was originally introduced, it abstracted away a lot of boilerplate java code. However, Spring itself needed some configuration to be set up initially. This has been taken one step further in Spring boot, where it takes an opinionated view on Spring and sets up sensible defaults out of the box. A few things set up are starter dependencies, embedded web server, metrics, etc.
We at bol.com use an internal framework which utilises spring boot under the hood, making it an even more popular framework within our company.
Spring Cloud is a framework to quickly bootstrap some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, etc). It is a parent project which contains many child projects varying across a wide range of technologies. A popular example is the spring cloud GCP module which supports many cloud services such as Pub/Sub, BigQuery, Cloud SQL, etc out of the box.
Spring cloud also provides security related projects such as the Spring Cloud Security module which provides features related to token-based security in Spring Boot applications.
As an add-on to the Spring framework Spring integration offers lightweight messaging within Spring-based applications. It doesn't stop with messaging within your application, though. It also offers channel based communication for interconnecting your Spring app with other applications.
Spring integration implements many popular design patterns involved around messaging architectures, such as the Publish Subscribe, Bridge and Adapter pattern. This way you can rely on industry standards for building flexible, loosely coupled, interconnected applications and processes.
Even though Spring dominates the industry, there are some new and upcoming alternatives, some of which seem to be very promising. The following two frameworks are worthy to compare with Spring:
In the day and age of docker containers, Java is still widely used. Java has always been (in)famous regarding its performance, due to the abstraction layers between the code and the underlying machine - a price to pay for being able to run across multiple platforms. Nowadays, due to multiple companies adopting microservices, this may not be relevant anymore. The artifact will always run on the same place and platform, i.e. the docker container.
Quarkus is an open-source set of technologies adapted to GraalVM and HotSpot to write Java applications. It offers an extremely fast startup time and a low memory footprint, making it ideal for containers and serverless applications. Quarkus has better memory consumption, garbage collection, and request throughput. However, this framework is still relatively new and does not have extensive documentation or community support like Spring does.
Ktor is a lightweight framework for building asynchronous servers and clients in connected systems using the Kotlin programming language. Similar to Quarkus, Ktor provides very fast startup times (~60% faster than Spring) and low memory usage (~50% less than Spring). Ktor is unopinionated (unlike Spring) and doesn’t impose a lot of constraints on what technology a project should use – such as for logging, templating, messaging, etc. This framework also uses Kotlin coroutines for asynchronous programming where coroutine IO can be used for communicating with other services.
Currently Ktor works with JVM based languages, but it pairs better with Kotlin since Ktor itself is written in Kotlin.
A "simple elegant, high-performance full-stack web framework" is how the authors themselves describe the Lets blade project. Lets blade is more of a collection of lightweight libraries that can be modularly combined depending on your specific needs. Amongst other things it offers:
- A restful style routing mechanism to define a binding between URLs and your application controllers
- A simple way to serve static resources
- An embedded Netty server, so you don't need an application server to run it
- A way to map Json objects to plain old Java objects
- Monitoring for your blade application
- A basic template engine of its own and the possibility to plugin an external engine of your liking, such as Velocity.
You build it, you (need something to) run it, you love it. This section focuses on the middle part - the Java runtime for running your application written in your favourite JVM language.
Not all our applications run in the cloud (yet). For the ones that don’t we also don’t get to pick a JVM for running them on. So, when we migrated to OpenJDK 11, we still got a bit excited.
It was not because of the fact that it opened the way to migrate to Java 11. Don’t get us wrong, because this new long term support Java version brings us many nice new features, such as:
- handy utility methods for strings, files and arrays,
- an enhanced syntax for lambda parameters which enables them to be annotated with, for example @NonNull annotations, and
- a better performing http client.
What really enthused us, is the two new garbage collectors this release brings. OpenJDK11 ships with the Epsilon garbage collector and the Z garbage collector. The Z collector is still in its experimental phase. It works radically differently from other more traditional garbage collectors. It aims to pause no longer than 10ms even on incredibly large heaps. Sounds good, right?
It even gets better, because the Epsilon garbage collector guarantees no pauses at all. Ok, that is a bit unfair, because it also does not collect any unused objects. This means that your heap will only grow as you allocate more objects over time. The Epsilon garbage collector is therefore only useful in specific scenarios. Think of taking the GC pauses out of the equation while benchmarking. Or using it for (short) run batch applications that finish before the heap fills up.
GraalVM has recently been taking the technology world by a storm, and for a good reason. It is a high-performance runtime that provides significant improvements in application performance and efficiency. “This makes your Java programs run much faster without any code changes!”
It has the following key strengths:
- Just-in-time (JIT) compiler - A traditional compiler compiles all code to a machine language before it executes the program. A JIT compiler however, runs after a program starts and compiles code. The compiled code, or bytecode sequences, are turned into a faster, more readable machine language, or native code. It translates source code to a language that a host CPU natively understands which results in a faster and more efficient instruction set.
- Ahead-Of-Time (AOT) compiler - GraalVM also supports an AOT compiler which translates JVM code into a native platform executable. These artifacts start instantaneously, are smaller in size, and consume less resources, making them ideal for the cloud and microservices architecture.
Want to read more about hyped, happening and happened tech at bol.com? Read all about The hyped, happening and happened cloud technologies and data storage solutions @ bol.com or go back to The hyped, happening and happened tech @ bol.com for a complete overview of all the hyped, happening and happened tech at bol.com.