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.
