Here are some things that every Java dev should know, after they complete an introductory Java course like Learning Tree’s Java Introduction, Course 471 (which I wrote the original version of, back when the world was using green threads).

Java Language

Think you know the Java language inside out? Check out the Java Puzzlers book or try the Java DeathMatch web site (people don’t actually die, they just don’t get on to later levels). There was also the Java Black Belt web site but it has gone dark, alas.

Use Your IDE Effectively

Never type more than about 3 or 4 characters of any name, unless you’re creating the thing. — Ian’s Rule

When you need to use a class, call a method, insert an annotation, override a method, and so on, don’t type out the full name. Just type 3 or 4 letters (case insensitive on sensible IDE’s, and vice versa), then press the completion shortcut - CTRL/SPACE on Eclipse. You will see a pop-up list of choices. Do not take your hand off the keyboard, grope around for the mouse, move it into position, click, take your hand off the mouse and move it back to the keyboard._ Save those neurons! Save time! If the choice you want is the first one, just press Enter. If it’s near the top, either type 1 or 2 more characters, or, use the down arrow key followed by Enter. This will add up to lots of time and mental energy saved every year. For more Eclipse shortcuts - and there are lots - try to find a good book on Eclipse, or see my Eclipse shortcuts poster.

Build Tools

Step 1. Automate.

You don’t want to rely on your IDE to do the final packaging of your application, whether it’s a desktop app, a web application, or anything else. Ant was the first widely-use build tool for Java, but over the past years has been largely displaced by Maven, which in turn is being somewhat displaced by Gradle. Read about them all here.

Testing

If you don’t have a test, how do you know your program works? You don’t!

Test early and often! That’s my theme and I’m sticking with it. I wrote the book on the Lint testing tool for C programmers (decades ago), and more recently a book on Java Testing. This book is morphing into a set of videocasts for O’Reilly Media, due out Q1-2016. There is also a set of slides on some aspects of testing.

Internationalization/Localization

Not all the citizens of the world are native speakers of English. I18N is a big subject, but basically you have to put the text you want to be able to localize into a text file that is in "properties format" (name=value), have one such file for each language, and either load them using ResourceBundle class or use a framework like JSF that fully supports them. Then you provide versions of that file for each language you want to support, e.g., text.properties for English, text_es.properties with the Spanish translations, text_fr.properties for French, and so on (using the ISO 2-letter language codes). There is also support for ISO country codes, e.g. text_fr_CA.properties for the variant of French used in Canada (known internally as Quebecois). Android uses the same file format but slightly broke the file name format standard for regional variations.

Reference: Java Cookbook has a whole chapter on I18N.

Reflection API

The Reflection API allows you to examine or "introspect" on another class. You might have used one little part of it in your JDBC101 lesson: Class.forName("driverName"); The forName method of the class Class loads a class file into memory, and returns the Class descriptor for that class. You can also get a class descriptor by using anyKnownType.class or by asking any object to getClass().

Once you have a Class Desriptor, you can create instances, discover methods/fields/annotations/constructors, invoke methods, and have all kinds of fun.

Reference: See the chapter "A Class Named Class" in the Java Cookbook

Scanning and Parsing

A lot of what we do as developers involves pattern matching. Long ago the Unix folk mastered this, by giving textual form to the mathematical notion of 'Regular expressions'. In developer terms, a regex is a concise but precise statment of a pattern to match. As a well-used exzample, consider writing code to match the USA style of "zip code" or postal code. These come in two forms, 5 numbers, or 5-numbers-dash-4-numbers. You could imagine writing some complex if statement with conditions, and lots of Character.isDigit(), but it turns out to be easier:

boolean validateUsaPostCode(String userInput) {
	return userInput.matches("[0-9]{5}(-\\d{4})?");
}

The [0-9] and the \\d both stand for "any digit" (you could use either one in both places, I just used \d the second time because it’s less typing), the {n} specifies a repetition count, and the ? means "0 or 1 occurrences", e.g., optional.

RegEx matching will get you pretty far in parsing line-based files. For full grammatical parsing (e.g., writing a DSL, a Domain Specific Language), you will probably want to learn about recursive-descent parsers, the tools used in the compilers for most programming languages. There are several parser generators for Java; my personal favorite is called Antlr, and you want to start with V3 or V4 of that tool.

Reference: See the chapter on regular expressions in the Java Cookbook, or Jeffrey Friedl’s Mastering Regular Expressions.

It’s the Web

There are over a hundred web frameworks for Java, listed on my site. Two dominant ones are JSF (JavaServer Faces), the Sun/Oracle "official" Java EE way to do things, and Spring MVC, which normally uses JSP (JavaServer Pages, Sun’s previous official way). Personally I prefer JSF because it is more high-level and component-based, but lots of devs prefer Spring - let the battle roll on! P.S. You can use Spring MVC without buying fully into the Spring Framework kool-aid, but it’s a syrupy slope once you start on it.

Spring Framework

Spring is the canonical "anti-Java EE" framework. It was originated in 2004, way back when the Java Enterprise Edition was called "J2EE" and was, indeed, complicated, ungainly, and hard to use. If you didn’t know this at the time, you had only to listen to Spring founder Rod Johnston who was going around to all the Java conferences saying so. He did, indeed, improve things for the developer by introducing Spring. Spring injected the age-old ideas of "dependency injection" and "don’t repeat yourself" into the Java world.

However, time waits for no framework. By the time Java EE 5 rolled around, the people at Sun had gotten the memo about EE being too complex, so they simplified. EE5 introduced dependency injection via annotations at a time when Spring still required complex XML to do so. EE 5 also included JPA, which improved on Hibernate. In all these areas and more, EE 5 showed it could simplify the developer’s world even more than Spring did, and so the momentum has started moving back to direct use of EE. That said, many Java Enterprise devs have invested their entire careers in Spring, so they see the world through a lens that has Spring stamped on it. Others, of course, view the world through rose-EE colored glasses. But it’s my take that, if you’re starting now (that is, 2015 or so), you can skip Spring and go straight to "this glorious sun"-derived Java Enterprise, that is, Java EE 6 or 7.

Keep Up To Date

Always in motion the Java future is. — Yoda

Every new release of Java SE and Java EE brings new features. For example, Java 8 features Lambda Expressions which allow you to replace this code:

class WorkActionListener implements ActionListener {
	public void actionPerformed(ActionEvent e) {
		doSomeWork();
	}
};
workButton.addActionListener(new WorkActionListener());

with this:

workButton.addActionListener(e -> doSomeWork());

Pretty spiffy, eh? Think of all the lines of code that you don’t have to write anymore! Read up on Java 8 in the "What’s new in…​" section of my Java Cookbook, or in any of several books with Java 8 or Java Lambda in their title.