Re: Generics: instantiating an object from a class name in configuration

From:

Roedy Green <see_website@mindprod.com.invalid>

Newsgroups:

comp.lang.java.programmer

Date:

Fri, 09 Jul 2010 22:27:09 -0700

Message-ID:

<301g361utfoul8rr843pgcnkfvg6ssgcqr@4ax.com>

On 9 Jul 2010 23:07:32 GMT, Simon Brooke
<stillyet+nntp@googlemail.com> wrote, quoted or indirectly quoted
someone who said :

OK, here's a problem which many people must have encountered, and there
must be a 'best practice' solution.

I have a thing which is configurable by plugging other things into it.
Obviously the other things I plug in must conform to specific interfaces,
but what thing I actually plug in is determined at run-time by reading
the name of the plugin class from a configuration file. An example (in
Java 1.4) is as follows:

1 String v = config.getValueAsString( "authenticator_class");
2
3 if (v != null) {
4 Class authenticatorClass;
5
6 try {
7 authenticatorClass = Class.forName( v);
8 } catch (ClassNotFoundException c) {
9 throw new InitialisationException(
10 "Could not find class [" + v
11 + "]", c);
12 }
13
14 try {
15 authenticator =
16 (Authenticator) authenticatorClass
17 .newInstance();
18 } catch (ClassCastException e) {
19 throw new InitialisationException(
20 "Not a valid authenticator class", e);
21 } catch (InstantiationException f) {
12 throw new InitialisationException(
23 "Could not instantiate authenticator", f);
24 }
25 }

Obviously one can vacuously 'bring this up to date' by changing line 4 to

4 Class<?> authenticatorClass;

but I feel that the right thing to do must surely be to use

4 Class<Authenticator> authenticatorClass;
5
6 try {
7 authenticatorClass =
(Class<Authenticator>) Class.forName( v);
8 } catch (Exception e) {

then if the class specified did not inherit from Authenticator a
ClassCastException would be caught at line 8, and the second try/catch
block might become redundant. However, if I do that, Java 1.6 gives me a
warning at line 7:

'Type safety: Unchecked cast from Class<capture#1-of ?> to
Class<Authenticator>'

Eclipse offers to fix this by adding an @SuppressWarnings clause, but I'm
not sure I want to suppress warnings...

What is the preferred pattern in Java 1.5/1.6, and why?

here is how I handle that:

// Make sure the class we dynamically load implements the
// Configuration interface:
final Class<? extends Configuration> configurationClass =
Class.forName( binaryClassName ).asSubclass( Configuration.class );

configuration = configurationClass.newInstance();
--
Roedy Green Canadian Mind Products
http://mindprod.com

You encapsulate not just to save typing, but more importantly, to make it easy and safe to change the code later, since you then need change the logic in only one place. Without it, you might fail to change the logic in all the places it occurs.