Hacker News Reader

Comment by jhh | Hacker News Reader

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 is quite heavy. See this article: http://www.ibm.com/developerworks/library/j-codetoheap/index...

3. The heavyness of the ecosystem in terms of the magnitude of concepts and tools being used and the enterprisy-ness of libraries.

View on HN

> 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs

Where do you get these numbers from? On my five year old MacBook Pro with default JVM options parsing a 20 MB file:

real 0m0.248s

user 0m0.325s

sys 0m0.043s

> 2. Memory usage of Java objects is quite heavy.

That's IBMs enterprise VM that uses three word headers. HotSpot is actually better. If you compare that with other "lightweight" programming languages it is really, really light.

> real 0m0.248s

A quarter of a second to start up the VM, run some code, and exit again is actually pretty steep compared to typical interpreted and compiled languages. Among other things, this means that you can't really call Java executables from a loop in a shell script.

For comparison purposes, both Ruby and Rust will show between "0.00 elapsed" and "0.02 elapsed" for a simple "Hello, world" program on my laptop.

That's just Hello World, though. He said his app was parsing a 20 MB file.

To do a fair comparison, with your example, I just compiled and ran Hello World in Java on my machine and got this:

real 0.06 user 0.06 sys 0.01

Here you go:

https://bitbucket.org/ewanhiggs/csv-game

The parent did write "parsing a 20 MB file". So not a hello world.

I'm not arguing with you, those are genuine problems, but there are a few projects in a pipeline to address a few of these things.

1. Startup time being addressed by precompiling the standard library (or your own library). See "JEP 295: Ahead-of-Time Compilation": http://openjdk.java.net/jeps/295. Also addressed by modularisation of the standard library, "JEP 220: Modular Run-Time Images".

2. Memory usage (and less garbage collection overhead) using value types. See "JEP 169: Value Objects": http://openjdk.java.net/jeps/169.

> 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.

While this is true in practice it can be hard. You don't always have control of what libs you are using and often finding lightweight alternatives to many libraries is hard to impossible. It is better once you get outside Java proper, but nearly all the alternative languages on the JVM tout access to the Java ecosystem as a plus which then brings back in all that pain.

> You don't always have control of what libs you are using

Well that's true regardless of the language. If you're not making the decisions on the codebase, there can be all kinds of gnarly dependencies and practices that you have to adhere to. I agree that big legacy corps tend to have over cumbersome setups, but hey, at least it's not cobol. My advice is not to work for big legacy corps.

But some languages have better cultures/eco-systems than others. Java has one of the worst.

Far from it IMO. It depends on which subculture you immerse yourself in. If you subscribe to the IBM/Oracle/Red Hat thought leaders, then yes - you'll encounter enterprisey stuff, because they're all targeting legacy corps.

Believe me that I know where you're coming from -- I have a real aversion the big enterprise side of the Java world. There's a lot of interesting development in Java open source though, and it'd be a shame to throw the baby out with the bathwater.

This is one thing I've never understood about Clojure - the Java interop. I actually love Clojure but I close my eyes to the fact that it requires an object-oriented VM to work its magic. Clojure is a functional Lisp based on immutable data structures which is about as far from Java OOP as it gets yet we're encouraged to mix Java objects and classes into our Clojure apps as if nothing matters.

Funny, when I code in Clojure there are these things called multi-methods, protocols and multiple dispatch.

I think it was originally designed in a Lisp library called CLOS, which incidentally stands for Common Lisp Object System.

Very nice explained on how to implement OOP in Lisp, in a book called "The Art of the Metaobject Protocol".

Users of Lisp based languages should think twice before criticizing OOP.

Users of Lisp based languages generally think about six times, on average, before criticizing OOP (each time).

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.

JHipster equivalent to Rails? You have to be joking, surely. I just setup a JHipster site and when I opened it up in IntelliJ it was the same labyrinthine mess I've come to expect from Java frameworks, ie. knee-deep in endless subdirectories and everything abstracted away to the point of incomprehension. Contrast that with the simplicity of Ruby and Rails. Java by its very nature makes it impossible to build simple, easily comprehended frameworks and apps. The trouble is that devs who have spent most of their lives in the Java ecosystem can only think relatively, ie. Java Framework X is simpler than Java Framework Y. Unless they expose themselves to something like Ruby or Clojure they will never experience true simplicity.

This is non-sense, something like Spring boot is easy to comprehend, there's no labyrinthine mess whatsoever. You've got the choice to use other simple frameworks like Spark, or plain libs like Jersey + Jackson. All in all it's still the same, you write your Controller, your services and that's it. Where is that complicated?

And I'm a big fan of Clojure, but it's not because Clojure is cool that Java becomes de-facto a big pile of poo. People have been drilled by so much FUD about Javaland that they simply can't stand to try it correctly without preconceptions.

I didn't say equivalent in general. I said equivalent in the Java world where we are more used to having to deal with bloat. Just free yourself from your preconceptions and run ./gradlew . Everything will start up fine, no mess, I promise.

> hiding complexity

This makes me shiver in terror.

Our job as programmers is to hide complexity and expose it when needed. Nothing to shiver about.

Spring Boot hides needing to deploy to an application server along with the extra configuration that entails, it doesn't hide Spring from you.

There's still a ton of "enterprise-grade" shit in Spring, you just aren't forced to use it if you don't want - but it's always there, lurking behind the scenes.

Startup time on my late 2014 MPBr for Clojure Hello World is indeed 1.29s, which is what the OP was measuring.

   $ time java -jar target/uberjar/clojure.jar
   Hello, World!
   1.29s user 0.08s system 181% cpu 0.755 total

   $ /usr/sbin/system_profiler -detailLevel full 
      Model Name: MacBook Pro
      Model Identifier: MacBookPro11,3
      Processor Name: Intel Core i7
      Processor Speed: 2.3 GHz
      Number of Processors: 1
      Total Number of Cores: 4
      L2 Cache (per Core): 256 KB
      L3 Cache: 6 MB
      Memory: 16 GB

It is Clojure. It loads an additional runtime by itself. It is unfortunately not usable for CLI applications. Pure Java does the same thing in fraction of time. http://blog.ndk.io/jvm-slow-startup.html

4. Garbage collection. The fact that Java does not have a refcount collector, that can release memory back to the process's pool as soon as something goes out of scope and is no longer referenced, is horrid. Nearly every major software written in Java goes through the worst kind of struggle wherein users have to assign a 4 GB heap size to run a service that only really needs 500 MB. When fatal Out-Of-Memory crashes are the status quo, something is very very wrong.

I'm sorry to call out this comment specifically, but almost everything you said here is not true. Out-Of-Memory crashes are not the status quo. The JVM garbage collector is (generally) a very high performance system that has improved incredibly over the past decade, it's not as simple as saying it's missing reference counting so it's "horrid".

These are the kind of lazy generalization that causes people to make poor technology decisions.

These points are true in my experience (EDIT: 1.5 startup time sounds like too much) and they are enough to debunk the claim "The JVM is not that heavy". I hadn't ever heard anybody considering disk consumption or installation time before, when making that claim.

To add,

4. Garbage collection and lack of value typed records. As far as I know there is currently no way around going full SOA (structures of arrays (of primitive types)) for large data collections.

Object overhead (memory usage) and GC overhead are the reason why only SOA will work (and it's a pain because the language doesn't make it convenient) if you have like >10^7 objects. (That's my personal experience from a 2-month project, and I normally don't use Java).

> As far as I know there is currently no way around going full SOA

There are if you use language extensions like Packed Objects on the IBM JVM or Object Layouts on Azul.

So just like C, you have C and then GCC C, clang C, ....

Eventually Java 10 will fix this, but for those that like to live on the edge there are already snapshots available.

> Object Layouts on Azul.

https://objectlayout.github.io/ObjectLayout/ does not save you any headers. It just allows you to control where your objects are in memory and compiler optimizations based on this. It does not help you with memory footprint.

Also I'm not sure if it's really implemented on Zing considering that from the outside the project seems dead.

> Eventually Java 10 will fix this

I would not be so sure. The challenges especially regarding primitive generics are not to be underestimated. See

http://cr.openjdk.java.net/~jrose/values/shady-values.html

> It just allows you to control where your objects are in memory and compiler optimizations based on this. It does not help you with memory footprint.

It is already better than what you get on Hotspot.

> The challenges especially regarding primitive generics are not to be underestimated. See

The challenge here is due to how Java designers to build them in first place.

Modula-3 and Eiffel are two examples of languages with proper generics, value types and toolchains that do AOT compilation to native code.

So I am still hopeful.

However, like everything, some challenges are technical and some are political.

1.5 secs for the jvm only seems excessive.

$time java HelloWorld

Hello, World

real 0m0.071s

user 0m0.053s

sys 0m0.020s

That is a linux vm running in a mba (first run).

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.

I agree that my claim is false. I kind of wrote that from the top of my head.

In any case, the point that I wanted to make in the parent comment was that the JVM startup time itself was basically fine.

I just checked on my Macbook and a HelloWorld class gives me .13 secs real.

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.

In my mind, 1½ seconds is huge; that essentially rules out any interactive usage. It's even annoying for rapid development cycles. Only low expectations or heavy orchestration can overcome such a startling disadvantage.

It rules out any interactive usage where you are starting and stopping the jvm, like in a command line context.

There are work arounds for this (things that reuse jvms and such) but until that is overcome the jvm is largely not appropriate for cli tools that start/stop.

But for other kinds of interactive programs, things with long running sessions and such, it is pretty easy to a) lower that startup time and b) do things that mitigate it to the user.

I've always thought it'd be nice to build a sort of hybrid between a "ClojureScript for bash", and a Java boot-script + RPC client.

Picture a Clojure macro library just for writing CLI driver programs, where you could call all your Clojure code like normal, and where some of the subcommand-defining methods of the driver program could be annotated with something like "@inline".

The un-annotated subcommands, as a simpler case, would translate into calls to spawn a JRE and feed your ARGV over to it once it gets running. These would be the slow-startup calls, so you'd just use them for the things that need the full "horsepower" of the JVM.

The @inline subcommands, on the other hand, would grab your app, its deps, and the JRE, do a whole-program dead-code-elimination process over them to trim them down to just what that subcommand needs, and then would transpile that whole resulting blob to bash code and shove it into a bash function. (So, something like Emscripten with a different frontend + backend.)

That's completely false in the context of a Lisp.

I boot the JVM once and iterate endlessly in the same process. Same for ClojureScript in the browser or node.js. Lisp is by far the most interactive language there is with the fastest iteration times (AFAIK).

1.5 seconds would be huge if you had to constantly restart your application like you do everywhere outside Lisp. Iterating in Clojure is literally instant.

I wrote applications in dozens of languages, and none come remotely close to Clojure's iteration speed or joy of use.

Lisp is by far the most interactive language there is with the fastest iteration times (AFAIK).

That's Forth. Lisp comes next.

if you had to constantly restart your application like you do everywhere outside Lisp.

This was probably true in the 80s, but hasn't been in a while. Many languages have this, either built-in or as a tool. In the case of the JVM, there's spring-loaded, which works in Java, Groovy, etc.

That 1.5 seconds is FUD anyway.

1.5 is huge, except it is completely wrong. JVM startup time is within fraction of the second.

You are right, I was just going with what the grandparent said. But I think with normal amounts of class scanning and other overhead, 1.5 seconds becomes the practical normal.

Certainly the JVM startup always feels slow, in my experience.

Well, if you create a lot of additional objects on startup then it will take some time. JVM startup is still fast. http://blog.ndk.io/jvm-slow-startup.html

That links says 1.2 seconds for a hello world! 1.2 microseconds is what I would expect to be called fast.

1.2 seconds was hello world in clojure, the Java hello world presented the numbers below, so it's mostly clojure that is slow:

$ time java Hello Hello world 0.04user 0.01system 0:00.12elapsed 43%CPU (0avgtext+0avgdata 15436maxresident)k 29672inputs+64outputs (82major+3920minor

While 120ms elapsed is not stellar, it's rarely a problem with how the JVM ecosystem looks.

That's clojure, not java. JVM startup is much faster.

Please be kind to reread it.

Startup time of a simple Java application and therefore also whole JVM is 0.4s (in the linked article).

1.2s is for the implementation in Closure that includes its additional quite heavy runtime.

I read it fine, but Clojure is an application of the JVM. The fact that a popular interpreted language of the JVM takes 1.2 seconds for hello world is a problem of the JVM itself, or at least it's ecosystem. An interpreted language in C wouldn't take nearly that long.

The way an interpreter is implemented and the language it runs on don't have anything to do with each other.

A Clojure interpreter written in C, if written the same way as for Java, it would run just as slow, given the way it is building Clojure every time the application starts.

On my old ThinkPad X201 with HDD and 8GB of RAM, running Fedora 25 and Gnome 3 I can start vanilla WildFly 10.1 in less than 10 seconds, http://imgur.com/a/BCDNP:

    20:43:44,578 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) started in 6551ms - Started 331 of 577 services (393 services are lazy, passive or on-demand)

Not too shabby IMHO.

There's that word again "enterprisey".

Reply on news.ycombinator.com