harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [general] Reduced footprint class library
Date Fri, 19 Sep 2008 12:05:20 GMT
Chris Gray wrote:
> On Thursday 18 September 2008 17:31, Tim Ellison wrote:
>> 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?

I think it depends on the world you envisage when somebody steps outside
the scope of the released artifact:

If you assume a 'closed' world, then I suggest you don't want to have
these 'mines' left in the runtime, because when somebody calls such a
method you will get a guaranteed runtime exception (ClassNotFound or
whatever).  So, as you say, in a closed world the choice is either to
pre-process the source code to remove the methods, or post process the
class files to hide/remove them.  Either way you are not binary
compatible with SE.

If you assume a 'dynamic, connected' world, then you would leave the
methods in and download/expand the runtime when somebody uses a missing
method.  Provided the application stays within the boundaries of the
released artifact all is well, but it would mean that the first call to
BeanInfo.getIcon() takes a really long time while the runtime goes off
to fetch AWT !


View raw message