Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of t.p.ellison@gmail.com
 designates 209.85.218.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=Tpg8IoiLKWBB06GzKgwwRK8WFi/j85tWfTJ1VRnKL9cmoKctiZxFbpVN2XvCeQp2vo
         oA24qdxs7p81ZGZ0qMXe/jIr0C7oMLJYamsxQiO+cn/9wN55qr4Kb9wwceYNV8xiuXA3
         3UkZi8oa0bUg9tql8cuwLyKk1zp9ikzrdE2UQ=
Message-ID: <4AD30125.5070702@gmail.com>
Date: Mon, 12 Oct 2009 11:12:53 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib] Modules and reuse
References: <200910082123.n98LNE6l011502@d12av03.megacenter.de.ibm.com>
 <a43fbc6a0910081739m69843c49i86f05525219a62d7@mail.gmail.com>
In-Reply-To: <a43fbc6a0910081739m69843c49i86f05525219a62d7@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 09/Oct/2009 01:39, Jesse Wilson wrote:
> On Thu, Oct 8, 2009 at 2:23 PM, Mark Hindess <mark.hindess@googlemail.com>wrote:
> 
>> I was wondering about our modules and potential for re-use.
>>
>> For example, archive, auth, awt, imageio, nio, prefs, sql, security,
>> suncompat, swing, and x-net modules depend on non-API packages in luni.
>> This sucks from a re-use point of view since it means that you can't
>> re-use those modules without re-using our specific implementation of
>> luni.  Aside from nio (which in some respects is beyond help when it
>> comes to depending on luni) there are really only ~7 non-API classes
>> that are required by other modules.  I think it might be a good idea to
>> separate out these classes into a new util (or hyutil to avoid confusion
>> with java.util) module.
>>
>> It is tempting to create a platform and net modules to "own" the
>> org.apache.harmony.luni.platform/net packages but this only benefits nio
>> so I'm not convinced there is as much benefit in doing this.
>>
>> There are a few other odd things I noticed while looking at coupling
>> between modules.  For instance, the misc module depends on java.nio
>> because StringAccessor.compareString uses java.nio.ByteOrder.  However:
>>
>> * the signature of the method doesn't use ByteOrder even though the
>> documentation says it does but rather an int.
>>
>> * the misc module (and indeed StringAccessor specifically) has natives
>> so it would be trivial to implement a byteorder native method to avoid
>> the dependency on the nio module.
>>
>> * a quick glance suggests that nothing uses StringAccessor.compareString
>>  anyway
>>
>> I think we need to give a little more thought to modularity and in
>> particular dependencies on non-API classes.
>>
>> Regards,
>>  Mark.
>>
> 
> Depending on implementation classes in luni module doesn't offend me.
> Certainly all modules already depend on the public bits of luni for
> compilation, and the proposed module would have circular dependence with
> luni, so the tangible benefits are negligible.
> 
> Perhaps we could designate some classes or packages in luni as "Harmony
> public"?

The convention [1] is that packages with "internal" in their name are
only for use within a module, but others can be exported to other modules.

So, for example, NIO is free to call into
  org.apache.harmony.luni.net

but not
  org.apache.harmony.internal.net.www

Of course, we aim to reduce dependencies between modules (both to spec
and implementation packages) as much as possible within 'design reason'.


[1] http://harmony.apache.org/subcomponents/classlibrary/pkgnaming.html

Regards,
Tim