6 ms·

I love how the article shows an 11 MB Hello World as "stripped down" 2x improvement :-)

• nine_k 9y ago
  The VM + minimal stdlib is not exactly small. Also AFAICT it works the same on every major platform, that is, it's a fat binary. Not bad.
  • kevin_thibedeau 9y ago
    > Not bad. Unless you consider that basic support services are what the Java runtime should be providing on its own. Fundamentally, a command line Hello world should only take a few dozen bytes of bytecode.
    • oblio 9y ago
      Doesn't this bundle the VM/GC/etc. besides the bytecode?
      • paulddraper 9y ago
        Yes, it does.
    • kbsletten 9y ago
      The 11MB is (most likely) 11MB of the Java runtime (compared to 200MB for the full runtime which includes all the classes required by the standard library) + a few dozen bytes of bytecode.
  • zten 9y ago
    Plus, you can strip down the Java bytecode even further using ProGuard, but convincing it to not delete code that's actually used is an error-prone dark art.
    • kodablah 9y ago
      I've been hoping that a community project would come about to break java.base into smaller modules. Even if there are cross/circular dependencies, I wouldn't mind if many methods were stubbed out or just removed if I promised not to use them.
• cytzol 9y ago
  Yes, you can get smaller binaries using compile-to-native languages. But speaking as someone who had to install the JVM and our application on clients' computers, this is way better! You don't need to be the best to be good.
  • karussell 9y ago
    There is stuff in the works (heard this related to Graal I think) where Java will be a compile-to-native language.
    • dullgiulio 9y ago
      And like the real Graal, it existed and got lost: it was called GCJ, part of GCC.
      • wst_ 9y ago
        Kotlin and Scala native are on the horizon.
• pault 9y ago
  Still better than electron.
  • malkia 9y ago
    We've been counting the number of apps that use Electron at work (Windows machines) - ok, Microsoft Teams, Visual Studio Code, Slack, and few others! Now all engineers are "angry" :) :) :) after seeing the same process spawned multiple times, and taking lots of gigabytes!!! (hehee)... I simply don't care and love the Slack app! (Teams is also nice looking, and Visual Studio Code rocks)
• lomnakkus 9y ago
  Well, I mean on my Arch Linux system libc is ~2M, so that's not exactly trivial either. The only reason hello world can be so small is that all the stdlib code already exists on your system -- not so for Java[1]. Of course there are far smaller libc implementations, but they may be missing functionality. [1] Unless, of course you require an installation of Java... which would kind of go against the premise of this whole exercise.
  • blueline 9y ago
    unless you're statically linking the entire standard library, libc being 2M is irrelevant, no? you only pay for what you use if you dynamically link it.
    • fgonzag 9y ago
      so if the jvm is installed in your system, 11M out of the 11M in the example (since it includes the cut down jvm) is irrelevant? Then all you need for the example is a 1k .class file.
  • mitchty 9y ago
    Err, glibc is its own level of derp. Here, a fully static binary on linux with musl libc, designed for static linking unlike glibc. Note, this on 32 bit arm, size might differ on different arches, all I have access to off the cuff: # printf '#include <stdio.h>\n int main(int argc, char**argv) { puts("hi"); }' > /tmp/hi.c # make /tmp/hi cc -c -o /tmp/hi.o /tmp/hi.c cc /tmp/hi.o -o /tmp/hi # du -hs /tmp/hi 12.0K /tmp/hi # ldd /tmp/hi /lib/ld-musl-armhf.so.1 (0x7f5af000) libc.musl-armhf.so.1 => /lib/ld-musl-armhf.so.1 (0x7f5af000) # strip /tmp/hi # du -hs /tmp/hi 8.0K /tmp/hi # rm /tmp/hi # make LDFLAGS=-static /tmp/hi cc -static /tmp/hi.o -o /tmp/hi # du -hs /tmp/hi 92.0K /tmp/hi # ldd /tmp/hi ldd (0x7f5e3000) # file /tmp/hi /tmp/hi: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, with debug_info, not stripped ungh, go home ldd and file, you're both drunk and dead to me right now: # objdump -p /tmp/hi /tmp/hi: file format elf32-littlearm Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**16 filesz 0x00001f68 memsz 0x00001f68 flags r-x LOAD off 0x00002ea4 vaddr 0x00012ea4 paddr 0x00012ea4 align 2**16 filesz 0x00000204 memsz 0x00000798 flags rw- DYNAMIC off 0x00002eb4 vaddr 0x00012eb4 paddr 0x00012eb4 align 2**2 filesz 0x000000e0 memsz 0x000000e0 flags rw- STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4 filesz 0x00000000 memsz 0x00000000 flags rw- RELRO off 0x00002ea4 vaddr 0x00012ea4 paddr 0x00012ea4 align 2**0 filesz 0x0000015c memsz 0x0000015c flags r-- Dynamic Section: SYMBOLIC 0x00000000 INIT 0x00000468 FINI 0x00001f38 INIT_ARRAY 0x00012ea4 INIT_ARRAYSZ 0x00000004 FINI_ARRAY 0x00012ea8 FINI_ARRAYSZ 0x00000004 GNU_HASH 0x000000d4 STRTAB 0x00000250 SYMTAB 0x00000120 STRSZ 0x000000ee SYMENT 0x00000010 DEBUG 0x00000000 PLTGOT 0x00012f94 PLTRELSZ 0x00000018 PLTREL 0x00000011 JMPREL 0x00000450 REL 0x00000340 RELSZ 0x00000110 RELENT 0x00000008 BIND_NOW 0x00000000 FLAGS_1 0x08000001 RELCOUNT 0x0000001c private flags = 5000400: [Version5 EABI] [hard-float ABI] Note no NEEDED section, so we're indeed fully static. # strip /tmp/hi # du -hs /tmp/hi 16.0K /tmp/hi 16K for a fully static hello world sounds pretty decent to me vs 8k for dynamic. Will be faster than involving ld.so as well. I could probably improve that further, but I'm not about to golf this tonight.
• userbinator 9y ago
  At the far end of the scale, here is a 20 bytes Hello World, nearly 6 orders of magnitude smaller: https://www.gnostice.com/nl_article.asp?id=225 https://www.gnostice.com/nl_article.asp?id=225 The difference in abstraction level is amazing.