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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]