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. :-) 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
