Question

While refactoring some code I stumbled over this oddity. It seems to be impossible to control the strictfp property for an initializer without affecting the entire class. Example:

public class MyClass {

    public final static float[] TABLE;
    strictfp static { // this obviously doesn't compile
         TABLE = new float[...];
         // initialize table
    }

    public static float[] myMethod(float[] args) {
         // do something with table and args
         // note this methods should *not* be strictfp
    }

}

From the JLS, Section 8.1.1.3 I gather that the initializer would be strictfp if the class would be declared using the strictfp modifier. But it also says it makes all methods implicitly strictfp:

The effect of the strictfp modifier is to make all float or double expressions within the class declaration (including within variable initializers, instance initializers, static initializers, and constructors) be explicitly FP-strict (§15.4).

This implies that all methods declared in the class, and all nested types declared in the class, are implicitly strictfp.

So, the modifier is not accepted for the static initializer, and when applied to the entire class, everything becomes strictfp? Since there is no opposite to the strictfp keyword, this is impossible to achieve?

So, am I screwed to use a static method to hold the body of the initializer block to achieve precise control over strictfp’dness?

Answer 1

Using the requirements that:

• the initialization code is called once,
• the MyClass.myMethod method is non-strict floating-point,
• the class API is not “littered” with methods,
• and the initialization code is strict floating-point

… this will suffice:

class MyClass {
  //1) initialized/called once
  public final static float[] TABLE = MyClassInitializer.buildSomething();

  public static float[] myMethod(float[] args) {
    //2) non-strict
  }
}

//3) doesn't "pollute" the MyClass API
class MyClassInitializer {
  strictfp [static] float[] buildSomething() { //4) strictfp here or on the class
    //TODO: return something
  }
}

If you think of the static members of a class as objects in a separate, singleton object, the above example will seem natural. I think this plays very nicely with the Single Responsibility Principle.