db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: VOTE: Principles of sharing code
Date Fri, 28 Oct 2005 18:21:29 GMT
David W. Van Couvering wrote:

> You also avoid strange behavior such as slightly different SQL States
> between client and server,

There is absolutely nothing stopping you from using the same source
property files that we have for server for client messages.  They aren't
java files so don't have the same problems of cloning and can  let you
get the  messages localized without all this controversy  I think.

<snip a whole bunch of stuff about future needs>

> In terms of your particular issue, I'd like to challenge that it is as
> bad as you say it is.
> Why would someone want to run at different patch versions of the same
> minor version in the same VM

See my response to Rick.  Nobody wants it they just get it.  It is one
totally unrelated appllication affecting another.

We need, I think, to discourage jar mixing  by changing the
documentation to encourage application developers to use classloaders to
insulate their application and protect others from it, printing warnings
to the log file when jars are mixed or there is more than one copy or
version of derby in the classpath,  providing a way to print sysinfo to
the log when  classes have been loaded with classloaders and possibly
even deprecating the ability to mix jars if the community wills it
because of the impact on development, but it can't happen overnight like
this.  It is an application developer  education issue and even those
that understand the need for classloaders now  need some notice.

> So, as I see it, this can be solved in one of two ways:
> Solution A - Port the Fix

> Solution B - Separate Out the Common Code
> You do not have this problem if the code common between the network
> client and engine is placed into a separate jar file.  

Neither of these work for the scenario I mentioned in reply to Rick's
mail.   Application A still inadvertently regresses and the user has to
change their classpath to fix it.  (But of course they first have to
figure out that is what they have to do which is the hard part)


View raw message