We have jars that goes pretty deep into the package hierarchy. For example,
com.sun.em.api.alarm.jar contains classes from the package com.sun.em.api.alarm.
When this jar is exploded on a user's machine, the permissions of the 
directories com, com/sun, com/sun/em, com/sun/em/api and com/sun/em/api/alarm 
are 754. Since it is root that is doing the jar explosion (during postinstall),
the classes are inaccessible to less privileged users. The permissions of these
directories should be 755. See workaround.

-Akhil Arora


I'm going to update the description of this bug a bit because it's become a huge problem.  The synopsis of the bug refers to directories, but jar doesn't have the ability to retain permission information on any files at all.

This is keeping a major new features of Java 1.3 from working.  Using Java 1.3, if I go to a web site that requires a Java Optional Package like Java 3D, if I don't have it, the package is automatically downloaded and installed, and then the application is executed as normal.  I call this feature "Extension-Installation" after the name of the associated manifest file attribute.

Supporting Extension-Installation involves wrapping the installer for your extension in a jar file, signing it, and putting it on the web.  When the user goes to the web site with the Java application requiring a Java Optional Package, the Java Plug-In (JPI) checks to see if it's installed, and if it isn't, automatically downloads and installs the extension.

To do this, it downloads the signed jar file, asks for permission, unjars the file, and runs the installer contained inside.  And there's the problem.  The installer, since it was in a jar file, is no longer executable, and therefore won't run (Permission denied).

What this means is that Extension-Installation works on Windows, and fails on Solaris.

The jar utility *must* have a way to preserve execute permission on the files it contains.  In the 'tar' unix utility, this is achieved through the -p parameter.  Jar needs something similar.

Note that the workaround mentioned above will not work here.  The JPI downloads the jar, unjars it, and runs the installer.  There's no place to insert any scripting to change the permission on the file before it gets executed.  The feature simply won't work and there's no workaround.  

All of the Java Optional Packages are adding support for Extension-Installation.  We are the first to run into this bug, but I'm sure you'll hear from all of them as well, plus the JPI team.  Please help!