> tricks aren't always good ;) if you take a > step back and explain 'why' you want to > import a single, not-known-before-hand, > unversioned class into your application > then it would help others suggest solutions
He he... yeah, tricks... Well, essentially I have a framework that accepts classes abstracted to a certain type. For simplicity, let's just use a concrete example: Vehicle. I don't want the framework to know anything about the domain specifications of Vehicles (like Automobile, Bicycle, Skateboard [hey, why not?], etc.). The framework just does some really generic stuff on the Vehicles, like managing lifecycles and such. However, to actually be useful to consumers (ex: UI dev and such), I need to cast each Vehicle to its particular domain. Currently, I see two ways of doing this, each one requiring the client to do the casting: First old-school way: Vehicle vehicle = service.getVehicle( "1234" ); Automobile auto = (Automobile)vehicle; Second way using generics: Automobile auto = <Automobile>service.getVehicle( "1234" ); Third way using dynamic proxies: VehicleInvocationHandler = service.getHandler( "1234" ); Automobile auto = (Automobile)Proxy.newProxyInstance( ... ); I don't like the first way or the third way, since I want to hide this kind of cruft from the client. I don't like the second way because in my implementation, generics are already getting out of hand with calls like (no exaggeration): Vehicle<T extends B<V>, V extends X, W, Y extends Date> I really like generics, but this is getting bloody ugly, not to mention brain racking... So, my idea was to work with the third way (dynamic proxies), since this is the cleanest, but move the creation of the proxy to the host framework bundle. Only problem is that I get my CNFE. So, I need to be able to load the interface into my bundle so I can cast the dynamic proxy. Cheers, David _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
