Over a million developers have joined DZone.

Two Useless Java Customs

DZone's Guide to

Two Useless Java Customs

· Java Zone ·
Free Resource

The CMS developers love. Open Source, API-first and Enterprise-grade. Try BloomReach CMS for free.

A couple common Java practices that annoy me.

Calling super() in a constructor

If you use Eclipse to generate a constructor it will look something like this:

public MyClass(int x) {
this.x = x;

Eclipse always adds the call to super(). PMD has a rule for this (in its Controversial Rules category). The explanation is simply “It is a good practice to call super() in a constructor”.

If you omit super() in a constructor the compiler adds the call to super() for you. The compiled code is identical, whether you write the call or not. Effective Java doesn’t seem to address this. Is there any benefit to writing the call in all your constructors?

Supplying messages to JUnit assert calls

JUnit assert methods support a message argument, displayed if the test fails:

assertEquals("a != b", a, b);

This message does make a test failure slightly easier to read but I don’t believe the benefit outweighs the tedious overhead of typing messages for all your asserts. Tests should fail rarely, and when they do they almost always require stepping through or at least looking at the source of the test to figure out why they are failing.

I always omit the message unless it’s explaning something that isn’t obvious when looking at the code.


From http://dmy999.com/

BloomReach CMS: the API-first CMS of the future. Open-source & enterprise-grade. - As a Java developer, you will feel at home using Maven builds and your favorite IDE (e.g. Eclipse or IntelliJ) and continuous integration server (e.g. Jenkins). Manage your Java objects using Spring Framework, write your templates in JSP or Freemarker. Try for free.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}