Joe Sam Shirah wrote:
> To reinforce Chris' answer, the general rule is to not use sun.xxx
> classes unless you are willing to have the rug pulled out from under you at
> anytime. They may change, remove, rename, etc at any time. com.sun.xxx
> classes, on the other hand, may be used with the same level of confidence as
> any other third party classes ( what ever that may be. ) So, do as you
> please, but understand the possible ramifications.
>
> Joe Sam Shirah
> Autumn Software
I disagree with Joe Sam's statement that "com.sun.xxx" classes should be used.
They are still "undocumented and unsupported, subject to change at any time."
The distinction between "sun.*" and "com.sun.*" should be treated as
meaningless.
In addition, Sun has implemented the Java API specifications in their own JVM
ports with these internal classes. When a JVM is ported to a different
architecture, the organization doing the port has complete freedom in whether
or not to copy the Sun internal package and class names. I've heard plenty of
horror stories about people who relied on this, only to find that their
programs didn't work under third party JVMs because these classes were not
included. The most infamous example, of course, is the internal mail-sending
class that everyone around here seems to like, but the principle applies to all
of them.
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
