Hacker News Reader

Comment by matthewbauer | Hacker News Reader

I think it’s funny to use java as an example when jar files have been around forever. Still there are some use cases for other things where statically linking is not possible.

I wonder what benefits this has over other solutions? Originally when it said multi-platform i thought it meant that one binary could run on multiple platforms like a fat binary. But i think all of the examples require you to have a specific target in mind.

View on HN

There's something to be said for the fact that these are native binaries. Like under windows you'd be able just call CreateProcess with the file. Jars never did that and intrinsically needed an interpreter to run them.

This. A .jar file could be anything. Is it a library or an executable? When I run it, do I need to make sure its dependencies are on my classpath? What're the java command line flags I need? Do I have the right version of java on this machine?

There's something to be said for an entirely self-contained native binary, at least as an easy on-ramp for users.

Unfortunately, it turns out this is not a completely self contained binary - it's more of a packer. So if you pack a Java app, you're still going to need the JRE, and if you pack a .NET Framework app, you're still going the .NET Framework, etc.

So I don't know what this is doing. But I know that microsoft is developing WPF to run in a fulled contained .NET Core binary. Meaning that there is no requirement of having any preinstalled software when running it. I would assume this technology to be translated into most any .NET core app.

Yes, any .NET Core app can already be 'published' as a self-contained app. That basically means it ships along with the .NET Core files (there are a lot of them), so you don't need to have a globally installed .NET Core to run it.

What Warp does is act like a packer, creating a thin, native executable that compresses and embeds all the files required to run your app, then decompresses them to disk the first time the app is executed.

You can build "fat jars" that contain all dependencies. IMO, this is how most Java apps should be deployed.

You still have issues of needing a JVM. The JVM is not a small runtime considation. I'm in the process of converting to GO since I have more time than money. 1 JVM in Docker uses 512 MB to sit still. A Go version is around 16.

Here is what Google did internally:

- Bundle all C/C++ native libraries, and link them all together with the java launcher - e.g you produce your own java.exe that has your C/C++ libraries linked in, then you slap the .jar file - for extra bonus you can slap at the back of your .exe and make it load from there

  Voila - you have single executable (almost) with all you need, and you don't need to unpack .dll's anywhere

  But... you must compile java.exe yourself...

Java is somewhat like chrome in that it pre-emptively gets some RAM, because it's managing memory allocation to programs itself. (and because the speed increase of not doing system-calls offsets some of the performance hits from running a JIT)

Is that 512 the lowest you can get it with command line options?

That was with Xmx set to 64 MB and a stack of 256k

Mostly FUD. You can easily tweak your min and max heap sizes. You can have an app that takes less that 512 megs of RAM.

> I think it’s funny to use java as an example when jar files have been around forever.

Jar files are not a self-contained, single binary (executable).

I can't

    curl -o binary http://example.org/binary
    ./binary

In reality, you can't do that with these either. You have to have the runtime installed before your example works.

It's really not much better than running a fat jar that contains all of its dependencies.

    curl -o binary.jar http://example.org/binary.jar
    java -jar binary.jar

This is more like a self-extracting shell script, but more opaque.

You might be right, but documentation says "self-contained".

How is it self-contained if it's not self-contained?

Reply on news.ycombinator.com