[osgi-dev] Best practices regarding 'static' variables and methods

Richard Gomes rgomes1997 at yahoo.co.uk
Wed Sep 16 17:58:54 EDT 2009


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
>> osgi-dev at mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev at mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.osgi.org/pipermail/osgi-dev/attachments/20090916/14173dd1/attachment.html


More information about the osgi-dev mailing list