Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think what's needed here is actually just a cross-platform binary format that can be linked and loaded without using the OS native linker, along with an integration with cross-compilers. Java apps mostly use JNI to either access operating system specific APIs, or to access high performance hardware the JVM doesn't directly expose (like simd), and WASM doesn't help you with either.

And then you also have the problem that WASM/WASI is basically a new OS which is incompatible with every other, so it requires ports.

On the other hand, if you had something like ELF, PE or Mach-O but designed for cross-platform distribution and which had a nice and convenient cross-building toolchain and a portable dynamic linker, then it'd be a lot easier to compile and distribute once but use on every OS. Sort of like MachO fat binaries but more fine grained and not Apple specific.

Graal also has some sort of capacity for that in the way it can execute LLVM bitcode. You can do it either inside a sandbox that looks like a virtualized Linux (syscalls are recompiled into upcalls into the JVM), or it can be allowed to access native code. There is a toolchain that you simply point your PATH at and it produces the necessary files. But, it's not well known, LLVM bitcode still requires JIT compilation before it can execute on the CPU, and the toolchain doesn't really cross-compile in the way I mean above. Plus bitcode isn't a stable format.



> On the other hand, if you had something like ELF, PE or Mach-O but designed for cross-platform distribution and which had a nice and convenient cross-building toolchain and a portable dynamic linker, then it'd be a lot easier to compile and distribute once but use on every OS.

I mean... .NET VM and JVM kind of achieve this, but I think I get what you mean, you would either have to build the environment that these binaries run on for each OS, and recipients would have to install it, or you hope the OS vendors adopt your standard. I would love to see such a project though.

Bonus points if it can be similar to DMG files where you drag it to your "Applications" folder to install, delete it to uninstall.


I'm thinking of something a bit lower level than app packaging. But yeah think something like "jar for native code" but with the ability to directly dlopen() and dlsym() from it. So the file could contain native code that's OS or CPU specific and the dynamic linker (bundled with your app) would be able to successfully load the right one and get symbols from it. It'd just be a more convenient way to ship code that can fully utilize the CPU and OS, without excessive duplication (e.g. think about merging the text sections and symbol tables together but using something a bit like symbol versioning to keep the code for each OS separated).


The new foreign function & memory interface is sort of like that, given a shared library that runs on multiple OSs you can use it as is with Java.


Almost sounds like wine or similar then, but you only need to simulate what's not directly available.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: