> What do I need to have a simple "hello world" CLI Java app which starts within 25ms and doesn't eat more than 10MB of RAM? Is GrallVM enough?

Yup. Here is another tutorial [1]. There are limitations, though:

* It's AOT, which means you don't get the JVM peak performance that come from JITting to your wordload profile. (but maybe in the future we can have startup in AOT then transition to JIT?)

* You're getting an embedded generational garbage collector. Not the sweet stuff like G1/ZGC/Shenandoah.

* You can't do dynamic class loading, or you have to declare (and know) beforehand which classes are reachable. A fair amount of frameworks use this and will not work with native-image. I suspect these will provide mechanisms to help in this regard in the future (for JSPs: generating the code of all classes-pages that are reachable at compile-time).

* There are other limitations [2].

All in all, great for CLIs and cloud lambdas.

[1] https://medium.com/graalvm/instant-netty-startup-using-graal...

[2] https://github.com/oracle/graal/blob/master/substratevm/LIMI...

AOT implementation in the JDK, that we call the "HotSpot AOT" implements tiered compilation (look for $JAVA_HOME/bin/jaotc). It is also based on Graal, but with a different set of plugins. You get reasonably good startup and re-JITing afterwards. Of course it doesn't give you compactness on the SVM, but it supports regular java code with class loading, reflection, etc.

A talk about HotSpot AOT: https://youtu.be/n5DCg6M2MDM

To answer some of your questions (I use vertx and mainly focus on the JVM world) - reactive is actually a widely used term in the java world to mean "event loop with async programming.

Origin of the term here: https://www.reactivemanifesto.org/

Graal is an R&D effort by a few folks in the java community driven by oracle right now to allow AOT compilation among other things for the JVM: http://www.oracle.com/technetwork/java/jvmls2015-wimmer-2637...

Java is generally not for apps that require fast VM spin up times. That being said, for what the JVM ecosystem can do it isn't bad in practice for heavy server applications.

I know gravitational mainly works in the go ecosystem which has its own trade offs there, but considering what else java already has a mature ecosystem for (big data, well understood native internals, other language built on top of it) the startup times and weaknesses while not ideal haven't been a show stopper.

GraalVM is an attempt to address a wide variety of problems you get with JVM startup time, GC etc.

At most it's simplistic right now and will be for a while. The fact they are working on it is really cool though!

Hope that helps!

Thanks, that's very helpful

Vert.x is a framework for developing server applications using an event loop (think Node.js but for the JVM, with the ability to fallback to normal threads). If you've heard of Spring Boot or Spark, it's a lighter/faster alternative to those (which are generally based off of heavier webservers like Tomcat or Jetty).

Graal compiles JVM bytecode to native code, so that's the critical factor for your CLI app use case. You'd only need Vert.x if you were writing a server.

> Spark

I thought u were talking about big data spark. But I think you are talking about http://sparkjava.com/

> Spring Boot

Vert.x is nothing like Spring Boot. Spring Boot combines Spring with autoconfiguration and the ability to run in its own container. Spring Boot can run on Undertow which the other branch of JBoss marketing promotes a lighter weight than Netty.

But they're both frameworks for writing a server right?

Not Spring Boot. Spring Boot is a framework for implementing a server side application. For example you use Spring Boot to implement a RESTful server side application including persistence and security. You do not use Spring Boot to write an HTTP server, instead Spring Boot uses an existing HTTP server.

Vert.x uses an existing HTTP server as well: Netty.

I look at Netty as an async IO library. You use Netty to build your own servers. Yes, I know, Netty ships with an HTTP client and server.

> But they're both frameworks for writing a server right? reply

> Not Spring Boot. Spring Boot is a framework for implementing a server side application.

'server side application' and 'server' or 'web server' are two terms for the same thing in many people's vocabulary. You two are arguing at cross-purposes.

Then people need to use these words more carefully. 'server side application' and 'web server' are not even close to being the same thing.

Right, but you don't use Vert.x to "write an HTTP server" either. In both cases you use the server from the framework, though in the case of Spring Boot that is also pluggable.

Sorry, Vert.x web would be a more appropriate comparison.

Even Vert.x web has no equivalent to Spring which forms the basis of Spring Boot. Spring is a complete application framework that combines dependency injection, AOP and enterprise integration.

To my knowledge Vert.x and Vert.x web have no equivalent to Spring Boots autoconfiguration.

I am not saying Vert.x or Vert.x web are worse than Spring Boot but they do very different things.

Spring's WebFlux is the closest analogue I could find to Vert.x web (https://docs.spring.io/spring/docs/current/spring-framework-...). However WebFlux is quite new and looks like it's targeted to existing projects that use Spring and need some reactive features.

Yes it's SubstrateVM that gives the small fast starting binaries, if you can accept its limitations.