Re: [cp-patches] ResourceBundle

[Mark Wielaard]

Hi,

On Sun, 2004-11-21 at 03:51, Bryce McKinlay wrote:
> > We've been using this in libgcj for many months now without problems, 
> > so I'm pretty confident that its stable. However, Mark asked me to 
> > post the patch here before checking it in, so here it is.
> [...]
> >     (getBundle(String, Locale, ClassLoader)): Re-written to use new
> >     caching strategy, no-allocation lookup, and new tryBundle methods.

This new implementation is correct (and we should have it).
But it is more strict in that it now always signals a error
(NullPointerException) when the ClassLoader is null (which is correct).

This exposes a latent bug in our startup process when setting up the
system/application classpath. When the classpath contains a zip file
created on a posix like system that used the additional extra bytes
extension to set a time stamp we are now in trouble. See:

java.lang.NullPointerException
   at java.util.ResourceBundle$BundleKey.set (ResourceBundle.java:309)
   at java.util.ResourceBundle.getBundle (ResourceBundle.java:425)
   at java.util.Calendar.getBundle (Calendar.java:387)
   at java.util.Calendar.getInstance (Calendar.java:472)
   at java.util.Calendar.getInstance (Calendar.java:424)
   at java.util.zip.ZipEntry.getCalendar (ZipEntry.java:217)
   at java.util.zip.ZipEntry.setTime (ZipEntry.java:167)
   at java.util.zip.ZipEntry.setExtra (ZipEntry.java:343)
   at java.util.zip.ZipFile.readEntries (ZipFile.java:275)
   at java.util.zip.ZipFile.getEntries (ZipFile.java:342)
   at java.util.zip.ZipFile.getEntry (ZipFile.java:359)
   at java.util.jar.JarFile.readManifest (JarFile.java:283)
   at java.util.jar.JarFile.<init> (JarFile.java:253)
   [...]

Which comes from initializing the system/application classloader since
while this is initializing it is reading the zip files on the classpath
and if the zip file does contain a extra bytes time stamp extension we
try to get a Calendar object to translate the time and that tries to get
the appropriate ResourceBundle for the default Calendar which is read
from the application/sytemclassloader, which is in the process of being
initialized.

We actually had this problem with libgcj in the past also:
http://gcc.gnu.org/ml/java/2003-06/msg00084.html

You are not seeing this in libgcj since your system classloader is
initialized a little earlier now. But it could bite again when we merge
the ClassLoader implementations finally.

So I propose to only try to parse the extra bytes when really needed
when getTime() is called on a ZipEntry, which is unlikely to happen
during bootstrap.

2004-11-27  Mark Wielaard  <address@hidden>

        * java/util/zip/ZipFile.java (KNOWN_EXTRA): New static field.
        (setExtra): Don't parse bytes.
        (parseExtra): New private method.
        (getTime): Call parseExtra.

This solves the startup problem for me (with the GNU Classpath
examples.zip since that one is created by a zip implementation that sets
the extra bytes to contain additional time information).

What do you think?

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part