Chapter:Programming in Java

From Juneday education
Jump to: navigation, search

Meta information about this chapter

Expand using link to the right to see the full content.

Introduction

This is an introduction to programming in the Java programming language. It is aimed at giving the student some nomenclature and feeling of the structure of a Java program. It is not a theory focused chapter, but rather a first encounter with Java programs to give the students a first feel of what Java programs look like and what basic components make up such a program.

Purpose

The purpose of this chapter is to provide the students with basic knowledge of the layout of a Java program and its source code files so that the student can compile and run a sample (in this chapter provided) program.

Another purpose is to explain to students that a Java program has a starting point for the execution of the program in the main method.

Goal

The goal of this chapter is that students understand that a Java program has at least one class defined in a source code file and that this class contains a main method where all the execution starts.

The students shall be able to read and understand a simple sample program, compile it and run it.

Instructions to the teacher

Common problems

Java is complicated in the sense that even the smallest program requires a great deal of components and concepts all completely new and foreign to the novice programming student. It requires a class definition (with a name corresponding to the first part of the source code file name), and it requires a main method. The main method in itself is complicated in that it involves a great deal of technical concepts of the Java programming language:

  • public
  • static
  • void
  • main
  • ()
  • String
  • []
  • {...}

Moreover, a typical Java program is located in a package (requiring a package declaration on top of everything) and often uses classes from other packages (requiring import statements). And the typical thing that takes place inside the main method, is the creation of some object (or objects) which will drive the programs execution forward depending on user actions.

When the student is first exposed to a Java program, she doesn't know what an object is.

The challenge for the teacher is to strike a balance between focusing on the important part (e.g. what goes on inside the main method) and at the same time handling all the details that won't get explained until much later in the course (see the list above).

One strategy is to focus here on the layout of a Java program:

  • Every Java program file (compilation unit) has a class declaration (sometimes in the form of an interface or enum declaration)
  • Every Java program starts inside the main method - i.e. the execution starts in the main method
  • The main method must look as the example given
  • The main method must be defined inside a class declaration
  • The Java program file must be named using the class name as the first part (ending in ".java")
  • Often, a real-life Java program does not do all the work in a stand-alone huge main-method, but rather instantiate objects which sets the execution in motion

Later we can return to each of these parts in more depth and detail.

A common problem with classic Java courses and Java text books is that typically the first half (or more) of the material focuses on writing huge stand-alone main methods, sometimes using static methods in the same, only, class of the program. This is not what typical Java programs in the wild look like, so why should we lead the students into this kind of behavior? The cost of the decision to not fall into this trap is, of course, that we have to introduce the concept of classes and objects early on. That's a price worth paying in our humble opinion.

Another thing, which we think is good to look out for and address already at this point in the course material, is how students use the command line and their editor. We force our students to use the command line to compile and run programs, but also to edit the program's source code. A common behavior among students who are new to the command line is to open the editor via their graphical desktop environment (e.g via some panel, start menu or desktop shortcut), and then start typing away. The problem comes when they are about to save the file, so that they can compile it and run it from some directory using the terminal and command line.

What we tell our students, is to stop regarding the editor and editing of the program as a separate activity from the rest of the program development process. If you work in the command line, invoke your editor from the command line too! If you create a directory from which you will do your work, and you need a new Java source code file there, just open it via the editor. Most editors (all we have worked with) either creates the file in the right place at the time of the first save, or it asks the user something like "The file you want to edit doesn't exist, do you want to create it?" when you start the editor from the command line, giving the "new" (non-existing) file as the argument.

We try to teach them that the command line is a safe place, and you don't have to leave it. You can do everything you need from the command line, without having to open applications for file browsing, or editing text using your operating environments graphical interface.

You want to edit a file? Tell the editor from the command line where the file is, using a relative path! You want to create a new file and start editing it? Tell the editor from the command line where to create the file, using a relative path! Want to list the files in your directory? Use ls from the command line - you probably are in the directory you want to investigate already, otherwise use a relative path! Want to see the whole directory tree? Use the tree command! Etc.

Teaching the students how to invoke the editor using a relative path as the argument, saves a lot of problems which are common to students who are just learning how to program. Ever helped a student who is certain that she has fixed a problem and recompiled, only to find that the student is editing one copy of the file, and compiling another copy. That's a sure indication that the student didn't open the file from the command line.

Using bash actually helps you to be sure of what you do. You can use tab completion when writing the absolute path to the file you want to edit, compile or run. That eliminates many common mistakes and sources of headache.

Full frontal - Example code up-front!

Here's a small Java program, creating an object using the class Talker and asking the object to talk.

public class TestTalker {
  public static void main(String[] args) {
    Talker myTalker = new Talker();
    myTalker.talk();
  }
}

You don't have to understand the code at all, before seeing the videos, but reading code is always good, so we included it here for reference.

The layout of a Java program

A Java program, in its smallest and simplest form, has one source code file. The source code file is a text file with instructions written in the Java programming language.

This small, single file Java program contains at least one top level declaration of something called a class. This class has one special piece of code, called the main method, where the execution really starts.

Videos

English videos

Swedish videos

Live coding videos (English)

This one is in English, and is included in both playlists above. It's here for completeness.

Watch some videos right here!

There are more videos (linked above) over at Vimeo, but you can get a taste right here:

Questions and Answers

Q: “You say that even the smallest Java program has at least one ‘class’ declared. Is it common to have more than one class?”
A: Oh, yes! It is in fact more common than having only one! In these first introductory courses, we usually start with the simplest form and structure however. But since it is so uncommon in the real world to write everything in one single file with one single class, we will very quickly move to the situation where you use many classes. Note that since Java comes with a huge library of predefined classes for you to use (the so called standard Java API), it is not uncommon that even if you were to write a stand-alone program in just one file with just one class defined by you, you would anyway use one or many classes from the API! In fact, you hae already used (or seen in the examples) how to use classes from the API.

Q: “Wait, what? There were classes from the standard Java library in your examples?”
A: Indeed! For instance, you remember the so called main method? It had the name String inside the parentheses. String is a predefined class from the Java API. It is a class representing strings of text. If you look closely to the greet() method of the Greeter class, it also uses a class called System. That’s also from the standard Java API. System is a class for accessing and using the computer system where Java is running, so that’s where we have stuff for writing out text to the terminal (standard output stream, which is usually connected to a terminal) for instance. Soon we will look at more predefined classes from the API (in the chapter on using objects for instance).

Q: “But in your example, you said that the Small class was using the name Greeter which was a class in a package/directory called ‘lib’. In order to use stuff like the Greeter class from that package/directory we had to write “import lib.Greeter”. How come we don’t need to import the path to the Java standard API classes like String and System?
A: Well spotted! There is no fooling you it seems! In fact, all classes in the Java API are grouped together in various packages and in order to use the classes in some package, the path to that package needs to be imported to your program. However, the creators of Java have cheated a little when it comes to one particular package called java.lang (where commonly used classes like String and System exist). That is the one package that is always available to your programs with or without an import statement! You may, of course explicitly import “java.lang.String” for instance, but nobody does that. But try for yourself and see that the code still works the same with such a statement. Now try and remove the “import lib.Greeter;” statement from the Small class and re-compile. Greeter is definitely not part of the java.lang package of the standard Java API (probably many people wish it were! No just kidding!). It is a local class that we wrote and put in the lib directory/package. So the compiler will complain about the Greeter name, and probably complain that it can’t find a class named Greeter anywhere. Put back the import statement again and re-compile and see that it works again. This way, you will understand that classes in packages other than java.lang can only be used if the path to the correct directory/package is imported. You may think of the import statement as an instruction to the compiler where to find classes and other names that occur in your code but is not part of the java.lang package. There is actually an alternative, however, to using import. We will see later in the course that you may also use classes by their full names including the package name. So if we wanted to avoid importing lib.Greeter, for instance, we could change every occurrence of Greeter in the code to lib.Greeter (packagename.classname is the pattern here). But that is quite long to write (there are packages with very long names) so the import statement is very handy.

Don’t worry if this sounds confusing at this point. We will use packages and imports a lot throughout the course!

Q: “The Small class did not have a package declaration at the top of the file. So it’s OK to have classes that are not in a package?”
A: It is not forbidden, but it would be wrong to say that a class could not not be in a package. That would actually be the same as saying that the file is not in a directory! Remember, package is the Java way of talking about paths and directories. So, the Small class does actually also belong to a package, but a package without a name. The reason we can compile and run this class in the Small.java file is that we instructed you to navigate to the same directory as the Small.java file. So when we run the Small class, Java will actually know that this is a class in the nameless package. Classes in the nameless package must always exist in the same directory as where you ran the java command (unless you have used a special construct called class path, but that’s a topic for later chapters!).

Links

Further reading

Where to go next

Next page contains the exercises for this chapter: Programming in Java - Exercises

« PreviousBook TOCNext »