Rhett,

I was originally thinking along the lines you have suggested.  In fact, 
I have been vaguley thinking along these lines for some time, triggered 
by the build contortions we have seen in the past.  My preference is to 
sort out as much as possible (and feasible) at run-time.  However, 
because I have no experience in the complexities of class loaders, etc, 
I was loathe to suggest it.

I'm with you in trying to alleviate as much of the burden as possible 
for users.  At the end of the day, the product that is the easiest to 
set up and use has a huge advantage.  Ask Microsoft.

Peter

Rhett Aultman wrote:
> Peter,
> 
> Rather than building multiple version dependant JARs
  and having users select the best one, perhaps we could,
  behind an interface that effectively hides the issue,
  detect the version of the VM being run and dynamically
  load appropriate handler classes?  This alleviates the
  burden of users selecting appropriate JARs.
> 
> As you said, it does increase complexity, and the only
  case we're dealing with thus far can be solved in other
  ways, but I suspect that this is a problem that's only
  going to grow over time as we find other JVM version
  (and *VENDOR*) inconsistancies.


-- 
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to