[classlib] Modules and reuse

[Mark Hindess <ma...@googlemail.com>]

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.

Re: [classlib] Modules and reuse

[Tim Ellison <t....@gmail.com>]

On 09/Oct/2009 01:39, Jesse Wilson wrote:
> On Thu, Oct 8, 2009 at 2:23 PM, Mark Hindess <ma...@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

Re: [classlib] Modules and reuse

[Jesse Wilson <je...@google.com>]

On Thu, Oct 8, 2009 at 2:23 PM, Mark Hindess <ma...@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"?