Code quality rule for finding non threadsafe singleton spring implementations

Question

Is there any Checkstyle, PMD or Findbugs rule which could find the following non threadsafe spring singleton implementation?

private String helperVar;

public String getValue(String value) {
   helperVar = value;
   return convertValue();
}

private String convertValue() {
   return helperVar.trim();
}

I know this sample is horrible but it is the easiest way to show what I mean.

When executing the getValue method from the bean in a single execution it would work fine. But when executing it in a multi user environment it would lead to unpredictable errors/behaviour.

Is there a way to find these occurences without going through the code manually? Are there any static code checkers which could check this and each variation of it automatically?

Answer 1

This might not be acceptable to you but I sometimes employ runtime bean reflection to validate code consistency.

For your use case I would first make all of my beans use constructor based injection and make all member fields final. I believe findbugs even has some immutable bean checkers.

Second to do the code consistency for your use case I would use either Spring BeanPostProcessor or just a class that implements ApplicationContextAware and then walks the ApplicationContext. Now you just check the beans that get loaded in the application context that are yours (just check the package name of the beans class) to make sure that all the fields are final. Yes you will need a more lax security manager or enable your security policy to allow private variable reflection but for most this is not a problem especially if your already using something like hibernate.

If there is a field that is not final ie invalid code you just throw an exception and your Spring app will not start.

For various exceptions to the rule you could use custom annotations for fields that need not be final or classes thats need to ignore the rule.

You might be concerned with performance or that Spring constructor injection is not powerful enough but Spring already does an enormous amount of reflection anyway on boot up and constructor based injection has gotten rather powerful these days such that you can even do property place holder values with @Value(${PROP}).