Hacker News Reader

Comment by WatchDog | Hacker News Reader

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.

View on HN

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

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?

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.

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.

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)

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.

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

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.

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.

Reply on news.ycombinator.com