Surviving Second Year · Java tips

Submitted by co60ca on Wed, 06/29/2016 - 14:41

Graduate from first year, stop doing the work for the computer
Computers are really good at doing repetitive tasks so lets address some of the time saving and more professional ways of writing code

DrJava - Never use it again. Allegedly there are bugs discovered by our TAs that mean that if you use newer versions of Java (which is always recommended) the debugging features of DrJava will not work. Additionally it is missing a lot of features that upper years take frequent advantage of such as code completion and proper indenting. You will also learn that other IDEs can automatically generate boilerplate code such as getters and setters and solve common Java maintenance problems. We provide some suggestions below, available on all of Windows, Mac OSX and GNU/Linux.

Eclipse(my favourite) - Arguably one of the most well supported IDEs for Java and some other languages. It has the Window Builder which is the visual editor for Swing based GUIs in Java. It also has all of the features in the intro of this section.

Netbeans - Again, arguable one of the most well supported IDEs for Java. It has its own GUI builder that is more structured and restricted but gives less opportunities to really mess the GUI up.

Or perhaps don't reinvent the wheel. When writing a program that implements a queue do not write a queue, rather use an implementation of java.util.Queue, such as LinkedList<E> which is the built in version of LinkedList<E> that you may have written in COSC 1P03. Additionally, don't use arrays, the possibility of an error occurring when choosing the size of the array makes it not as effective as using a List, Set, or Map. The computational overhead associated with resizing an ArrayList only occurs at the next order of magnitude. Memory overhead isn't significant anymore in the applications you'll be writing but it is an exercise to the reader if you are interested in learning about this overhead.

Collections - Almost any structure that you will learn about in COSC 2P03 or COSC 1P02/1P03 will likely already exist within the Java standard library. They mostly exist within java.util.collections, they are all variable length meaning you don't have to manage the size or number of elements in the structure.

Map<T, E>

Avoid using bare for loops - for(int i = 0; i < array.length; i++) when you are using a collection like one in the above section if you don't care about the index but just want the element you can apply the for each loop, this will never go out of bounds and is more idiomatic Java.

for(Object obj : list) {
    // Apply an operation to each variable obj in variable list

Using Lists lets you do really fun stuff like sort, find maximum, or shuffle in one line of code too. Learning collections is the first step to this. Additionally many of the useful algorithms are already implemented that you could ever need. They are also probably more efficient than any you currently know how to perform. I'll provide some examples.

Collections.sort(List l) - Orders given a total order comparator (works for Integer types by default) O(n log n) but sometimes better performing then Quicksort or Mergesort!
Collections.shuffle(List l) - Linear time algorithm for shuffling a list randomly
Collections.binarySearch(List l, E element) - Log n time algorithm for finding an element within a sorted List.

There are many more, many are defined in static class java.util.Collections (check the Java reference) or in the collections themselves. (List.sort()List.shuffle())

Visual Debugging - Stop using System.out.println("Here 1"); for debugging, it doesn't provide as much information and arguable takes longer then Visual debugging in some cases. A visual debugger takes advantage of the ability to pause the Java virtual machine as well as use reflection (A feature of most modern programming languages). In a visual debugger you can click lines in your source code to set break points. A break point is simply a point in which the VM will halt and allow you to inspect variables before continuing program execution. At this point you can step over or step into expressions. This, for instance, allows you to follow the control statements (i.e. if, for, ...) as your program executes. The aforementioned can be tedious so it may be useful to "resume" or continue to the next break point to go to the next point of interest. When you are paused you can look at the locals of the section of code you are in, more simply the local variables and/or class variables of this object. You can follow "has-a" relationships such as the members of a particular object. On example of the inspections you can do is viewing the char[] that a String has for backing.

Example of use: You are getting a Null Pointer Exception in a Java program. You can see the line the error is occurring on but there is no indication why the variable is null. You set the break point to the initialization of the variable Object bean = ObjectBeanWidget(5) and see when the variable bean is being assigned null, or if the ObjectBeanWidget(5) is not returning the correct object for instance. If you wanted to do this manually you may have to use several print statements, but for situations when you are using loop structures with several variables to keep track of it may be simpler to use the visual debugger then trying to print out statements to debug your code manually.