Jeff Don’t be too surprised OSGi is rather elegant It is minimalist and unpresumptious This is awesome as it keeps system size down But it is a system's level programming model. - APIs are low level - Dynamics are hard, cause, well, dynamic stuff is hard and there is not a lot of help Fundamentally, OSGi is an implementation detail, an enabling element. For most people is it something to be hidden from view
Sometimes its better not to know whats around you Programming POJOs help isolate you from the OSGi gorp Really we are talking about dependency injection and a style of coding. - Encourages reuse - eases testing - Clarifies design and dependencies This is a pervasive theme throughout this talk In short: Its bad mojo to pollute the POJO
Chris
chris
Martin
Jeff Imagine this Hello <cable co> my TV is not working string another line Keep doing that until the price of copper skyrockets and someone steals the pole Know the bundle food chain Minimizing your dependencies improves reuse Improves freedom of action
Paul Using services as the unit of reuse is preferred over just sharing packages: -lifecycle management -pluggability DS is better than Service Tracker: -for a bundle needing two services..... -100 lines of code vs 8 lines of XML -error-prone -required hours of effort from experts DS: -encourages good componentizaiton -allows lazy classloading -nice tooling ServiceTracker: -too easily ties your code to OSGi -makes testing and reuse more difficult -pollutes the POJO (bad mojo)
this is for a bundle requiring two services
Paul just because something in your application needs to be registered, it does not mean that you should make that thing a service and use the service registry -whiteboard pattern can easily fall into this trap -example: student registers for a course. student is NOT a service -core & other utility classes -HashMapFactoryService counter-example
Jeff OSGi is a bit of a fairy tale story. The small but secretly powerful modularity system That runs around brings dynamism to everyone Yeah, well, sorry, but fairy tales are just that, fairy tales. <any kids in the room?>
Oh, and BTW, …
Dynamics are not free Real work is needed Analogous to running multi-threaded – you have to code for it. not for everyone Relate to Eclipse adoption
Paul
Paul OSGi is not omnipresent -If you’re spending all your time writing OSGi-related code, you’re doing it wrong! OSGi is not infallible -Plenty of crap in the OSGi holy scriptures: Wire Admin, Event Admin… -OSGi is not omnipotent Not everything OSGi provides is ideal for your application ConfigAdmin