tag:blogger.com,1999:blog-7530126026798191467.post1185576366666654739..comments2023-04-18T09:31:11.711+01:00Comments on Simon's blog: OSG-whySimon Maplehttp://www.blogger.com/profile/01598225687431093637noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-7530126026798191467.post-73734475375454685692011-03-03T19:36:55.379+00:002011-03-03T19:36:55.379+00:00Hi Francisco,
Thanks for reading and commenting. ...Hi Francisco,<br /><br />Thanks for reading and commenting. The Java access modifiers, such as private, public etc, police code at compile time rather than runtime. However, have you found that quite a few of your classes should be public to a range of classes/packages/jars, but private to others? This is where OSGi fits. <br /><br />Lets take an example: Imagine a collection of packages containing a collection of classes all contained within a JAR file. This JAR may be a component in a larger system. It will contain some classes it wants to expose to other JARs or components, and some classes that should remain internal. These internal classes, perhaps utility classes for the component, are marked as 'public' so that all classes in the same component can make use of their function, irrespective of which package they are in. This function is internal function that should only be used in the component or JAR it exists in. But nothing restricts any other class in the flat Java classpath to access that function. This is where OSGi steps in.<br /><br />OSGi can mark JARs with metadata to protect the code within. JARs with appropriate OSGi metadata (OSGi bundles), police which packages can and cannot be accessed outside of the JAR, as the metadata specifies which packages are exposed and which are not, among other things.<br /><br />Separating the API and SPI interfaces does make good programming sense. However, APIs and SPIs are typically coupled which means there is a level of interaction between them. In other words, they are both marked as 'public' to enable them to talk to each other. Referring to my previous point, this does not add any policing once the code is in runtime and both interfaces are public and accessible.<br /><br />I'm constructing an youtube Enterprise OSGi channel which will host short overviews and presentations based around OSGi. I will launch the channel next week and post the links here. <br /><br />Thanks -- SimonSimon Maplehttps://www.blogger.com/profile/01598225687431093637noreply@blogger.comtag:blogger.com,1999:blog-7530126026798191467.post-46760086291760240442011-03-02T12:14:41.692+00:002011-03-02T12:14:41.692+00:00when you said Nothing at runtime is policing the a...when you said Nothing at runtime is policing the accessibly between the classes, what about the Java Access Modifiers, is't this a patch for a bad design?. could you give a example where a very clear solution is osgi?<br /><br />and when you said Java has no easy way of controlling the split between API and SPI interfaces. Why do you not separate the interfaces and the implementation in different project? separate the API and API would fix the problem?<br /><br />I find great OSGi, but still don't get it enough, could you give me or recommend, some book, site, anything where i could clear my doubts? <br /><br />Thanks<br />FranciscoFranciscohttps://www.blogger.com/profile/01306477954049863051noreply@blogger.com