I haven't been following Java community in a while, can someone clarify this for me please: so the benefit of "thin" JVM comes from GraalVM or Vert.x? I looked at https://vertx.io/ and it says nothing to me, I have no idea what a "reactive" application is. Is it an async event loop library? And then there's Polyglot, so now there are 3 new things in the picture.

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?

> 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.

Have recently been trying out Micronaut [1] which is a similar idea. However Micronaut does not use Graal and manages a very similar memory footprint [2]. So I don't think you necessarily need Graal to achieve just that.

I have actually been surprisingly happy with my initial experience with Micronaut. It is clearly engineered as a next-generation framework where all the defaults are set to exactly what you want to build small microservices right from the start. I am using Groovy and it still starts up in ~ 1 second with minimal memory use.

[1] http://micronaut.io/

[2] https://jaxenter.com/micronaut-framework-microservices-14245...

It looks as if Micronaut is using compile time class generation through annotation processors. This explains a lot as this probably removes a lot of not all of their reflection at startup and runtime.

This seems to be the right way to do things in Java to me since I learned about Dagger https://github.com/google/dagger

They are also working on graalvm compatibility, as of late July.

Bitcoin as example. Ugh. Anyone got a more interesting use case?

Using Unifi Controller in Docker right now, uses 300 MB for Java (OpenJDK 1.8 x86-64) and 63 MB for Mongo DB. Haven't compared with UNMS though which needs to run in an Ubuntu 16.04 VM.

Yeah - it's pretty heavyweight. I run my Unifi controller on a spare Raspberry Pi that's been kicking around. There are plenty of pre-packaged versions of that tool as well.

Would love to see them reduce the overhead of the controller, but to be honest, traditional IT managers will probably just spring for the $100 cloud key and be done with it.

I guess as he mentioned on the blog it was a POC, if you just ignored the fact it's using the bitcoin api to track transactions it implements DB access, interaction with the event bus, websockets. I fail to see why it's not interesting.

I'm asking for other (IMO more interesting) POCs, and I do find in interesting.

I sold my UniFi gear because I shouldn’t have to install software on a server or buy an accessory to get the full features of my device. Their gear is great, but there are several lines that can’t be managed from the same control plane. It was infuriating.

It's more infuriating when you realise that there's no consistency between devices. The Security Gateway is an ancient MIPS thing that can only barely keep up with 100 megabit WAN even with hardware offload, the Cloud Key is a Mediatek dongle that makes remote management slightly less painful (although Power over Ethernet is nice) and the AC access points are some Qualcomm SoC that's sure to be abandoned as soon as the next shiny thing comes along.

Oh, and that $400 AP is slower than the Turris Omnia that it was replacing - and that was doing 4x gigabit switching at the same time.

> It was infuriating.

What part? The Unifi controller software is not for "a device", it's for multiple devices, imagine having to manage SSIDs / auth for primary+guest Wifi network across just 5 access points. I don't think anyone would enjoy logging into 5 separate AP UIs. Add your Unifi gateway + switches to that and the need to have a unified control plane is pretty obvious.

If you want self-contained, that's a separate product line, usually prefixed with "Edge". What's "infuriating" about having two product lines I don't understand. Honda makes motorcycles, boat engines, cars and jets and nobody gets pissed about it.

GP is saying the exact opposite of what you think he's saying

> there are several lines that can’t be managed from the same control plane.

Cheaply embedding a Datomic (=Clojure=JVM) transactor into a C process or other dynamic runtime to get shared-memory IPC to your non-JVM business logic?

Minor typo in the title: "10Mb" would be 10 Megabits.

They really mean "10 MB" as in 10 Megabytes.

Megabytes (1000^2, MB) or mebibytes (1024^2, MiB)?

They used MB and not MiB on the homepage.

Its pretty clear from context what it means

It is fairly clear however it is a small nitpick that has some significant consequences when it comes up as one is an 8th the size of the other.

Megabits is often used in the context of RAM.

At the hardware (RAM chip) level, yes. At the software level, basically never.

Vert.x is pretty sweet. It's basically like Node.js but automagically multi-threaded and will also play nicely with fibers.

Performance is usually way better than any Spring-driven app.

Was trying to seek akka support(for native-image), but looks it has sadly been left behind https://discuss.lightbend.com/t/akka-and-graal-s-native-imag...

That seems more like the work just hasn’t been done yet, not that is has explicitly been left behind as your phrasing suggests. In fact, multiple requests to file issues/bugs have been made in that thread.