On Mar 23, 7:12 pm, d...@dagon.net (Mark Rafn) wrote:
OP, instead of instantiating all classes in a package, how about
instantiating all classes located within a specific directory on the local
harddrive?
Jason Cavett <jason.cav...@gmail.com> wrote:
Each class will implement the same interface.
Each class will exist in the same package.
As stated, it's impossible. s/package/searchable location/ and you're golden.
I want a way (without knowing the actual names of the classes in
package X) to instantiate those classes. This way, developers can
continuously add new rules (errors and warnings) and the JAR can
easily be redistributed just by packaging it up and pushing it out to
the main system.
Great. A jar is a searchable location. It's nearly trivial to list all
class files in a given subdirectory of a jar, and you don't even need
reflection to access them.
Use the java.util.jar.JarFile#entries method to list files in the jar,
translate them to classnames, and call
Class.forName(className).isAssignableTo(yourInterface)
to see if it's the right interface.
Any additional suggestions on how to do this?
The above is very easy to write.
P.S. Another alternative I thought of is have some sort of
configuration file where a developer adds the name of his class to the
config file every time he adds a new class. The major problem with
this is, 1, it will have to be read every time the error checker is
run and, 2, it is prone to error if a developer types the class name
incorrectly.
The config file will be faster than scanning the jar, and is a much more
direct reflection of developer intent than trying to discover things by magic.
It also allows the implementation to be in a different jar (or non-jar
classpath location) and still be found by your app.
I'd HIGHLY recommend using the config file.
--
Mark Rafn d...@dagon.net <http://www.dagon.net/>
Indeed. This is called Inversion of Control, and is a great boon to
complex, extensible designs.