You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alex Blewitt <al...@gmail.com> on 2006/10/15 01:54:46 UTC
[classlib][pack200] Moving pack200 to a separate module?
I was in the process of trying to put together a patch for the new
stuff that I've added recently, and it turns out that someone's gone
through and pulled out all of the hard-coded strings in the code and
added a dependency on
org.apache.harmony.archive.internal.nls.Messages, which in turn has a
dependency on org.apache.harmony.kernel.VM. This causes a few
problems:
1) There's now a tighter dependency from the pack200 code to the
Harmony VM. As I've noted previously, I was wanting to develop this as
a portable implementation of pack200 so that others could use it
outside of Harmony; for example, on JVMs prior to 1.5 that don't have
it built in.
2) The messages for Pack200 are now mixed up with the messages for the
remainder of the archive code, when they don't need to be. That means
exporting/building a separate Pack200 is going to have extra detritus
in it that doesn't n eed to be there.
3) There were a bunch of messages that I was leaving in the code (in
Error messages) reminding me to implement certain facets of the code,
that were never meant to be extracted. These have now been extracted
into a messages file with less than helpful 'archive.1C' messages left
behind.
I'd really like to undo this set of changes and leave message
externalisation until later, once the implementation is complete. I
also want to avoid getting the pack200 stuff tied up any more than is
necessary with the Harmony VM, because it should be possible to use
this on other VMs (or even the standard Java Sun VM ... the pack200
code is switchable based on a property in any case).
I'd also like to move the pack200 into its own module, so that when
messages do get externalised, they can be processed just for that
particular set of code and not lumped in with the remainder of the
archive code. I did suggest this in the past, although there was a
conclusion at the time that it wasn't worth doing at that time. I feel
that this is now the justification to separate the pack200 and archive
modules before it gets any more joined together.
I'll hold off updating and submitting a patch until we can figure out
what's best to do with the code.
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: Re: [classlib][pack200] Moving pack200 to a separate module?
Posted by Alex Blewitt <al...@gmail.com>.
Cool. I've attached patches for the stuff I've done up until now as
well as rolling back the localisation stuff as a patch in
HARMONY-1871. And, for some reason, I've accidentally created an empty
HARMONY-1870 too ...
Alex.
On 15/10/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> I agree with your motivations. Lets move it to the javatools/ part of
> the project when I get that done this weekend.
>
> As to the ties to o.a.h.k.VM, I'm sure we can work something out...
>
> geir
>
>
> Alex Blewitt wrote:
> > I was in the process of trying to put together a patch for the new
> > stuff that I've added recently, and it turns out that someone's gone
> > through and pulled out all of the hard-coded strings in the code and
> > added a dependency on
> > org.apache.harmony.archive.internal.nls.Messages, which in turn has a
> > dependency on org.apache.harmony.kernel.VM. This causes a few
> > problems:
> >
> > 1) There's now a tighter dependency from the pack200 code to the
> > Harmony VM. As I've noted previously, I was wanting to develop this as
> > a portable implementation of pack200 so that others could use it
> > outside of Harmony; for example, on JVMs prior to 1.5 that don't have
> > it built in.
> >
> > 2) The messages for Pack200 are now mixed up with the messages for the
> > remainder of the archive code, when they don't need to be. That means
> > exporting/building a separate Pack200 is going to have extra detritus
> > in it that doesn't n eed to be there.
> >
> > 3) There were a bunch of messages that I was leaving in the code (in
> > Error messages) reminding me to implement certain facets of the code,
> > that were never meant to be extracted. These have now been extracted
> > into a messages file with less than helpful 'archive.1C' messages left
> > behind.
> >
> > I'd really like to undo this set of changes and leave message
> > externalisation until later, once the implementation is complete. I
> > also want to avoid getting the pack200 stuff tied up any more than is
> > necessary with the Harmony VM, because it should be possible to use
> > this on other VMs (or even the standard Java Sun VM ... the pack200
> > code is switchable based on a property in any case).
> >
> > I'd also like to move the pack200 into its own module, so that when
> > messages do get externalised, they can be processed just for that
> > particular set of code and not lumped in with the remainder of the
> > archive code. I did suggest this in the past, although there was a
> > conclusion at the time that it wasn't worth doing at that time. I feel
> > that this is now the justification to separate the pack200 and archive
> > modules before it gets any more joined together.
> >
> > I'll hold off updating and submitting a patch until we can figure out
> > what's best to do with the code.
> >
> > 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
> >
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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] Moving pack200 to a separate module?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I agree with your motivations. Lets move it to the javatools/ part of
the project when I get that done this weekend.
As to the ties to o.a.h.k.VM, I'm sure we can work something out...
geir
Alex Blewitt wrote:
> I was in the process of trying to put together a patch for the new
> stuff that I've added recently, and it turns out that someone's gone
> through and pulled out all of the hard-coded strings in the code and
> added a dependency on
> org.apache.harmony.archive.internal.nls.Messages, which in turn has a
> dependency on org.apache.harmony.kernel.VM. This causes a few
> problems:
>
> 1) There's now a tighter dependency from the pack200 code to the
> Harmony VM. As I've noted previously, I was wanting to develop this as
> a portable implementation of pack200 so that others could use it
> outside of Harmony; for example, on JVMs prior to 1.5 that don't have
> it built in.
>
> 2) The messages for Pack200 are now mixed up with the messages for the
> remainder of the archive code, when they don't need to be. That means
> exporting/building a separate Pack200 is going to have extra detritus
> in it that doesn't n eed to be there.
>
> 3) There were a bunch of messages that I was leaving in the code (in
> Error messages) reminding me to implement certain facets of the code,
> that were never meant to be extracted. These have now been extracted
> into a messages file with less than helpful 'archive.1C' messages left
> behind.
>
> I'd really like to undo this set of changes and leave message
> externalisation until later, once the implementation is complete. I
> also want to avoid getting the pack200 stuff tied up any more than is
> necessary with the Harmony VM, because it should be possible to use
> this on other VMs (or even the standard Java Sun VM ... the pack200
> code is switchable based on a property in any case).
>
> I'd also like to move the pack200 into its own module, so that when
> messages do get externalised, they can be processed just for that
> particular set of code and not lumped in with the remainder of the
> archive code. I did suggest this in the past, although there was a
> conclusion at the time that it wasn't worth doing at that time. I feel
> that this is now the justification to separate the pack200 and archive
> modules before it gets any more joined together.
>
> I'll hold off updating and submitting a patch until we can figure out
> what's best to do with the code.
>
> 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
>
---------------------------------------------------------------------
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: Re: [classlib][pack200] Moving pack200 to a separate module?
Posted by Alex Blewitt <al...@gmail.com>.
Yeah, it would be easy enough to do :-) I've added some comments in
the header of each file to that effect. As for the (indirect) ties
with o.a.h.k.VM, that's just an implementation issue with the Messages
class; it should be fairly easy to roll out a less specific one for
the pack200 messages.
Alex.
On 15/10/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> I'm assuming that the person just didn't know... Please put a readme
> into the root of the codebase so that these special circumstances are
> known by others (assuming someone doesn't have a big problem with it...)
>
> geir
>
> Alex Blewitt wrote:
> > On a related note, it seems that some changes have been committed that
> > are using generics in the pack200 code. These will prevent it from
> > being run on pre Java 1.5 systems, which again was one of my goals in
> > writing this. I'll have to revert those changes, too ...
> >
> > Alex.
> >
> > On 15/10/06, Alex Blewitt <al...@gmail.com> wrote:
> >> I was in the process of trying to put together a patch for the new
> >> stuff that I've added recently, and it turns out that someone's gone
> >> through and pulled out all of the hard-coded strings in the code and
> >> added a dependency on
> >> org.apache.harmony.archive.internal.nls.Messages, which in turn has a
> >> dependency on org.apache.harmony.kernel.VM. This causes a few
> >> problems:
> >>
> >> 1) There's now a tighter dependency from the pack200 code to the
> >> Harmony VM. As I've noted previously, I was wanting to develop this as
> >> a portable implementation of pack200 so that others could use it
> >> outside of Harmony; for example, on JVMs prior to 1.5 that don't have
> >> it built in.
> >>
> >> 2) The messages for Pack200 are now mixed up with the messages for the
> >> remainder of the archive code, when they don't need to be. That means
> >> exporting/building a separate Pack200 is going to have extra detritus
> >> in it that doesn't n eed to be there.
> >>
> >> 3) There were a bunch of messages that I was leaving in the code (in
> >> Error messages) reminding me to implement certain facets of the code,
> >> that were never meant to be extracted. These have now been extracted
> >> into a messages file with less than helpful 'archive.1C' messages left
> >> behind.
> >>
> >> I'd really like to undo this set of changes and leave message
> >> externalisation until later, once the implementation is complete. I
> >> also want to avoid getting the pack200 stuff tied up any more than is
> >> necessary with the Harmony VM, because it should be possible to use
> >> this on other VMs (or even the standard Java Sun VM ... the pack200
> >> code is switchable based on a property in any case).
> >>
> >> I'd also like to move the pack200 into its own module, so that when
> >> messages do get externalised, they can be processed just for that
> >> particular set of code and not lumped in with the remainder of the
> >> archive code. I did suggest this in the past, although there was a
> >> conclusion at the time that it wasn't worth doing at that time. I feel
> >> that this is now the justification to separate the pack200 and archive
> >> modules before it gets any more joined together.
> >>
> >> I'll hold off updating and submitting a patch until we can figure out
> >> what's best to do with the code.
> >>
> >> 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
> >
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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] Moving pack200 to a separate module?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I'm assuming that the person just didn't know... Please put a readme
into the root of the codebase so that these special circumstances are
known by others (assuming someone doesn't have a big problem with it...)
geir
Alex Blewitt wrote:
> On a related note, it seems that some changes have been committed that
> are using generics in the pack200 code. These will prevent it from
> being run on pre Java 1.5 systems, which again was one of my goals in
> writing this. I'll have to revert those changes, too ...
>
> Alex.
>
> On 15/10/06, Alex Blewitt <al...@gmail.com> wrote:
>> I was in the process of trying to put together a patch for the new
>> stuff that I've added recently, and it turns out that someone's gone
>> through and pulled out all of the hard-coded strings in the code and
>> added a dependency on
>> org.apache.harmony.archive.internal.nls.Messages, which in turn has a
>> dependency on org.apache.harmony.kernel.VM. This causes a few
>> problems:
>>
>> 1) There's now a tighter dependency from the pack200 code to the
>> Harmony VM. As I've noted previously, I was wanting to develop this as
>> a portable implementation of pack200 so that others could use it
>> outside of Harmony; for example, on JVMs prior to 1.5 that don't have
>> it built in.
>>
>> 2) The messages for Pack200 are now mixed up with the messages for the
>> remainder of the archive code, when they don't need to be. That means
>> exporting/building a separate Pack200 is going to have extra detritus
>> in it that doesn't n eed to be there.
>>
>> 3) There were a bunch of messages that I was leaving in the code (in
>> Error messages) reminding me to implement certain facets of the code,
>> that were never meant to be extracted. These have now been extracted
>> into a messages file with less than helpful 'archive.1C' messages left
>> behind.
>>
>> I'd really like to undo this set of changes and leave message
>> externalisation until later, once the implementation is complete. I
>> also want to avoid getting the pack200 stuff tied up any more than is
>> necessary with the Harmony VM, because it should be possible to use
>> this on other VMs (or even the standard Java Sun VM ... the pack200
>> code is switchable based on a property in any case).
>>
>> I'd also like to move the pack200 into its own module, so that when
>> messages do get externalised, they can be processed just for that
>> particular set of code and not lumped in with the remainder of the
>> archive code. I did suggest this in the past, although there was a
>> conclusion at the time that it wasn't worth doing at that time. I feel
>> that this is now the justification to separate the pack200 and archive
>> modules before it gets any more joined together.
>>
>> I'll hold off updating and submitting a patch until we can figure out
>> what's best to do with the code.
>>
>> 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
>
---------------------------------------------------------------------
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] Moving pack200 to a separate module?
Posted by Alex Blewitt <al...@gmail.com>.
On a related note, it seems that some changes have been committed that
are using generics in the pack200 code. These will prevent it from
being run on pre Java 1.5 systems, which again was one of my goals in
writing this. I'll have to revert those changes, too ...
Alex.
On 15/10/06, Alex Blewitt <al...@gmail.com> wrote:
> I was in the process of trying to put together a patch for the new
> stuff that I've added recently, and it turns out that someone's gone
> through and pulled out all of the hard-coded strings in the code and
> added a dependency on
> org.apache.harmony.archive.internal.nls.Messages, which in turn has a
> dependency on org.apache.harmony.kernel.VM. This causes a few
> problems:
>
> 1) There's now a tighter dependency from the pack200 code to the
> Harmony VM. As I've noted previously, I was wanting to develop this as
> a portable implementation of pack200 so that others could use it
> outside of Harmony; for example, on JVMs prior to 1.5 that don't have
> it built in.
>
> 2) The messages for Pack200 are now mixed up with the messages for the
> remainder of the archive code, when they don't need to be. That means
> exporting/building a separate Pack200 is going to have extra detritus
> in it that doesn't n eed to be there.
>
> 3) There were a bunch of messages that I was leaving in the code (in
> Error messages) reminding me to implement certain facets of the code,
> that were never meant to be extracted. These have now been extracted
> into a messages file with less than helpful 'archive.1C' messages left
> behind.
>
> I'd really like to undo this set of changes and leave message
> externalisation until later, once the implementation is complete. I
> also want to avoid getting the pack200 stuff tied up any more than is
> necessary with the Harmony VM, because it should be possible to use
> this on other VMs (or even the standard Java Sun VM ... the pack200
> code is switchable based on a property in any case).
>
> I'd also like to move the pack200 into its own module, so that when
> messages do get externalised, they can be processed just for that
> particular set of code and not lumped in with the remainder of the
> archive code. I did suggest this in the past, although there was a
> conclusion at the time that it wasn't worth doing at that time. I feel
> that this is now the justification to separate the pack200 and archive
> modules before it gets any more joined together.
>
> I'll hold off updating and submitting a patch until we can figure out
> what's best to do with the code.
>
> 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