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) Kathey
