|JTF > Rationale > The JTF Subset|
In the public announcement of the ACM Java Task Force at SIGCSE 2004, the first item included in our list of deliverables was
A definition of a subset of the standard Java APIs appropriate for first-year computer science. This subset would involve restricting both the number of classes used as well as the number of public methods made visible within those classes. Note that this subset must be sufficient to have students write significant applications using Java. To this end, it will presumably be a superset of the AP Java subset
[Astrachan00], which seeks to define what aspects of the language will be tested on the AP exam. [Roberts04b]
This task is clearly a perilous one, particularly given that any decisions we make are sure to upset those instructors who feel compelled to use some piece of the standard Java API that did not make it into the Task Force subset. At the same time, it is also true that the Task Force has a responsibility to provide guidance in this area. In a very real way, the most significant problem with Java is not any of the specific shortcomings that we have sought to address with the ACM packages but rather the enormous scale of the languages and its APIs.
In some ways, however, the issue can be made less contentious by redefining the goal. Rather than defining any sort of official standard, our current strategy is to define a subset that we agree to support as effectively as possible. That support has three components:
Figure 9-1. Java classes that form the preferred JTF subset
In putting this list together, we undertook a mechanical survey of the code that is published on the web for several of the leading text books to see what classes they used. This survey provided us with considerable insights into how classes are used, but required some analysis to separate out various artifacts from the useful data. For example, one of the leading classes on the list is java.lang.StringBuffer, not because these textbooks refer to it directly, but because Java compilers generate references to StringBuffer (or its newer StringBuilder counterpart) whenever they process string constants. Thus, it was important to analyze the data and look for this type of outlier. In the end, we used the list developed by the automatic survey as a sanity check on our own consideration as to what classes one might reasonably present in the first-year curriculum.
We expect that this list will evolve slowly over time, but believe that it is likely to remain stable through the official release of the materials in spring 2006.
A public web site containing an updated javadoc reference manual for the approved Java subset. This web site would make it possible for students to browse the standard classes and methods defined in the subset without being overwhelmed by classes, methods, and concepts they are unlikely to use. For the classes and methods that are included, the web site will contain more examples and tutorial material than is currently supplied with the Java APIs.
After all, given that Javas corporate creator assures us that the network is the computer, what matters is whats described on the web rather than a standard buried in a bookcase somewhere.
Our proposal to use the javadoc documentation to define the JTF subset includes the following goals:
The current draft release of the Task Force materials implements the split between the student and complete view only for the documentation of the ACM packages. When you go to the web site, you come up in the student view. Each page in the student view contains a link in the navigation bar to the complete view for the same page (and vice versa), making it very easy to move back and forth between the two views. The primary characteristic of the student view is that it hides extraneous information. Figure 9-2, for example, shows the top of the page in the student view for the GLabel class in acm.graphics. What you see in the figure looks familiar enough and also illustrates the level of documentation we plan to associate with each of the classes. But whats more important is what you dont see. You dont, for example, see a navigation tab directing you to the discussion of inner classes or deprecated methods. Similarly, you dont discover that GLabel implements the mysterious interfaces Cloneable and Serializable. You do, of course, see these features in the complete view, but they are not getting in the way here.
Figure 9-2. Beginning of documentation page for the GLabel class
Figure 9-3. Selections from the GLabel method summary
Figure 9-4. Standard javadoc presentation of inherited methods
The only other significant change in the student view is the inclusion of a usage line in the detailed presentation of methods, preceding the declaration of parameters and results. Student find a paradigmatic example extremely useful, particularly when they can cut it out of the documentation and paste it into their own code. This line is illustrated in Figure 9-5.
Figure 9-5. Standard javadoc presentation of inherited methods
Final ReportJuly 31, 2006