Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Really Small Java Apps

august.nagro.us

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Really Small Java Apps

#41

Post by tastyfreeze »

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…

Sure, the number one requirement is to get the job done. But, nobody that takes pride in their work is going to be satisfied with fat, slow code. Efficient code is a thing of beauty that takes time to craft. Unfortunately, our desire to make beautiful things gets crushed under the constant race to production of the next feature.

Re: Really Small Java Apps

#43

Post by NathanielLovin »

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

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

Re: Really Small Java Apps

#44

Post by sgt »

Longwelwind wrote: post #16
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…

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…

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

Re: Really Small Java Apps

#45

Post by sgt »

sz4kerto wrote: post #5
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…

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

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

Re: Really Small Java Apps

#47

Post by retbull »

gcbw3 wrote: post #42
chvid wrote: post #37

"Since bundling apps and runtime is the new best-practice" When did this become the new best-practice in Java land?

since the author internalized the AWS marketing message.

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

Re: Really Small Java Apps

#48

Post by dwild »

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…

> #1 complaint I hear from software _users_ is “damn, this thing is slow”.

I strangely hear that quite often too on morning traffic ;). When will theses real professional engineers will learn?!?!?!

> make the most efficient use of resources

Can you define this? Everything can be done more efficiently.

A real professional engineers won't do premature optimization. You won't see bridges using some amazing new carbon material, it's not only too costly for the budget, it's also not needed (the bridge does everything it has to do per the requirement).

A real professional engineers will do the most he can with the resource he has, which is pretty much what we do in software engineering.

Re: Really Small Java Apps

#49

Post by diroussel »

chvid wrote: post #37

"Since bundling apps and runtime is the new best-practice" When did this become the new best-practice in Java land?

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.

Re: Really Small Java Apps

#50

Post by zmmmmm »

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.

Post reply on HN