[classlib][pack200] Unpacked archive; now reconstituted Jar file too :-)

[Alex Blewitt <al...@gmail.com>]

Following from my last success ... I've now got a minimal version of a
Pack200 archive decoded and then reassembled into a Jar file,
including spitting out the .class code so that javap correctly decodes
it. I'm using the standard JarEntry/JarOutputStream to dump data out
(and at the moment, I'm testing it against the
JarEntry/JarOutputStream on Mac rather than the harmony version).
Still, it assembles the right files in the right order and for any
non-class file, dumps the file as is.

Whilst this may sound like I'm making a lot of progress, there's still
a lot more to be done, so don't get your hopes up too high yet. I've
just demangled a test interface with no methods, so there's still work
to be done in decoding bytecodes and inserting them into the resulting
file. Still, I think I've got a handle on how the attributes work now
in a pack200 archive (and for that matter, a class file) so the next
part of the work is pretty clear.

I also have to make sure that the output class file is exactly the
same as the standard pack200 will generate. As an example, a class
file can contain m1() and m2(), or it can contain m2() and m1() --
they'll both work the same in a JVM. However, since pack200 archives
can be signed, it's essential that for any two pack200 decompressors
that they produce exactly the same binary output. (There's
well-defined orderings along the lines of 'sort all methods
alphabetically' but a bit more detailed; currently, I don't respect
those.)

I'm putting together my own mini version of BCEL to generate the class
files and deal with the constant pool entries primarily because of the
strict ordering and processing that the class file has to be in. I'm
not sure if harmony uses BCEL elsewhere (or similar) but I'd prefer to
write something that's entirely self-contained for pack200, since the
pack200 stuff can be exported as an independent Jar and used in other
systems (e.g. Eclipse) regardless of underlying VM. Mind you, in doing
so, I think I see some good refactorings that I can make for the main
Segment class, which is probably just as well since it's growing to be
a bit of a monolith.

There's also a bunch of optional-ish stuff which I've not tackled yet.
For example, parameter and method annotations (e.g. @Override etc.)
are handled specifically within the archive; in other words, if you
pass in a packed Jar file that has no annotations, it will go well,
but if you pass in a packed Jar file where one (or more) of the
classes has annotations, it will fall over. (It's not an
insurmountable problem, it's just one that will take time; but I'm
going to focus on the main stuff of methods, bytecodes etc. first)

Lastly, there's known places in the decompression which I don't
handle. For example, an archive can pretty much ignore the default
compression for a piece of data and instruct the decompressor to use a
different one instead. I can detect when that happens, but I just
throw an Error (for now) rather than do the necessary switch.

Anyway, I'll get the code that I have at the moment tidied up a bit
(and update the copyright notices) and then make a patch with the
current state of play. I can then start focussing in on decompressing
an interface with a constant or some empty methods :-)

Alex.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [classlib][pack200] Unpacked archive; now reconstituted Jar file too :-)

[Tim Ellison <t....@gmail.com>]

Thanks for updating us on the progress Alex, it's good to see and sounds
like you have a clear understanding of how to progress.

Alex Blewitt wrote:
> I'm
> not sure if harmony uses BCEL elsewhere (or similar) but I'd prefer to
> write something that's entirely self-contained for pack200, since the
> pack200 stuff can be exported as an independent Jar and used in other
> systems (e.g. Eclipse) regardless of underlying VM.

We have BCEL as a dependency of the Yoko (CORBA) code that we picked up,
but if your requirements are modest then I agree that a simple
self-contained manipulator makes sense.

Keep up the good work.

Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org