This Month in Spring - May 2021

May 28, 2021 Josh Long

Hi, Spring fans! Welcome to another installment of This Month in Spring! How are you doing? I hope you've had a wonderful week since we last spoke. I've had a ton of fun! Springtime is officially here in the northern hemisphere. Heck, it's almost summer. The 3rd of May marked the 20th anniversary of the JdbcTemplate, which I think is super cool! Happy birthday, JdbcTemplate! The JdbcTemplate was important to a lot of people because it's one of those great little utilities that made it easy to justify pulling Spring into applications almost two decades ago. It also helped people learn a lot about some of the design patterns that Spring was trying to make commonplace.

And as time marches on, we celebrate Java's 26th birthday! I can't believe it! I'll be on a livestream with the Java team's Billy Korando on Saturday, the 29th of May, talking about Spring, Java, and so much more. Join us! We're going to be talking about this, that, and the rest. You know, the usual stuff. There's a ton of stuff to talk about, too.

Did you see the new* Spring Boot 2.5* release? It's packed with useful features, among which one of my favorites is the new sanitized database initialization. Previously, you could put a file, src/main/resources/schema.sql and src/main/resources/data.sql, and Spring Boot would pick it up and initialize your JDBC javax.sql.DataSource. Neat! But what about R2DBC and its reactive ConnectionFactory instances? No dice. How did the schema.sql and data.sql interact with Hibernate's automatically created DDL? I only needed to use this feature ever so often so it was always surprising to me which way it would go. Thankfully, all of that is much simpler (data.sql and schema.sql are evaluated before Hibernate kicks in, though you can defer it to after), and R2DBC ConnectionFactory instances are supported now too.

Hot on the tail of Spring Boot 2.5 is the new Spring Native 0.10.0 release which has a ton of neat features.

The core conceit of the GraalVM native image builder is to statically analyze your code and strip away everything that the native image builder can't be sure is used at runtime. It strips away all the extra types on the classpath, all the extra types in the JRE, etc. It keeps only what it can be sure you're using. This is a problem, of course, because Java applications are dynamic. Java has a runtime that lets them dynamically register and unregister types, and synthesize types anew from whole cloth. You can dynamically synthesize a new class for the classloader, and then load that class from the classloader using Class.forName(String), etc. You can then serialize that class to a stream of bytes. You might create JDK proxies out of the resulting type if its an interface. GraalVM lets us have our cake and eat it too: we can provide it configuration to tell it to retain the classes it might not otherwise retain, allowing our applications to retain their dynamic quality. Spring Native knows about, and automatically provides this required GraalVM configuration for, typical Spring Boot applications.

So far, Spring Native has worked very well for a ton of use-cases. Spring Native offers a programmatic way to register the configuration that GraalVM expects for JNI, serialization, reflection, and JDK proxies. The trouble is that Spring applications can use both JDK proxies, which are limited to interfaces, and class-targeting proxies, that synthesize a new class by dynamically subclassing a type at runtime. GraalVM didn't know what to do with these Spring- and framework-specific class-targeting proxies, and so things like AOP, Spring Security's @PreAuthorize on a class that didn't implement any interfaces, etc., just didn't work. Until now.

I love Spring Native. It's gotten to the point where I sometimes spend time, for no reason at all, working on building Spring Native integrations for other projects; it really makes some third-party abstractions come alive! It's hard to know what the right comparison is. There's not much you can do in this life that results in such an instantaneous, night-and-day difference in performance and memory profile with so few (user-visible) changes. Imagine snapping your fingers and having your luxury hypercar (Spring Boot in this metaphor) transform into an equally capable, and very comfortable, rocket ship capable of interstellar travel. That's the sort of paradigm shift implied by Spring Native. Or, at least it feels like that to me! What a wonderful time to be alive.

Anyway, we've got a ton of stuff to get to - this last month was jam-packed with fun stuff, so let's dive right into it!

About the Author

Josh Long (@starbuxman) is a Spring Developer Advocate at VMware. Josh is a Java Champion, a Google Developer Expert for Kotlin, author of six books (including O'Reilly's "Cloud Native Java: Designing Resilient Systems with Spring Boot, Spring Cloud, and Cloud Foundry") and the just released "Reactive Spring" (ReactiveSpring.io), six best-selling Livelessons video trainings (including "Building Microservices with Spring Boot Livelessons" with Phil Webb and "Spring Security Livelessons" with Rob Winch, and "Cloud Foundry Livelessons" with Josh McKenty), and an open-source contributor (Spring Boot, Spring Integration, Spring Cloud, Activiti and Vaadin). Josh also has a podcast, "A Bootiful Podcast," and does a series of screencasts, "Spring Tips", on YouTube (bit.ly/spring-tips-playlist). Josh routinely blogs on the Spring blog (spring.io/blog)

Follow on Twitter Visit Website More Content by Josh Long
Previous
The Abstracted Mesh: Dealing with Application Complexity
The Abstracted Mesh: Dealing with Application Complexity

Service meshes can both simplify the development of more capable applications and abstract away some of the...

Next
The Truth About Kubernetes: the Benefits & Challenges
The Truth About Kubernetes: the Benefits & Challenges

Kubernetes and cloud native technologies continue to gain momentum. Michael Coté explains the benefits and ...

SpringOne 2022

Register Now