harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] Modules and reuse
Date Mon, 12 Oct 2009 10:12:53 GMT
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

but not

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


View raw message