On 9/16/05, David W. Van Couvering <[EMAIL PROTECTED]> wrote: > I appreciate your pragmatic approach, Andrew. The thing is I have seen > a number of other pieces of functionality queued up for code sharing > between client and server. These include DRDA network code, potentially > some higher-level JDBC functionality, logging and tracing, and > management via JMX. I also discovered that the versioning mechanism in > org.apache.derby.iapi.services.info is actually reused across tools, > client and engine.
This is true, I realize that there are a lot of opportunities for code sharing and reuse. I just don't know if *this* is the one that is worth it. I think the way these possible code-sharing opportunities should all be handled is for someone to implement some new functionality as a module and package it into a new *optional* jar file. The new code can be used if it is present, and the old code can be deprecated, but remain packaged for a certain number of releases before it is removed, if it is removed. This gives users time to prepare for a change and developers to work through all the issues without causing any unnecessary pain along the way. Do we really want to go to this trouble for the client localization functionality? I don't know. To me, logging seems like a better first project for that. > We may still decide this is intractable and throw up our hands, but I > hope that's not the case. It's been a healthy debate, and has brought > to bear some good discussions about "who" we want to be, what our key > principles are, and I think that's been good too. I agree, it's been a good healthy debate, but I thought it might be good to reflect upon the task at hand. :-) > You talked about signing/sealing problems about packaging the classes in > multiple jars. I saw this mentioned before, can you or someone else > elaborate? When a jar is sealed, classes cannot be loaded from multiple if the package they are in is sealed. You can unseal specific packages, so that's less of an issue than for signed jars. I believe attempting to load the same class from different jars if the jars are signed will cause a SecurityException, but I'm not well versed in the ins and outs of signed jars. andrew
