summaryrefslogtreecommitdiff
path: root/TODO
blob: 81ee89aa17e57dcad0df831ee3fb1fb9b69435b5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
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.

-- Audit code for thread safety. 

-- 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.