200 likes | 314 Views
Resources to Support the Use of Java in Introductory Computer Science. The ACM Java Task Force. Eric Roberts, Stanford University (chair). Kim Bruce, Williams College James Cross, Auburn University Scott Grissom, GVSU Karl Klee, Alfred State College. Susan Rodger, Duke University
E N D
Resources to Support the Use of Javain Introductory Computer Science The ACM Java Task Force Eric Roberts, Stanford University (chair) Kim Bruce, Williams College James Cross, Auburn University Scott Grissom, GVSU Karl Klee, Alfred State College Susan Rodger, Duke University Fran Trees, Drew University Ian Utting, University of Kent Frank Yellin, Sun Microsystems http://www.sigcse.org/topics/javataskforce/ AP CS ReadingClemson, South CarolinaJune 14-20, 2004
We should shift our attention from the whether Java question to the if Java, then how question. — Chris Wallace, Peter Martin, and Bob Lang Java in the Computing Curriculum, 1997 The Current Situation • Since its introduction in 1995, Java has grown in popularity as a language for introductory computer science. • The importance of Java, particularly for high schools, has been increased by its adoption by the College Board for the Computer Science Advanced Placement (CSAP) program. • There is a growing sense that Java may become a virtual standard for computer science education in the sense that Pascal was for so many years. • But there are some difficulties . . .
At present 79% of high school computer science teachers rated their current knowledge of Java as poor to fair and only 3% rating their knowledge as excellent. At the same time, 86% rated their personal need to learn Java as very important to critical and 89% indicated that they needed to do so within one year. — Chris Stephenson, JETT proposal, 2002 Not Everyone Is Happy • Java as first programming language: a critical evaluation [Hadjerrouit98] • Java pitfalls for beginners [Biddle98] • Java, the good, the bad and the ugly [Martin98] • . . . and many more . . . • Several papers have identified problems in the use of Java: • High-school teachers find themselves unprepared for Java: • At ITiCSE 2002, Niklaus Wirth assailed Java’s complexity: I have yet to see a manual on UNIX/C++/Java that I can dare to read in about a week. Their manuals are unreadable, they expect you to belong to a cult whose incantations are not public, and you are not to expect much in terms of reliability, coherence or general elegance.
And Stuart Reges’s Wonderful Observation Now I find myself sitting in on Java intro courses and I almost can’t watch. It’s like staring at a traffic accident. I have a morbid curiosity to know what’s going on, but it’s almost too painful to witness. — Owen Astrachan’s keynote address, SIGCSE 2004
AP Computer Science • AP Java Subset • “The AP Java subset is intended to outline the features of Java that may appear on AP Computer Science Examinations. The AP Java subset is NOT intended as an overall prescription for computer science courses—the subset itself will need to be supplemented in order to cover a typical introductory curriculum.” — AP CS Course Description
The CS AP Dilemma: • How do AP CS teachers “supplement” the AP CS Java subset so that it parallels what is done in the introductory courses in colleges and universities? • Some paths taken: • Follow the textbook. • Find out what other AP CS teachers are teaching. • Find out what some universities are teaching.
Problem Taxonomy High-Level Issues H1. Scale (remains a concern) H2. Instability (remains a concern) H3. Speed of execution (improving over time) H4. Lack of textbooks and environments (improving over time)
Problem Taxonomy Language Issues L1. Static methods (including main) (remains a concern) L2. Exceptions (remains a concern) L3. Interface/implementation separation (addressed by tools) L4. Wrapper classes (fixed in Java 1.5) L5. Lack of parameterized classes (fixed in Java 1.5) L6. Lack of enumerated types (fixed in Java 1.5) L7. Inability to code preconditions (fixed in Java 1.4) L8. Lack of an iterator syntax (fixed in Java 1.5) L9. Low-level concerns (disposition varies)
Problem Taxonomy API Issues A1. Difficulty of the graphics model (remains a concern) A2. GUI components hard for novices (remains a concern) A3. Support for event-driven code (remains a concern) A4. Lack of a simple input mechanism (largely fixed in Java 1.5)
More background on these problems and the sources from which they arise can be found in the background paper in the SIGCSE 2004 proceedings: Eric Roberts. The Dream of a Common Language: The Search for Simplicity and Stability in Computer Science Education. SIGCSE 2004. The Critical Problems • Complexity. The number of programming details that students must master has grown much faster than the corresponding number of high-level concepts. • Instability. The languages, libraries, and tools on which introductory computer science education depends are changing more rapidly than they have in the past.
A Dramatic Example of Complexity There are more public methods in the java and javax package hierarchies than there are words in Jensen and Wirth. The amount of text once deemed sufficient to teach the standard introductory programming language is thus no longer sufficient for a full index of the operations available today. — SIGCSE Proceedings
The ACM Java Task Force In October 2003, the ACM Education Board approved the formation of a new task force with the following charter: To review the Java language, APIs, and tools from the perspective of introductory computing education and to develop a stable collection of pedagogical resources that will make it easier to teach Java to first-year computing students without having those students overwhelmed by its complexity. The Java Task Force held its first meeting at the end of January 2004. It proposes to issue its final report in June 2005, in time for use in the following fall.
1. A definition of a subset of the standard Java APIs appropriate for first-year computer science 2. A public web site containing an updated javadoc reference manual for the approved Java subset 3. A collection of pedagogically oriented APIs that have been evaluated and approved by the task force 4. A survey of existing noncommercial materials and tools for teaching Java 5. A proposal for sustaining the activity begun by this task force Deliverables
1. 2. Object-oriented approach. In our work, the Java Task Force will design around an objects-first approach to the introductory curriculum. At the same time, we will seek to ensure that the resources we provide will be usable with other approaches wherever possible. Backward compatibility. In order to be forward-looking and to ensure that our resources remain current for as long as possible, our baseline version of Java will be J2SE 1.5. However, we anticipate that some institutions will not be in a position to adopt Java 1.5, even by the time at which the Task Force materials are released. For this reason, we will make every effort to ensure that those resources work in Java releases from Java 1.2 forward. Principles
3. 4. Minimalism. To avoid the proliferation of a complex collection of tools that does little to address the scale problems of Java, the Task Force will seek to define tools that are, as Einstein put it, “as simple as possible, but no simpler.” Conformance. Insofar as possible, the Task Force will work within the standard frameworks provided by Sun Microsystems and avoid the development of new APIs. To the extent that we do endorse additional APIs, we will ensure that there is a work-around that remains within the standard. Thus, anyone who chooses to use the resources provided by the Task Force should be able to do so without being forced to adopt nonstandard packages. Principles(continued)
5. Multiple environments. The Task Force will not enforce the use of any particular programming environment but will instead seek to ensure that the resources work with all major integrated development environments (IDEs). Principles(continued)
Jan 04 Convene initial meeting of full task force Mar 04 Introduce the project at a SIGCSE special session Call for submissions of proposed pedagogical APIs Publish taxonomy of issues identified in the literature Apr-Nov 04 Conduct series of working meetings Undertake review of existing resources Review submissions of pedagogical APIs Refine definition of Java teaching subset Publish draft of Java teaching subset on the web Dec 05 Present complete draft report at SIGCSE 2005 Feb 05 Review and incorporate feedback from SIGCSE Construct website Mar-May 05 Publish final report and website in time for fall Jun 05 Milestones
1. A description of any additional challenges you have beyond those identified in our taxonomy. 2. A description of any solutions you have developed in response to these challenges. The Task Force Call for Proposals At SIGCSE 2004, the Java Task Force issued a call for two-page submissions in the following two categories: We received a total of 32 proposals, which we reviewed in May.
1. A simple, object-oriented graphics package for which the underlying metaphor is that of a felt board. Under this model, students create pictures by instantiating graphical objects and adding them to a component. 2. 3. A set of GUI-based interactors that simplify I/O. We believe that the use of these interactors should involve method invocations on interactor objects as opposed to the static method calls typically used for JOptionPane. A Console class that provides a traditional, interactive, text-based console. Proposed Extensions to the Standard APIs Based on our analysis of the problems instructors have reported in teaching Java and our review of the submissions we received in response to our call for proposals, we believe that the ACM Java Task Force needs to develop the following extended APIs:
1. A description of any additional challenges you have beyond those identified in our taxonomy. 2. A description of any solutions you have developed in response to these challenges. Planned Extensions to the Standard API At SIGCSE 2004, the Java Task Force issued a call for two-page submissions in the following two categories: We received a total of 32 proposals, which we reviewed in May.