Scalability is about being able to handle more work without this causing issues. For most software, scalability is about the number of people using it. If a million people suddenly open your website at the same time, your server should be able to handle this. As Checkstyle is only run locally or as part of a continuous integration pipeline, this aspect of scalability is not an issue. What can however grow, is the size of the project Checkstyle is run on, and the number of checks to be run.

For a project like Checkstyle, being able to assure some quality standards is both beneficial for developers and users, as it has the advantage of likely making the software more reliable, as well as creating a project that is easier to maintain. Checkstyle makes an attempt to ensure quality by going through several measures. In this essay, we will be evaluating the actions the Checkstyle team has chosen to ensure quality, analyse them together with some discussion, and find possible reasons for their choices.

As discussed in our previous essay, The Checkstyle Vision: Keeping Your Code in Check, Checkstyle is a static analysis tool that can help a Java development team keep the same coherent code style across their project, which keeps the code readable, maintainable, and consistent. This essay will talk about the core architecture of Checkstyle. Firstly, we will talk about the main design pattern used in Checkstyle: the visitor pattern. Then, we will go over four different levels of overview: the container view, the component and connector view, the development view, and the runtime view.

Most of us probably remember the advertisements: ‘more than 3 billion devices run Java!’, and since the time when these ads were common, the Java ecosystem has continued evolving. It is hard to overstate the influence of Java: it is used extensively in server development, it is a key pillar in Android, and its object-oriented approach has influenced the development of many other languages. At the end of 2018, there were an estimated 7.