harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject [classlib][pack200] Moving pack200 to a separate module
Date Tue, 05 Dec 2006 23:29:18 GMT
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.

Mime
View raw message