Really Small Java Apps • Hacker News Board

Re: Really Small Java Apps

#21

Post by icedchai » Tue, Nov 05, 2019, 2:16 PM UTC

userbinator wrote: post #12

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 install…

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

Re: Really Small Java Apps

#22

Post by z3t4 » Tue, Nov 05, 2019, 2:21 PM UTC

sgt wrote: post #2

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 .j…

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)

Re: Really Small Java Apps

#23

Post by ngcc_hk » Tue, Nov 05, 2019, 2:23 PM UTC

Koshkin wrote: post #17

bluedino wrote: post #13

Earlier quoted context omitted.

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

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

Well support thousands of users using mvs. Only got 24 MB as well.

Re: Really Small Java Apps

#24

Post by lvh » Tue, Nov 05, 2019, 2:52 PM UTC

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.

Re: Really Small Java Apps

#25

Post by commandlinefan » Tue, Nov 05, 2019, 3:18 PM UTC

icedchai wrote: post #21

userbinator wrote: post #12

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 install…

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

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.

Re: Really Small Java Apps

#26

Post by commandlinefan » Tue, Nov 05, 2019, 3:20 PM UTC

sgt wrote: post #2

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 .j…

> bundles the JDK

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

Re: Really Small Java Apps

#27

Post by aabbcc1241 » Tue, Nov 05, 2019, 3:37 PM UTC

hyperpallium wrote: post #19

userbinator wrote: post #12

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 install…

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

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

Re: Really Small Java Apps

#28

Post by stuff4ben » Tue, Nov 05, 2019, 3:42 PM UTC

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?

Re: Really Small Java Apps

#29

Post by mhd » Tue, Nov 05, 2019, 3:51 PM UTC

userbinator wrote: post #12

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 install…

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

Re: Really Small Java Apps

#30

Post by tijsvd » Tue, Nov 05, 2019, 3:59 PM UTC

commandlinefan wrote: post #25

icedchai wrote: post #21

Earlier quoted context omitted.

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

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 comp…

That quote about premature optimization is from 1974. Back then, manually tweaking code to produce the "right" machine instructions really mattered. But it was time-consuming and hard, and hence should be applied only to the most time-sensitive part of a program.

Today, we get that kind of optimization, for the whole program, simply by adding -O2 to our build options, and waiting slightly longer for the compiler to complete.

Engineers using that quote are an important reason for the failure of software projects. Not only should we make efficient use of resources, but performance of software must be taken into account right from the beginning of any software project. Performance requirements must be clear from the start (how many concurrent users, how many requests per second, etc., times 2 (or 20) for safety) and when a design is made, performance requirements for each individual component should be set (and measured after implementation).