Thanks, I'm adding a detector (http://fb-contrib.sourceforge.net/) for use of internal classes in code. I added com.sun.*** detection, and decided it probably would be a good idea to add detection of common 3rdparty apis as well.
thanks for the info. dave -----Original Message----- From: kesh...@us.ibm.com Sent: Monday, February 23, 2009 9:58am To: xalan-j-users@xml.apache.org Subject: Re: Internal Xalan packages > > Everything that is declared "public" and documented under > > "org.apache.xalan" may be used. Otherwise, I'd say, it wouldn't > > be public and documented. > > That's not what the documentation says. See: [http://xml.apache.org/] > http://xml.apache.org/ > xalan-j/public_apis.html Unfortunately, the Java language sometimes requires that things be made public for code-design reasons (inter-package access in the absence of C++-style "friend" packages) even though they are not intended for use by anyone outside that codebase. So don't rely on the public declaration in the source. Look at the documentation. If you can't reach it through the official APIs, don't count on it remaining stable or handling data other than the subset needed by the original designers. If you think there's a widespread need for something, you can try to make a case for it being officially exposed, or indeed refactored all the way out info a utilities package. Sometimes there are reasons such as performance which argue against that, but in general promoting code reuse is a good thing ... when it makes sense. If you're desperate -- well, Xalan is open-source, so subject to the usual Apache license (which IIRC basically means visibly giving Apache credit, but I Am Not A Lawyer) you could copy the code you're interested in into your own system. Then you'd have a stable copy, though of course you'd have to maintain it yourself.
