Weblog entry #321 for simonw
See all weblog entries made by simonw.
#321
Signing "jar" files
Posted by simonw on Fri 24 Apr 2009 at 20:48
Just wasted too much of my life trying to sign "jar" files properly and consistently.
The "fastjar" utility didn't hack it for unpacking and repacking "jar" files. I think it lacks the understanding of the current features of the manifest file, but which aspect I'm unclear on.
Some of the "jar" files signed with an older version of SUN's jarsigner (Version 5 mumble) could no longer be repacked with SUNs jar utility (i.e. jar xf ..., jar cmf .... and now it fails jarsigner -verify). I don't understand this problem at all, since unpacking and repacking is a glorified "zip" operation it ought to "just work". Clearly something else is stored in the jar file format, but I couldn't find any useful documentation.
So I ended up reverting to the jar files as they were before they were signed last year, and signing those after removing expired signatures.
I think I learnt:
use only SUNs JDK tools for jar file manipulation.
backup at every step (no really it helps figure out what the tools did wrong).
IE caching of Java is broke
Iceweasel with fancy Java features enabled like Console is borked (on my Lenny box).
SUNs website has been updated, and all the Java help links are broken.
I'm also left wondering why the applet in question consumed 288MB of virtual memory, most of it probably memory mapped files, but 288MB?! I fear my boss didn't keep a close enough eye on the Java developer we used.
In the dim and distant past I was a Java developer, and aside from badly written code by developers I depended on, I don't remember any of these sorts of problems. Java reputation is worse than the reality, and I know Debian hasn't been exactly a Java friendly place, but I was still depressed by the state of things.
As always in Debian the packaging was excellent and when I removed "fastjar" and other Java tools, and installed the non-free SUN java, /etc/alternatives was correctly updated.
The "fastjar" utility didn't hack it for unpacking and repacking "jar" files. I think it lacks the understanding of the current features of the manifest file, but which aspect I'm unclear on.
Some of the "jar" files signed with an older version of SUN's jarsigner (Version 5 mumble) could no longer be repacked with SUNs jar utility (i.e. jar xf ..., jar cmf .... and now it fails jarsigner -verify). I don't understand this problem at all, since unpacking and repacking is a glorified "zip" operation it ought to "just work". Clearly something else is stored in the jar file format, but I couldn't find any useful documentation.
So I ended up reverting to the jar files as they were before they were signed last year, and signing those after removing expired signatures.
I think I learnt:
use only SUNs JDK tools for jar file manipulation.
backup at every step (no really it helps figure out what the tools did wrong).
IE caching of Java is broke
Iceweasel with fancy Java features enabled like Console is borked (on my Lenny box).
SUNs website has been updated, and all the Java help links are broken.
I'm also left wondering why the applet in question consumed 288MB of virtual memory, most of it probably memory mapped files, but 288MB?! I fear my boss didn't keep a close enough eye on the Java developer we used.
In the dim and distant past I was a Java developer, and aside from badly written code by developers I depended on, I don't remember any of these sorts of problems. Java reputation is worse than the reality, and I know Debian hasn't been exactly a Java friendly place, but I was still depressed by the state of things.
As always in Debian the packaging was excellent and when I removed "fastjar" and other Java tools, and installed the non-free SUN java, /etc/alternatives was correctly updated.
Comments on this Entry
Oops, I accidentaly pressed the "report" button, sadly it reported immediately with no "are you sure" page in between. Heh!
It is quite normal for Java to take that much memory. It is only virtual memory however. But even in its virtual form running such java tools on virtual servers with less memory (more than enough for the tool but not enough for Java's virtual memory hunger) is impossible from my experience.
If you don't care about that, just ignore it. It does not really use that much memory.
It is quite normal for Java to take that much memory. It is only virtual memory however. But even in its virtual form running such java tools on virtual servers with less memory (more than enough for the tool but not enough for Java's virtual memory hunger) is impossible from my experience.
If you don't care about that, just ignore it. It does not really use that much memory.
[ Parent | Reply to this comment ]