Want to Get Better at Java? Go Old School.

So you’re a Java programmer, and you want to take your skills to a higher level. I’m going to suggest you take a project and go old school.

Over the course of this blog, I’ll explain what “going old school” means as well as give you some tips and tricks to get started. We’re going to step away from most modern tools and go back to the basics, so you gain a deeper understanding of what Java is and how it works. By the end, you should be well on your way to improving your Java skill set.

Originally published on Keyholesoftware.com by Rik Scarborough on 1/3/23.

Getting Started

Don’t do this on a time-critical project. The tools we currently use have been developed to increase our productivity, so we can deliver these projects in a timely manner, which is a great thing.

However, the way they’re designed has isolated us from the compiler and even the build file. We begin to rely too much on the editor to provide us with clues on the best way to code and the environment to set up and control the build process. To truly improve your Java skills, you’re going to need to step away from these.

So instead, choose a side project, possibly a personal project, that you have control over and can spend some time trying out things.

I will not suggest truly old-school Java programming. When I started in Java, we built Java classes with the javac command. This led to writing shell scripts to build complex projects and finally, Makefiles using the Unix and Windows commands make and nmake respectively. I remember being thrilled when the Ant utility came out and we had a pure Java build tool.

You certainly can go back that far if you’d like, but it will be more difficult to build anything but a very basic Java project.

Choose a Build File

After Ant was on the scene for a while, the Maven utility was introduced. As happy as we were with Ant, we eventually flocked to the easier-to-use Maven. Still later, Gradle was introduced. In my opinion, Gradle is a much more powerful tool. I wrote a blog about it quite a few years ago. Your IDE likely uses one of these under the covers to build your other projects.

So choose your build tool and use the links above to find the getting started documentation for that tool. Once you have your build file (and possibly a stubbed main class), you can turn your attention to editing.

Editing

You certainly can use your IDE of choice at this point to edit both the build file and Java source files. This provides several nice-to-have features, including code completion, creating any new Java source files in the correct directory for the package, and informing you of code errors before running the compiler.

But it also isolates you from the reasons why these are important, and without full understanding, it’s almost impossible to truly improve your Java skills.

Even if you use your IDE for this project, I would suggest having a good editor on your system. There are several good programmer editors for your operating system of choice, but I’d like to take a moment to promote the Vim editor.

The first thing I’ll say about Vim is to get out of it, hit the escape key a few times, then press the : key and type q! followed by the enter key.

The learning curve for Vim is steep, but I find that as a programmer editor, it is invaluable, especially for refactoring code. As an aside, I wrote this article initially in Vim using the markdown language.

The biggest complaint I hear about Vim is that people launch it and then can’t figure out how to get out of it. Because of that, they never want to use it again. And that is why I started out with the key sequence to get out of it; now you know.

When creating Java source files outside of an IDE, you have to be very careful about the directory structure you are placing the files. They must first conform to the location the build file is expecting them. The startup documentation for the build tool will show you that.

Second, you have to follow the package structure you are using. Also, be aware that even in Windows, upper and lowercase are important. In Windows, it will allow you to create the file with letters that are a different case than you use in the source code for the package and class names, but it will create problems for you. In any Unix system, the compiler will have a much harder time.

Code Completion

We, or at least I, have gotten very used to being able to use the IDE to look up method names for the class I am using at any particular time. Before this very helpful innovation, I would have the JDK documentation in a browser window at all times.

We had to write our own frameworks (uphill, both ways) but most current frameworks will have similar documentation pages as well. Both Apache and Spring are especially good at that.

Source Control

Whether you are using Git or Subversion or some other source or version control software, try using it from the command line. This will force you to become a little more familiar with how it works and the different options it has.

If this is a personal project, you may not have a remote repository to sync this to. However, source control is still helpful; it will allow you to track the changes you make to the project as you work on it.

Conclusion

Some of the most frustrating coding sessions seem to come from not fully understanding the tools we are using. I have had discussions with young developers that are frustrated because the environment is not working the way they think it should. Once I explain the reasons things are happening, the frustrations disappear and they are able to move on with the project.

Taking a step back from modern tools will improve your Java skills by growing your understanding. Understanding is a foundation every technician in any skills-based career should strive for.