What do you think of these tips?   They come from a code peer review we did and their origin is from various sources.

 1) Then anyone handling it does not need to handle null values, can just use the normal iterator for the array or collection.  Although people argue performance is a reason to return nulls, this is not worth worrying about.    If you are worried about it, create a constant zero length array in your program (so it is only created once) and always return this. 2) Only one return per method?3) Only one catch block per method (can be multiple exceptions chained) and not two different areas in a block.4) Declare variable where they are first used in a method? Not all at the top, though they will be used at the end.

5) Keep method names from being too long, but descriptive.

6) Be wary of deep class hierarchies.   This usually means something is wrong with the design. 

7) Declare constants in an interface.

I am not saying I agree with all of this 100%, but arguments can be made…. 


Romain Guy (glad I only have to write it and not say it, the Java Posse struggle with his name every podcast) has a posting that asks Is Java SE becoming too much like Java EE?

I first read this (and not looking first who wrote it) my answer to the question was NO, it is just doing what it has to do to be relevant. When I first read that Java DB (Derby) was going to be included in Java 6 I thought what a great idea. Even though I am concentrating on the server side now because of work responsibilities, I started out doing a lot of client work. Property files, while effective, didn’t seem right to me. The idea of having a bundled database and ability to have persistence on the client side with a small overhead is nice.

And think about not having bloated, hard to read XML files. So Romain is correct and these additions are a good thing. One does need to ask why some of the deprecated methods are still in, but backward compatibility is a heavy burden.

Now, Sun make it easy to create Swing applications (you are getting there with Matisse) and the Java client may be back.

A couple of days ago I wrote a review of the book “Agile Java Development with Spring, Hibernate and Eclipse”, My review was brief only stating I recommend the book. Not a lot of info there I realize.
Well Matt Morton has blogged with a much more thorough review of this book, I can only agree with everything he says. By the way, I could not get the Safari 45 day online access to work either, told me invalid ISBN (I bought it on Amazon).

When I am teaching Java to my students or mentoring a junior person on the job they often ask for some tips to become productive in Java.  I have always believed that a solid foundation in generic object oriented concepts and techniques and an understanding of how these relate to programming in Java.

Going Public

In object oriented systems objects define their behavior through their exposed behavior.  In Java this is through their public methods.   Often people will call the methods that an object exposes its interface.   The most common example I have seen is your television set and the remote control (who uses the buttons on the front of their TV still?).   The remote control defines how you interact with your television.

As a side note, interfaces in Java are often portrayed as a way to circumvent the lack of multiple inheritance in Java that is present in other languages like C++.  While you can implement a form of multiple inheritance and it does solve what C++ critics like to call the diamond problem, this is not where I see interfaces being useful.  I spent a lot of years writing C++ code and do not remember consciously using multiple inheritance anyway.

Contract & Polymorphism

For me interfaces provide an elegant way to implement polymorphism as well as making sure my public interface (this is the interface that means the exposed methods) conform to what is expected.

First to polymorphism.  If you need a refresher here try this.   If you need more help there are thousands of definitions, tutorials and articles on the web.   Interfaces allow me to work with the interface type in Java and not worry about which object I am currently referencing with my interface.   A good example of this is found in this article.  I think in this context interfaces are a nice, simple and lightweight solution verse using base classes etc.   Think of the standard example with an interface  type Shape and implementation classes such as Square, Circle and Triangle.  The interface declares a method Draw and each implementing class must know how to draw itself.   I like this, it makes sense and it is elegant. 

OK, what about forcing a public interface.   This is called Design By Contract.  You can do this by documenting that anybody who wants to implement a class within this hierarchy HAS to implement a method or a set of methods with the signature as specified.  But, who is going to make them.   For a good example of this, think to when you do Swing programming.   You want the system to call an event handler after you have registered a component with the event handling subsystem using the addActionListener(this); method call.    The event handling subsystem will then call a method called actionPerformed(ActionEvent event) when an event occurs.   But how can you be sure this method is implemented, with the write name, in correct case and the right parameters.   By implementing the interface ActionListener.   By declaring your class with the words implements ActionListener all of this will be guaranteed and enforced by the compiler.  So this is a formal way to make sure you deliver what you promise.

So interfaces aren’t about multiple inheritance and were not included to make up for the lack of this being present in Java.  They are for: 1) Elegant way to implement polymorphism;  2) Insure your classes deliver the public interface you promise.

powered by performancing firefox

I am in the middle of reading a book on Agile Development called Agile Development With Spring. Hibernate and Eclipse. All I can say so far is that it is highly recommended. It is a great read and has a clear path leading the reader through the desired content. This is a book that I recommend reading now as it is a real world dose of development with the right mix of Agile with standard methods (Agile doesn’t mean no documentation for instance).

Of course everyone is recommending The Pragamtic Programmer at the moment. While I also consider this book a must read, the above mentioned book is just as good.

I am just coming into day two of teaching the Programming I course. This course should be a real challenge, there are 21 students!!!  That is by 6 the most I have ever had in this course.  My project management course had 28, but that requires less one on one interaction.

By the way, one of the things I love about teaching the University of Phoenix online courses is that I have students who live in places ranging from the northwest, CA, across the USA, the east cost and even Guam (actually 2 of them who found out they know each other and live there but didn't know they were attending the U of Phx!).

Anyway, in the first few days the main gaol is to get everyone to the same level. This involves getting everyone with the same JDK installed,downloading a text editor and getting their first app running. For a text editor I recommend JGrasp but don't enforce it.  The next step they need to create a program that prints their name or the proverbial "Hello World" just to show they have everything installed.  The students, though generally very experienced in their careers, quite possibly have not had a lot of experience programming.  Most have done one other programming course in C at this point.  Therefore some get frustrated when they cannot get their programs working.  This is 99% of the time 1 of 2 problems. 

1) They did not name their public class the same as their Java file.

2) They had something in lower case or at least the wrong case.  For instance system.out.println instead of System.out.println. 

You can imagine this becomes very frustrating when you first start out.  Therefore I have always recommended when you reach the boiling point to walk away and do something else for awhile or at least go away and write it down on paper.  This always worked for me and seems to be a great method to see the "forest through the trees".

Therefore I was really happy to see this entry on the website.  Especially the portion with the text Take A Break as this was almost word for word what I tell my students.   

What other useful hints do people have that I could pass on to my students? 

I am making final preparation for another online University of Phoenix course today and it has put me in a reflective mode on teaching and learning Java. Maybe because I am also burying myself in the world of JSF and AJAX this weekend in connection with a project I am working on I am thinking more about learning new topics.

Anyway, I am teaching a Programming I course (POS 406) where I usually teach the Programming II course. This semester I have been assigned the predecessor and I have been updating my discussion questions, exercises and syllabus all day. Here is the 5 week class layout (note there are simple programming assignments at each step):

Java Basics

· Explain the Java Virtual Machine.

· Explain the terminology of object-oriented terminology.

· Explain documenting, coding, compiling, executing, testing, and debugging Java programs.

Data Types

· Define data types.

· Explain classes and methods

Selection and Repetition

· Explain selection

· Explain repetition


· Explain arrays.


· Explain objects.

The challenge in teaching this course are many. One is creating an interesting and fun environment for students to learn in. The other is the diversity of backgrounds of the students. Some come with many years of practical experience and are finally taking time to get their degree where others are newbies to CS and development. Finally, for this class is not to make it a Learn Java only but to teach the topics generically while using Java as a tool. This was why I was looked at integrating BlueJ, but decided against it as strays too far from the norm for the Univerisity.

The challenges for this course are really different for my GMU IT 443 Course. This course is not a selective but a mandatory course. Also, I believe it contains a lot of theoretical information which you need to teach differently. Finally, when programming in Java you can see a result from a program fairly quickly, in project management this is hard to do in a 15 week, 1 night a week format. Don't get me wrong, I think each is as important as the other, just find teaching Java much easier.

Speaking of teaching Java, the company I work for the FDM Group is looking for Java programmers. I will blog about this later but in the meantime check out the FDM Academy.

Next Page »