harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [general] jdktools and classlib?
Date Wed, 29 Jul 2009 15:55:08 GMT
Mark Hindess wrote:
> In message <4A6844DA.7040203@googlemail.com>, Oliver Deakin writes:
>> Tim Ellison wrote:
>>> On 23/Jul/2009 09:43, Sean Qiu wrote:
>>>> Do we really need this big change?
>>>> There are so many "duplicated" xml files whose original goal is to
>>>> achieve modularity.
>>>> So each component can be developed and tested separately.
>>>> I guess that's the reason that we got so many build scripts on each
>>>> modules of classlib.
>>>> (It is another story whether they worked as we expected)
>>>> I prefer to keep jdktools and classlib separately, it sounds more
>>>> natural to me.
>>> My gut feeling is also to keep the class library and jdktools
>>> separated, but I'll admit that it is only a gut feeling and not
>>> something I can defend technically.
>>> If it really does make life easier for build then it is something I
>>> could learn to live with.  I'd like to hear the arguments though.
>> I agree. It just feels to me like the VM and classlib are obvious
>> "units" and putting the additional jre/jdk tools in with either one
>> of them doesn't sit right.
> I'm still not sure I've heard a convincing technical argument about the
> current split.  

I not sure I've heard a convincing technical argument not to have them 
split :) A long time ago the tools were another module of classlib, and 
general concensus seemed to be that they would be better organised as a 
separate component to the class libraries, so they were split. I think 
the rationale was simply that all the other modules were part of the 
class libraries except for the "tools" module and as such it was a bit 
of an odd-one-out. Separating the tools from the class libraries made 
sense from a source organisation point of view rather than a technical one.

> I feel sure we'd all be just as happy if the original
> split had been vm and non-vm.  (I really think of this split as the VM
> and the frontends to the VM that users generally use and it seems quite
> natural to me.)

I might argue that this is not really a convincing technical argument to 
separate the VM and other components' source from each other, which at 
the moment seems to result in having quite different organisation of 
code between VM and classlib and different build systems (cpptasks vs. 
make). I think the real reason is that separating their source into 
different locations just makes organisational sense because they are 
clearly separate layers of the JDK [1], and I would argue similarly for 
the jdktools component.

> (I think deep down Oli isn't convinced either since he recently sent
> a message to the dev@ list with tags "[classlib][jdwp]" and made no

I was just demonstrating how separate classlib is from jdwp by not 
mentioning it in my mail ;)

> mention of anything classlib-related AFAICT. ;-)
> However, I think improving the federated build so that it could be used
> by those currently working with just classlib (or jdktools or vm) would
> be a reasonable compromise.
>> If our goals are to get the jdktools
>> used/looked at more and to unify the build scripts as much as
>> possible, then I would suggest improving the federated build for wider
>> use.
>> At the moment if a contributor wants to just work on classlib, they
>> will probably just check out classlib trunk and build from there
>> copying in whichever VM they wish to use. I think it would be better
>> if we made the federated build the starting point for this kind of
>> development and improved the build targets it provides so it plays
>> nicely when working with individual components. For this to work
>> we would need to allow more control over what source gets checked
>> out/built/tested, so they more closely reflect the targets within the
>> components - here's a few examples of what I was thinking of (names
>> like hy.component are just suggestions, not really important):
>> "ant -Dhy.component=classlib,jdktools populate-src" - just checkout the 
>> source for classlib and jdktools
>> "ant -Dhy.component=classlib rebuild-native" - just clean and build the 
>> native code for the classlib module, and automatically populate the 
>> built binaries under the federated target directory
>> "ant build-java" - build java code across all components. This target 
>> could detect which components have been checked out, much as the 
>> classlib build works out which modules to build automatically by 
>> checking if build targets exists, and only build those so that 
>> hy.component does not always need to be specified.
>> The above is just a rough idea of how it could be done, but I can see a 
>> few advantages of this approach:
>> 1) The federated build would get used more, giving us a more unified 
>> approach to building Harmony while still allowing contributors to work 
>> in individual areas with the same ease. This should also help remove 
>> some of the build script duplication across components.
>> 2) The java/javaw executables could be moved to jdktools (which makes 
>> more sense than classlib to me) meaning that jdktools would get more 
>> attention also.
>> 3) The common_resources directory would work for those working on the 
>> whole jdk and also for those just working on one or two components, as 
>> they would both use the federated build.
>> 4) If we ever wanted to add components (for example, split portlib into 
>> it's own component) it would be easier managed.
>> 5) If you started working on drlvm only and also wanted to make some 
>> changes to classlib later on, you could just run populate-src specifying 
>> the classlib component to check out the additional source and then carry 
>> on working.
> I like this idea.  If we are going to improve the federated build can
> we also:
> 1) Find a way to reduce coupling.  Currently federated/build.xml know
>    too much about DRLVM - things like the "set overwrite flag to take
>    hythr from VM" comment.
> 2) Call the directories drlvm, jdktools and classlib rather than working_*.
> 3) Allow the choice of VM component to be overridden - default 'drlvm'.

+1 to all 3 of these.

>> These are just ideas at the moment, but I can see there are benefits to 
>> this approach. Any thoughts/comments?
> Perhaps we could create a new federated sandbox to work out ideas?

That sounds like a good starting point.


[1] http://java.sun.com/j2se/1.5.0/docs/images/j2se5.gif

> Regards,
>  Mark.

Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

View raw message