The Java community is a mature yet evolving one. Java still has a stable group writing enterprise-grade software and newer interest from Android, Minecraft, and more trendy JVM projects such as Kotlin and Scala. In the ten years that I've been writing Java software, much has changed in tooling, with the core idea retained. This article goes over the various development tools for Java development, each one's benefits, and my preference based on working with them.
The IDE is arguably the most crucial part of a software development toolset, as it's what you interact with the most during day to day development.
IntelliJ IDEA by JetBrains has cemented itself as the most capable Java IDE; providing hundreds of features to speed up development. IntelliJ includes a best-in-class debugger, a wide range of integrations, and inbuilt static analysis tools. A community version designed for purely Java development is available for free, with a further ultimate edition available at varying price points. The ultimate edition adds support for more languages, as well as Java EE and Spring tooling.
There is also a modified version of IntelliJ distributed by Google known as Android Studio, specially built to include Android application tools. While other IDEs are capable of this, Android Studio removes the need to install plugins and setup the UI for an Android workflow.
Eclipse IDE by the Eclipse Foundation is the other leading Java IDE. Unlike IntelliJ, Eclipse is entirely free and open source. While it doesn't provide as many of the time-saving features as IntelliJ, it is still a very capable IDE. The most significant benefits Eclipse has over IntelliJ is being open source, and support for other languages and frameworks without a price tag.
After having used both IDEs for almost five years each, I prefer IntelliJ IDEA. In saying this, I have not seriously used Eclipse in five years. It's possible and likely that the IDE has improved substantially since then. I also did not dislike using Eclipse; I feel that IntelliJ better suits my workflow.
Build tools are practically required when writing a larger project. They handle the entire compile flow, from compiling the code, running tests, packaging, and deploying the final application.
Gradle is a mature yet recently popular build tool for Java, that uses the Groovy or Kotlin language to define a build script. Gradle allows writing code that defines tasks, and the dependencies between them. While very flexible, Gradle can appear more verbose for simple situations due to the nature of being written code. Gradle also includes many inbuilt features to speed up larger builds, such as multithreaded and incremental builds.
Gradle has many plugins that add new tasks or functions, such as license validation or maven deployment. Existing plugins quickly solve most everyday tasks, and it's easy to write plugins in Java. It's also easy to write the code within the build script itself for simple project-specific tasks.
Maven is a mature and ubiquitous build tool from the Apache Software Foundation. Maven, unlike Gradle, uses a more declarative method of describing the build steps. Maven projects use an XML file that lists dependencies and plugins. A plugin handles each action of the build, generally written in Java. Like Gradle, there are plugins to handle most everyday tasks. The main caveat regarding plugins is that any custom behaviour must be written as a plugin rather than inlined in the build file.
As Gradle and Maven work somewhat differently, people are often more particular about the choice here. If you're better at conceptually understanding declarative build scripts, Maven is likely a better choice. If you prefer working with code to handle the build, Gradle is probably a better choice. They both generally support the same features through plugins, so the only correct decision is what works best for you.
I prefer Gradle, as I struggle to understand the flow of builds with the declarative approach Maven takes. I also feel that Maven can be unnecessarily verbose when working with multi-module projects, which I commonly do. In saying that, the verbosity can also make it easier to reason with what's going on for more complex multi-module projects.
Profilers are an essential tool for identifying the cause of slowdowns in applications so that you can work to fix them.
YourKit is a powerful paid Java profiler, with support for a wide array of features. YourKit can perform both CPU and Memory profiling and has extra features to profile exceptions and database calls. There are also numerous display modes to assist in identifying performance woes, such as a flame graph. There is also support for remote profiling using a Java Agent and profiling over an SSH tunnel. On top of this, YourKit can deobfuscate code on the fly from many popular mapping formats, even with support for Minecraft mods.
VisualVM is a free Java profiler; commonly used due to being included with the Java Development Kit. It's a very capable profiler, capable of both CPU and memory profiling and remote profiling. While it's capable of remote profiling, it cannot do it over an SSH tunnel. Overall this is a solid choice of a profiler, given inclusion in the JDK and being free.
I use YourKit when profiling; however, I have it through an Open Source license due to only using it with Open Source Software. If I were to use it with closed source software, I would use VisualVM as I don't personally use many of the features that differentiate them. For enterprise software, I very much believe that YourKit is worthwhile over VisualVM.
Static Analysis tools help alert programmers of potential bugs that they may have missed when writing the code. They also take a bit of strain away from code reviews, by allowing the reviewer to focus on more critical aspects of the changeset rather than formatting or frequent issues.
Checkstyle is a very mature tool for enforcing code style. It has plugins for almost all popular IDEs and build tools and preset configurations for most popular code styles. Checkstyle integrates easily into a CI flow to spare reviewers the pain of noting style issues in a PR.
SpotBugs is the spiritual successor to FindBugs, a project that aims to use static analysis to detect known bugs in code. It includes a long list of default checks, as well as an API to add your own. Like checkstyle, there are also IDE and build tool integrations for SpotBugs and FindBugs.
Both of these tools are useful for larger projects. Checkstyle is excellent to use and easy to set up, but SpotBugs can be a bit more complex to make beneficial. It makes sense to fine-tune the checks used with SpotBugs, as not all can make sense for every application type. And to get the most out of it, you should write checks for common anti-patterns within your application. I use checkstyle for all of my projects and run the SpotBugs IntelliJ plugin every so often to see any insights it can provide me.
There are many tools in the Java ecosystem, each with their pros and cons. You can't go wrong by using any of the popular tools, but different ones work well for different situations. An excellent way to find what's right for you is to give a few of them a try. What works for me may not work for you, but I hope my description of each of these tools helps you find out what's right for you.