Initial checkin

1 files changed, 167 insertions, 0 deletions

diff --git a/TODO b/TODO
new file mode 100644
index 000000000..6f5243e84
--- /dev/null
+++ b/TODO
@@ -0,0 +1,167 @@
+The Classpath TODO list as of 2000/04/17
+
+-- Modify Classpath build to support libgcj out of the box.  Ideally
+   the gcj folks could simply include a stock classpath in one of their
+   distribution subdirectories, have their master configure run a configure
+   on Classpath the appropriate arguments, and everything would build.
+
+-- Integrate packages from libgcj that don't exist in Classpath:
+   o java.util.zip
+   o java.util.jar
+
+-- Modify ClassLoader.getSystemResource() to support loading classes 
+   from zip files in the CLASSPATH.  This requires java.util.zip to
+   be integrated first.  Jar filed can probably be treated as zip
+   files for now.
+
+-- Perform a class by class comparison in packages where both Classpath
+   and libgcj have implementations, and make recommendations for how
+   to merge them and/or which implementations are superior.  This has
+   been done for java.net by Gaute Smaaland.  See the mail message:
+
+   http://www.mail-archive.com/classpath@gnu.org/msg02135.html
+
+   for his comments.  The packages where we need similar work are:
+   o java.io
+   o java.lang
+   o java.lang.reflect
+   o java.text
+   o java.security
+
+   Please keep in mind that Cygnus wishes to continue to use CNI
+   as their preferred native interface.  See:
+
+   http://sourceware.cygnus.com/java/papers/cni/t1.html
+
+-- Identify a way to resolve the CNI versus JNI issue.  JNI is the
+   Java standard for calling native methods.  Classpath needs to support
+   this for standards compliance.  CNI is the Cygnus Native Interface,
+   an efficient method for calling native code, but one limited to use
+   with gcj.  Cygnus wishes to continue using this because it is more
+   efficient than JNI in their implementation, and uses substantially
+   easier and more readable native code.  Proposed solutions to date:
+   o Binary interface
+   o A .in file that is pre-processed through a script to generate
+     CNI or JNI as desired.
+   o Multiple implementations with a compile time switch.
+   o Pre-processing script to convert CNI source to JNI 
+
+-- New web site.  The Classpath web site at:
+
+   http://www.classpath.org/
+
+   is hideously out of date.  Please contact Paul Fisher (rao@gnu.org)
+   and Brian Jones (cbj@gnu.org) if you wish to work in this.
+
+-- Update the GNU Classpath Hacker's Guide.  There is a master texinfo
+   file in the doc/ directory in Classpath CVS.
+
+-- Implement a bug tracking system for Classpath.
+
+-- Write Mauve (http://sourceware.cygnus.com/mauve/) tests for those
+   classes that don't have them.
+
+-------------------------------------------------------------------------
+
+Here is what needs to be done on a package by package basis for Java
+1.1 compatibility.  Note that debugging should be done by running
+Mauve tests against Classpath where possible.  If Mauve tests don't
+exist, the first step is to write them.  Note that while I say "1.1",
+the implementations of these packages should be written to the "1.2"
+standard.
+
+-- java.applet: Coded and compiles cleanly.  Needs debugging.
+
+-- java.awt:  Mostly done and compiles cleanly.  A few classes are
+   missing.  Needs to be debugged and integrated with Paul Fisher's
+   AWT peers.  This task should not be worked on for the time being.
+
+-- java.awt.datatransfer:  Coded and compiles cleanly.  Needs
+   debugging.  This task should be considered "On Hold" for now.
+
+-- java.awt.event:  Coded and compiles cleanly.  Needs debugging.
+   This task should be considered "On Hold" for now.
+
+-- java.awt.image: Unsure of status but partially implemented.
+
+-- java.awt.peer:  Done.  Nothing needs to be done here.
+
+-- java.beans:  Done.  Additional testing/debugging/real life use
+   reports would be helpful, as would efficieny improvements.
+
+-- java.io:  Needs to be merged with libgcj.  See above.
+
+-- java.lang:  Needs to be merged with libgcj.  See above.
+
+-- java.math:  Needs to be merged with libgcj.  See above.  Missing
+   some methods.
+
+-- java.net:  Merger with libgcj in progress.  No tasks to be done at
+   this time.
+
+-- java.rmi:  No implementation.  Rumor has it that Transvirtual (Kaffe)
+   is producing a version we can use.
+
+-- java.security:  Debug the implementation and get it working with Japhar
+   and/or gcj.  Mark Benvenuto (mcb54@columbia.edu) wrote this, but 
+   I'm not sure that it is totally running.
+
+-- java.sql: Coded and compiles cleanly.  Needs debugging.
+
+-- java.text:  Needs to be merged with libgcj.  See above.
+
+-- java.util:  Needs to be merged with libgcj.  See above
+
+-- java.util.zip:  Need to merge in the libgcj version.  See above.
+
+-------------------------------------------------------------------------
+
+-- Write Java 1.2 packages not currently included or improve existing 
+   ones.
+
+-- Write an implementation of Swing.  This is a big job and should
+   probably be a separate, non-Classpath project that can be shared
+   with Kaffe.  Please write to the mailing list if you are interested
+   in helping with this.  (classpath@gnu.org)
+
+-- Figure out an easy method of generating online Javadocs from our
+   code.  This will probably involve lots of misc HTML fixes.
+
+-- Audit the code to identify methods that do not have Javadoc comments
+   and/or comments that are incomplete.  All input parameters, return
+   values, etc should be documentes.  Also look for Javadoc comments on
+   variables that are serializable.
+
+-- Figure out a way to generate a hardcopy manual for the Java class
+   library from the embedded Javadocs.  This probably involves writing
+   a custom doclet and probably some supplementary documentation
+   files into which the extracted Javadoc files are included.
+
+-- Audit the code to ensure that all variable declarations are consistent
+   with the "Serialized Form" in the JDK.  That is, all serialized
+   variables in the JDK should be included in Classpath and all Classpath
+   instance variables that are not part of the JDK docs should be marked
+   transient.  Please be sure to use the online version of the Javadocs
+   for this and do not accept any "clickwrap" licenses from Sun in order
+   to download the JDK 1.2 Javadocs, which is where this information is
+   stored.
+
+-- Audit code similar to above to determine where Sun uses readObject()
+   and writeObject() for serialization and determine what Classpath
+   needs to do for compatibility.
+
+-- Audit code to ensure that every class that should be serializable
+   actually implementst java.io.Serializable and has the correct
+   serialVersionUID private static variable that is identical to the
+   JDK 1.1 version.  You can obtain that variable value using the
+   serialver command.
+
+-- Do real life serialization compatibility tests of our code with Kaffe 
+   and the JDK.
+
+-- Update the packaging of Classpath to make sure that we can build
+   good distribution tarballs.
+
+-- Bug reports are always welcome.  They are double welcome if they
+   are accompanied by a Mauve test that reproduces the bug.
+