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 ! Regards, Tim
