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.
1,206 karma · joined March 24, 2017
reach me at sam at the domain mentioned above, or github.com/sgammon
It also makes sense to reduce container size and vulnerability surface, and to reduce warmup time to peak JIT performance.
> Still I don't see any need for native compilation.
Sure, there isn't a "need," per se, just like there is not a "need" for JIT. This is how technology evolves. Things get better. Java's startup and time-to-peak performance are now comparable to native langs.
Cosmo/APE support would fix this, and GraalVM already ships with a Musl libc implementation, so it isn't very far off.
A pure Java hello world now compiles in a few seconds on a commodity machine and weighs in at about 9mb.
Also, make sure you enable `-Ob` on newer versions of GraalVM, which significantly speeds up build times.
It even has a compat layer, and like Quarkus it supports GraalVM out of the box, with minimal reflection at runtime.
https://micronaut-projects.github.io/micronaut-spring/5.9.0/...
It really shouldn't be. It bloats everything. Containers are bigger. Software is bigger. There's no reason to do this, since very few apps use the entire surface area of a runtime (Python, Node, Java, etc).
Instead, a native GraalVM binary can embed all these things, including only the portions which the application needs to run. Thus it behaves like a dynamic piece of software during development, but a static, high-performance, low-surface-area-of-vulnerability native binary in production.
> That's what I actually do for our product. The JRE is shipped with it as well as startup scripts
Please, as a user, I implore you to look into native targets. It's not as hard as it seems anymore. Some thins really do need Jlink.
> I guess the native compile thing is more for "Java on the Cloud"
Not so. GraalVM is great for embedded development. It's great for desktop development or even shared native library development.
> Java on the cloud seems like a waste of resources to me.
There is no difference now between C++ "in the cloud" and Java "in the cloud" except Java remains memory safe by default.
Sure, that is true, but with native compilation available, Java can do even more things. There are other reasons, too: startup time, quicker time to peak performance, and better interfacing with FFM and JNI, to name a few.
> If you _need_ native, for one reason or another and it's non-negotiable, then choose a native compiled language.
You could do that, sure. But then you would need to worry about all the things that come with that. For example, memory safety -- GraalVM preserves memory safety guarantees with native binaries. Even binaries which themselves ship JIT features.
https://blogs.oracle.com/java/post/graalvm-free-license
So, yes, GraalVM CE is slightly nerfed (the performance difference across all EE features is like 30% maximum, at peak, in limited circumstances). You also do not need to use GraalVM CE in as many places anymore, and Oracle GraalVM with G1 is a free download. Many free projects like Pkl use the full-blown VM.
https://www.graalvm.org/latest/reference-manual/native-image...
Serial GC is still very performant. It's great for things like command line tools which don't need a low-pause long-running GC like G1.
Much of this configuration could be automatic if more attention were given to GraalVM by library authors.
How would they access that information? Under this feature, no location information for the user would be held by Apple's servers. Plus, Apple would have to divulge it somehow to law enforcement, which they don't do as a matter of course until compelled by a court. Courts have a high bar for accessing that information.
Even so, having compelled Apple, they cannot give up what they do not have.
> you've really been shilling apple
I am not "shilling" for Apple, I am commenting about a technology Apple has adopted and which I have decided to trust.
> giving multiple replies to the same comment
Sometimes I prefer to break my replies up so they are easier to consume. I don't agree with the premise that this is obnoxious and so far none of my counterparties has complained. Why are you complaining?
> what's your problem?
What's your problem?
> BOUGHT TLRY
So Apple kneecaps Meta's cross-app advertising, something that literally makes them no direct revenue to implement, and protects users (it famously reduced Facebook cross-app analytics traffic to a significant degree), and you think this is business as usual?
Then you should reconsider my comment at the top of this thread, because it is 100% speaking to this exact phenomenon.