I suspect this is adequate for the problem user Dan has identified: the
novice Java developer who doesn't understand classpaths. I suspect that
we will not come up with a bullet-proof solution for advanced users who
experiment with tricky techniques for faulting in classes. I would err
on the side of keeping it simple.
-Rick
Francois Orsini wrote:
This issue reminds me of the database deadlocks issue - you can't
completely get rid of them but you can do a good job at
preventing/reducing them...
I think it has been proposed before but can't we have the very first
class of the network Client driver and Server check for a
legitimate/compatible version of the common classes (package) via a
Version class and a static method being passed the caller's version
number - this can be done with a static block early on on the
ClientDriver class for instance (for the client part) - The common
Version class could have a compatibilty table (matrix) if we need more
advanced compatibility check computations...If the common package is
compatible (based on the compatibility table) then all is fine,
otherwise a (runtime) exception is raised in ClientDriver. I do _not_
think we need to check for all interfaces as long as we preliminary
checked on Version.checkIfCompatible(versionNumber) early on via the
static block - I think we could assume that if you get the proper
Version class from the common package and it is compatible, then the
rest of the common interfaces should be compatible as well since they
would get loaded in the same order as the common Version class which
has been identified as (version) compatible. Sure people could come up
with twisted scenarios shooting themselves in the foot, but at the end
I think we want to be able to address the majority of the
cases/situations...just some more thoughts...
--francois
- Re: Sharing code Rick Hillegas
-
