"This is almost already what happens behind the scenes[...]" Deeper behind the scenes javac will complain. And if you trick javac, the runtime will complain. And if you trick both javac and the runtime, you have went out of your way to do so, probably by encoding type info in a non-type and then explicitly casting in application code.
Service properties are not checked either statically or dynamically. Types are checked *both* statically and dynamically. Using the former to hint at the latter only makes sense if the type system can't express what you want. At least that's my narrow world view. :) I get what you're saying, but there's no reason not to use the type system if you can - that I can think of. On Thu, Dec 19, 2013 at 5:14 PM, CLEMENT Jean-Philippe < [email protected]> wrote: > From my point of view there are only few scenarios where the introspection > is mandatory. > > The question is why the method would not be in the API? If the method > exists in the implementation, so there nothing that prevents it to be > present in the API. Or you can want something from an object which is not > directly implemented in the object itself (so it cannot be declared as > service - not directly). This is the point where aspects start. > > JP > > > > -----Message d'origine----- > De : Per-Erik Svensson [mailto:[email protected]] > Envoyé : jeudi 19 décembre 2013 16:29 > À : [email protected] > Objet : Re: Reflection > > "[...]which have different methods that can be called." > > This is a type problem. You can publish each service as a set of types. > For example, following Stijn's example, publish the EpsonWF2530 as an > EpsonPrinter and a Printer. Your consumers will now be able to do a > "proper" type filtering, asking for an EpsonPrinter and call "epsonPrint" > on it, if this is what they need. > > Service properties are "ok" when you need a specific Printer with a > certain implementation of print. It isn't a solution to the problem where > you need a Printer with a method not in the API. > > In short, use types to encode type information. > > Service properties fall under "stringly typed solutions". Sometimes they > are needed because the type system isn't expressive enough. Like the well > known problem of storing dates as strings in JSON, because JSON has no date > type. Going to the extreme, why not publish all services as "Object" and > filter on "class=org.acme.MyClass". > > All that said, pragmatism is probably more worth than idealism. :) > > > On Thu, Dec 19, 2013 at 11:26 AM, Stijn de Witt < > [email protected]> wrote: > > > Let's say you have a service interface like this: > > > > interface Printer { > > void print(); > > } > > > > You could have multiple implementations (for different hardware): > > > > class ConsolePrinter implements Printer { > > public void print() { > > System.out.println("Hello World!"); > > } > > } > > > > class EpsonPrinter implements Printer ... > > class CanonPrinter implements Printer ... > > > > Each implementation can be registered in the service registry on the > > same interface, but with different OSGi service properties. Consumers > > can then add a filter when querying the OSGi service registry to get > > the implementations suitable for their purposes. E.G. by adding: > > > > (Printer-Brand=Epson) > > > > it could pick the EpsonPrinter without ever having to know that that > > specific class exist. It only knows the interface and some properties > > to filter on. > > > > -Stijn > > > > > > -----Original Message----- > > From: Neil Bartlett [mailto:[email protected]] > > Sent: maandag 9 december 2013 14:02 > > To: users > > Subject: Re: Reflection > > > > The service interface represents the standard API. It is not necessary > > for clients to use reflection to find the methods of the service: they > > are compiled against the service interface. > > > > However at runtime, the service implementation can change... so long > > as it provides the methods specified in the service interface. > > > > > > On Mon, Dec 9, 2013 at 12:54 PM, Snorre Lothar von Gohren Edwin < > > [email protected]> wrote: > > > > > Ok I see where you are going with this. > > > But what if one have a standard api with different hardware types > > > behind, which have different methods that can be called. > > > Im having troubles in seeing how this can be done dynamically? > > > > > > > > > On Mon, Dec 9, 2013 at 1:51 PM, Neil Bartlett <[email protected]> > > > wrote: > > > > > > > On Mon, Dec 9, 2013 at 12:44 PM, Snorre Lothar von Gohren Edwin < > > > > [email protected]> wrote: > > > > > > > > > Is reflection the way to go to handle a dynamic OSGi environment > > > > > > > > > > > > No. > > > > > > > > > > > > > or are > > > > > there other customs or patterns to use? > > > > > > > > > > > > > SERVICES! :-) > > > > > > > > > > > > > In other words, is this heavily used in OSGi? > > > > > > > > > > > > > No. > > > > > > > > > > > > > > > > > > -- > > > > > Mvh > > > > > Snorre Lothar von Gohren Edwin > > > > > MeetMe: http://doodle.com/vonGohren > > > > > +47 411 611 94 > > > > > > > > > > > > > > > > > > > > > -- > > > Mvh > > > Snorre Lothar von Gohren Edwin > > > MeetMe: http://doodle.com/vonGohren > > > +47 411 611 94 > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
