Hacker News Reader

Comment by geodel | Hacker News Reader

After playing with Java native stuff, one thing has become clear to me that is not general purpose technology where one can take existing Java application and make it native. It will not work even for apps that one write while choosing any library from vast Java ecosystem.

Framework vendors are betting on fact that most Java apps are HTTP/ORM/JSON plus metrics and security etc. So if framework provide transitive closure of these libraries and provide configuration to compile native, it will work.

For my purpose it does not work because I have many more dependencies which do not fit in above framework. Also I prefer to write my code directly with JDK and external libraries without any of these framework.

View on HN

Since their introduction around 2000, AOT compilers have been special purpose.

There are several features in the platform for dynamic code generation that are very hard to make work in an AOT scenario.

This is fine. However one thing that is not clear to me is why after telling for decades that startup time and memory usage does not matter, Java world is promoting Graal native so much.

Because Graal Community is free beer and plenty of developers don't want to pay for their tools, but enjoy being paid.

i don't understand your point; openjdk is free beer too. and graal-vm is an oracle project, as is hotspot?

And exactly for that reason, many are also euphoric about jaotc, which makes use of Graal anyway.

The goal is to remain competitive with Go. Java is still going to excel in cases when the benefits of JIT and superior GC have the opportunity to show themselves.

Graal native gives up the benefits of JIT for fast startup. It might be a useful tradeoff for some but it is not a universal solution.

As someone who's spent much of the last 20 years writing J2EE, Java EE and Jakarta EE projects, the answer is definitely that with containers and container orchestration, no one believes it anymore. Our new services are written in Go and have significantly shorter start-up times and smaller memory usage and it does matter (to us at least)!

I think this touches on some of the points that GraalVM/Mandrel and Quarkus are trying to address. No one wants those large J2EE/Spring monoliths anymore especially if they're deploying to K8s. Being able to quickly spin up replicas is where that short startup time and smaller memory usage comes into play. Scaling out vs scaling up (horizontal vs. vertical) is what Java devs have needed and it's being addressed with these new technologies.

Agreed ... but as noted elsewhere in this thread, your chance of getting a Wildfly (e.g.) application running in Quarkus and compiled to native via GraalVM is pretty small unless you've got a pretty standard CRUD application. We run into all sorts of problems with connections to anything that isn't a database including jobs that process JMS messages in an async fashion.

The funny thing is HotSpots startup time and memory usage are drastically lower on jdk 14 vs 8 [0].

I think the next step for Java will be more people shifting to using ZGC which automatically releases unused heap back to the OS where the current default (G1) doesn't.

[0] https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...

Simple applications that don't use reflection are pretty easy to compile with graal native image.

You absolutely don't need to use a framework like micronaut. You do however need to understand what libraries you are using, and if/how they use reflection and dynamic class generation.

I totally agree with all you said. But as there's different styles and approaches to development, I can say I've mostly worked (and still) on teams where rarely anything we touch works without reflection. Concretely: if you work for a company that has committed and hired to be building Spring (Boot) applications, GraalVM seems like a complete non-starter.

To the point of: if you want to deploy serverless applications and GraalVM requires you to write Java code that is so fundamentally different than what you have been doing for so long, why would you even stay with Java, you already lost much of the benefit of it being supposedly "the same language", and you may then just as well write your serverless application in Javascript or Python. Instead of using a far from mainstream solution like GraalVM.

I'm even wondering how obvious or subtle the bugs would be if I ever accidentally did something reflective in GraalVM.

I found this video very validating for thoughts I already had about how optimizing Java for use in AWS Lambda is not how I want to be programming Java: https://www.youtube.com/watch?v=ddg1u5HLwg8 What he lays out in this video makes me think back to doing my own memory management in C++. There's surely a place for that: high-level application development just ain't that place, in my mind.

Spring Boot is setting the Java ecosystem back 10 years. But such missteps aside a lot of modern Java libraries have a more "plain old Java" attitude, and it's now reasonably idiomatic to write Java code in a style that doesn't depend heavily, or even at all, on reflection.

(Myself I'm interested to see how well this handles Scala, since avoiding reflection completely is pretty much the norm there).

I am quite happy that with my hops between Java and .NET, every time I land on a Java project I have been able to avoid it.

Apparently you are not representative of average HN user :/ just kidding..

Well, it is true, specially if you follow my threads regarding games development, or paying for software. :)

Spring Boot is setting the Java ecosystem back 10 years.

How so?

By Spring 4.x it felt like the ecosystem had learned the value of staying close to vanilla Java - annotation-based configuration meant that there would be a (Java) reference to any class that was instantiated by Spring, constructor injection meant that there was less need for Spring-specific lifecycle methods like afterPropertiesSet() and it was more practical to write "dual-use" classes that could be used with or without Spring.

Whereas for me Spring Boot has the same feel as the bad old days of early Spring 3.x - lots of magical constructs that were impossible to understand unless you knew all the Spring specifics. A Spring Boot application will behave completely differently based on just which libraries happen to be on the classpath - the exact same code might start up a tomcat server when run one way and not when run another way - and has a whole host of new Spring-specific things that you have to learn if you're going to understand how your application is behaving.

It increases the distance between the developer and the actual, deployable executable that they output. It's like all these JS libraries that allow you to spin up an app in 20 lines. It's meaningless garbage unless you understand the libraries, but the people who are writing those apps usually just copy and paste the code from somewhere.

Seconded. Throughout all my time working on Java, Scala and Clojure, I've considered reflection to be a code smell. It's a bit more complicated with Clojure, since it uses reflection to bootstrap the language.

There's a burgeoning ecosystem in Clojure for creating native apps using GraalVM native image

https://github.com/borkdude/babashka is a good place to start

Babashka is a scripting tool that is meant to be compiled with GNI and a great tool but to link your own Clojure app like that a good starting point might be https://github.com/taylorwood/clj.native-image

(or https://github.com/taylorwood/lein-native-image if you are using Leiningen)

It's also widening the gap between Dev and Ops. I was a developer for 6 years and started moving towards DevOps and trying to build relationships between the ops teams and the programmers. The programmers are always whining about not being able to use the latest language/tool/library/<<insert flash tech here>> while the ops team are just trying to make the pile of junk they've been handed work.

Spring, and Spring Boot most egregiously, work only to widen the gap between devs and ops. The developers have no idea what a Boot app is doing internally for 90% of its stack. The ops guys just want to stably deploy something that is well understood and supportable when it falls over. Not to mention the memory management headaches it introduces...

I moved away from JS early on in my career because it's mostly a disaster waiting to happen, but now the Java devs have the same potential to output a steaming pile of crap that they don't understand.

> The developers have no idea what a Boot app is doing internally for 90% of its stack.

This is the biggest problem by far with Spring Boot. It’s not just hidden default settings or convention or configuration, it’s entire hidden applications.

> Not to mention the memory management headaches it introduces...

Could you elaborate on this?

I read that as more of a criticism of the ORM/JPA and maybe xml than Spring Boot. In practice it's easy to pull down half the database with an errant "eagerly loaded" collection or attempt to deserialize a giant xml document into an in memory DOM, both of which can exhaust memory and hang jvms with very little information on what happened than an 'out of memory' exception.

We have had app teams whose Spring Boot application leaks memory at a rate that meant we needed to do app restarts once a month, even once a fortnight on occasion. Investigation is then hampered by half of the conversations we have being along the lines of "well we're using Spring Boot so it can't be our problem" and the other half are "it's Spring Boot causing the leak."

The dev team refused to accept responsibility as though they hadn't fought tooth and nail to use Spring Boot in the first place.

Just curious how you're measuring the memory leak in this case? Can you explain how that's being determined?

We monitor just about every aspect of the machines and JVMs that we own. When the Heap graph climbs steadily over days/weeks at a time, i.e. each GC still results in considerably more overall memory usage.

Because Python doesn't have the performance of any JVM implementation (not counting toy ones here), not even via PyPy, and JavaScript lacks the tooling, performance of static typing and good support for parallel programming.

Seems like some confusion here.

GraalVM is two things. One is a regular but enhanced HotSpot. All existing Java code works on it. You can also run all the Truffle/Graal languages on it fast - it basically turns the JVM into a VM for many languages with good or great performance.

Then there's "native-image"/SubstrateVM. This can also run most Java code, including all code that uses reflection. Reflection isn't missing or broken on this platform, but by default it throws out the metadata you need for it and maybe the code (because it will appear unused). So you have to tell native-image what classes you'll want to reflect over at runtime so it keeps the data. This is well known to mobile developers who used ProGuard because it's the same; you have to say "classes matching these patterns need to be reflectable so don't optimise them".

You can't really have bugs caused by not setting these configurations correctly because if you try to reflect something you didn't pin you immediately get an exception telling you about your mistake.

The thing SubstrateVM cannot do, at least not until a later project that Oracle are working on is released, is run dynamically generated bytecode.

It's bytecode synthesis and plugin loading at runtime, not reflection, that causes the compatibility issues.

If rampant reflection becomes a taboo because of native compilation, that would be great.

This is already happening with Kotlin driving people to use functions instead of annotations. E.g. the kofu project gets rid of most anootation driven configuration for Spring Boot; specifically with the aim to speed up startup and ultimately enable native compilation via Graal.

You can use annotations without reflections, you just need another build step, take a look at Micronaut [1], it really looks like Spring Boot but makes all annotation processing in compile time. Because of that it also supports GraalVM as first class

[1] http://micronaut.io/

Thanks for sharing this, I’m new to Micronaut - it seems to solve a lot of problems inherent to Java.

Really, thanks for sharing this. I just perused the docs and its got me excited to get back into Java development again!

+1 - I tried using GraalVM for a Clojure(script) + re-frame application recently and it didn't work, changing back to OpenJDK works fine. It's a shame because the times were Graal does work, the start-up time is orders of magnitude faster.

I believe that startup time is already a solved problem https://github.com/facebook/nailgun

There is also https://mail.openjdk.java.net/pipermail/discuss/2020-April/0...

Not a solved problem.

nailgun doesn't solve it generally.

leyden is not released yet; its proposal into JDK future is validation of the approaches projects like GraalVM/Mandrel and Quarkus are doing.

What often is not clear is that GrralVM in "native" mode is NOT faster than JVM mode, because the JVM has a number of tricks up its sleeve for dynamic optimization based on actual usage patterns. It definitely has faster startup times, but for a web client/server application this is not so significant.

I personally am more interested in the lower memory usage.

Memory usage is smaller mostly for small apps. Larger apps will see larger memory usage because the GC and heap layout is a lot weaker.

SVM/native-image has its place, but currently it's optimised for things like command line apps or servers that people constantly shut down and start up to try and save on huge AWS costs. Actual runtime throughput and latency will be far better on regular OpenJDKs, especially the latest ones with much better garbage collectors.

Exactly. Add a little bit of jaxws, jpa, javafx stuff and it won't work.

Still today, jlink for the above modules won't work (not generating jmods, especially all those jakarta.xxx stuff) with original tool, imagine with GraalVM.

JPA works fine as proven by quarkus which uses hibernate. For JavaFX you should be using substrate from gluon to achieve this.

Reply on news.ycombinator.com