harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bootjvm@earthlink.net" <boot...@earthlink.net>
Subject Re: Bootstrapping the classlibrary builds
Date Wed, 28 Dec 2005 01:11:28 GMT

-----Original Message-----
>From: Tim Ellison <t.p.ellison@gmail.com>
>Sent: Dec 25, 2005 4:13 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: Bootstrapping the classlibrary builds
>Stefano Mazzocchi wrote:
>> Maybe I'm missing something, but if A depends on B and B depends on A,
>> isn't the separation between A and B something to reconsider?
>I agree that we should be minimizing these circular dependencies, but if
>you make their avoidance a hard rule then you soon end up dragging lots
>of code into a single massive-component.
>Some of the API circularities are quite minimal.  For example regular IO
>in the LUNI component depends upon NIO because, amongst a few other
>cases, java.io.FileInputStream.getChannel() returns a
>java.nio.channels.FileChannel which in turn may throw a java.io.IOException.

This is a standard type of problem in many Java application packages also.
As a system grows, one developer uses a class in another package that was
developed to depend on the first.  One way around this problem is to permit
all code to depend on all code with impunity, but when the final classes have
been built for a specific directory, any .class file that does not have a
corresponding .java source file is purged before packaging.  This will mean
that a purged .class file may be compiled more than once, but it eliminates
th possibility of it being packaged twice, possibly creating a bogus error,
depending on the package target (ie, a .jar file or an install directory) and
the packaging tool (ie, 'jar' or script fragment in 'ant' or 'make' directives).
I have seen this in several systems and have never had any problems by
using this approach.

>I believe that the set of circular dependencies can be managed down to a
>small number, and the extra modularity gives greater flexibility.

This means, of course, that circular dependencies are irrelevent in the
final, packaged deliverable, whatever form it takes.  I hope this helps.

>Tim Ellison (t.p.ellison@gmail.com)
>IBM Java technology centre, UK.

Dan Lydick

View raw message