7 ms·

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 m

by geodel 6y ago

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.

WatchDog 6y ago
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.
- sverhagen 6y ago
  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 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.
  - lmm 6y ago
    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).
    - pjmlp 6y ago
      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.
      - entha_saava 6y ago
        Apparently you are not representative of average HN user :/ just kidding..
        pjmlp 6y ago
        Well, it is true, specially if you follow my threads regarding games development, or paying for software. :)
    - andor 6y ago
      Spring Boot is setting the Java ecosystem back 10 years. How so?
      - lmm 6y ago
        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.
mister_hn 6y ago
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.
- vips7L 6y ago
  JPA works fine as proven by quarkus which uses hibernate. For JavaFX you should be using substrate from gluon to achieve this.
pjmlp 6y ago
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.
- geodel 6y ago
  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.
  - smoyer 6y ago
    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)!
    - stuff4ben 6y ago
      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.
      - smoyer 6y ago
        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.
AJRF 6y ago
+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.
- The_rationalist 6y ago
  I believe that startup time is already a solved problem https://github.com/facebook/nailgun https://github.com/facebook/nailgun There is also https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html https://mail.openjdk.java.net/pipermail/discuss/2020-April/0...
  - maxandersen 6y ago
    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.
- kimi 6y ago
  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.
  - imtringued 6y ago
    I personally am more interested in the lower memory usage.
    - thu2111 6y ago
      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.
entha_saava 6y ago
If rampant reflection becomes a taboo because of native compilation, that would be great.
- jillesvangurp 6y ago
  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.
  - augusto-moura 6y ago
    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/ http://micronaut.io/
    - haram_masala 6y ago
      Thanks for sharing this, I’m new to Micronaut - it seems to solve a lot of problems inherent to Java.
    - stuff4ben 6y ago
      Really, thanks for sharing this. I just perused the docs and its got me excited to get back into Java development again!

by geodel 6y ago

WatchDog 6y ago

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.

sverhagen 6y ago
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 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.
- lmm 6y ago
  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).
  - pjmlp 6y ago
    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.
    - entha_saava 6y ago
      Apparently you are not representative of average HN user :/ just kidding..
      - pjmlp 6y ago
        Well, it is true, specially if you follow my threads regarding games development, or paying for software. :)
  - andor 6y ago
    Spring Boot is setting the Java ecosystem back 10 years. How so?
    - lmm 6y ago
      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.

mister_hn 6y ago

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.

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

pjmlp 6y ago

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.

geodel 6y ago
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.
- smoyer 6y ago
  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)!
  - stuff4ben 6y ago
    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.
    - smoyer 6y ago
      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.

AJRF 6y ago

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

The_rationalist 6y ago
I believe that startup time is already a solved problem https://github.com/facebook/nailgun https://github.com/facebook/nailgun There is also https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html https://mail.openjdk.java.net/pipermail/discuss/2020-April/0...
- maxandersen 6y ago
  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.
kimi 6y ago
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.
- imtringued 6y ago
  I personally am more interested in the lower memory usage.
  - thu2111 6y ago
    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.

entha_saava 6y ago

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

jillesvangurp 6y ago
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.
- augusto-moura 6y ago
  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/ http://micronaut.io/
  - haram_masala 6y ago
    Thanks for sharing this, I’m new to Micronaut - it seems to solve a lot of problems inherent to Java.
  - stuff4ben 6y ago
    Really, thanks for sharing this. I just perused the docs and its got me excited to get back into Java development again!