51–60 of 68 posts
"Since bundling apps and runtime is the new best-practice" When did this become the new best-practice in Java land?
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.
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 curio…
Earlier quoted context omitted.
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…
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
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…
Over the years I have wasted a lot of time reviewing or discussing "optimizations" that didn't help - or even hurt - performance. Micro-optimizing some once-off init function instead of tackling major per-frame overhead and stuttering. Creating a nice lean core site and then burdening it with a billion third party scripts requested by marketing.
30MB matters for a website, or keyboard firmware.
On the other hand, my gamedev workloads often crash on 32GB machines. I measure useful SSD sizes in TB. In that context, 30MB is line noise. A rounding error. You could spend a lifetime optimizing more important performance issues, and still never turn your attention to that 30MB as something useful to spend time reducing further.
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 curio…
With a JVM kept hot in OS cache, how many different JVM versions would you need to support apps made with different JVM versions?
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…
The fact of the matter is that quality simply does not matter in today's world. Not in software, not in hardware, not in food, clothing, cars, or basically any other area. It's all about minimizing costs.
"Since bundling apps and runtime is the new best-practice" When did this become the new best-practice in Java land?
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…
Try to make software good enough to sell, and that is quickly the obvious conclusion.
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. I…
>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.
The real issue is the GC is not as efficient.
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)?