harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: Re: [classlib][pack200] new module (was: [classlib][pack200] Development has stalled :-( )
Date Tue, 09 Jan 2007 16:02:18 GMT
As for me, I don't really care if we have a new module or not. I did
this just to make Alex happy and because I didn't hear any objections.
Just a New Year exercises. I can roll it back if we decide that it
will be better for us to live without it.  At the same time I don't
think that having the pack200 code in a separate module is something
more illogical than having annotation in the separate module (total
code size is about 16K) or having nio and nio_char separated.

On the other hand, I still don't understand how this solves the SVN
problem described by Alex. I've missed something probably. Another
thing I can't really get why we keep pack200 in the classlib workspace
if, as Alex has said, it has no relations (should not have relations?)
to the rest of classlibrary code and does not implement any public
API. May be jdktools is a better candidate indeed?

And again about this SVN issue. We may establish some process
probably. For example Alex can add a comment to critical JIRAs that he
can't live without this JIRA is applied. I did something like it
during my pre-committer life while working on the beans module.
Another suggestion is to post small JIRAs if some files should be
added to the workspace. It is easy to integrate and should simplify
Alex's life.

Regards,

2007/1/9, Alex Blewitt <alex.blewitt@gmail.com>:
> 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.
>


-- 
Alexei Zakharov,
Intel ESSD

Mime
View raw message