I am sure you lose functionality with native image as well - reflection etc.
[Edit: I get the point about GraalVM itself just not the native image in the context of kubernetes. With GraalVM maybe they want to optimize better, allow various other languages to run on the JVM etc. None of that is Kuberenetes specific - not much of a memory or startup speed benefit unless I am missing something.]
It makes sense for things like lambda or knative ("serverless"). Also command-line applications (including tools you might put in CI).
Also, while the JVM starts quickly you also need to do class loading, which can take a while for complex applications with lots of classes. This is also pretty important when running a JVM-hosted language like Clojure which has quite a few classes of its own.
Quarkus uses build-time steps for most of what would be done at runtime (DI, mapping, routing etc.) in Spring. This makes it faster to start up and reduces reflection overhead even when not using GraalVM.
Disclaimer: working at Red Hat, contributing to Quarkus a bit.
But not simply using Graal.
JIT infrastructure, class metadata, etc are real, of course, but they are a small fraction of total memory use in every app i have ever worked on. Okay, you get a small saving by using Graal, so my original comment is not quite right. But it's not going to make the difference between an app needing 256 MB and 238 MB.
The comparable compile-time effort in Spring is being explored in the spring-init project and I believe will be a core feature in Spring Boot 3 / Spring Framework 6, along with Graal support.
A compiler/JIT development stack not bound to the cargo cult that C and C++ are the only path to system software.
byte  compileToNative(byte byteCode);
I'm discussing this in this post about a Serverless blog search I've built with Quarkus and Lambda: morling.dev/blog/how-i-built-a-serverless-search-for-my-blog/.
So the build time complexity may just be ok if I get to save a bunch of money by scaling down the amount of nodes I need for my K8s apps.
Spring Boot with JVM was slow to cold boot and its native image generation is still way behind. Quarkus provides like 60% of Spring Boot’s features and ease of doing things with bundled option to generate native image which was a win-win for us.
I’m actually jumping the gun here as none of our apps are in production now but it has been a good experience to work with Quarkus so far.
But one might raise a question whether you need to go through all this pain for Java in Lambda and instead use something faster already - NodeJS or Python or even Go.
I worked on dotnet for 12 years and still do. It’s my first go to if I have to build a quick project.
But my team is all Java developers and we decided to go with Java and Spring Boot few years back for all our microservices. Now that we are using Lambda a lot, the SpringBoot is long in the tooth when it comes to cold boot times and our path differed on which way to go.
I built few Python + Flask functions which have cold boot time of less than a second when equivalent with Java and SpringBoot would take 8-9s. But team was not comfortable with Python. We still have few functions running in Python which are the most stablest and fastest of functions we are running in prod.
We dabbled with NodeJS + Express which no one in the team liked to work on.
So when it was decided that it was going to be Java, we took alternative frameworks to Spring Boot like Quarkus and Micronaut more seriously and went with Quarkus as that seemed to be the one close enough to Spring Boot in terms of familiarity and features.
What you're doing here is comparing apples (large web frameworks) with oranges (languages). If you used a framework written in the same way as Spring Boot with Python, it'd also be very slow to start up.
OTOH, there's at least an argument that the structure and features of languages influence the kind of frameworks that people tend to use with them. They are distinct but not necessarily causally-unrelated elements of the community/ecosystem around a language
I also didn't make the bench marks.
* The quality is there. If they claim it is supported, it works. It gives reasonable error messages, etc..
* The documentation is very good, which makes the onboarding experience nice. Give a java dev the site, and they are up and running on their own in minimal time.
* The support on their zulip chat is also very good. People are both friendly and have deep knowledge. Most questions are answered in an hour.
* The development speed is fast. If you file a bug report, it might appear in the next version a week later
* If you have (enterprise) stuff that's not yet supported, you'll suffer. The oracle jdbc database driver cost us graalvm. soap took a lot of time to get working.
* cloud integration is a bit too magic for its own good. Quarkus tries to hide complexity by generating config files, executing openshift and docker commands, etc.. But if anything goes wrong, it is hard to find out what it tried to do and how it failed. The options in application.properties are only half-documented and it is hard to map them to the corresponding options of the underlying tools. Error messages are out of context. I ended up debugging maven and reading the source code.
All in all, I am convinced it is a good tool. It has both an open source feel and enterprise class support, combining best of both world.
Wonderfully simple -- I always liked JAX-RS (and in particular Jersey) for it's simplicity.
Expect from a few quirks here and there with new integrations and the fact that I hate hibernate and there is no other option for persistance, it's great.
Super fast reload, easy to implement, good developer tools.
I have loved Dropwizard in the past, which encourages the use of Liquibase. Not right for every project, but it was great when it fit.
For me personally, I'd like to see something like EntityFramework, but in Java. No annotation hell, linq queries are amazing too.
I know a lot of people are moving to just using jOOQ as well.
It's also really difficult to use an EntityManager outside of a JEE/Spring/framework container. They're not thread safe and you have to manage their lifetimes manually.
https://github.com/spring-projects/spring-framework/issues/2... is an open issue for Spring; the moral equivalent is closed for Quarkus. If you have DI misconfiguration, you tend to get it at build time rather than runtime.
* mostly uses standard javax/Jakarta/Eclipse etc APIs so code is relatively portable (in ~600 classes I found 8 quarkus imports)
* build time DI/weaving
* best dev-mode autoreloading I have seen
* in general, less Spring-y
* less reliance on classpath-searching and reflection voodoo, less weird shit breaking bc of dependency version conflicts
* stack traces and class names (https://gist.github.com/thom-nic/2c74ed4075569da0f80b) that fit within a human’s field of vision
* less overriding feeling of death by OOP
We started with Spring Boot, switched about halfway through and never looked back.
This is the selling point for me, never was a Spring fan.
Disclosure: I work for VMware, which sponsors Spring, but I don't work on Spring itself.
Quarkus comes with a toolchain enabling developers from live reload all the way down to deploying a Kubernetes application
Read the landing page, still no clue...
I actually thought the landing page was informative -- the code snippet and boot-time comparisons should give it away. Not used to seeing this kind of energy from java land but it is refreshing.
I'm still not going to pick java for any project ever again since better options exist IMO but this looks cool.
For personal projects I continue to prefer golang. For enterprise apps, I think Java still has a lot of potential.
What do you think about the angle of Go having a lot of potential (I honestly think it might replace java for large enterprises in 10-20 years?) because it's built for developer fungibility?
If there's one things enterprises want to do, it's reduce the cost of employing resources, and employees are one resource that gets a lot cheaper when codebases are easier to pop in and out of, and you don't need a Java Spring MVC expert, but rather a golang dev fresh out of a coding bootcamp (or whatever actually good shorter-term switch-to-tech education trends come out in the future).
Golang is used by a lot of startups, it lets you move insanely fast. Larger enterprise don't care as much about speed, but care more (allegedly!) about maintenance so as long as there are a ton of Java devs and consulting firms around, I don't see these enterprises switching over anytime soon. With the coming of Generics in v2, I think the language might start to gain a lot more adoption than it has today.
Spring Boot will also support Graal
I read through the get started guide, and could not figure out those features.
Don't Java folks have Gradle/Maven already? What's the difference between Quarkus' Hibernate Validator vs its vanilla version?
Are you confused by the wording extension here? They use it synonymously with dependency / library, in this case, maven/gradle dependencies. They are probably extensions in the sense that those dependencies / libraries are useless without quarkus.
Spring provides the same: https://start.spring.io/
They also curate the right set of matching (transitive) dependencies for each library, you just need to add the Hibernate ORM Quarkus extension, without having to think too much about versioning. Also they integrate different APIs: e.g. when having the Kafka Streams extension and the MicroProfile Metrics one, you'll automatically get metrics for your streaming pipeline.
Disclaimer: Working for Red Hat, contributing to Quarkus a bit (Kafka Streams and Debezium outbox pattern extensions).
Slow and steady does win some races.
They are also easily parseable and you can filter them to exclude framework code.