harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [general] jdktools and classlib?
Date Wed, 22 Jul 2009 07:31:22 GMT

In message <4A668437.3030401@gmail.com>, Regis writes:
> Mark Hindess wrote:
> >
> > If you are reading the commits list, you will have noticed that I've
> > been making a few improvements to the ant scripts in classlib.  I've
> > still got a way to go before I've finished the refactoring but I've
> > already started wondering about doing the same thing for jdktools.
> >
> > But the question that sprang to mind was why am I doing it twice.
> > Why not just have the jdktools modules as modules in classlib?  You
> > don't really lose anything in modularity since all classlib modules
> > can be checked out alone and built against an hdk.
> For me, this may be a bit confused - jdktools is not a part of
> classlib. If I wanted to see code of jdwp, I would never thought it
> was in classlib.

But you would look for jre tools in the jdktools component?  I didn't
really intend for this to be about the names since we've largely been
happy to ignore the incorrect jdktools one for a long time.  Instead of
'classlib' just think of a name that means everything-except-the-vm and
consider what I wrote again.  Does it make more sense now?

> For Ant script, I'm not familiar with it, just flying thinking, is
> it possible to extract common parts or make some templates to reduce
> maintain efforts?

There is already some sharing between components.  I'm increasing the
use of common code in classlib at the module level at the moment.  We
could do more sharing across components but refactoring these takes
quite a bit of (elapsed) time[3].

I guess I just don't understand why we don't just have two components:

1) VM (which can be replaced by another VM and was a modular structure
to allow parts to be replaced, etc)

2) Everything else (which also has a modular structure that allows
a downstream user to pick and choose the bits they need or wish to


> > I think we'd gain in that jdktools might get a little more attention
> > if it was built and tested with classlib[0].  (Currently it would
> > break quite a few ports since samsa seems to have quite a few
> > linux-isms.  I'll fix these shortly though.)
> >
> > Of course, it adds a little (20M on top of 250M) to the checkout
> > footprint and the build/test takes a little longer so there is a
> > downside.
> >
> > I've read the original thread[1] but I still don't see a good
> > argument[2] for this separation.  What do other people think?
> > 
> > Regards,
> >  Mark.
> > 
> > [0] and trunk -> branches/java6 merged with classlib
> > 
> > [1] http://markmail.org/thread/l44kkyiom45ks6e6
> > 
> > [2] That thread did contain an argument but not a good one and not one
> >     related to this topic. ;-)

[3] The changes are usually fairly straight-forward but testing each change
    at federated-build, classlib, classlib-module, and hdk levels takes a
    long time to run.  And there are lots of changes that could/should be

View raw message