harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [general] jdktools and classlib?
Date Wed, 22 Jul 2009 08:01:56 GMT
Mark Hindess wrote:
> 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

I guess so, since JDK includes a JRE, it makes sense for me.

> 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?

I agree that move them together make things easier, but still not sure 
'classlib' is right place to put all them in. I can think 'classlib' means 
'everything-except-the-vm', but not everyone can, especially ones just join the 

>> 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
> replace.
> -Mark.
>>> 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
>     made.

Best Regards,

View raw message