Bean vs Class with static methods

[pete reisinger]

Hi,
we have a util package that contains a helper class:

...
private static final javax.validation.Validator VALIDATOR;

static {
	ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
	VALIDATOR = factory.getValidator();
}

public static <T extends Object> Set<ConstraintViolation<T>> validate(
		T object, Class<?>... groups) {

	return VALIDATOR.validate(object, groups);
}

...

the idea is that validator is thread safe, so we don't want to create a new instance in controllers all the time, so we just call static methods on the class.

but this could be achieved by creating normal class, where constructor creates validator instance, and mehtods are not static and used as a bean and autowired in controllers.

application context is loaded only once so we know that validator isntance is created only once on application start.

Is it better to leave it as it is (and why) or use a bean (and why)?
Thanks

[Mark Spritzler]

Yes.

I think the difference would be where the object is held. An instance would be on the heap. But created up front, only one, so it would get into the tenure space quickly, which is a good thing.

If it is static methods, then it goes on perm gen and the stack. perm gen usually has less space in it.

I try not to have any static methods myself unless you have an extremely good reason why it has to be static.

Mark