Hi Peter, Thank you very much for your explanation.
Richard Gomes M: +44(77)9955-6813 http://www.jquantlib.org/index.php/User:RichardGomes twitter: frgomes JQuantLib is a library for Quantitative Finance written in Java. http://www.jquantlib.org/ twitter: jquantlib Peter Kriens wrote: > Static methods and variables are usually to be avoided in OSGi > services. The problem is that the life cycle of the static variables > and methods depends on the class loading life cycle. Normal instance > based services have a much more dynamic life cycle. > > Inside a bundle you can use static methods freely. Static variables > should be constrained to be in private packages because otherwise you > might have to manage their sharing. Your library could be in memory > multiple times. > > In short, avoid static variables you make your code much more rigid. > Static methods that do not maintain state are ok. Hope this helps. > > Kind regards, > > Peter Kriens > > > On 15 sep 2009, at 15:06, Richard Gomes wrote: > >> Hi, >> >> As this is my first post, let me first quickly introduce myself: >> >> I'm Richard Gomes, lead developer of JQuantLib >> http://www.jquantlib.org/. >> At the moment, we are preparing some of our code for a proof of concept >> running on top of OSGi containers. >> I've done some tests with Felix, Equinox and Newton. I've also studied >> the various programming paradigms: raw API, DS, iPOJO and a a very >> little of Spring DM. I selected DS for my tests. >> >> If you are impatient, my question is will pre quicker and very >> imprecise: >> "Are private static variables a good practice from the OSGi container >> point of view?" >> >> Thanks a lot for any help, opinions, etc which will be very much >> appreciated. >> >> >> >> If you are patient, I'd like to expose an use case and I'd like to be >> more specific: >> >> Suppose the following class: >> >> class WithoutOsgiInMind { >> public int getA() { ... }; >> static public double getX() { ... }; >> } >> >> As static methods cannot participate in interfaces we have to find >> another way to declare them. >> >> OK. We can make static methods look like non-static methods via a sub >> interface. >> Our class of interest can implement the interface and an inner class can >> implement the sub interface. >> More or less like this: >> >> public interface ABC { >> public int getA(); >> >> public interface XYZ { >> public double getX(); // mimics :: static double getX(); >> } >> } >> >> >> public class ABCimpl implements ABC { >> >> private int a = 10; >> >> public int getA() { >> a++; return a; >> } >> >> >> private static final X = 1.2; >> >> private static final class XYZimpl implements ABC.XYZ { >> >> private XYZimpl() { /* outside world cannot instantiate */ } >> >> public double getX() { >> return X; >> } >> } >> >> } >> >> >> So, the next step is expose the static inner class somehow. >> One idea would be provide a public method in interface ABC (and ABCimpl) >> which returns the inner class. >> Something like this: >> >> public class ABCimpl implements ABC { >> ... >> public statics() { >> return statics; >> } >> >> private ABC.XYZ statics = new XYZimpl(); >> ... >> } >> >> This solution is not very convenient from the API usage point of view >> because it oblige us to eventually instantiate an ABC object just >> because we are interested on its static methods implemented by XYZ sub >> interface. Like this: >> >> double d = new ABCimpl().statics().getX(); >> >> Another possibility would be expose an static variable which provides >> access to the inner class: >> >> public class ABCimpl implements ABC { >> >> public static final ABC.XYZ statics = new XYZimpl(); >> ... >> } >> >> ... which allows us to call like this: >> >> double d = ABCimpl.statics.getX(); >> >> Well, the later solution does not sounds well because it explicitly >> references implementation ABCimpl. >> But... if we remember that ABCimpl acts as a service class, injected by >> DS, our code would be: >> >> // injected by DS >> void setABC(ABC abc) { >> this.abc = abc; >> } >> >> ... >> >> double d = abc.statics.getX(); >> >> >> Another idea would be inject XYZ interface directly: >> >> // injected by DS >> void setXYZ(XYZ xyz) { >> this.xyz = xyz; >> } >> >> ... >> >> double d = xyz.getX(); >> >> >> Now my question can be rewritten more precisely: >> >> Is this the correct approach to expose static variables? Am I making >> things more complicated than it should be? >> >> Regards >> >> -- >> >> Richard Gomes >> M: +44(77)9955-6813 >> http://www.jquantlib.org/index.php/User:RichardGomes >> twitter: frgomes >> >> JQuantLib is a library for Quantitative Finance written in Java. >> http://www.jquantlib.org/ >> twitter: jquantlib >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
