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

291–300 of 373 posts

Re: The JVM is not that heavy

#291

Post by alimbada »

frant-hartm wrote: post #282
nikcub wrote: post #261

Microsoft seem to have learned a lot from Java in designing their new .NET Core CLR. It has gotten almost everything right: * a small and fast CLR (JVM) * a class library that defaults to almost nothing but primitive classes * proper and standardized version, platform and package management (NuGet) * open source and MIT license[0] * a patent promise[1] * arguably the best dev IDE available (Visual Studio) and one of…

I could more or less agree with most of it apart from > arguably the best dev IDE available (Visual Studio) and one of the best up-and-coming dev text editors (VS Code) https://www.jetbrains.com/resharper/documentation/comparison... Refactoring, Coding assistance, Navigation & search sections being most important.

Although the last version I used seriously was VS2013, VS on its own is pretty mediocre. With ReSharper though, nothing beats it in my opinion.

On the other hand I've been using Eclipse and IntelliJ for the past year. Eclipse is not even worth talking about but even IntelliJ does not come close to vanilla VS in terms of usability. Again, my opinion.

Re: The JVM is not that heavy

#292

Post by mirekrusin »

gregschlom wrote: post #60
derefr wrote: post #41

Earlier quoted context omitted.

> I wrote a simple tool that allows you to filter out what you don't need It'd be a short hop from here to a tool that basically does for JDK-platform apps what Erlang's releases do for the ERTS platform: builds a new JRE (as a portable executable, not an installer) that actually contains the app and its deps in the JRE's stdlib, such that you just end up with a dir containing "a JRE", plus a runtime "boot config" fi…

Funny you mention that, that's exactly why we wrote this tool. We were having a ton of support issues with our Windows users having to install Java, incompatible Java versions, needing admin privileges to install the JRE, etc... We fixed this whole class of issues by doing exactly what you suggest: bundling the JRE and writing our own launcher binary.

Does java license interfere with this kind of setup?

Re: The JVM is not that heavy

#293

Post by monodeldiablo »

d_burfoot wrote: post #67
jhh wrote: post #13

I agree with many points in this article. That being said, there are dimensions of heaviness not captured in the article as far as I can see: 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs, but the startup time of your application gets higher if you have a lot of classes on the classpath. I guess it's the classpath scanning that takes a lot of time (?). 2. Memory usage of Java objects i…

Did you test that 1.5 second claim yourself? I literally just wrote a HelloWorld and ran it on my MacBook, the total time for the whole program was <0.2 seconds.

To be fair, 0.2 seconds is still ludicrously long. I can literally say the output of the program in less time than the runtime can.

Re: The JVM is not that heavy

#294

Post by rahilb »

I wish I was as good as the developers commenting how slow java is to start. They are clearly on a higher plane of enlightenment where 1.5 seconds to start ruins their day, their deployment process, and development cycle.

More power to them.

Re: The JVM is not that heavy

#295

Post by monodeldiablo »

jwr wrote: post #285
Jeaye wrote: post #157

Earlier quoted context omitted.

In production, what matters is the ridiculous memory usage. Both Java and App Engine are to blame about this, but the Python and Go folks aren't running into the same issue.

Well, I don't know what you consider "ridiculous", but I run a web/application server with significant complexity (written in Clojure) in a 2GB RAM VM, with the JVM taking up about ~800MB. I'd say that's pretty reasonable and it meets my production/business needs.

Considering that RAM is the primary cost in hosted environments, I'd say that 800MB is anything but reasonable. In fact, as a guy coming originally from a non-Java background, that seems downright opulent. Perhaps that's fine if it's the only thing running on that machine, but is that very realistic? A database, some daemons, cron jobs... It seems uncouth to me that the business logic should take up as much RAM as the data itself.

I run a fairly complex Clojure app and it uses 1.5GB of RAM all told. Factor in cron jobs, caching, DB flushes and other periodic spikes on the machine and whoops! we're over 2GB used. To prevent thrashing and OOMEs, I sized up to a 4GB VM, doubling my monthly costs (there are several of these boxes).

Now yes, I can go through and swap out libraries to slim the beast down. But that would mean rewriting large chunks of it, since so few Clojure libraries are interoperable and most simply wrap "enterprisey" (and heavy) Java libraries in sexier syntax. And if I'm rewriting it, I might as well avoid the whole mess and pick an ecosystem with a more streamlined standard library.

It's tough. I adore Clojure, but the combination of Clojure+JVM has made deployment and management less fun and more expensive than necessary. The JVM is awesome, but, just as it's not the hog so many claim it is, it's also not sleek.

Re: The JVM is not that heavy

#296

Post by hashhar »

derefr wrote: post #41
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 wrote a simple tool that allows you to filter out what you don't need It'd be a short hop from here to a tool that basically does for JDK-platform apps what Erlang's releases do for the ERTS platform: builds a new JRE (as a portable executable, not an installer) that actually contains the app and its deps in the JRE's stdlib, such that you just end up with a dir containing "a JRE", plus a runtime "boot config" fi…

.NET Core does have this and allows distributing the runtime, your classes as a standalone executable. It is obviously larger than just the class files and dlls but works great for portability.

Re: The JVM is not that heavy

#297

Post by geodel »

nikcub wrote: post #261

Microsoft seem to have learned a lot from Java in designing their new .NET Core CLR. It has gotten almost everything right: * a small and fast CLR (JVM) * a class library that defaults to almost nothing but primitive classes * proper and standardized version, platform and package management (NuGet) * open source and MIT license[0] * a patent promise[1] * arguably the best dev IDE available (Visual Studio) and one of…

> I feel that if Android were being developed today, they'd almost certainly take .NET Core as the runtime.

If it were to develop today as against raising against time(Apple) then Google would have written their own runtime and everything.

Re: The JVM is not that heavy

#298

Post by coldpie »

nikcub wrote: post #261

Microsoft seem to have learned a lot from Java in designing their new .NET Core CLR. It has gotten almost everything right: * a small and fast CLR (JVM) * a class library that defaults to almost nothing but primitive classes * proper and standardized version, platform and package management (NuGet) * open source and MIT license[0] * a patent promise[1] * arguably the best dev IDE available (Visual Studio) and one of…

> * all platforms are equal citizens

This may be true for the Core CLR specifically, but it's not true of real .NET apps that are being built today. The vast, vast majority are strongly tied to the Windows platform, especially because of the lack of a cross-platform GUI like you mention. As a Wine developer, it's a huge pain in our side because we either have to run the entire .NET virtual machine, which is hard, or depend on Mono, which is by design not completely compatible. This results in really souring my opinion of .NET and .NET applications when compared with win32 applications that do tend to work quite well in Wine.

Re: The JVM is not that heavy

#299

Post by simonh »

geodel wrote: post #297
nikcub wrote: post #261

Microsoft seem to have learned a lot from Java in designing their new .NET Core CLR. It has gotten almost everything right: * a small and fast CLR (JVM) * a class library that defaults to almost nothing but primitive classes * proper and standardized version, platform and package management (NuGet) * open source and MIT license[0] * a patent promise[1] * arguably the best dev IDE available (Visual Studio) and one of…

> I feel that if Android were being developed today, they'd almost certainly take .NET Core as the runtime. If it were to develop today as against raising against time(Apple) then Google would have written their own runtime and everything.

But then when Android was initially developed and acquired by Google Apple wasn't in the phone business at all, so the base architecture was already laid down long before the race started.

Re: The JVM is not that heavy

#300

Post by geodel »

pjmlp wrote: post #242
radicalbyte wrote: post #223

Earlier quoted context omitted.

The problem with visiting that site is that Oracle have started litigating against users of their JVMs. In that way the JVM can be "heavy".

With users that use commercial features without paying for them. It is quite easy to know which features those are when they require a flag named -XX:+UnlockCommercialFeatures , you just don't use them by mistake.

Oracle gives free license to use commercial features in development[1] in section B. It is very easy to some script for JVM startup parameters and get that script deployed in production by mistake.

1. http://www.oracle.com/technetwork/java/javase/terms/license/...

Post reply on HN