An issue that constantly comes up here at the Ranch is that we see Java beginners struggling to use Eclipse or NetBeans or another IDE while learning Java. Our advice is always the same; put away the IDE and learn Java first. Then and only then return to using an IDE. But users always seem resistant to this idea. They want to jump right into using the latest version of (insert favorite IDE here) with all its bells and whistles because, well, just because. This article is going to try and convince you to follow this advice.
The first problem is that you now have two things to learn, Java and the IDE, and lets face it, an IDE is a complex piece of software. It can take a fair bit of configuration to get it setup and working properly. So lets keep things simple for now, okay? Added complexity is just going to increase your frustration level. Once you start using an IDE you will have plenty to learn about all its features, so solidify that Java knowledge first.
Second, the Java JDK (or SDK, or whatever it's called this week) comes with a command line compiler, javac.exe. It's imperative that the beginner learn to use this compiler and all its option switches, but this is one of the many things that the IDE hides from you. Trust me when I say that youll never understand how to manage the classpath if you rely on the IDE to do it for you.
Third, most IDEs have a neat feature that will pop up the Javadoc for a class or method when you pause on it. It seems convenient but its preventing you from learning to navigate the real Javadocs. I advise you to have the api Javadocs open in a browser at all times while developing so you can refer to them as needed (and youll need them a lot). Dont let the IDE make you lazy, at least not yet.
Fourth, when building web applications the IDE creates the entire directory structure for you such as the WEB-INF folder and the package folders under the classes folder. You need to understand this structure and how build it all manually.
Finally, the IDE will warn you about possible compile-time and runtime errors before you even compile and run the program. Sometimes it will even let you run code that wont compile, leading to all kinds of weird, hard to diagnose errors. You need to learn to understand the messages that come from the command line compiler and analyze the stacktraces that result from runtime errors. A stacktrace will give you the failing class and line number, and with or without an IDE, youll need to learn the dark magic of reading them because its not always the top line of the trace that shows the true error. You'll find a good document about how to fix those nagging compiler errors here.
So get one of the editors listed here and use that for editing your .java files. Compile them at the command line using javac.exe. Package them in jar files for command line applications and run them from the command line, or create a war file for web applications and deploy it manually.
You should understand that we dont have anything against using IDEs. They are powerful, useful tools. We all use them and you should too, just not yet. We just want you to delay taking that step until you understand the magic going on behind the curtain.
So how do you know when are ready to make the leap? Ask yourself these questions. Can you create the directory structure for a new web application from scratch? Can you compile your web application into a war file and deploy it to Tomcat (or Glassfish)? Can you compile a command line Java application, package it in a jar file, and run it from the command line? Can you diagnose and fix compiler errors? How about runtime errors? Can you successfully add an external library to the classpath switch of the compiler?
When are comfortable doing all these things, then you can break out that shiny copy of Eclipse with its new IDE smell and start learning how to use it to increase your productivity. Youll be a better programmer for having done it this way.