void : Java Glossary

A keyword used in Java to indicate a method does not return a value. It is not used to indicate a method requires no parameters. Constructors don’t use the void keyword even though they don’t return an object.

Void is also a dummy class.

Void also refers generically to the various flavours of hollow Strings, namely: blank (i.e x.length() != 0 && x.trim().length() == 0, e.g.   ), empty (i.e. x.length() == 0, e.g. "") and null (i.e. x == null). One of the most common sources of error in Java programs comes from confusing the three different flavours of void strings. Java code often has a maintenance timebomb ticking in it in the form of inconsistent representation of void strings and objects. It is unwise to just let NullPointerException find your problems for you. The problem may surface many kilometers from the true source of the problem. There will always be one more bug. It is better to decide on your canonical void representation and be fanatically rigid about it.

Which void representation should you use?

If you don’t use a canonical representation and consistent checking for the various void forms you will have two classes of bug:
  1. Void Strings mistakenly treated as if they were non-void. The effect can be indirect and very hard to track down, e. g. You may test for the presence of A and if it exists do some operation on B.
  2. Non-void Strings are mistakenly treated as if they were void. Data just disappear or are ignored.
These bugs can be a bitch to track down because the variant voids or void itself are often rare for many data fields. It may require a particular improbable constellation of data for the bug to surface.

There are two plausible canonical representations for void namely null and empty (""). Normally you combine either of them with canthappen. The four ways you might represent void Strings are:

  1. canthappen

    Check for all forms of void parameters and throw an IllegalArgumentException or NullPointerException if Java won’t throw one all by itself soon. It is far easier to prevent bad data (i.e. inconsistent void representations) getting into your objects and databases that to deal with it once it gets in. You might wrap this code in if (debugging) so it can be turned off for production speed. Unfortunately Java has no design-by-contract features to do this more elegantly. You can catch these with a neverNull method.
  2. null

    Make sure all void inputs are converted to null using a possiblyNull method.
  3. empty

    Make sure all void inputs are converted to "" using a possiblyEmpty method.
  4. blank

    Not recommended.
You are just asking for trouble if you use a variety of void representations. The code may be clear to you, but will drive people who come after you maintaining the code crazy.

In a similar way you can get into trouble returning null instead of an empty Collection. One convention, used by File.list, is to return an empty array or Collection for no elements, and null to represent the result of an invalid request.

Note to C programmers

There are a few differences between C and Java that may confuse you.
There are three ways you might initialise a reference String variable:
  1. No initialisation at all: advantage: compiler catches you if you fail to provide a proper value later (for local variables).
  2. null: advantage: fast comparison test. Run time catches you if you fail to provide a proper value later. Happens automatically for static and instance variables.
  3. "": advantage: The value will be processed just like any other String without incident. This may be quite suitable if an empty String is a reasonable default.


IntelliJ IDE (Integrated Development Environment) has custom annotations @Nullable and @NotNull that you can use to mark a parameter or return value as potentially null, or must be not null, respectively. You must import to make the
// making IntelliJ @NotNull and @Nullable available to your program
import org.jetbrains.annotations.NotNull;
import org.jetbrains.annotations.Nullable;
The IntelliJ annotations.jar file must be available to javac.exe on the processorpath (usually the classpath) for them to work. You must specify the specific jar, not just the directory.

Learning More

Oracle’s Javadoc on Void class : available:

This page is posted
on the web at:


Optional Replicator mirror
of mindprod.com
on local hard disk J:

Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.
Your face IP:[]
You are visitor number