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 Tue, 09 Jan 2007 00:14:21 GMT
On 07/01/07, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >> 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.
>
> Why?  it wouldn't compile.

You need this to be in the IDE, and not just in the build target. For
example, at some point between when I last did any work on this
(mid-November) and the reorg of the modules, various annotations were
added (which are now compile time errors in my workspace, because I
have it set to 1.4 compatibility) as well as generics:

http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/pack200/src/main/java/org/apache/harmony/pack200/bytecode/Attribute.java?revision=493560&view=markup

http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/pack200/src/main/java/org/apache/harmony/pack200/Pack200Adapter.java?revision=493560&view=markup

These were likely not added intentionally -- the source code is
plastered with comments like 'Dont add generics or annotations' at the
top -- but when loaded as a project in Eclipse, you can do automated
'clean-up' of source files, including the ability to automatically add
cancer like this into a codebase. And because it doesn't show up in
the IDE, you might then continue to do a bunch of work before
committing.

Even if you have the build to compile with -target 1.4, you'll still
potentially end up with a lot of manual work to undo the automated
clean-up.

On the other hand, as a separate project, with separate manifests,
source files, and compiler settings, you can set up the project so
that it compiles against 1.4, and therefore without adding this kind
of stuff in.

I've spent a good 15 minutes going through the code and undoing these
automated clean-ups just so that it compiles again on a 1.4 system. I
really, really don't want to have to do it again.

> > Plus, the manifest should list J2SE-1.4 as its requirements,
> > and not J2SE-1.5 (or J2SE-5 or whatever it is).
>
> That's only because there's one manifest at the moment - there's no
> reason why there can't be other build targets, and therefore other
> manifests.

At what point are you just including one project inside another
project for the sake of it?

> Right - so how do we do this so that there's the appropriate maifest
> for you?
>
> Lets try this - what does the manifest look like?

It'll be a standard OSGi manifest. I'm working on the update to the
project's manifest now, and will commit a patch shortly.

> > 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?
>
> Because I think that our notion of module was defined with
> architectural boundaries for the classlibrary, not issues like this.
> So I'm against it being a classlib module.

Isn't this just a more verbose way of saying 'because'? After all,
there's a 'regexp' module separate from the other java.util code; as
is the archive module, too. Perhaps you could explain why it's OK to
have 'regexp' as a separate module, but not pack200? After all, regexp
is just a part of java.util; as for that matter is the java.util.jar
code.

> It may make sense as a jkdtools module for which the classlib has a
> dependency - that's not that much better, but it's an improvement.

There's a distinction between the pack200 executable (which I've not
started work on) and the actual bundle implementing the algorithm.
It's very likely that if this is to be shared elsewhere, it will be
via the bundle and the code, as opposed to the command line (since its
main goal is to be used in programs outside of Harmony).

> > 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.
>
> Ah - yes.  I remember that and meant to say something about it in my
> last message (today is my last day of vacation and I'm distracted...)
>
> Yes, there should be separate messages.

The problem is that the guidelines state that there's one messages
bundle per module. Ergo, following those guidelines will lead to
message intermixing. In addition, I've already raised the issue about
how to deal with the accidental inclusion with the Harmony core NLS
code. Ideally, I'd want it to be in a separate project that doesn't
have any dependencies on the core Harmony code, so that this can't be
added accidentally as has been done already.

> > 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.
>
> Sure - the key here is to respect these boundaries and you shouldn't
> have to undo - you should squawk and someone who made the change
> should fix it.

It happened again with the code clean-up. It will keep happening if
it's in a project that is defined to use 1.5 defaults. The only way to
prevent it happening is to move it out into a separate project that
only uses 1.4 code.

> > 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
> > ...").
>
> Because our module structure is organized around well-thought-out
> boundaries for a classlibrary for java SE 5, not because of a
> developers issues w/ SVN or our message bundle system or any of the
> other reasons.

That's just a longer form of 'because'. Why should regexp and archive
be in separate modules, when they could be in the same util module?
And given any answer for that, why should the answer be any different
for code that is in 'java.util.jar' be in the same module as
'org.harmony.pack200'? In short, why does this conflict with the
'well-thought-out-boundaries'? Heck, the pack200 stuff is *supposed*
to be modular; it's supposed to be swapped out for any other
implementation of pack200.

It's not just about SVN. Nor is it just about messages. It's about
developing an entirely independent module that implements pack200,
like I've been saying from the beginning, which has absolutely no
dependencies on other Harmony code or mixed up with any java*
libraries. The pack200 code is aimed at being created as a separate
OSGi bundle that can be used in OSGi containers, Java applications or
Harmony.

> > 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.
>
> Well, that is always your choice.  I'd prefer not to see that happen
> - having you do the work here is great.  I think that we need to just
> find solutions to these problems that we're all happy with.

I've not done any work here since Nov 20th
(http://issues.apache.org/jira/browse/HARMONY-2246). I've been waiting
to get to a solution to this problem that we're all happy with since I
started here, and it just hasn't happened -- in fact, the dialogue
only started up when the pack200 code was finally moved to its own
module and I was about to start work on it again. Yet it seems that we
are no nearer to a consensus now than we were before.

Alex.

Mime
View raw message