Creating a CAD Application in Java

I'm a Java (JavaFX) freelance consultant, Software Engineer, and Software Designer and a few months ago I finished a CAD application for a client.

This is a CAD application whose purpose is to calculate the energy efficiency of dwellings (or multiple dwellings). It can be seen as an application similar to Autocad, which is used in civil engineering, architecture, etc., but with the specific purpose to perform energy efficiency assessments. 

My client and I were able to finish the project within a much shorter time frame and on a much smaller budget than other similar projects from competing companies. It wouldn’t be an exaggeration to say that its cost was about 30 times less and it took at least half the time.

The feedback and reception to our application have gone far beyond what we expected, even though the application is still in beta (at the time this article was first published).

Background

My responsibility in this project was to define the higher-level architecture, perform the implementation, design the User Interface and User Experience, and go through all the aspects of setting up a professional environment and workflow for developing a software application.

My client, an energy rater by profession, has always been pushing energy rating to a higher level. He’s done energy ratings for several buildings, including commercial, public, and residential spaces. Some of the award-winning projects. As a self-taught, amateur programmer he also helped implement the application. 

The purpose of the tool, called HERO, is to perform the energy efficiency assessments of buildings and generate an energy rating certificate. These certificates are mandatory and every building must meet a minimum value of energy efficiency. Applications that do this type of work must be certified by a public entity (ours already is) and the professional doing the energy rating must, themselves, be a certified energy rater (having completed an accredited course with success).

High-Level View

You probably noticed from the above picture that the application is using JMetro. The image above is from the Model view.  In this view, you create the project and enter all its data. The pane to the left is where you can view the visuals and create the floor plan (visually). The pane to the right is the Datagrid where you see and enter data for all the objects of the project (walls, windows, floors, top lights, etc.) in a table-like format. All these views are inside a Dockpane-like container that allows you to resize, restore, and maximize each pane.

There are also other views, inside the Model view, not shown in the picture. One of these is the library, where you can create and manage the materials that you can use throughout your project, create custom assemblies for walls, view the different types of windows, etc.

After you run the simulation, you can also see the results of your energy efficiency modeling (picture above). The Results View shows a dashboard, with charts, tables, etc., that lets the user view, at a glance, how efficient the dwelling or dwellings are and quickly notice what might need to be readjusted. 

Details and a Few Features

The calculations for the energy rating can get really complex. They can depend on a multitude of factors. To name a few:

1. The materials used. There’s a huge database of materials that can be used in floors, ceilings, walls, etc. And the user can also, for instance, create his own custom assembly for walls defining their list of materials in a specified order (for both interior and exterior walls).
2. Size and layout of the building’s areas.
3. The climate over the year in the area where the building is located.
4. The orientation of the building (influences how the sun heats up each area).
5. Shading of other buildings, fences, etc. that are around the building.
6. The building’s penetrations.
7. Top lights used, ceiling fans, exhaust fans, etc.
8. Other factors.

All the items mentioned are modeled and calculated in HERO.

All the geometry, intersections, etc. are also computed by the application. For instance, if you create a Zone in a level – a Zone can be a living room, kitchen, bedroom, etc. – and then another smaller Zone in the level above, there will be an intersection. This intersection will produce a “hole” in the ceiling of the level below, like a donut. HERO will realize automatically that the two zones are connected and will create a new Ceiling in the zone below (in the place of the donut) adjacent to the zone above.

Shading objects are also calculated automatically, one Zone can cast a shade on another Zone placed elsewhere.

Another thing that HERO automatically computes are adjacencies between walls and zones. If you create a Zone right next to another, instead of creating two walls between the zones, the application will automatically figure out that the zones are connected. It will connect the two zones by creating a lone internal wall between them, which is different from an exterior facing wall. 

For this post not to get too long, too tedious, and too technical I just pointed out some of the features of HERO, there are a lot more. I think you can get a general idea of HERO’s features from what was mentioned above. 

Reception and Feedback

My client and I were surprised by the reception the application got. Given that, at the time this article was first written (and at the time the application got its first release), the application was still in beta and that there were already three similar applications in the market, two of them well established, we were expecting a much more moderate reaction.

Before 24 hours after the first release, we already had 50 registered users and one certificate issued. In our issue tracker, which just stores bug reports from our users, we were getting thank you messages.

Technology and Form Factor

Notice: I might be a bit biased because I’ve been working with JavaFX (and Java) since the very first release. However, I’m going to be as impartial as possible.

If the requirements are to build a productivity application, the best option in my opinion is to go desktop native, instead of, for instance, doing a mobile app. Nothing beats a keyboard and a mouse in this area. Besides more precise and faster input, you can display much more content on the screen without having to worry about the touch targets being too small for the user's fingers. This also means the user will be able to see more data on the screen, which is important in a productivity application.

As for “native” vs. web, native allows for better performance, security, etc. than a web application. Web apps have the advantage of higher availability (no required installations, all the user needs is a browser) but if you’re building a performance demanding app, I think your best bet is to go native.

Regarding the programming model, I tend to prefer Java (or any other object-orientated, type-safe language) and its framework and big collection of third-party libraries over the web programming model; especially when building complex applications.

JavaFX (and Java) are a perfect fit in this type of scenario as JavaFX really shines in the desktop world. HERO is currently running on Windows, which will probably be the majority of users for your desktop applications. But we can easily, with a few tweaks, support Mac as well and even Linux (though in our case there probably won’t be many users using that OS, if any).

If for some reason, we ever have a need to create a scaled-down mobile or tablet version or reuse some of our existing components in a mobile application, we can. Oracle and Gluon have been pushing hard for this, continuously working and making it better. Recently, by leveraging GraalVM, applications have become AOT compiled, benefiting from faster startup times and performance. This is also great for iOS since iOS doesn’t allow for JIT compilation.

To be fair and to try to be impartial, I’ll conclude this section with what, in my view, are some of the downsides of JavaFX (currently, at this moment):

• Table API.
• Lack of tools to better debug CSS issues and try out CSS tweaks, for instance having something like Firebug (ScenicView is great for other purposes, but not this specific one).
• Lack of support for some of the web’s CSS properties. Also one of my pet peeves is the fact that every property is prefixed with “-fx-” (I would prefer this to be dropped when working properties that have the same behavior as the ones in CSS).
• IDE support for JavaFX CSS isn’t great: error highlighting, etc. (side note: I’m using IntelliJ).
• The JavaFX API is too closed off and lacks support for an extension in some cases (classes that are final, classes with final methods, etc.). Due to this issue, I prefer Swing’s more open API.
• Some Font rendering issues (this might only happen with some fonts and only on some platforms – Windows is worse than Mac).
• Better separation of concerns in JavaFX Controls. There was a plan a few years ago to make behavior classes public, which would probably provide a better separation between the View, Controller, and Model aspects of a Control. Right now it’s a bit difficult to create a new skin for an existing JavaFX SDK Control if your only requirement is to tweak some of its View aspects, especially when that can’t be done through CSS. This often results in developers preferring to create a new Control altogether rather than creating a new skin, which would mean more work and a higher degree of coupling with those Controls (for instance, you won’t be able to easily switch between skins). The fact that the API is often too closed off also means that, usually, extending an existing control isn’t an option.

Conclusion

Despite being quite a complex application, I believe HERO was created in record time. Not only that, but feedback from users makes me feel like the application fills a gap and that they are keen to start using it and pushing it as the default tool for their company.

I believe that having a good UX, creating features that users have been dying for, writing well-structured code that lets you continuously evolve and better maintain what you already have, and developing a nice looking user interface are the markers of a successful application. I think we’ve been able to score high in all those markers.

The choice of form factor and technology is also really important when building an application. I believe the right choice was made for this productivity application: going desktop native and choosing Java and JavaFX.

You can check out my talk at JFXDays about this application here.

You can follow me on Twitter if you want to keep up-to-date with my work, open-source projects, and published articles.