On Jul 29, 7:41 am, Streets Of Boston <[email protected]> wrote: > You are changing the public set of interfaces in Interface.jar by adding a > new Foo2 interface. > You are trying to have clients with an 'old' Interface.jar (ones without > Foo2) interact with an Implementation based on a 'new' Interface.jar. This > won't work. > > Older clients have to update their Interface.jar first before they can make > use of implementations (compiled into Implementation.jar) of Foo2 or > implementations that indirectly may use or load Foo2.
What I would like to be able to do is support both old and new clients with a single implementation.jar. Older clients that don't know about the Foo2 interface won't use it and will stick with the functionality exposed in Foo, but new clients that want to can also use Foo2 functionality. The Foo2 interface is an extension of Foo, so a single implementation object would be castable to either one, and, in theory, the new implementation.jar would "match" both the old and new interface.jar. I might not be explaining the situation well, but does that make sense? This might be heresy to say, but I'm thinking of something like what MS COM does in C++, where you have IWebBrowser, IWebBrowser2, etc. There, a single implementation DLL can maintain binary compatibility with multiple nested levels of interfaces. I have written a small test program in Java that runs on a normal JVM, and this works. The difference is that the normal JVM does not complain that there is a definition of the Foo class in both interface.jar and implementation.jar, whereas the Dalvik VM throws an error in that case. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
