the debugger API.
And one method that is relatively "nice", using a fairly simple subset
of reflection, is serialization.
Say you have a plugin architecture with, say, pluggable codecs. You
employ the strategy pattern and create a Codec interface that has
encode() and decode() methods, among others, and supply some
implementations. But you also provide code that runs at startup or
when a user picks "Scan for plugins" from a menu that looks in a /
plugins directory someplace looking for ".codec" files, which are
actually serialized instances of Codec objects. It reads these one by
one with an ObjectInputStream and casts each to Codec; if a
ClassCastException is thrown, it's ignored and so is the object that
was loaded; same if any of the various serialization exceptions or
IOExceptions are thrown. NoClassDefFound? Discard.
ObjectStreamException? Discard. The surviving objects are added to the
collection of Codec objects the program maintains. Perhaps there's an
initialize() method on these, and the ones that are newly added (using
a Set allows detecting which are really new) get this run, adding
particular "Save As" options that go through their respective encode()
methods. Perhaps the program tries to decode files opened with "Open"
by invoking each one's "decode()" in turn until one of them returns
something other than null (or doesn't throw some exception); the new
ones now get a crack at decoding any opened file.
This requires, on the programmer's part, no nastier reflection code
than code to deserialize objects (and, in some SDK somewhere, to
serialize them so plugins can be made). A plugin's installation
requires only that some .class files (perhaps wrapped in a .jar) go
into the application's classpath and a .codec file go in the
application's plugins directory. Likely that plugins directory is on
the app's class path and contains the plugin classes as well.
and loading serialized bean instances. See sections 10.3 and 11.8 of