harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Gray <chris.g...@kiffer.be>
Subject Re: [general] Reduced footprint class library
Date Fri, 19 Sep 2008 11:20:01 GMT
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?



Chris Gray        /k/ Embedded Java Solutions      BE0503765045
Embedded & Mobile Java, OSGi    http://www.k-embedded-java.com/
chris.gray@kiffer.be                             +32 3 216 0369
Skype: k.embedded.chris

View raw message