harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: Re: [classlib][pack200] new module (was: [classlib][pack200] Development has stalled :-( )
Date Sun, 07 Jan 2007 22:50:33 GMT
On 07/01/07, Geir Magnusson Jr. <geir@pobox.com> wrote:
>  From what I grok, Alex has problems with
>
> 1) not having patches applied fast enough
> -> 1) I vote that Alexei is responsible for getting patches in SVN :)

It's not so much the patches being applied fast enough. The problem is
that if I'm adding a new file, and I contribute that, I effectively
can't work on it any more until the file is applied. That's because
when it's subsequently added SVN throws a wobbly and refuses to do
anything because there's a file already there. I'm going to get this
anyway -- solution is to delete and then svn up -- but if I've made
changes to that file (or someone else has made changes that I don't
have) then any further changes get lost. It's less of a problem when
there are already added files there, but most patches I've submitted
have had new files in place, and it does take me a while to sync after
a patch has been applied.

As such, I've found it easier to wait until a patch has been applied,
so that I can do an svn up knowing I've not lost any of my new files.

> 2) not being able to keep the code at Java 1.4 for portabliity
> -> 2) This I think we can handle easily - can we add a small CC target
> that simply compiles this package as 1.4 code?  While it doesn't
> prevent someone from making an inappropriate change, it does ensure
> that if it is changed, it's identified and reversed quickly.

That doesn't help for people who try to genericise the code, for
example. Plus, the manifest should list J2SE-1.4 as its requirements,
and not J2SE-1.5 (or J2SE-5 or whatever it is). There's also the issue
of compile time libraries; you can compile against a 1.5 system with
1.4 code compatibility, but still end up using e.g. System.nanoTime()
inadvertently. As a separate project, with 1.4 in the manifest, I can
actually compile against the real 1.4 VM libraries on my machine; and
know that I'm not going to get burnt by accidental inclusion of an API
that's not there.


> 3) ease of use working w/in eclipse because of other packages (java/
> util/*) as well as manifest drek
>
> -> 3) I don't quite know what to do here, other than setup a work
> environment in a sandbox where we use the svn switch trick to just
> let the code get checked out as a workable tree, yet still have the
> checkins happen where we like them to be, in the archive tree

Or, just have a separate module. Plus, if there's going to be a
separate bundle generated, why not use the fact that one module is a
bundle? Why go to all the trouble of setting up a build library that
has this separation and then try and force two bundles to live in one
module?

> 4) what else?

Well, I've also made the point about messages and internationalisation
thereof. The goal is for this to be separately downloadable outside of
the Harmony APIs; therefore, mixing up messages designed for this
bundle with messages in the generic Java util library.

The same also goes for the Apache NLS classes. The Pack200 stuff can't
rely on that for internationalisation without dragging extra baggage
with it. This has already been applied once to the strings in the
pack200 code, and I had to manually undo it.

> I'm hoping we can find solutions to these.  Some suggestions about
> the individual pieces...

Personally, I'd also like to hear from people about why moving this
out into a separate module is a bad idea. There seems to be resistance
for resistance's sake ("No, let's try and find a way to keep it the
same") as opposed to a justification ("We shouldn't do that because
..."). I've been arguing since the beginning that it made sense to
keep it separate, and justified the reasons for doing so. I don't
believe that there have been reasons given against moving it out, just
that it should not be moved out.

> Another solution is to simply have Alex submit a work environment
> that we place in the sandbox, and from time to time we migrate code
> from there into modules/archive?

Frankly, it's probably easier for me to continue development on a
completely different repository. If you're going to go to the extent
of doing a wait and merge, it's going to be far easier for me to work
against an SVN repo that I can commit directly, and then build myself
and make available for anyone (including Harmony) that wants to use
it.

Looking forward to your thoughts,

Alex.

Mime
View raw message