[Mulgara-general] Mulgara Lite

[Life is hard, and then you die]

On Thu, Sep 04, 2008 at 10:05:13AM -0500, Paul Gearon wrote:
> On Thu, Sep 4, 2008 at 3:55 AM, Life is hard, and then you die
> <ronald at innovation.ch> wrote:
> > On Wed, Sep 03, 2008 at 02:47:43PM -0500, Paul Gearon wrote:
> >
> > Sounds good. However, how much is the network stuff, i.e. how is the
> > difference between the two jars? Having too many jars to choose from
> > is also annoying, so I would vote to only have two if the difference
> > in size is significant.
> 
> Well, I can't quite remove all the network stuff yet, though I can
> iteratively reduce it over time. For instance, EmbeddedMulgaraServer
> directly refers to Jetty classes, so I can't simply remove the Jetty
> jars, however if I isolate that code in another class (something that
> should be done anyway) then I can call that up with reflection,
> meaning that the Jetty jars will only be needed when Jetty is
> configured.

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.

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.


  Cheers,

  Ronald