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).
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.
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.
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!
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.
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.
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.
> 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.
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.
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.
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.
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.
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 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.
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.
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?
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.
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?