harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: [classlib][pack200] Pack200 status update
Date Tue, 15 Jan 2008 00:48:55 GMT
On Jan 14, 2008 9:14 PM, Andrew Cornwall <andrew.pack200@gmail.com> wrote:
> Both Sian and I have made good progress with Pack200. We're now creating
> valid .class files from Pack200 archives, at least with simple test cases.
> I've had a lot of success with HelloWorld :-)

Cool!

> There are a few things left to do. Inner classes are still a problem, and I
> noticed today that all our unpacked .jar files have archive dates of January
> 1, 1980. I won't vouch for major / minor versions yet either.

The archive dates aren't specified, unless they're added in as part of
the extra information if I remember correctly. Have a look at:

"If the #archive_modtime value is non-zero, the decompressor is
requested (but not required) to adjust the system-specific
modification time for its output. For example, if the decompressor
produces a JAR file, it may set the modification date of each JAR
element, or of the JAR file itself, to that date, in the absence of
any more specific directive, such a non-zero file_modtime value. The
#archive_modtime value is interpreted as the number of seconds since
the epoch used by System.currentTimeMillis, which is 1/1/1970,
00:00:00 GMT. However, the special value zero is reserved to indicate
the absence of any modification time for the archive as a whole. A
decompressor may supply an arbitrary value in place of a missing
archive modification time. If this is done, and if file_modtime values
are present, those values are interpreted relative to modification
time supplied for #archive_modtime by the compressor."

So it depends whether the packed file contains it or not. As the
compression levels get higher, more and more meta-info like that gets
lost out.

There's a similar one for the major/minor classes. There's a default
major/minor version for all classes, which can be overridden if the
version bit is set for each class (and subsequently put in there). It
would only be in mixed cases (i.e. a jar has both major/minor in
there) that would cause this to occur.

> In short, we've done a lot, and although there's a little ways left to go,
> we can see daylight ahead.

Hooray!

Alex

Mime
View raw message