Classes That Don't Work With the JDK

[John Keiser]

Some of our classes won't work with the JDK.  It will help to determine
which.  Can everyone who's worked on a package, please add to this list?

Here is an algorithm for determining which classes will not work with the
JDK:

Foreach Class In Classpath:
   If Sun's VM uses package-protected, private, or VM-created members of the
Class, add Class to the No JDK List.
   Else If Classpath's version of the Class uses native calls that talk to
the VM in some way other than the JVMDI or JNI, add Class to the No JDK
List.
End Class

Do:
   Foreach Class Not In the No JDK List:
      If Classpath uses package-protected, private, or VM-created members of
any class in the No JDK List, add Class to the No JDK List.  (Note that it
may safely use protected and public members).
      Else If one of Sun's classes in the No JDK List uses
package-protected, private or VM-created members of the Class, add Class to
the No JDK List.
      Else If Classpath uses a gnu.* class in the No JDK List, add Class to
the No JDK List.
   End Foreach
While the No JDK List keeps getting bigger (at some point it should stop;
for example, I can guarantee that java.beans will work fine, because the
only part of java.lang.reflect it uses is the public part.)

We should figure out what classes are in step 1 before we continue to step
2.

My NoJDK List
java.lang:
   Object
   Class
   ClassLoader
   System
   Runtime
   SecurityManager
   (?) String
   String --> (?) StringBuffer (relies on String internals)

java.io:
   (?) FileDescriptor
   FileDescriptor --> (?) FileOutputStream (relies on FileDescriptor
internals)
   FileDescriptor --> (?) FileInputStream (relies on FileDescriptor
internals)
   FileDescriptor --> (?) FileWriter (relies on FileDescriptor internals)
   FileDescriptor --> (?) FileReader (relies on FileDescriptor internals)

java.lang.reflect:
   Method
   Field
   Constructor

gnu.java.lang:
   ExecutionStack
   StackFrame

--John Keiser