I’m trying to understand what you are after with the “single executable” part?
Self-contained. For the most part controversy I guess? :-)
Right. That controversy you may have. I guess we have rather differing interpretations of self-contained.
$ file start.sh
start.sh: POSIX shell script, ASCII text executable
$ file target/hprotostuffdb-rjre
target/hprotostuffdb-rjre: ELF 64-bit LSB executable
$ grep JAR start.sh
$BIN $PORT comments-ts/g/user/UserServices.json $ARGS\
$PUBSUB $ASSETS -Djava.class.path=$JAR comments.all.Main
$ objdump -p target/hprotostuffdb-rjre |grep RPATH
$ objdump -p target/hprotostuffdb-rjre |grep NEEDED
$ find . -name ‘*so’
I’m not even going into the rest of the jre scaffolding. I guess you could argue the stuff under comments-ts is not part of the “comment-engine”, but it’s there, and it (or something equivalent) is needed anyway. Admittedly, only two of the files in the entire package have the ‘executable’ flag set, so you can have half your cake if that’s the criteria for being self-contained :-)
Thanks for the detail response.
It was my way of showing people that jvm apps can have “golang-style” deployments where you ship a binary and run and be only 12MB (my production nginx binary is 14MB)
But realistically, if you have the jvm installed, the jar is only 455kb and that is only the one that needs to be shipped along with the 92kb js and 7.1kb css. That is how I deploy internally.
With golang, you do not have this choice.
Ah, so now I am starting to see the points that you are really trying to make.
Bundling of dependencies. I don’t think there’s much novelty to it; proprietary and floss applications alike have distributed binaries with bundled dependencies for a long long time. This includes many applications that bundle a jvm.
A jvm bundle can be reasonably small. Admittedly I haven’t paid attention to it, but I’ve had jvm bundles before, and I don’t recall them being outrageously large.
Calling it a “single executable” or self-contained might not be the best terminology to get the point across. Even more so when you consider that the executable also depends on many libraries that are not bundled; see objdump output above and compare to the list of bundled shared objects. Any one of these system libraries could go through an ABI change (in worst case one where existing symbols are removed or modified to work in an incompatible way, without symbol versioning…), and when that happens, your uhm.. self-contained single executable thingy won’t run right, or at all. It’s not just a theoretical concern, it’s something people using binary distributions of proprietary software (e.g. games) may have to feck with rather often.
I can’t comment on how this compares to golang deployments, which I’ve never used.
I understand your points and appreciate your comments. Cheers
Recent versions of go have additional build modes: https://golang.org/cmd/go/#hdr-Description_of_build_modes
Theoretically you could deploy your code as a plug-in.