You can't "call" a class. You "load" a class. You "call" a method within the class.
The parameter of Class.forName() is the fully-qualified (i.e. including the package) class name.
There are many disadvantages of using dynamic class loading and reflective method calling. The code has far fewer compile-time checks, so bugs can more easily get into the running code. The code is much more verbose and harder to read. One would never use it unless it is actually necessary (or if one is just doing it as an exercise).
Dynamic class loading and reflective calling of methods can do things that are simply not possible any other way. For instance, loading a class whose name is defined in a configuration file, whose contents are only known at run-time. For this reason, they are great features, but not to be used at random.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Is the parameter inside Class.forname(parameter) a fully qualified path of the class? Yes, always.
Are there any disavantages of calling a class dynamically? Things have improved dramatically since Java 1.2, where reflection took about 200 times longer, and while it won't be this bad the code will still be slower, even if you cache references (methods, constructors, fields etc) after discovering them.
Muni K Reddy
Joined: Aug 23, 2007
Thanks very much for you replies! I now got myself confused a bit by reading the the following in an article:
Can you avoid changing the code you have already written and tested to add new functionality? Can you add new classes to your program without having to recompile the whole thing? The answer to both questions is yes, and as you might have guessed, is based on interfaces and dynamic class loading.
If there is a need to add functionality to your own classes, why would you be using dynamic loading? I will always know all the methods in it so why not use the "new" keyword and do a static loading to load the classes and add functionality??
Here's the article!Im still trying to understand the example in the article and would like to know if the given dynamic loading example is the correct design pattern for such scenarios!
Would be glad if someone could help me clarify my confusion! [ September 17, 2007: Message edited by: Muni K Reddy ]
There are only a few patterns where doing dynamic loading would be your first choice. If you know what class you want to use, call one of it's constructors with "new".
However, if you don't know what class you're going to be using, you could do dynamic loading. For example, maybe you have a "RuleSet" interface. Perhaps you have several classes that implement this and you routinely add more. Perhaps you want to store information in a database (maybe about a Procedure, ManufacturingStep, etc) - you can store the fully qualified classname of the RuleSet that belongs to this record and load the class dynamically using this value. There are, of course, other ways to solve this problem, and other problems that lend themselves to dynamic class loading.
Hopefully that gives you a better idea of where and when you'd use dynamic loading. Assuming you're going through this for learning, here's an idea of how you could use dynamic classloading to call an "apply" method (totally off the top of my head - untested):
-- File rule/set/RuleSet.java
-- File rule/set/BasicRuleSet.java
-- In some other class
Hope that helps!
Muni K Reddy
Joined: Aug 23, 2007
Todd, Thanks a lot. Just loaded a class dynamically! That was a beautiful explanation! Owe you a beer!
I use things like this all the time ... using RuleSet from the last examples ...
This code can be "closed" to future change, but "open" for extension by adding new RuleSet implementations. We can put new key-ruleClass pairs in configuration and load them without touching this code.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi