Superduper Slow Jar Command (embarassing bug in the jar code)
blogs.sun.com
blogs.sun.com
There's no way I couldn't notice something taking 100% CPU for a long time while not writing to disk when it ought to start writing to disk immediately.
It's part of the reason I notice and hate flash stuff that takes 100% CPU for no reason at all. (but I'd notice anyway because my fan gets noisier real fast)
Windows only shows CPU like that, and it works really badly because if your CPU spikes to 100% it momentarily stops updating. There's simply no comparison between the two.
It's called 'top'.
I always wondered why it was so slow, I thought my OS was having to page the files back into memory inefficiently (too little ram cache). Or my disk was too slow. SSD write was so slow that builds weren't improved, so this will be nice to compensate.
It sucks that I've been wasting that much time, but it is great that I'm about to see a real speed up.
I've been a Java programmer for, yikes, is it ten years now? Of that decade, perhaps 45 minutes has been spent waiting for jar to finish.
Tell me, does it sound like a productive use of my time to go hunting for an optimization to cut 30 minutes off of that?
If I were to wake up in the morning one day and say "You know, instead of implementing features customers actually want, I think today I'm going to make fast things faster", I'd start by targeting things which happen frequently, take a lot of time, and are on the critical path for my users. JAR is oh for three. For my business, I have to run it once per release candidate, or about eight times a year, for a total cost of two minutes. Even at my day job, since you can restart development servers without re-jarring everything, we only have to re-jar once per every restart of the production servers, a process which is rate limited by collecting approval on paper for the restart anyway.
I have been at a new job for 2 weeks, using Java EE. My IDE and my application use tons of memory, and I am often waiting for it to respond. Why is it paused? My coworkers just say "garbage collection". But they don't know if that is, in fact, what's happening. If you see jar running at 100%, do you think "oh it's just garbage collection", or "a bug, perhaps?"
Considering the fact that, there are millions of Java developers out there, that open source development has proven true the mantra "with enough eyes, all bugs are shallow", and that this jar bug has potentially been around for years... I am just surprised.
Also, as much as I would love to extrapolate meaning from your single anecdote, I suspect that some people out there are running jar a lot. In fact, the blog post's writer mentions that he was trying to address actual complaints of the user base. It is a "well-known" fact that jar is slow.
Your argument is pretentious, arrogant, and ultimately clueless.
For small builds, jar is sufficiently fast as to not raise any red flags. For large builds, jar overhead is small enough as to be easily lost in the noise.
The build should have been profiled, and this is an embarrassing bug, but it's absolutely, completely ridiculous to generalize this to the fact that Java developers could be the "kind of people who just accept the limitations of their systems without questioning".
Still, I'm glad this is fixed and wouldn't mind if Sun or other big Java vendors had a few interns/students just roaming legacy code looking for cheap wins like this.
Which means that you don't do regression localization by doing an automated binary search of the total revision history of the complete product. ("Oh, but touching the complete product is rate limited by paperwork." [sob]) Having the build system hand you the exact delta that introduced a subtle bug once in your product's lifetime would pay for rather a lot of build optimization.
Even if the goal is to make jar "100% pure java", which I don't recall it being, why wouldn't they transcribe a relatively complete implementation of .zip from the get-go?
A relatively complete, solid, performant implementation of what is probably the world's most common compression algorithm seems like exactly the kind of thing that belongs in Java's enormous library system. Maybe typical jar duties wouldn't tax it but it seems like someone somewhere would use it for something big and these kinds of issues would have shaken out long ago.