[Mulgara-general] Mulgara Lite

[Paul Gearon]

On Thu, Sep 4, 2008 at 4:53 PM, Life is hard, and then you die
<ronald at innovation.ch> wrote:
> This is something I meant to bring up after seeing ticket #146: I
> think using reflection for this sort of stuff is a _really_ bad idea,
> because you silent breakage. E.g. 80% of the SessionFactoryFactory
> code is broken because it uses reflection to invoke methods that have
> long since changed their signature and the compiler doesn't catch
> that.

Actually, I think that's just poor programming practice. Reflection
can be great for loading things under lots of circumstances. However,
if loading fails, it should ALWAYS be reported. The system ought to
continue after failing to load something that was dynamically
configuration (unless it was the core package), but to do so silently
is a really bad idea.

> Additionally, there's no need to resort to reflection to avoid runtime
> dependencies (if you want to avoid compile-time dependencies then yes,
> you'll need reflection). Java class-loading does specify a certain
> amount of lazyness, so that you can avoid classes from being loaded
> that are not used. Generally, if you have a classes A that uses a
> class B in some piece of code but that doesn't have a field of type B
> or subclasses B or otherwise statically references B (imports don't
> count), then B will not be loaded until that piece of code is actually
> run the first time.

This lazy loading did cross my mind just after I submitted it, but at
least I got my point across.  :-)  The idea is to isolate this code so
that the Jetty classes are not required unless they're configured.
Using lazy loading or reflection are both ways to do it.

(I admit that reflection should always be avoided unless you really do
need it - but it was waaaay after midnight when I typed the ticket).
:-)

Paul