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

The JVM is not that heavy

opensourcery.co.za

Post reply on HN
Print view View original

171–180 of 373 posts

Re: The JVM is not that heavy

#171

Post by gregschlom »

deepsun wrote: post #146
gregschlom wrote: post #25

Also worth noting that the JVM itself only weighs a couple of megabytes. The bulk of the size comes from the Java runtime (ie: the "standard libraries"), and there are lots of things that your app may not need there (XML parsing, serialization, etc...) A couple of years ago I wrote a simple tool ( https://github.com/aerofs/openjdk-trim ) that allows you to filter out what you don't need. We were able to get the size…

Proguard is de-facto standard for Android Java ecosystem, what's the difference OpenJDK-Trim has? Except that Proguard determines used/unused classes automatically, by doing static code analysis, so you need to have proguard config to omit removing stuff that is used dynamically, of course.

We were already using Proguard for obfuscation and we tried to use it to reduce the size of the JDK as well. If my memory serves well the main problem was that the results weren't good enough results because Proguard was being conservative and keeping a lot of stuff that we know we didn't need, but static analysis indicated that it could potentially be used.

Also, Proguard's config is pretty complicated and the results are hard to understand. Our approach (openjdk-trim) is dumb simple: unpack the java runtime jars, use rsync to filter out entire directories we don't need, pack it back.

It's a simple, brute-force approach compared to Proguard's advanced static analysis, but in this case it gives better results. Maybe a good example of "worse is better".

Re: The JVM is not that heavy

#172

Post by bjoernw »

snuxoll wrote: post #147
flavor8 wrote: post #37

Earlier quoted context omitted.

> The heavyness of the ecosystem in terms of the magnitude of concepts and tools being used and the enterprisy-ness of libraries. You don't have to use the enterprisey libraries though. Using Dropwizard, for example, gives you a tight and performant set of libraries that have a fairly minimal learning curve and require relatively little boilerplate.

I mean, even the "enterprisey" stuff like Spring Boot is more than fast enough. I have a little REST service I just deployed to production today, 5 seconds to start up on my laptop's SSD (unfortunately it took about 50 seconds in production because our SAN is dog-slow for some reason).

How is Spring Boot "enterprisey"? It makes modern java programming simpler and more accessible by hiding some of the unnecessary complexity. It enables things like https://jhipster.github.io/ which to me is the Rails equivalent in the java world.

Re: The JVM is not that heavy

#173

Post by bjoernw »

linkmotif wrote: post #19

This interview with Bob Lee is really interesting on this topic: https://www.infoq.com/interviews/lee-java-di . Apparently, Square was first built out on Ruby with the mindset that the JVM is an old clunker. Fast-forward a few years they switched to the JVM because it was faster and the language (I know, not related) provided compile-time safety.

Same with Twitter. Remember the Fail Whale? Those were the non-jvm days before they ran ruby on the jvm.

Re: The JVM is not that heavy

#174

Post by gregschlom »

geocar wrote: post #144
gregschlom wrote: post #25

Also worth noting that the JVM itself only weighs a couple of megabytes. The bulk of the size comes from the Java runtime (ie: the "standard libraries"), and there are lots of things that your app may not need there (XML parsing, serialization, etc...) A couple of years ago I wrote a simple tool ( https://github.com/aerofs/openjdk-trim ) that allows you to filter out what you don't need. We were able to get the size…

I don't know. 10MB still sounds really too big. Why is it so big? What do we gain? I don't have a system with 10MB of cache, so I imagine Java can't run faster than memory...

10MB for a platform that allows you to run code on all three major operating systems without too much trouble and in a performant way is a huge win, in my opinion. Not many alternatives come close to that.

Re: The JVM is not that heavy

#175

Post by flavor8 »

realusername wrote: post #159
flavor8 wrote: post #40

Earlier quoted context omitted.

Which tooling specifically? Going from Java to Python a couple years ago I was in shock about how immature the tooling in the Python world is by comparison.

I also hate the Java tooling as well personally, it's my #1 complaint with the language and one of the reason I avoid it. I would say that nothing really follows unix principles and seem over-engineered, everything is quite complex to grasp to become proficient.

Which specifically? I'm curious which tools you object to.

Re: The JVM is not that heavy

#176

Post by nostrademons »

martingxx wrote: post #110
brianwawok wrote: post #96

Earlier quoted context omitted.

> aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to run in AWS. This is the easy trap to fall into though. What if you aggressively rewrote the Java apps from crappy legacy frameworks to well developed Java apps? A rewrite ALMOST always is faster. So the new language seems faster. Except if you would then rewrite the rewrite back in the original languag…

These apps are mostly microservices and the Java ones are mostly only a year or two old. None of them use things like spring. Some use Dropwizard. Would you consider dropwizard modern? If not, what would you use instead?

Take a look at the TechEmpower benchmarks:

https://www.techempower.com/benchmarks/

DropWizard is modern, but it isn't fast. Go and even Node.js are significantly faster. If you want performance, you cut layers out of the stack - check out the numbers for raw servlets or even just straight Jersey annotations in that benchmark. If I were doing JSON-over-HTTP microservices in Java, I'd likely use straight Jersey + Jackson, or if performance was really a problem, Boon over straight servlets.

What framework did your Go rewrite use? The standard libs?

Re: The JVM is not that heavy

#177

Post by Macha »

rev wrote: post #48
outworlder wrote: post #18

Interestingly, the author does not touch startup times. Frankly, for server-side loads, no-one cares how much your runtime weights, be it disk space, download size and even memory (heck, my last project required developer workstations with at least 96GB). There are all sorts of environments where that matters. And that's one of the reasons why Clojure didn't catch on on Android.

Wow, 96GB of RAM? I don't even... Would you care to elaborate?

We have applications that require 100GB of RAM to run.

The result being that they're not run locally. At least we have alright tests.

Re: The JVM is not that heavy

#178

Post by mahmud »

dvlsg wrote: post #94
jjtheblunt wrote: post #88

Earlier quoted context omitted.

Isn't that _exactly_ what GoLang does for its binaries, insofar as shipping them statically linked?

dotnetcore has it as an option, as well.

It's called "treeshaking", and is a classic option in Lisp delivery tools.

Re: The JVM is not that heavy

#180

Post by Macha »

lmm wrote: post #152
ohstopitu wrote: post #74

Just out of curiosity: If you decide to use Java (or any other languages that run on JVM), are their 3rd party libraries as "nice" (read: as many) as npm?

Yes. Maven has been doing package management right for years (and avoids the wasteful repetition that node does, that can often hide silent incompatibilities until runtime).

If you're building jars with a classpath on the filesystem, maybe.

If you're building wars, fat-jars or anything else that gets you to that "single jar deployment" which is often mentioned as a pro, you're definitely not immune to duplication. Especially when you get to libraries that have changed their package name over the year like say jackson.

Post reply on HN