4 ms·

I'm sincerely wondering how you came to that conclusion. Java has one of the fastest VMs, but maybe you mean the startup speed?

throw2838 6y ago
Slow startup from command line
- pjmlp 6y ago
  All free JDKs now offer AOT compilers and JIT caches.
- coldtea 6y ago
  Which is relevant for a server how?
  - forgetfulness 6y ago
    This is on the comment thread of a tool to make client-side applications. However, it's all besides the point because this tool takes Java (JVM) bytecode and translates it to WebAssembly, there's no JVM involved for end users at any point.
- JAlexoid 6y ago
  Is sub 100ms not enough these day? Sure... IntelliJ IDEA startup isn't instant. Atom's startup isn't instant. QT Creator's startup isn't instant. GIMP starts in a few seconds... etc.
pharmakom 6y ago
JVMs that most people use are optimised for repeated execution of the same code paths on long running processes. If this isn’t your use-case then lots of tuning work is required.
- pjmlp 6y ago
  Like using the AOT compiler or JIT caches provided in recent versions, they are no longer features only available to customers of commercial JDKs.
  - skjfdoslifjeifj 6y ago
    The free AOT compilers have atrocious compile times (far, far worse than even Rust or Scala) and don't support all of the features so library support is extremely fragile. A lot of extremely popular Java libraries make extensive use of runtime reflection and none of the AOT compilers handle it well without a lot of extremely error prone manual configuration. I actually like Java and the JVM but if AOT compilation and efficient memory usage is what you want Java is definitely not the language to use.
    - imtringued 6y ago
      Yes, GraalVM requires a new sub ecosystem of libraries that are built with it's native image feature in mind. That means no more Spring, no more Hibernate and so on. Old codebases will not benefit and new code base require abandoning your existing Java expertise.
      - pjmlp 6y ago
        They work perfectly fine with JIT caches. Plus not everyone is fan of Spring and Hirbenate. The first I used only once in 20 years of Java projects, the second is the first to go away when I get called to optimise database performance in Java applications.
      - skjfdoslifjeifj 6y ago
        I agree. My main issue is with the Java zealots that come into the discussion and make it seem like anyone can just take their existing Java application and use it with an AOT compiler. The reality is that you will most likely have to make changes to your code, do a significant amount of configuration, and heavily modify or remove dependencies. Furthermore, you are isolating yourself from the huge Java community because very few people are using any of the existing AOT Java compilers. They try to paint an extremely rosy picture of the current situation when the reality is that it's a very long way from the experience you get in Rust, Go, D, C, C++, Haskell, Ocaml or any of the languages where AOT is considered the default.

throw2838 6y ago

Slow startup from command line

pjmlp 6y ago
All free JDKs now offer AOT compilers and JIT caches.
coldtea 6y ago
Which is relevant for a server how?
- forgetfulness 6y ago
  This is on the comment thread of a tool to make client-side applications. However, it's all besides the point because this tool takes Java (JVM) bytecode and translates it to WebAssembly, there's no JVM involved for end users at any point.
JAlexoid 6y ago
Is sub 100ms not enough these day? Sure... IntelliJ IDEA startup isn't instant. Atom's startup isn't instant. QT Creator's startup isn't instant. GIMP starts in a few seconds... etc.

pharmakom 6y ago

JVMs that most people use are optimised for repeated execution of the same code paths on long running processes. If this isn’t your use-case then lots of tuning work is required.

pjmlp 6y ago
Like using the AOT compiler or JIT caches provided in recent versions, they are no longer features only available to customers of commercial JDKs.
- skjfdoslifjeifj 6y ago
  The free AOT compilers have atrocious compile times (far, far worse than even Rust or Scala) and don't support all of the features so library support is extremely fragile. A lot of extremely popular Java libraries make extensive use of runtime reflection and none of the AOT compilers handle it well without a lot of extremely error prone manual configuration. I actually like Java and the JVM but if AOT compilation and efficient memory usage is what you want Java is definitely not the language to use.
  - imtringued 6y ago
    Yes, GraalVM requires a new sub ecosystem of libraries that are built with it's native image feature in mind. That means no more Spring, no more Hibernate and so on. Old codebases will not benefit and new code base require abandoning your existing Java expertise.
    - pjmlp 6y ago
      They work perfectly fine with JIT caches. Plus not everyone is fan of Spring and Hirbenate. The first I used only once in 20 years of Java projects, the second is the first to go away when I get called to optimise database performance in Java applications.
    - skjfdoslifjeifj 6y ago
      I agree. My main issue is with the Java zealots that come into the discussion and make it seem like anyone can just take their existing Java application and use it with an AOT compiler. The reality is that you will most likely have to make changes to your code, do a significant amount of configuration, and heavily modify or remove dependencies. Furthermore, you are isolating yourself from the huge Java community because very few people are using any of the existing AOT Java compilers. They try to paint an extremely rosy picture of the current situation when the reality is that it's a very long way from the experience you get in Rust, Go, D, C, C++, Haskell, Ocaml or any of the languages where AOT is considered the default.