Hacker News Reader

Comment by hippich | Hacker News Reader

Whenever I hear "Java" I also get association "slow". But looking into this list - java web frameworks doing incredible job!

View on HN

Java gets that wrap from originally being slow to execute, and also having a huge up-front cost to spin up a VM.

The first isn't true any more: the Java VM competes with native code on most benchmarks, and due to its ability to perform runtime optimizations, can occasionally outperform native code.

The second doesn't matter at all for web servers. The cost of starting up the web server is tertiary to uptime and performance. If the thing is going to run for 4 months without going down, who cares all that much if it takes 5 seconds or 5 ms to start up?

I agree with everything you've said here, but I'd like to add something about startup time.

If it takes you 5s to start up your server, that's a lot of time you've added to each development iteration. Make a change, restart the server, wait 5s, see if it works/check debug output.

Ruby or Python are even worse (slow / big) than java these days.

I'm a ruby guy btw..

Java is not that bad at all these days. For years now every iteration of Java EE has become lighter (with respect to the programming model and the startup time of servers).

JBoss EAP 6.0.1 does a cold start in 1.5 seconds on my 2.93Ghz i7. TomEE is some 2 seconds.

If even that's too much, there's JRebel which does full hot reloading of pretty much every piece of code you change.

typically you don't stop/start server during development cycle, hot deployment works 99% of cases

This is business as usual for me with ASP.NET. IIS Express has to start, then the app to load, then to initialize, then to compile the views.

And don't get me started on the Azure Compute Emulator.

If you're continuously restarting, you're doing it wrong. That argument became invalid about 4 years ago I think around the time Eclipse Helios was released.

Now-a-days, starting a Tomcat or TomEE JVM in debug mode with Eclipse gives you the ability to hot swap probably 95% of your changes. It doesn't supporting adding completely new functions or changing declared fields. JRebel does support this though.

As a matter of fact, if you're in a stack frame and you pause the execution pointer with a breakpoint, you can completely change the code of the function and the JVM will discard the current stack frame and then restart the functional call. Essentially, you can rewrite your code, while it's executing, without losing your stack.

    Make a change, restart the server, wait 5s, see if it works/check debug output.

Look at JRebel, Play or Nailgun.

Most of us aren't waiting 5 seconds before checking output. We just refresh the browser.

I think that this lingering perception is an artifact of two things. Firstly, in the mid-to-late 90s, Java was really was slow and back then C/C++ application layers were pretty common (perl if you could get away with it). So initially Java did not compare well, which is why we wasted a couple years on applets. Even as late as 2005 at Amazon, there were many people predicting doom when we introduced the first Java service as a dependency of the home page. Secondly, the early Java web frameworks were highly synchronous, with lots of locking, and there was no evented IO. So sites written that way really were dogs.

Although I hope to never write "public static void main" again (except ironically, of course), and I spend some time dabbling in Python/Ruby/obscure-language land, I'm really happy to see Clojure and Scala doing well here.

In my opinion, you hit the nail on the head with regard to a view on Java (being that it is "slow"). For many years in the early going, it was slow, but it has come around so much.

That being said, as a day-to-day Java web-developer, I cannot honestly remember the last time I wrote "public static void main".

Because it is slow. Compared to C/C++/langs without runtimes [albeit with JIT compilation, for long running applications this is becoming a non issue].

Compared to the current crop of dynamic language interpreters, waaaay more engineering time and talent has been poured into optimizing the jvm.

People I think forget that Java was a more user friendly C++; the price you paid was somewhat slower apps, but that's OK because you write more robust apps more easily. Rinse and repeat for Ruby/Python/Your Lang Here.

Feels like Java is the new C, C is the new ASM (performance wise at least). I've been doing this long enough that when I started using Java it was too slow for "anything serious", now it's the coice for performance. Definitely feels weird.

That was only true in the 1.x days, before JIT was the default in most VMs and native code compilers were available.

Check out the graphs on the "benchmark game":

http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

The JVM indeed kicks some major butt.

You should link quad 64 rather than uni 32 as it is much more real-world applicable. That being said, it doesn't change the fact you are stating here.

I always assumed the slowness is associated with build times and such. You are slow developing a Java web app, but not running it.

and GUIs.

Not when using GUI designers.

At the time Java gained its fame, the GUI applications were unresponsive, not slow.

They could lock at any time, for a perceptible few hundreds of miliseconds, but had still a nice average speed.

You ought to put together a benchmark for that!

Not really, major IDEs have had incremental compilers for ages. Usually Maven compiles of our largest projects are also done in no-time.

When your competition is mostly ruby/js/python...

Java does well with C, Haskell and Go competitors in these results...

Reply on news.ycombinator.com