You're kidding: Java compilation time

jdavidb on 2008-02-21T20:17:08

While XP works with any language, we believe it works well with Java for a few reasons. Most important is the speed with which Java compiles. XP relies on test-first development in which programmers write tests for code before they write the code. For each new feature, you should write a test and then watch the test run and fail. You should then add the feature, compile, and watch the test run successfully. This implies that you must write a little code, compile, and run the tests frequently, perhaps dozens of times each day. Because Java compiles quickly, it is well suited to the test-first approach.

-- Java Extreme Programming Cookbook (emphasis added)

This is a joke, right?


Compared To ___

chromatic on 2008-02-21T21:19:49

Java loses when you compare it to Smalltalk, Lisp, or anything else even remotely decent. Java wins when you compare it to C++, at least until you try to mix Java generics with Java closures, in which case you have to use trigraphs in your STL templates to match the level of ugliness.

Re:Compared To ___

waltman on 2008-02-21T22:42:19

But Java loses when you compare it to C++ when you consider that any decent C++ compiler has dozens of optimization parameters you can set to try to improve the speed and/or size of your executable. Does javac have any?

Re:Compared To ___

ChrisDolan on 2008-02-22T04:28:59

Actually, with compile-as-you-code tools like Eclipse, I've found that the compile+run portion of the edit-test-fix-test loop in Java represents a similar amount of time as the compile+run portion of a similar loop in Perl.

That said, the actual coding time usually compares disfavorably to higher-level languages like Perl in my personal experience.

Re:Compared To ___

chromatic on 2008-02-22T07:52:33

It probably seems faster because actual editing in Eclipse is so slow.

Re:Compared To ___

ChrisDolan on 2008-02-22T13:21:37

Really? It's slow to start up, but after that it doesn't seem slow at all to me. All of the slow parts (indexing, compiling, SCM synchronization) happens in a background thread and does not interfere with editing. It's the most productive programming environment I've ever encountered. Honestly, the Perl 6 feature I'm most looking forward to is its improved parsability so maybe a really great Eclipse plugin will be possible (no offense intended toward the EPIC plugin, which tries to provide Perl 5 support in Eclipse and only barely succeeds).

I think the Eclipse==slow meme is as useless as the Perl==unreadable meme. It's complaining about all the wrong things and ignoring the overwhelming value of the tool.

Re:Compared To ___

jdavidb on 2008-02-22T15:03:34

Eclipse usage is subtly mandated for me at $WORK. I do like it, but it is slow. Not always slow, but often slow. There's probably some reorganization we could do to our project to speed some things up, but I'm not an Eclipse wizard, yet (hoping to achieve that later this year).

I'm not going to trash the tool, but I'm not going to say it isn't slow, either. It's slow for me. May not be for everybody. Memory will probably help, if they ever get me some. :)

Oh, and not all of that stuff happens in background threads. The most striking example to me is when I try to save a file and have to wait because it's busy updating the workspace. Everything stops.

Re:Compared To ___

ChrisDolan on 2008-02-23T02:12:18

Ahh, well, yes. With Java, RAM equals performance. I develop on a machine with 2GB and a dual 3.4 GhZ P4D and I set -Xmx=768M for Eclipse. I typically just leave Eclipse running for a week or so at a time, so it's always up to date.

Our codebase is large and well-documented, so I rely heavily on Eclipse's tools for text searching, API searching, autocompletion, Javadoc tooltips, and global refactoring. The quantity of keyboard shortcuts is astonishing and generally mnemonic if idiosyncratic. Once you grok the core 50-80 shortcuts, Eclipse really shines.

Before Eclipse, I'd been using Emacs for development for the last 15+ years, so the above features have felt quite profound to me (see, I love obscure keyboard commands I guess!). I've used other IDEs like XCode and various Windows C/C++ implementations, but those always felt inferior to Emacs to me due to their clunky editing.

This is all a digression from Java compilation speed, of course... Sorry about that.

Anyone know the equivalent for "M-x butterfly RET" in Eclipse? :-)

Re:Compared To ___

chromatic on 2008-02-22T19:10:03

It's complaining about all the wrong things and ignoring the overwhelming value of the tool.

I'm sure there's tremendous amount of value in the tool. I'm only starting to use it for serious things, and I can't seem to get anything done quickly. It feels like the programming equivalent of Mac OS X, where people who know what they're doing have to wear oven mitts to slow them down and let them enjoy the aesthetics, except without the aesthetics.

Hrm...

Alias on 2008-02-22T03:14:37

I thought Java unit testing was mostly class based.

So if you write a test, for some method that doesn't exist, the test code doesn't even compile at all, so you can't run it?