harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Hindess" <mark.hind...@googlemail.com>
Subject [classlib] Modules and reuse
Date Thu, 08 Oct 2009 21:23:10 GMT

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.




Mime
View raw message