JArchitect: A Review

JArchitect is software for analyzing Java projects.

I think we need to use software to reason about software. As software developers, we are building software to help other professionals in doing their job but still, we rely not so much on software to help us in our work.

We like the romantic ideas of being artisans. While there is a large amount of craft involved in writing software, there is also space for benefiting from software to:

• Navigate large codebases.
• Identify problems in an automated way.
• Recognize patterns and repetitive structures.
• Perform refactoring at scale.

The question is:

Can JArchitect help with any of that?

Disclaimer: I was contacted by the company behind JArchitect and I was given a license to review their product. They did not compensate me for this review and I have no incentives to do a biased review.

First Impression of JArchitect

Right after I downloaded and installed JArchiatect, I wanted to start it for the first time. At that point, I noticed how the icon looked poorly compared to others. It popped out at me simply because it was the only one not looking nice.

Let me say that I am not a design maniac: I have been using Linux as my main system for most of my professional life, and I am an engineer at my core: I just want to get things done properly. However, in this screen, I can see different icons from large companies or open-source projects. They all look decent. I can like or not like them, but they all look professional. The one from JArchitect is the only one which looks sloppy.

Is this relevant? Not so much.

Does it help make a good impression? Not so much.

I received the license by email. They had sent me the license for the last version of the software, but it was not available for Mac or Linux, just for Windows. I guess they assumed I was running Windows. I am not a Windows-hater or anything like that, but in the last five years, when I have worked with Java, I have seen only a small percentage of developers using Windows machines. So I take the fact they assumed I was using Windows as a hint that they cannot be very familiar with the Java development world. Or maybe I have only worked with companies that were the exception and Windows is far more widespread among Java developers than I can see from my small, biased world.

Anyway, when I downloaded the version, I got the previous one — not the one for which I had the license. So after some pretty confusing screens and instructions that were Windows-specific, I wrote to the guys at Codergears and got the right license. Still, in the email, there are references to Windows even if their software is not Windows-specific, but at least at this point, I was able to insert the license.

Ok, the start was not frictionless, but now it is time to dive in.

Selecting a Project

You can select a project in different ways:

I am happy to see they support Maven, but I am frustrated they do not support Gradle.

Personally, I use Gradle in all my new projects, so for me, this is a big limitation. You can also import an Eclipse workspace, but you cannot import an IntelliJ IDEA one. For me, the most important option would be a Gradle import, followed by an IDEA project import. However none of this is supported.

For the sake of reviewing JArchitect, I opened JavaParser, which is based on Maven. If you do not know, JavaParser it is a great library to process Java code. Incidentally, I am a contributor to that library.

How the Home Screen Looks

This is how JArchitect looks like when you start it:

JArchitect – How it looks like

One of the characteristics of JavaParser is to not have any dependency. In the image at the center of the screen, it seems that javaparser-core has a dependency on a module. That module has a suspicious name: MISSING.

I do not know why they report this MISSING module. Maybe it is an error that happens when the project has no dependencies, maybe they cannot handle multi-module POM files. For example, in the case of JavaParser there is a POM representing the whole project (the “parent”) and then modules like javaparser-core and javaparser-testing.

Let’s look into this MISSING module.

This module apparently refers to the MISSING.jar. I guess it is a default value for when something wrong happens. To me, this seems very… sloppy. Instead of saying explicitly that is not connected to any JAR, they just used this sort-of placeholder. This piece of software is intended for people who build software, and they realize this is a very poor programming practice. This is not helping to give a good impression.

The fact that JArchitect cannot deal with a simple project defined using Maven, when you basically support just Maven, is surprising for me.

Exploring the Tool

We have a bar that we can use to jump to different views.

Some of these buttons change the view in the tool while others open windows in the browser. Personally, I do not like it and I would expect that HTML files could be displayed inside the application. On the other hand, I appreciate the fact that some HTML files could be shared with people that do not have access to the tool.

For example, one of the views shows a report. This report should give an overview of the status of the project, and I like the way it is organized.

However, some of the diagrams reported just do not make sense to me. Take this one:

What does this mean? Aside from the fact that the names of the modules are very small, there is basically not much explanation. I am also not sure why most modules have (apparently) a very high instability (really? Why?) but are in the green band, which I suppose is a good sign.

Clicking on the trend charts, things work less well. It opens a window that looks like this:

We are talking about a very simple project based on Maven. As I open it with a fresh installation, I get broken pages and errors?

As a note: some of the code in JavaParser is generated, and it is marked using the standard annotation javax.annotation.Generated. From what I saw, no report or graphs seem to handle generated code differently or separately. Maybe the tool does that and it is just not evident to the user, or maybe the author of the tools are not familiar with this annotation. I am not sure.

Looking at the Queries Written

Honestly, the report and the charts did not provide much value to me, but the strong point of JArchitect should be the fact it supports queries on code.

Let’s first look at the queries that are provided with the tools and the results they give us. In the next section, we will instead look at how we can write our own queries.

Queries are organized by groups. You can select a group on the left and see the corresponding queries on the right:

Queries on Java code

If you then click on specific queries, you can see the code of the query itself and the matched elements in another panel:

Queries on Java code

At this point, you may want to investigate some of the elements identified by the query. I would expect to be able to click on a method to open it and look into it. You cannot. There is an item in the context menu, but I get this:

What should have been set? I imported the POM. The source code is located accordingly to the standard organization of Java projects. Why is not just imported correctly?

At this point, I have these bunch of methods and I just cannot check them from JArchitect.

Also, looking at the error messages, it seems clear it has been written using .NET. They are not from the Java world.

Some of these queries are naive. For example, there is a query suggesting to not use boxed types:

Prefer primitive types to boxed primitives

But it also does not make much sense: There are differences between primitive and boxed types.

Another one is “Always override toString”. Really?

Or another named “potentially dead methods”: I am writing a library, so of course I do not call all methods. Some are intended to be called by users. Same thing for the methods that could have lower visibility (3219, according to JArchitect).

It is hard to write queries that are useful in all cases, and I would expect to have to do some tuning to get values out of the queries provided. However, honestly, I did not find many valuable insights using these queries. The fact that I can neither see the code of the classes or methods identified by the queries make the user experience much more painful, and it significantly reduces the possibility of using the tool in a productive way.

Writing New Queries

So I started writing my first query. My goal is to identify methods with a long name. The query editor offers auto-completion and, by looking at existing queries, I could write my own quickly:

The problem with the result is that it seems to consider, as the method name, what is actually the method signature. The proper name (juggleArrayCreation in the picture) is most definitely not 76 characters long, as it seems to be by looking at the results of the query.

It turns out I should use the SimpleName. This is not a term I have ever heard when discussing Java methods, but at least I can get my intended result:

Or I may want to look for methods with many parameters:

If you look at the first result, it is not even a method, it is a constructor. I think there are definitely issues with the naming chosen. As result, it is quite confusing for Java developers.

I really, really like the idea of running queries on Java code — and the basic support is there — however, the underlying metamodel does not seem to have been created with Java in mind or by someone familiar with Java. This is a major issue because, even if I learn and get used to the wrong terminology used, it would make my queries confusing and unreadable for persons who know Java.

Summary

I am disappointed.

I heard good things about NDepend and it seems like a hurried, half-baked port to the Java world, probably done without involving Java developers.

I like the idea of writing queries on Java code. That is great. This is why I worked on a project named effectivejava years ago — and I am now working on JavaSymbolSolver.

I get that writing automated queries that make sense is not easy. Most static analysis tools are a waste of time unless they are properly configured. However, I think the company does not have the experience or knowledge of how things work in the Java ecosystem.

I think the possibility of writing your own queries has great potential — and it could justify a good price. However, in my opinion, the quality and the current status of the project are inadequate for the price. We are not talking about an open source project given away for free: The cheapest license with a 1-year subscription costs $599.

I believe in releasing early and often. This is always true for open source and can also be useful for commercial software — to get feedback. However, I would expect people to focus on a few core features and implement them correctly. This software seems very far from a level of quality that is acceptable.

I know JavaParser fairly well, and I did not get any insight about it using JArchitect. Maybe someone that is totally unfamiliar with a large project could get some help in navigating the project. I cannot exclude that, but to me, the value was very limited. I would love to hear from people with different experiences to better understand the intended benefit of this.

In my opinion, this is not a product that has been designed and crafted well enough to justify $599. I know that the same product can be used differently by different people — and in different contexts, it can provide a very different amount of value. However, at that price point, I would expect to get correct information and a polished product with support for mainstream options (like Gradle and IntelliJ IDEA). I have seen none of this in this product.

I do not think there are many alternatives to JArchitect. For this reason, if you need such tool, you could either build it yourself by using libraries like JavaParser and JavaSymbolSolver or you have very few alternatives. This could lead you to buy this tool, despite its limitations.

I would be happy to revisit my opinion once they have fixed the most obvious issues.