Technical tidbit

  1. Microsoft and IBM researchers Ramachandran Ramjee and Shivkumar Kalyanaraman in Bangalore have figured in this year’s ACM Distinguished Scientists list. .
  2. Concurrency is a hot topic and this website 1024cores was advertised in the Java concurrency list recently.

I hope that this last post of 2010 will bode well for my technical career in the next year.

Software Assurance Maturity models

I came across links to Software Assurance maturity models in the current issue of
Crosstalk.

There are so many maturity models to choose from but to the uninitiated they might
seem to be too theoretical.

  1. “Build Security In Maturity Model (BSIMM): www.bsimm2.com
  2. Capability Maturity Model Integration (CMMI): www.sei.cmu.edu/cmmi/index.cfm
  3. Open Software Assurance Maturity Model (OSAMM): www.opensamm.org
  4. Assurance Focus for CMMI: https://buildsecurityin.us-cert.gov/swa/downloads/Assurance_for_CMMI_Pilot_version_March_2009.pdf
  5. CERT Resilience Management Model (RMM): www.cert.org/resilience/rmm.html
  6. Build Security In website: https://buildsecurityin.us-cert.gov/bsi/home.html
  7. SwA Community Resources and Information Clearninghouse: https://buildsecurityin.us-cert.gov/swa/
  8. Making Security Measurable website: measurablesecurity.mitre.org/

They serve as good points of reference and cover governance. As far as practical technical guidance is concerned I would look elsewhere.

They drive home the point that security has to be built into the product and have suggestions to address different compliance requirements like PCI-DSS using a process.

Habit of reading source code

Reading code can be very enlightening but I have been following this practice only recently.One might come across nuggets that explain a particular code pattern clearly when one reads code.
Twitter has open-sourced its ‘Commons’ library and I came across the Curiously Recurring Generic Pattern and the Self-bounding pattern in it. These two are discussed in ‘Thinking in Java’ by Bruce Eckel. He also gives an exercise at the end of Page 709.

Exercise 34: Create a self-bounded generic type that contains an
abstract method that takes an argument of the generic type parameter and
produces a return value of the generic type parameter. In a non-abstract
method of the class, call the abstract method and return its result. Inherit
from the self-bounded type and test the resulting class

The code for this exercise could be

public abstract class SelfBound< T extends SelfBound<T>>{

    public abstract T get( T t );

    public T getValue( T t){
         return get( t );
    }

public class SubSelfBound extends SelfBound{

    
    public SubSelfBound get(SubSelfBound subSelfBound) {
        return this;
    }

    public static void  main( String[] argv ){

        SubSelfBound subSelfBound = new  SubSelfBound();

        subSelfBound.test();
    }

    private void test() {

        SubSelfBound subSelfBound = new  SubSelfBound();

        subSelfBound =  getValue( subSelfBound );//The sub-class's inherited method is forced
                                                 //to take only the derived type as parameter
                                                 //and not the base type. The parameter varies
                                                 //and matches the derived type( Covariant )
        
        SelfBound selfBound =  getValue( subSelfBound );//It also returns the super type.
                                                        //This is related to the covariant
                                                        //return types according to the book.

    }
}

Even though I might not have the absolutely correct solution here the idea is clear and it is that the Curiously Recurring Generic Pattern and the Self-bounding pattern are similar and the Self-bounding pattern permits a type of covariant argument types.

I used to think only covariant return types are possible in J2SE 5 but there seems to be a way to implement covariant argument types also though the practical applications of this concept could stupify the developers because not many are
used to advanced generics.

I understood all of this by reading the Twitter Commons source code that has used self-bounding types like this.

public interface Unit<U extends Unit<U>>;{

  double multiplier();
}


If one is not used to thinking about Java generics deeply this type of code will be
hard to understand and implement.