So, the most recent batch of Pack200 code is finally in Harmony-2246 (Thanks Alexey!) and it's now capable of reading pack files that contain abstract interfaces, abstract methods, and constant initialisers. I'm working towards being able to get the bytecode out next, which for simple bytecodes I hope will be fairly easy but has a bunch of subtleties that might take me a time to get complete ...
In any case, it would be a good opportunity now that the code is stable to move it out to a new module. To recap why this is a good idea: o The pack200 code should be useable as an OSGi bundle/Java JAR outside Harmony as well as inside it o The code should be compiled with Java 1.3/1.4 compatibility (i.e. definitely no generics or bytecode versions that may be incompatible with older VMs. If possible, the build should pass the appropriate -source flags in during compilation as well as Eclipse metadata enforcing compiler compliance of 1.3 rather than the current 1.5 for the archive module as a whole o It should have its own OSGi Manifest exposing dependencies on core libraries like java.util.jar, rather than being packaged inside the archive bundle (so that it will work on other VMs/classlibs) o The Harmony approach of message internationalisation is done on a per-module basis, and we've already had to roll back one set of changes where the pack200 messages were intermingled with the java.util.jar messages (again, it needs to be separately deployable from the java.util.jar implementations) o The messages files are supposed to be one per module, and it goes against the current module structure to have multiple message files per module as far as I'm aware There have been other suggestions (such as creating more source folders inside the current module) but none of these really seem to solve all of the requirements. It is not possible to ensure that one source folder is compiled against one compliance level whilst the other is compiled against another compliance level, and even though there are comments indicating that generics shouldn't be introduced into the pack200 code, it's only a matter of time before someone loads it up into a 1.5-configured project and auto-fixes all uses of generics without realising it. At least separating it out into another module, and defining different compliance levels for that, would help avoid that problem IMNSHO. I've raised Harmony-2479 to track this issue. Once it's been discussed and suitably resolved, I'll be able to plough on with the next part. Alex.
