Comment by SatvikBeri 3 days ago
I loved uberjars back when I was writing Scala. I don't miss much about the JVM, but I really miss having a single executable I could just upload and run without having to pay attention to the environment on the host machine.
Yeah, but building a docker image tends to be a lot heavier weight and slower, in my experience, than uploading a single jar
Heavier weight? Yes. Slower? Should be the same performance. Unless you are on a non-linux host, then there is no docker penalty.
The only time I can think where a JVM might be faster is if you have a multi-tenant setup. In that case, the JVM can be more effective with the GC vs having multiple JVMs running.
I didn't mean the application is less performant (indeed, it might be even more performant since there are more things we can tweak), but that the overall build + upload process is noticeably slower. I remember it taking <1 minute to rebuild + deploy an uberjar in 2016, and on an application of similar complexity today it takes somewhere between 3-15 minutes. Admittedly, this is a different company, language, and setup, so there are a lot of other potential differences.
Yeah, it'll be unrelated to docker.
Uberjars are (typically) extracting all the classes from jar dependencies and combining them into a single jar. That's all gzip compression work.
Container layers are simply saved off filesystem modifications. If you use something like Jib to build your image, then the actual deployable should actually be a lot smaller than what you could do with an uber jar. That's because Jib will put your dependencies in one layer and your application jar in another. Assuming you work like most everyone, then that means the only thing that usually gets transferred is your application code. Dependencies only get sent if you change them or the base image.
That's essentially the role docker serves now. Everything you need to run in 1 single image.