4 ms·

> Graal can only create native binaries targeting the system on which it is running. That means that if you want to create binaries for {Linux,Windows,Mac}x{Int

> Graal can only create native binaries targeting the system on which it is running. That means that if you want to create binaries for {Linux,Windows,Mac}x{Intel,ARM}, you need 6 different machines in order to build the 6 binaries and somehow aggregate them together for publication or deployment. This is not a blocker, but can definitely be inconvenient v.s. some other toolchains which allow you to build native binaries for all targets on a single machine. To me this is a huge downside. One of the reasons I like Go so much is that I can build binaries for any platform I want to support on my Mac or with Docker.

jeswin 2y ago
> To me this is a huge downside. One of the reasons I like Go C# with NativeAOT might be an easier path for Java developers. Some might like the expressiveness as well over Go.
- pragmatick 2y ago
  I don't think you'd be a Java developer anymore.
  - neonsunset 2y ago
    That made me laugh out loud for some reason haha Indeed!
  - pjmlp 2y ago
    Why not? Both ecosystems complement themselves, some stuff Java ecosystem does much better than .NET, like multiple implementations, with various kinds of GC and JIT implementations, wider support of hardware deployments, tooling like Graal, industry standards, IDE implementations, a mobile OS,... Other things the .NET ecosystem does better, support for value types, low level programming, SIMD, desktop development, game engines. To this day they keep copying features from each other, and if either C# or Java isn't one's taste, there are still several other options on each platform. Hence why I am confortably at home using them both, complemented by JS/TS for FE, and C++ for fiddling with their runtimes, or plugging into native libraries.
    - neonsunset 2y ago
      What features is C# copying from Java?
      - pjmlp 2y ago
        Most of C# 1.0 for starters, given that it was born from the lawsuit and J++ extensions, J/Direct, COM interop, events and Windows Foundation Classes. More recently, default interface methods, apparently the ongoing discriminate union design seems to now be settling on similar Scala/Java approach, I still have to spend some time delving into it. Not delving now on the CLR, versus the various JVM implementations, regarding GC, JIT, PGO, tiered compilation, escape analysis,...
        deleted 2y ago
        [deleted]
- brabel 2y ago
  I've been using Dart instead. Not too far from Java, but can compile to executable without any cerimony.
- josefx 2y ago
  How is the cross platform UI situation on C#? Anything official?
  - neonsunset 2y ago
    There is a good selection of multi-platform GUI frameworks: AvaloniaUI, Uno Platform, MAUI and smaller more focused alternatives.
cratermoon 2y ago
> this is a huge downside. Also the compiler can only do static analysis and code generation. I'd much rather a hotspot VM analyze the running code and identify the optimizations on the fly.
- Yasuraka 2y ago
  >I'd much rather a hotspot VM analyze the running code wasting gigabytes of ram and fast startup times >and identify the optimizations on the fly and still get gapped by statically compiled languages. I guess these are a cheap price to pay for the benefit of ... having to install and patch runtimes.
  - forty 2y ago
    > still get gapped by statically compiled languages. Which statically complicated languages are you referring to? :)
  - pragmatick 2y ago
    Native Image requires so much more work to have a medium-sized java project properly run when compiled the price gets a lot higher.
    - sgammon 2y ago
      More of this configuration is automatic with every release
  - gf000 2y ago
    Unused RAM is wasted. If you have plenty available then doing useless memory releases (including dropping/destroying objects with RAII, which can end up doing a lot of work in case of a data structure containing other objects that have to be dropped) will just hurt your throughput. Nonetheless, Java has a pretty trivial single flag to set an appropriate heap size if you are not happy with the default. -- You are thinking of AOT compiled, but does that AOT language support arbitrary class loading to expand functionality, live observability while taking almost zero overhead for that? -- So what do you do if a statically linked library of yours has a vulnerability?
deleted 2y ago
[deleted]
taurknaut 2y ago
Agreed, this is definitely an odd and very unnecessary constraint on builds.
- sgammon 2y ago
  Well, it's also not true. But aside from that, plenty of software builds in its native environment. Cross-compiling is straight up hard for many toolchains.
flakes 2y ago
I wonder if you could wrap this process in something like qemu for a cross-architecture build setup?
- taraparo 2y ago
  You can e. g. create ARM builds on x86 using qemu but the compilation takes ages.
rixed 2y ago
GCJ could do that, as well as JET I believe, but both are long dead. The history of native compilation for java I find fascinating: Nothing looks like a normal, boring programming language as much as java, yet somehow it resists being treated as a normal, boring programming language, and needs its own galaxy of special idioms and tools, like it was some smalltalk or lisp.
- chii 2y ago
  because java is not designed for it. It's retrofitted in, because of trends. There's actually, imho, no need for native compilation for java tbh. Why isn't shipping the runtime with the code a more common practise? it's how intellij or eclipse worked. People today ship electron apps for god sakes! If you _need_ native, for one reason or another and it's non-negotiable, then choose a native compiled language.
  - brabel 2y ago
    Absolutely. > Why isn't shipping the runtime with the code a more common practise? Well, Java has jlink which is meant to do exactly that (ship the parts of the JVM you actually need, which is easy to figure out as there are tools to do that), and that's the recommended approach today for shipping anything Java.
  - p2detar 2y ago
    > Why isn't shipping the runtime with the code a more common practise? That's what I actually do for our product. The JRE is shipped with it as well as startup scripts and services registration bridge for Windows. I guess the native compile thing is more for "Java on the Cloud" which tbh is not where Java shines. I say this as a long-term Java developer. Java is great for monoliths - on premises customers are supper happy. Java on the cloud seems like a waste of resources to me.
    - xxs 2y ago
      While not a fan of the cloud - in case of java; package it in docker or whatever deployables along with the JRE (or even JDK) and call it a day. Compile to native makes sense only for very fast startup cases. As for wasted resources - there are cases where the servers have to be deployed in specific jurisdictions (compliance) - it's easier to use AWS than manage tons of small sites. Still I don't see any need for native compilation.
pragmatick 2y ago
While I agree I think most use cases aren't for releasing end-user software that needs to run on many architectures and OSes but rather building enterprise software for one certain combination, usually x86 and linux, to deploy on a server or containerized in a hyperscaler. But to contradict myself, I actually use windows, WSL and oracle cloud to build for windows x86, linux x86 and linux ARM64 to build a java desktop application. Of course I'd prefer it if I could just use my main machine and OS to build all those like Go can.
ltbarcly3 2y ago
You realize you can run Linux, Windows, Mac x intel, arm builds on docker right? Right on your Mac.
sgammon 2y ago
https://github.com/oracle/graal/issues/8350 https://github.com/oracle/graal/issues/8350 Plz upvote
sgammon 2y ago
Also, I don't believe this is fully true. GraalVM depends on the underlying C compiler to generate native code, so if properly configured with target triples and flags (just like any cross-compiling setup) it should work.
- gf000 2y ago
  GraalVM reuses the normal java class loading logic which is platform-dependent. So e.g. on windows it will load some windows-specific File subclasses and the like, so this is more of an architectural problem to a certain degree. (It really does loadClass everything reachable based on the code to be compiled)
ludovicianul 2y ago
You can do the same with GraalVM on Mac for Java.

jeswin 2y ago

> To me this is a huge downside. One of the reasons I like Go C# with NativeAOT might be an easier path for Java developers. Some might like the expressiveness as well over Go.

pragmatick 2y ago
I don't think you'd be a Java developer anymore.
- neonsunset 2y ago
  That made me laugh out loud for some reason haha Indeed!
- pjmlp 2y ago
  Why not? Both ecosystems complement themselves, some stuff Java ecosystem does much better than .NET, like multiple implementations, with various kinds of GC and JIT implementations, wider support of hardware deployments, tooling like Graal, industry standards, IDE implementations, a mobile OS,... Other things the .NET ecosystem does better, support for value types, low level programming, SIMD, desktop development, game engines. To this day they keep copying features from each other, and if either C# or Java isn't one's taste, there are still several other options on each platform. Hence why I am confortably at home using them both, complemented by JS/TS for FE, and C++ for fiddling with their runtimes, or plugging into native libraries.
  - neonsunset 2y ago
    What features is C# copying from Java?
    - pjmlp 2y ago
      Most of C# 1.0 for starters, given that it was born from the lawsuit and J++ extensions, J/Direct, COM interop, events and Windows Foundation Classes. More recently, default interface methods, apparently the ongoing discriminate union design seems to now be settling on similar Scala/Java approach, I still have to spend some time delving into it. Not delving now on the CLR, versus the various JVM implementations, regarding GC, JIT, PGO, tiered compilation, escape analysis,...
      - deleted 2y ago
        [deleted]
brabel 2y ago
I've been using Dart instead. Not too far from Java, but can compile to executable without any cerimony.
josefx 2y ago
How is the cross platform UI situation on C#? Anything official?
- neonsunset 2y ago
  There is a good selection of multi-platform GUI frameworks: AvaloniaUI, Uno Platform, MAUI and smaller more focused alternatives.

cratermoon 2y ago

> this is a huge downside. Also the compiler can only do static analysis and code generation. I'd much rather a hotspot VM analyze the running code and identify the optimizations on the fly.

Yasuraka 2y ago
>I'd much rather a hotspot VM analyze the running code wasting gigabytes of ram and fast startup times >and identify the optimizations on the fly and still get gapped by statically compiled languages. I guess these are a cheap price to pay for the benefit of ... having to install and patch runtimes.
- forty 2y ago
  > still get gapped by statically compiled languages. Which statically complicated languages are you referring to? :)
- pragmatick 2y ago
  Native Image requires so much more work to have a medium-sized java project properly run when compiled the price gets a lot higher.
  - sgammon 2y ago
    More of this configuration is automatic with every release
- gf000 2y ago
  Unused RAM is wasted. If you have plenty available then doing useless memory releases (including dropping/destroying objects with RAII, which can end up doing a lot of work in case of a data structure containing other objects that have to be dropped) will just hurt your throughput. Nonetheless, Java has a pretty trivial single flag to set an appropriate heap size if you are not happy with the default. -- You are thinking of AOT compiled, but does that AOT language support arbitrary class loading to expand functionality, live observability while taking almost zero overhead for that? -- So what do you do if a statically linked library of yours has a vulnerability?

deleted 2y ago

[deleted]

taurknaut 2y ago

Agreed, this is definitely an odd and very unnecessary constraint on builds.

sgammon 2y ago
Well, it's also not true. But aside from that, plenty of software builds in its native environment. Cross-compiling is straight up hard for many toolchains.

flakes 2y ago

I wonder if you could wrap this process in something like qemu for a cross-architecture build setup?

taraparo 2y ago
You can e. g. create ARM builds on x86 using qemu but the compilation takes ages.

rixed 2y ago

GCJ could do that, as well as JET I believe, but both are long dead. The history of native compilation for java I find fascinating: Nothing looks like a normal, boring programming language as much as java, yet somehow it resists being treated as a normal, boring programming language, and needs its own galaxy of special idioms and tools, like it was some smalltalk or lisp.

chii 2y ago
because java is not designed for it. It's retrofitted in, because of trends. There's actually, imho, no need for native compilation for java tbh. Why isn't shipping the runtime with the code a more common practise? it's how intellij or eclipse worked. People today ship electron apps for god sakes! If you _need_ native, for one reason or another and it's non-negotiable, then choose a native compiled language.
- brabel 2y ago
  Absolutely. > Why isn't shipping the runtime with the code a more common practise? Well, Java has jlink which is meant to do exactly that (ship the parts of the JVM you actually need, which is easy to figure out as there are tools to do that), and that's the recommended approach today for shipping anything Java.
- p2detar 2y ago
  > Why isn't shipping the runtime with the code a more common practise? That's what I actually do for our product. The JRE is shipped with it as well as startup scripts and services registration bridge for Windows. I guess the native compile thing is more for "Java on the Cloud" which tbh is not where Java shines. I say this as a long-term Java developer. Java is great for monoliths - on premises customers are supper happy. Java on the cloud seems like a waste of resources to me.
  - xxs 2y ago
    While not a fan of the cloud - in case of java; package it in docker or whatever deployables along with the JRE (or even JDK) and call it a day. Compile to native makes sense only for very fast startup cases. As for wasted resources - there are cases where the servers have to be deployed in specific jurisdictions (compliance) - it's easier to use AWS than manage tons of small sites. Still I don't see any need for native compilation.

pragmatick 2y ago

While I agree I think most use cases aren't for releasing end-user software that needs to run on many architectures and OSes but rather building enterprise software for one certain combination, usually x86 and linux, to deploy on a server or containerized in a hyperscaler. But to contradict myself, I actually use windows, WSL and oracle cloud to build for windows x86, linux x86 and linux ARM64 to build a java desktop application. Of course I'd prefer it if I could just use my main machine and OS to build all those like Go can.

ltbarcly3 2y ago

You realize you can run Linux, Windows, Mac x intel, arm builds on docker right? Right on your Mac.

sgammon 2y ago

https://github.com/oracle/graal/issues/8350 https://github.com/oracle/graal/issues/8350 Plz upvote

sgammon 2y ago

Also, I don't believe this is fully true. GraalVM depends on the underlying C compiler to generate native code, so if properly configured with target triples and flags (just like any cross-compiling setup) it should work.

gf000 2y ago
GraalVM reuses the normal java class loading logic which is platform-dependent. So e.g. on windows it will load some windows-specific File subclasses and the like, so this is more of an architectural problem to a certain degree. (It really does loadClass everything reachable based on the code to be compiled)

ludovicianul 2y ago

You can do the same with GraalVM on Mac for Java.