Francois Orsini wrote: > Copying common classes to specific (tier) packages does sound good - > However, it is true that there could be confusion during development and > debugging if the engine and client common classes are not up to date > (did not get re-generated) and if some developers do not necessarily > understand how the 'common' package is managed in the codeline.
Sun seems to be thinking about this approach for J2SE, namely changing the package names of the Apache parser into the com.sun domain to avoid version confusion. :-) Here's an FAQ from http://java.sun.com/xml/jaxp/faq.html <quote> Q. Why are there Apache classes in the J2SE 1.4 RI? The J2SE 1.4 RI is the first version of the JDK that bundles in an implementation of JAXP 1.1. This allows developers to write applications without having to provide a parser and XSLT processor with their application. However, in some cases, it may create additional problems. The Sun J2SE 1.4 RI uses Apache software for its implemenation of JAXP 1.1 with package names unchanged from Apache software distributions. This can cause problems, for example, if your application wants to use a newer version of Apache software. Under the Java 2 class loader delegation model, the java launcher's ClassLoader will load the bundled version of a class before any other version. Thus, if you place a newer version of xalan.jar on your CLASSPATH, then that version will be ignored since the runtime will use the older bundled version instead. As a workaround, see the question on overriding the implementation in J2SE SDK 1.4. The future plan is to rename the org.apache.** packages to be something like com.sun.org.apache.** to fix this problem. In addition, other package-dependent parts of the software may also need to be modified. However, because of lack of resources, this may not be done until after J2SE SDK 1.4.1. </quote> Dan.
