Really Small Java Apps

http://august.nagro.us/small-java.html

by goranmoomin • 7 years ago

194 64 7 years ago

august.nagro.us

sgt3• 7 years ago

I get Docker and I use it, but it does bother me that one bundles the JDK along with the docker image. Such a waste of space. I like this idea, I hope it gets more traction.

In terms of deployment of Java apps, we've found that Nomad works really well as it doesn't need a full Docker image (or equivalent) like Docker, Kubernetes etc. In Nomad you just make sure the worker node has the JDK, and then you specify the .jar file in the job.

mzi• 7 years ago

That's not the whole truth, though. If you don't tweak chroot_env in the client settings you get a whole copy of /lib, /lib64, /sbin, /usr and some other things in each allocation. So less network traffic, but uses more real estate.

sz4kerto• 7 years ago

Docker images are layered, so this isn't a problem in most cases.

jacques_chester2• 7 years ago

Cloud Native Buildpacks take advantage of this to isolate a JRE or JDK to its own layer for fast rebasing and high reuse[0].

[0] https://github.com/cloudfoundry/java-cnb

sgt3• 7 years ago

Yeah I meant the container i.e. the end result, not the actual image. I'm aware of layered images.

taude• 7 years ago

I don't see what the issue is with space/size having the JDK in a docker issue layer vs installing through ansible/chef later (or whenever it is you're doing). Docker images are layered, and by including a pinned version of the JVM that's baked into a core Docker stack for your org that's been security hardened, tested, etc, seems like it's better than taking the time to install a JVM every time during deployment of the worker node.

EDIT: checking out Nomad now, since we have used other Hashicorp prods in the past...

Longwelwind• 7 years ago

I'm not sure this is the issue you are referencing, but you can use multi-stage Docker image builds to avoid bundling the JDK in the final Docker image:

  FROM openjdk:jdk AS build
  
  COPY . .
  RUN mvn package

  FROM openjdk:jre

  COPY --from=build ./somepath/app.jar .

  CMD java app.jar

The first stage (defined by the first FROM) is only used to build the ".jar", the second stage will only contain the JRE and the ".jar" copied from the first stage.

dashwav• 7 years ago

Anything after Java 9 would have to use the jlink method, as with the new modules system, there is no longer a distinction between the JDK and JRE.

The problem is most 3rd party libraries aren't ready for the modules switchover, so for anyone using those libraries, you are stuck with having either a 3-400mb docker image or using jlink

sgt3• 7 years ago

Sorry, I didn't intend to write "image", but rather container. I can no longer edit my comment.

z3t4• 7 years ago

The underlying file system might be able to dedupe the data. I remember playing around with linux containers and ZFS, where the base image was a snapshot, so only the changes to the base image take up hdd space. With modern solid state disks able to read several GB per second and with 1TB capacity, and Gbit Internet, i do not worry much if the app itself is 300MB big. If you skip the GUI the app should be fairly small - even when statically linked, then I use Linux namespaces for isolation, so no need to ship the entire OS with the app (which is a bit absurd imho. I wonder how many containers run old OS and risk container escape that would end up with root on the host, or the unnecessary extra virtualization layer killing the performance)

commandlinefan2• 7 years ago

bundles the JDK

Not being pedantic, honestly - do you mean the JDK (which includes the compiler) or the JRE (just the VM)?

manojlds• 7 years ago

Is GraalVM a good option for this?

hmottestad• 7 years ago

Yes and no. Graal Native Image doesn’t work for spring, since some of the jvm functionality wrt. class loading don’t work yet (I think). Also native image has lower throughput due to the lack of profile driven code optimizations.

argonium• 7 years ago

More info on Spring support for GraalVM native images: https://github.com/spring-projects/spring-framework/wiki/Gra...

jacques_chester2• 7 years ago

The Spring team and Graal folks are working on full support. I believe the main angle is to ensure the annotation-based model will work smoothly[0]. Another is to introduce a fully-functional model (Spring Fu/Kofu [1]).

Bear in mind, a lot of what Spring -- Spring Boot in particular -- gets charged with is beyond its control. It's an entrypoint to the vast Java ecosystem, much of which is also incompatible with Graal native images at the moment.

[0] https://github.com/spring-projects-experimental/spring-fu

[1] https://github.com/spring-projects-experimental/spring-graal...

userbinator2• 7 years ago

I thought this article would be about something like https://en.wikipedia.org/wiki/Java_4K_Game_Programming_Conte... but it's more appropriately "Really Small JVM".

For a simple project requiring java.net.http, using these steps produced a 23MB jlink image

23MB may seem tiny today, but depending on what that "simple project" does, in absolute terms it's still twenty-three million bytes. For comparison, a full installation of Windows 3.11 is roughly that size too, not compressed. As the saying goes, "there's still plenty of room at the bottom."

bluedino• 7 years ago

To be fair, Windows at that time was a pretty simple 16-bit operating system, and didn't even support networking until you added Winsock or WFW 3.11.

It didn't really support much of anything until you started adding lots of other DLL's and libraries

Koshkin• 7 years ago

Well, simple or not - the first UNIX needed 24 kilobytes of RAM. (Not sure about the disk space - probably 10x that if you count all the utilities.)

thrower123• 7 years ago

That'd be 16 floppy disks, or roughly a quarter of the hard disk space on my first PC clone. Or nearly ten Dooms!

hyperpallium• 7 years ago

Things That Turbo Pascal is Smaller Than https://prog21.dadgum.com/116.html

aabbcc1241• 7 years ago

This reminds me how small programs written in Red/Rebol/Lisp are in general: https://www.red-lang.org/

NathanielLovin• 7 years ago

The wikipedia page for Turbo Pascal, at 43,234 bytes, is bigger than Turbo Pascal

icedchai• 7 years ago

It is remarkable how bloated modern software is. My first hard drive, back in 1988, was 30 megabytes.

commandlinefan2• 7 years ago

If you start talking to most programmers about efficiency, you’ll almost immediately be shut down with “premature optimization is the root of all evil” (no matter how non-premature the optimization might be). There’s a pervasive belief among programmers that hardware is so fast that, as long as the software works, it doesn’t matter how efficiently it uses memory, or CPU, or disk space, or the network… yet the #1 complaint I hear from software _users_ is “damn, this thing is slow”. I yearn for a day when we start behaving like real professional engineers and strive to make the most efficient use of resources.

mhd• 7 years ago

Yes, I remember when people suddenly started writing win32 programs in assembly, as a backlash against the bloat of MFC etc. (and maybe because there was a bunch of non-PC assembly programmers switching?)

One interestin aspect of this is that we're going a bit back to Lisp/Smalltalk images in the mainstream, bundling runtime and code. (With few of the former's benefits, of course.) Has been done with scriptings apps, of course (Python, Perl, Tcl's Starkits), but with Java and Electron it's bound to have a wider audience.

Maybe because we can't complain about size/complexity issues anymore, now that something even more complex is common (code+runtime+wholefrigginoperatingsystem).

ComputerGuru• 7 years ago

23 megabytes does not seem, by any metric, “tiny” to anyone that I work with.

aasasd• 7 years ago

I thought it would be about sim cards and other smart cards.

jcollins• 7 years ago

I've found a combination of Spring Boot executable jar + a small jlink built JRE runtime packaged next to the executable jar works fairly well.

Our zipped distribution is 50mb. Uncompressed the executable is 26mb and the runtime is 75mb.

I'd love for it to be smaller but I can't complain. This also makes solving for Linux, macOS, and Windows pretty trivial. They each get their own zip with packaged runtime.

jwhitlark• 7 years ago

This seems to be about the sweet spot that I keep finding, although I normally work in clojure.

lvh• 7 years ago

GraalVM native-image is not a listed option, but I regularly use it to produce binaries that are competitive with (often better than) Go in terms of size and (start time) perf.

A Clojure tool that parses, traverses and processes JSON (caro, see below) worked out to 3.2MB. I'm sure C and Rust can do better, but it's not bad compared to a JVM, and it's an order of magnitude better than the best option in the article. It's also small enough that while comparisons like "that's three floppies!" are interesting historical perspective, you can't reasonably complain about having a 3 MB binary in ~/.local/bin.

Examples:

https://github.com/latacora/wernicke/releases https://github.com/latacora/recidiffist-cli/releases https://github.com/latacora/caro/releases

It mostly works out of the box. My biggest frustration is that you can't easily link in dynamic libraries, which makes it a little annoying to do e.g. EC TLS with a single binary. (Go would have a similar problem but sidestepped it by reimplementing most of it natively.) Second biggest frustration: it is not a fast compiler. You're definitely doing development on the JVM (I use Graal as my default JVM now) and a "production build" afterwards with native-image.

vips7L• 7 years ago

I regularly use it to produce binaries that are competitive with (often better than) Go in terms of size and (start time) perf.

How do they compare to go in terms of speed? Another comment also said graal native images still suffer with throughput vs using the jvm due to profile guided optimizations.

chrisseaton2• 7 years ago

It's still optimised native code - it's not like they're running in an interpreter.

The real issue is the GC is not as efficient.

stuff4ben• 7 years ago

Interesting to see this as I didn't know it was so simple to compile the JDK these days. But curious how this compares to Quarkus (https://quarkus.io/) which is built upon GraalVM?

nobleach2• 7 years ago

I keep a close eye on quarkus.io. I love what they're doing for the Java ecosystem. It's interesting to see other frameworks follow suit (Micronaut, etc)

crazysmoove• 7 years ago

Micronaut predates Quarkus by almost a year, but they both seem to be great frameworks.

chvid• 7 years ago

"Since bundling apps and runtime is the new best-practice"

When did this become the new best-practice in Java land?

gcbw3• 7 years ago

since the author internalized the AWS marketing message.

retbull• 7 years ago

I mean AWS has driven a lot of developer practices in the last 10 years. Not a terrible bandwagon to jump on.

diroussel• 7 years ago

Since people tested on one JVM version and ran production in another. Finding that gives unpredictables results people moved to linking the versions together. And then the next natural step is distributing the runtime and the app together.

Note this was not possible in the past as the java license prohibited redistribution.

javagram2• 7 years ago

After OpenJDK 8 the separate JRE was deprecated.

The recommendation now is for app developers to include their own JRE with the app; just like how each electron app includes its own copy of chromium.

chrisseaton2• 7 years ago

Since mid 2017 when the JRE was discontinued. How else are you shipping Java apps? With the JDK? That’s for developers.

malkia• 7 years ago

Hmmm.. Makes me wonder if this could help bazel slim down even more (although it's very acceptable size right now).

zmmmmm2• 7 years ago

It's an interesting turnaround. Once upon a time all the thinking was that you should pile as much into shared DLLs and common runtimes as you can, because those things will almost certainly be kept in the cache and will be much faster to launch / lower overhead.

Now not only is it becoming "best practice" to bundle your whole runtime with your app, people are bundling the whole operating system via Docker.

I'm curious if people have compared actually using a single JVM that is kept hot in OS cache vs separate minimal packaging for every app. It might favor single packaging if you only run 1 java app, but if you ran 10 different ones the benefits of shared code might win.

a3n• 7 years ago

With a JVM kept hot in OS cache, how many different JVM versions would you need to support apps made with different JVM versions?

zmmmmm2• 7 years ago

Ideally one, maybe two? An LTS and a current version?

Really Small Java Apps

Related Stories