4 ms·

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.

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.
    - rbrtl 6y ago
      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.
- pjmlp 6y ago
  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.
- thu2111 6y ago
  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.

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.
  - rbrtl 6y ago
    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.
pjmlp 6y ago
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.
thu2111 6y ago
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.