1. 6

  2. 2

    I’m trying to understand what you are after with the “single executable” part?

    1. 2

      Self-contained. For the most part controversy I guess? :-)

      1. 5

        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

        RPATH                $ORIGIN:$ORIGIN/jre/lib/amd64/server

        $ objdump -p target/hprotostuffdb-rjre |grep NEEDED

        NEEDED               libpthread.so.0
        NEEDED               libjvm.so
        NEEDED               libcrypto.so.1.0.0
        NEEDED               libssl.so.1.0.0
        NEEDED               libz.so.1
        NEEDED               libstdc++.so.6
        NEEDED               libgcc_s.so.1
        NEEDED               libc.so.6

        $ 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 :-)

        1. 4

          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.

          1. 4

            Ah, so now I am starting to see the points that you are really trying to make.

            1. 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.

            2. 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.

            1. 1
              1. Pretty much agree.
              2. A lot of ppl dismiss the jvm as bloated (in terms of size and runtime memory). I guess it all depends how one uses it (along with the knobs to tune). I run mine at 128mb memory max, and that could handle 130k req/s. My usage of the jvm is like a stored-procedure language though. All the heavy lifting is on the C++ libs that I’m depending on.

              I understand your points and appreciate your comments. Cheers

            2. 2

              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.