summaryrefslogtreecommitdiff
path: root/libjava/classpath/TODO
diff options
context:
space:
mode:
authorupstream source tree <ports@midipix.org>2015-03-15 20:14:05 -0400
committerupstream source tree <ports@midipix.org>2015-03-15 20:14:05 -0400
commit554fd8c5195424bdbcabf5de30fdc183aba391bd (patch)
tree976dc5ab7fddf506dadce60ae936f43f58787092 /libjava/classpath/TODO
downloadcbb-gcc-4.6.4-554fd8c5195424bdbcabf5de30fdc183aba391bd.tar.bz2
cbb-gcc-4.6.4-554fd8c5195424bdbcabf5de30fdc183aba391bd.tar.xz
obtained gcc-4.6.4.tar.bz2 from upstream website;upstream
verified gcc-4.6.4.tar.bz2.sig; imported gcc-4.6.4 source tree from verified upstream tarball. downloading a git-generated archive based on the 'upstream' tag should provide you with a source tree that is binary identical to the one extracted from the above tarball. if you have obtained the source via the command 'git clone', however, do note that line-endings of files in your working directory might differ from line-endings of the respective files in the upstream repository.
Diffstat (limited to 'libjava/classpath/TODO')
-rw-r--r--libjava/classpath/TODO76
1 files changed, 76 insertions, 0 deletions
diff --git a/libjava/classpath/TODO b/libjava/classpath/TODO
new file mode 100644
index 000000000..df7eed7d0
--- /dev/null
+++ b/libjava/classpath/TODO
@@ -0,0 +1,76 @@
+See also http://www.gnu.org/software/classpath/tasks.html
+Which is updated more often then this file.
+
+The Classpath TODO list as of 2002/05/05
+
+-- Write Mauve (http://sourceware.cygnus.com/mauve/) tests for those
+ classes that don't have them.
+
+-- Write Java 2 packages not currently included or improve existing
+ ones.
+
+-- Modify ClassLoader.getSystemResource() to support loading classes
+ from zip files in the CLASSPATH. This requires java.util.zip to
+ be integrated first. Jar files can probably be treated as zip
+ files for now.
+
+-- Continue comparison and merge of classes between Classpath and GCJ.
+
+ Current status: http://gcc.gnu.org/java/libgcj-classpath-compare.html
+
+ Please keep in mind that Red Hat wishes to continue to use CNI
+ as their preferred native interface. See:
+
+ http://sourceware.cygnus.com/java/papers/cni/t1.html
+
+-- No resolution was identified for generating JNI compatible code from
+ CNI source. The simple solution has been adopted to include
+ both in GNU Classpath if and only if another JVM chooses to use CNI.
+ Provisions for compiling CNI correctly need to be implemented.
+
+-- Update the GNU Classpath Hacker's Guide. There is a master texinfo
+ file in the doc/ directory in Classpath CVS.
+
+-- 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.
+ See http://java.sun.com/j2se/javadoc/writingdoccomments/index.html#tag
+ for details of what should be where in comments.
+
+-- 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 vs
+ the JDK using serialcompat from Japitools.
+
+-- Audit code for thread safety.
+
+-- Audit Java code for proper Security implementation.
+
+-- Audit native code for security, memory handling, etc.
+
+-- Bug reports are always welcome. They are double welcome if they
+ are accompanied by a Mauve test that reproduces the bug.
+