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