These classes are 'internal' and undocumented. I believe the same goes
for tools.jar (platform specific tools?), but memory fails me at
03:03 :).

Sun's official stance on them is "Don't use them", or "Go ahead and use
them, but don't ask for documentation, don't complain when they change
(or even disappear), and don't expect your code to be portable".

The whole com.sun hierarchy basically does the work in the (Sun) JVM.
The standard java.* / javax.* are largely 'Facade' classes, which have
simple methods that just call out to the com.sun methods.

You often see in the full stack trace how the facade works. Also try
toString() on a few classes you get from java.* class factories and the
like.

-= Ross =-

They are only documented on some high level. tools.jar contains the
implementations of the various tools that come with the JDK, like javap,
javadoc, javac, jarsigner, jdb, etc.

The JDK contains documentation for these applications, but not for the
individual classes.

It is risky to use them, because Sun can change them any time, and does
so. Other VM implementations are likely to not have all these Sun
classes at all.

Some very few such classes have sneaked into the rank of public or
semi-public APIs. E.g. the compiler invocation, and AFAIR the JPEG image
decoder in some early toolkits.

The internal ftp class was also popular at some point in time. But that
one AFAIK never made it into a semi-public API.

In general, unless you find a strong statement from Sun that it is ok to
use such a class, stay away from them.

/Thomas