The kind of people using the jar command (Java developers) are the kind of people who just accept the limitations of their systems without questioning.
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 totally agree in that I don't expect anyone to get up in the morning and make their mission-of-the-day the optimization of jar. I am just surprised that no one has noticed jar behaving strangely. As a developer, I am frequently on the lookout for programs that hit 100% CPU utilization. This is a very useful indicator. I have top running all the time. I don't run jar frequently... but if I did and it did hit 100% CPU, I would be curious indeed.
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.
I can't believe that no one's discovered this yet. Maybe this is a manifestation of the Python paradox. The kind of people using the jar command (Java developers) are the kind of people who just accept the limitations of their systems without questioning.
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".
Teams that run jar all the time probably do so in an asynchronous auto-build. It's already a process that runs 'many minutes' and you check back on later. So the delay is already mitigated, and the benefit less than the raw speedup would suggest. (And if lightning-fast builds were project-critical, even after this fix you'd switch to native zip.)
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.
I'd say that is a big honking "yes" to jganetsk's question. The acceptance of the build system limitations is so uncritical that you don't even try to build more than a few times a year.
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.
A jar is a packaging mechanism. It is not required step in most builds that I've encountered. Nor is it required to run (test) the code. Java classes can also be linked into a CLASSPATH from an unpackaged directory. Infrequent packaging does not imply infrequent building and/or testing.
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.