Identifying and Correcting Common Java Programming
Errors And Misconceptions for Introductory Computer Science
Students
Maria HristovaAnanya MisraMegan Rutter
Advisor: Prof. Rebecca Mercuri
Bryn Mawr College May 8th 2002
Overview
Abstract Introduction Theoretical Framework Data Collection And Organization Finding And Testing Solutions Example Errors, Solutions And Tests Sample Run Conclusion And Future of The Project
Abstract
The Java programming language is currently growing in popularity within the academic community, and as a result of this, a lot of colleges are converting their introductory Computer Science courses into Java. While Java is a very portable and web-compatible language, students often have a hard time mastering it. There have been some projects that were aimed to assist students in grasping Java’s conceptual framework, but many of these involved either simplified Java syntax or pre-constructed object modules that distanced students from the process of coding. Our goal was to design an educational tool that would identify common Java programming errors and misconceptions and facilitate the learning process, while making sure that the students interact directly with their code. In order to achieve our goal, we collected data from students, professors and members of the Special Interest Group on Computer Science Education, and compiled a list of errors we wanted our program to assess. We then created a multiple-pass preprocessor that detects these errors and suggests corrective action. This presentation discusses the process we experienced in identifying these errors, designing and coding solutions, and testing the resulting product.
Introduction
Background Proposal
Collaborative Research Experience for Women, Computer Research Association
Existing Projects DrScheme, BlueJ, Ready, JJ
Theoretical Framework Pea and Kurland – Cognitive Aspect
Define programming as both a mental mode and a skill like reading
Define the need for a tight bond between an instructional and programming environment
Du Boulay – Language-Independent Aspect
Defines the five language-independent areas of difficulty and three kinds of corresponding mistakes
Fleury – Java Aspect Creates a list of the four most common “student-constructed
rules” in Java Explores how students understand Java code and what their
misconceptions might be
Pea and Kurland – Cognitive Aspect
Du Boulay – Language-Independent Aspect
Fleury – Java Aspect
Data Collection
Original List of Errors Professor Surveys
US News and World Report’s Top 50 Liberal Arts Colleges 2002
SIGCSE Student Surveys
Swarthmore College Student Essays
Bryn Mawr and Haverford Colleges
Data Organization
List of Errors Collected List of Errors Not Included in Final
List Already Identified by Compiler Don’t Apply to Introductory Students Can’t Be Checked For
Final List of Errors Considered by Our Program (on hand-out)
Designing and Testing Solutions
Three Groups of Errors Syntax - errors in the spelling, punctuation
and order of words in the program Semantic - errors that are likely to ensue
from a mistaken idea of how the language interprets certain instructions
Logic - errors that tend to arise from fallacious thinking by the programmer rather than from language peculiarities
Single Versus Double Equals Operator
Assignment (=) versus Comparison (==) if( x = 0) instead of if(x == 0) int x == 1; instead of int x = 1;
Solution Looks for the former in if, for and while clauses Looks for the latter everywhere else Problem: this solution misinterprets == in boolean
expression outside selection and repetition structures
Incorrect Semicolon in If Statement or For/While Loop
Semi-colon after if, for or while clause if (x == 0); {<statements>} instead of
if(x == 0) {<statements>} Solution
Locate if, for and while statements Possible error if there is a semi-colon directly after
parentheses are balanced Special case: is the while keyword part of a do-while
loop?
Incorrect Semicolon at the End of a Method Header
There should never be a semicolon at the end of a method header
Void methodName(arguments);{<statements>} should be
Void methodName(arguments){<statements>} Solution
Search through code for method headers If a method header is found, make sure there is not a
semicolon before the opening curly bracket If a semicolon is found return an error
Invoking Methods With Wrong Arguments
Method call parameter types must match method definition parameter types
Given definition void methodName(int x, char y) in method call methodName(a, b) a must be an int and b must be a char
Solution Store variables and their types in one vector and method
names and their parameter types in another When method call is found in code, make sure its parameter
types match those in vector If they don’t match, return an error
Problems Multiple entries - will return false error Mismatched parameter types - will not detect error that is
there Types don’t have to match exactly - a double can take an int
Invoking a Non-void Method as a Statement
When a non-void method is called it returns a value of some type and it must be stored somewhere. For example: public int someMethod(){
int result; ...return result;}
is then being called as someMethod()
instead ofint someResultVariable = someMethod()
Solution Store all method names Every time when there is a method call check to see if it is
preceded by an operator like = or + or by ( If there is no variable that stores the return value an error
message is returned
Class Declared Abstract
Every Java interface being implemented in an applet requires that certain methods or adapters need to be present in the code even if they are empty
For example: someClass extends Applet implements ActionListener{public void init(){...}}
instead ofsomeClass extends Applet implements ActionListener{
public void init(){...}public void actionPerformed(ActionEvent e){...}}
Solution Create a list that associates every interface with the appropriate
methods or adapter If an interface is implemented, a search for the required components
is performed If some methods or adapters are missing, an error message is
returned
Sample Run Code// sample run
import java.awt.*;import java.applet.*;import java.awt.event.*;
public class SampleRun extends Applet implements ActionListener {
Label sampleLabel = new Label("Sample Label", Label.LEFT);Panel samplePanel = new Panel();
public void init();{samplePanel.setLayout(new FlowLayout(FlowLayout.LEFT));samplePanel.add(sampleLabel);add(samplePanel);repaint();}
public void paint(Graphics g){char bear = 'p';String cheese = "appleSauce";computeSum(cheese, bear);}
public int computeSum(int apple, int sauce){
int appleSauce;if (apple = sauce){
appleSauce= apple + sauce;
}else if (apple > sauce);{
appleSauce == apple - sauce;
} else{
appleSauce = 49;}
return appleSauce;}
}
Sample Run Outcome
Conclusion
Our aim in this project was to create an educational tool that would not only help students identify and fix their existing programming errors, but also help prevent them from making them again in the future.
We accomplished this by compiling a list of common Java programming errors made by introductory students, designing and coding a program that identifies these mistakes and returns instructive error messages, and testing our program on our test suite.
We believe that our resulting project will prove to be a very useful tool for future introductory Computer Science students.
The Future of Our Project
Assessment of the tool’s effectiveness in the classroom environment and examination of these results and student feedback to be reflected in future implementations
Submission to Computer Science Education Journals for Publication
Submission to SIGCSE Conference for Student Paper Presentation
Acknowledgements
We would like to thank: * our families and friends for their support throughout this project* each other for the super team work, patience and understanding
that made this project possible * Professor Rebecca Mercuri for her mentoring* the Computer Science department at Bryn Mawr College and
especially Professor Deepak Kumar without whose enthusiasm and love for teaching none of us would be Computer Science majors
* Anneliese Taylor who is the best science librarian that we know * Bryn Mawr College for establishing an environment where women
can excel in science * and Collaborative Research Experience for Women, part of the
Computer Research Association for their financial support with this project and their dedication to encouraging women in Computer Science.
Bibliography
Du Boulay, Benedict. “Some Difficulties of Learning to Program.” Journal of Educational Computing Research Vol. 2(1). (1986): 57-73.
Fleury, Ann. “Programming in Java: Student-Constructed Rules.” Proceedings of the Thirty-First SIGCSE Technical Symposium on Computer Science Education (2000): 197-201.
Kurland, D. Midian and Roy D. Pea. “One the Cognitive Effects of Learning Computer Programming.” New Ideas in Psychology Vol.2 No.2. (1984): 137 – 168.
Pea, Roy D. “Language-Independent Conceptual “Bugs” in Novice Programming.” Journal of Educational Computing Research Vol. 2(1). (1986): 25-36.
Kolling, Michael. The BlueJ Tutorial Version 1.4. 23 January 2002 <http://www. bluej.org/tutorial/tutorial.pdf>
Kolling, Michael. Why BlueJ? 22 January 2002 <http://www.bluej.org/why/why. html>PLT Scheme: Software: DrScheme Home Page. 22 January 2002 <http://www.plt-
scheme.org/software/drscheme/>TA Online: Common Java Compiler Errors. Department of Computer Science,
University of Arizona. 17 February 2002 <http:// www.cs.arizona.edu/people/teena/ ta_online/>