On Thursday 18 September 2008 17:31, Tim Ellison wrote: > Right. In fact, as you know Harmony has NIO (for IO channels) and > NIO_CHAR (for character converters). We went through an exercise way > back to split the monolith into different functional areas, and defined > the metadata to describe the inter-dependencies. While we try to > minimize the coupling some of it is forced upon us by the SE APIs.
Yep, and this makes Harmony a much more promising starting-point for such an exercise than the alternative(s). > > In actual use cases the most popular single import seems to be java.beans > > (which does actually correspond to a Sun-defined profile, namely CDC/PP). > > The biggest import was in order to run Ant on the target for purposes of > > auto-deployment - not a route I would recommend, but that was the > > customer's choice. > > A good example. Harmony's BEANS module depends upon AWT through a > spurious public interface parameter (and the fact that BEANS carries > around the persistence delegates). For people that don't want AWT and > SWING in their runtime they need to break the SE API in Beans. What to do about cases like this? Do we have classes in the build path which are not in the released artefact? Real ones or just-to-make-it-compile stubs? And afterwards do we leave those methods in the class file (so if someone uses the method it will break at runtime), or do we bytecode-engineer them out and hence break binary compatibility? Regards, Chris -- Chris Gray /k/ Embedded Java Solutions BE0503765045 Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 Skype: k.embedded.chris
