Why not IDE

From Juneday education
Jump to: navigation, search

Here are the authors thoughts behind the choice not to use an IDE throughout this book.

Rikard's thoughts

Understanding basic concepts

At least at first, I think it is wise to use the command line and an editor, in order to understand programming at a much more concrete level than as a theoretical practice. In my experience, starting with an editor and the command line gives a solid understanding of the computer environment. It makes clear the context of program source code as text files, and the role of the compiler. It also gives an opportunity to introduce concepts as arguments and PATH. Understanding paths (and directories) have in my experience proven to be of great importance for understanding the Java concepts of packages, classpath, the import statement (and the package statement). Using an IDE (such as Eclipse or NetBeans) effectively hides the basic concepts of classpath, current directory, relative paths, absolute paths and the concept of (command line) arguments.

Benefits from using editors

Using an editor has several other benefits. A text editor is very useful when working with a lot of the tools used in connection with the pure programming activity. Knowing a text editor makes it easier to later move on to an IDE but will be useful knowledge for editing general purpose files (such as configuration files etc). The same cannot be said about most IDEs ;-) they don't help a lot when you simply want to edit some settings file or create test input for some software that does I/O. And IDEs don't give you any knowledge about using the command line interface, which is a great skill for someone who wants a career or further studies working with programming and computers.

Using an IDE with this book

Our videos and exercises are focused around the use of editors and the command line. Using an IDE such as NetBeans or Eclipse will of course work as well, but the instructions provided in the exercises are not written with IDEs in mind. If you want to use this material and provide tutorials and supervision for NetBeans/Eclipse, the students will probably be able to use that instead. But there might be quite some assistance needed if they get stuck due to some configuration of NetBeans.

Proposed compromise

My suggestion is, that if you insist in using e.g. NetBeans, to introduce NetBeans as an option for the ambitious students, at a later point in the course, perhaps when it is time to start on the assignments. In this way, the students will be familiar with the concepts of directories, packages and classpath.

Benefits from using IDEs in introductory courses are welcome

Do you have any pedagogical benefits of using (starting with) IDEs in mind? Please share them with us, so that we can used this input when deciding on future revisions of our material.

It is probably quite possible to avoid any pitfalls of IDEs when designing a course. But our material is not designed in that way. Suggestions are welcome.

Pitfalls from knowing only how to use IDEs

Using the command line, the compiler, java runtime and an editor might be problematic on par with understanding a particular IDE. Our take is simply that we believe that starting with the basic tools gives a more solid ground to build on and makes learning any particular IDE easier at a later point. We have seen examples of students who only were subjected to Eclipse (or similar) getting totally lost, when faced with a headless environment (for instance when faced with the task of deploying some Java software on a headless server using only SSH) - even after several programming courses...

Pitfalls regarding student behavior and understanding

Things to consider when using IDEs in a beginner's level Java course:

  • Code completion is very convenient, but it may foster a behavior where the student never visit the online Java API documentation - the IDE knows the signatures etc, so why bother to read the docs?
  • Code completion works well when you know what class or method you want to use - but it doesn't help you explore the API to learn what packages, classes and methods (etc) exist...
  • Using an IDE might give the novice student the impression that the IDE is the same as Java - after all, it is both an editor, a compiler and a runtime - This could lead to misconceptions about the Java environment and the process of developing software
  • Using an IDE without ever using the tools that work behind the scenes, might pose problems when the student is faced with the task of deploying and running some software on a computer that doesn't have any IDEs

Command line arguments incompatibilities

For some examples of potential pitfalls using IDEs, take for instance an exercise where the application to be written makes use of user-supplied command line arguments. In a terminal, running the application would look something like:

$ java org.pak.TheApplication argument1 argument2 argument3

To run it inside NetBeans, the student would have to do somehing like this:

  • Open the project properties dialog box
    • Either right click on the project name in the Projects panel and choose the properties option, or choose the Project Properties option from the File menu
  • In the project Properties dialog box, choose the Run node from the left Categories tree
    • As soon as we select the Run node we can see the options for the run configuration
  • In the Arguments text box, type the command line arguments
  • Press OK
  • To run the application with the arguments, you should choose Run -> Run Main Project
    • If you only run any class with a main, the arguments will not get passed

In order to run a Java program we have to introduce the concept of "Project" which is IDE specific and has nothing to do with the Java programming language. Already, we have steered away from how the Java environment works, and instead we deal with how this particular IDE works.

There is some plugin available to make this process more interactive, but I think the point is clear. If we instead, introduce the students to the command line and a shell, and teach the students to run some commands interactively in the shell, the notion of arguments becomes very clear. You can use the ls command to list the contents of the current directory, or if you give it arguments, the contents of the directories supplied as arguments. Translating this to a Java applications then becomes quite straight forward: You tell the students that the arguments are supplied on the command line, as shown above, pretty much like any arguments to any command on the command line.

Benefits from being exposed to the command line in general

The command line also provides for an interesting discussion on the invocation of the compiler compared to the invocation of the java runtime. The compiler's task is to verify source code and produce binary class files as output. The source code to start with is supplied as an argument to the compiler. The source code is stored in text files with the .java suffix. The invocation of the runtime, on the other hand, deals with telling the Java Virtual Machine what class to run. In the Java world, a class has a name (including the package to which the class belongs). So the argument to the java runtime is the qualified name of a class, and not a file.

Benefits from using command line when understanding packages

Understanding the relation between packages and directories is crucial for understanding how to deploy a Java application, from source. You need to understand that the compiler and runtime are looking for classes relative to the current classpath (which defaults to the current directory). And in order to understand that, you need to understand paths in general, the difference between relative paths and absolute paths, the concept of class path as an environment variable compared to the class path as a flag to the java binary.

Benefits from using the command line for understanding standard streams

Using the command line and a shell, allows for showing the students what the standard streams are (input,output,error). This allows for also introducing redirection of the streams and using pipes. Writing software that makes use of the standard input stream is a great way of creating generic software. If a Java program can read from a file given as input, run interactively or reading input from standard in as the result of a pipe or redirect, it provides the user with great flexibility.

Using streams, redirects and pipes might not be very common for the typical Java application, but knowledge about the underlying principles is very useful for students who want to learn other programming languages or get a better understanding of e.g. the POSIX environment. Using only IDEs would make it very hard, to say the least, to demonstrate an application whose input comes from piping the output of another application to it...

Console incompatibilities

Another problem (however not a huge one) is that all IDEs are not fully compatible with how Java behaves when run on the command line (because running something in an IDE is not the same as running it on the command line, of course). As an example, when the System.console() was introduced in Java 6 (in 2005), users of Eclipse soon discovered that the console object could not be used for reading input from an application running inside Eclipse. The reason is that Eclipse doesn't have access to the console, but rather uses its own console window for input and output. The System.console() call returns null when run in Eclipse, which of course is a problem for students that want to use and try that method of reading input from the user interactively. It is interesting to read the bug report about this, since it stretches from 2005 to 2015 and no bugfix seems to be on its way (what I can tell from reading the bug documentation page). NetBeans seems to be in the same situation, there is no Console object associated with the runtime in NetBeans, so System.console() returns null.

It should be noticed that running Java in Cygwin on Windows also means there is no console object ( System.console() returns null ). This is more surprising, since Cygwin is a command line environment.

Running a Java program in Windows CMD.EXE console works with System.console(), as does running the same program in a terminal on GNU/Linux or a terminal in Mac OS.

This small test program can be used to see whether System.console() works:

public class Cons{
  public static void main(String[] args){
    String s = System.console().readLine();
    System.out.println("s: " + s);
  }
}

Running this simple program will crash with a NullPointerException if there is no system console (because System.console() returns null in which case).

The proposed workaround for using System.console() in an IDE (etc) seems to be to use a Scanner instead. Not a big deal, agreed.