3 ms·

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 on

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.

ankhmoop 17y ago
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".
- fsniper 17y ago
  Thinking of how broadly java and java build tools are used, cumulative losses of world is "remarkable" in economical and ecological terms.
gojomo 17y ago
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.

ankhmoop 17y ago

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

fsniper 17y ago
Thinking of how broadly java and java build tools are used, cumulative losses of world is "remarkable" in economical and ecological terms.

gojomo 17y ago

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.