

Superduper Slow Jar Command (embarassing bug in the jar code) - ks
http://blogs.sun.com/CoreJavaTechTips/entry/superduper_slow_jar

======
Hexstream
I don't know if there are comparable Windows and Mac equivalents, but with
Ubuntu I have this nice "Gnome system monitor" that shows me CPU, Memory,
Network, Load Average and Disk IO usage % in real-time at all times. I can't
imagine living without it.

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)

~~~
brown
I highly recommend Process Explorer ([http://technet.microsoft.com/en-
us/sysinternals/bb896653.asp...](http://technet.microsoft.com/en-
us/sysinternals/bb896653.aspx)). It is like the default Windows Task Manager
on steroids. It is the tool most preferred by Microsoft devs. It is very
lightweight and powerful. I have long hoped for a Process Explorer clone for
linux (maybe a side project for someone with lots of free time...).

~~~
moe
_I have long hoped for a Process Explorer clone for linux_

It's called 'top'.

~~~
rincewind
It's also the /proc filesystem

------
tezza
Yuck! I've been using _ant_ scripts which jar up dependencies for years. Other
people will be even more impacted than me, like shops that use continuous
builds ala CruiseControl.

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.

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

~~~
patio11
_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.

~~~
jganetsk
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
_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
Thinking of how broadly java and java build tools are used, cumulative losses
of world is "remarkable" in economical and ecological terms.

------
iigs
Sorry to be naive about java, but isn't .jar just .zip with a manifest and a
different extension?

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.

~~~
nradov
The JSE library has had zip support since version 1.1.
[http://java.sun.com/javase/6/docs/api/java/util/zip/package-...](http://java.sun.com/javase/6/docs/api/java/util/zip/package-
summary.html) The jar performance defect described in that article is
apparently in the application, not the library.

