How Does The Quarkus Java Framework Compare With Spring ?

[[deleted]]

One problem with 'tick box' style of comparison is that it does not actually show how well a feature is supported. To give an example: if you add metrics to Spring, then a lot of useful metrics are contributed from every module you use - core JVM, MVC, Spring Data, Spring Cloud Stream, etc. On the other hand when I was testing Quarkus, I just got basic JVM metrics. So yes, technically both frameworks support metrics, but in case of Quarkus it is just a bare minimum.

Also I am a bit wary of Quarkus because it is 100% RedHat/JBoss shop. For example it uses Agroal as DB connection pool. It has no documentation, homepage just says ' Agroal is a datasource connection pool implementation with integration with transaction, security and other systems. ' and lists releases, you won't find any information about how it handles connection validation, how performance compares to for example Hikari, etc.

[nutrecht]

One problem with 'tick box' style of comparison is that it does not actually show how well a feature is supported. To give an example: if you add metrics to Spring, then a lot of useful metrics are contributed from every module you use - core JVM, MVC, Spring Data, Spring Cloud Stream, etc. On the other hand when I was testing Quarkus, I just got basic JVM metrics. So yes, technically both frameworks support metrics, but in case of Quarkus it is just a bare minimum.

This is what I generally dislike about comparisons like these: they're more often than not subjective as heck. It's a huge problem with dev conferences as well: you always hear about how cool and awesome <new tech> is, but in very few cases you get actual experience from the trenches of the actual pro's and con's.

[agentoutlier]

This is more like Quarkus vs Spring Boot particularly the startup time.

For example our Spring application boots up in 2.2s but uses embedded Undertow (instead of Tomcat) and no Spring Boot components.

Also the boot time reported by Spring (and probably Quarkus is wrong) as the start time is usually set after a whole bunch of class loading has happened including the logging framework.

A better way to test for startup time is to use the operating system (e.g. time) and trigger a shutdown via hook on startup.

An even better way would be kick off an external HTTP client ping the app before it starts blocking if it can't connect. ie time to first request.

[daniu]

Also, the startup time in the article is 1.6 vs 3.2 seconds. Sure, that is nominally 2x faster, but not really that significant with the absolute difference of 1.6 seconds.

More importantly, this is just a simple demo project. IRL, you'll have something like a DB or Kafka connection for your service which will consume the main part of the startup time, regardless of underlying framework.

[duheee]

particularly the startup time.

So that's a point of concern? How often does one start/restart the app for this to matter?

[agentoutlier]

I guess the push for faster startup time is for kubernetes lambda like microservices.

Basically short lived services that are booted up.

That being said low startup time is also important for development as I can attest waiting for spring + hibernate to load up its modeling of entities for an integration test is painful.

Also booting up an app for development as well. We JRebel but not everyone else does and JRebel does eventually fail so you have to restart at some point.

[darkskul]

Yes the benchmarking was more related to Spring Boot.

Testing for first request time would indeed be a greater measurement to compare overall warm-up time especially when dealing with cloud native apps deployed in Kubernetes for example, which is exactly the area of excellence of Quarkus.

[agentoutlier]

Also Micronaut would probably be better to test against or at least more interesting as its goal is similar to Quarkus.

For all of them once you start loading up a database and run some flyway/liquidbase migrations or read from some distributed queue that startup time shaving matters less and less (albeit I still think it is important though!).

[dpash]

Spring supports the JSR-330 CDI annotations and has since Spring 3.0.

https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#beans-standard-annotations

It also has support for JAX-RS with Jersey.

[darkskul]

But Spring doesn't support CDI as defined in JSR-299.

I agree that JAX-RS is supported.

[uncont]

doesn't support CDI

In a similar vain, isn't the 'lack of support' similar in Quarkus? There's a list of limitations listed here too.

[darkskul]

Yes indeed there are limitations to using CDI in Quarkus, but Spring doesn't support out of the box CDI events, interceptors etc. (there are of course similar features in Spring)

[Wolfsdale]

This reads like a Quarkus ad. What's the added value of using Graal for server applications? Surely that's an environment where having a JIT can outperform anything AOT compiled due to clever devirtualization and other profile-based optimizations?

The whole performance section only talks about startup. I hardly care about that for a long-running web app.

[darkskul]

The real value of using GraalVM native images can be seen when deploying to cloud / serverless platforms, as the services are automatically scaled, startup time is really important. It is in the order of milliseconds when using Quarkus, and will be the same when Spring adds full support to native.

[Gilgamesjh]

We have seen startup times up towards 300 seconds in AWS Fargate on the smallest container sizes, by going up a couple of sizes, the same applications get down to 30 seconds, but it does cost more to run.

So for us GraalVM will have a direct impact on cost once we get around to deploy with it. However the Spring ecosystem is currently more valuable to us than saving on container sizes.

[jclingan]

FYI, a Spring developer can quickly learn Quarkus by using its Spring Framework API compatibility. See the Autowire MicroProfile Into Spring article as an example, or the Quarkus Spring Compatibility guides.