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 16:03:05 GMT
On Friday 19 September 2008 14:05, Tim Ellison wrote:
> 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.

For me the normal use case is that the world is 'closed' wrt java.* and 
javax.*. This is the case when for example an OSGi bundle is compiled against 
a given Execution Environment - specifiying the EE is like a shorthand for a 
manifest entry "Import-Package: java.lang,java.util,java.net,java.io, ...". 
The developer of a module needs to know something about the environment it 
will run on; if java.awt and/or javax.swing are not supported then this makes 
a big difference. In this case it is best to remove the unsupported members 
from the class, so that an attempt to use them can be detected at compile 
time instead of at run time.

> 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 !

Well, the first call to AWT normally takes some time to execute anyway ... for 
me java.awt is not a particularly likely candidate for this kind of lazy 
loading, but anyway I can see that it could make sense to ship the VM with 
some minimal set of packages and to download others on demand. In that case 
maybe the bootstrap or extension classpath could contain "placeholder" jar 
files which contain only and INDEX.LST and a pointer to where the "real" jar 
can be found. The index is needed so that the bootstrap classloader knows 
which classes are to be loaded from the referenced location; the first time 
one of these has to be loaded, the bootstrap classloader goes and fetches the 
"real" file and overwrites the placeholder with it. From that point on 
loading proceeds as normal ...

In this case you would certainly leave the unresolvables in the class file, 
they will be resolvable when the time comes.

I can see this working in Mika, in fact I'm tempted to implement it 
already. :-)



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