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:
- null is fast to test for, e.g. if ( it == null ), however, you can’t run any methods on it.
e.g anull. equals( somethingElse) will generate a NullPointerException.
- "" will work as a parameter to most methods expecting a String.
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.
- 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.
- Non-void Strings are mistakenly treated as if they were void. Data just disappear or are ignored.
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:
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.
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
Make sure all void inputs are converted to null using a possiblyNull
Make sure all void inputs are converted to "" using a possiblyEmpty method.
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.
- Java Strings don’t have a terminating 0 byte. They don’t have a
terminating 0 character either. Java Strings are 16-bit characters. Instead, they
have a hidden 32-bit count field to track how long they are.
- NULL in C is just a synonym for 0.
null in Java is a magic value that can be
assigned to pointers/references to say they don’t currently point to anything. Instance and static references are automatically initialised to null for you
in Java. Usually this value is represented by 0 at the hardware level, but
there is no way you could find out just by writing a Java program.
- In C, there is a difference between NULL, and a string consisting only of a
single 0. In Java, the equivalents are null and "" which makes a similar distinction.
There are three ways you might initialise
a reference String
- No initialisation at all: advantage: compiler catches you if you fail to provide a proper value later
(for local variables).
- null: advantage: fast comparison test. Run time catches you if you fail to
provide a proper value later. Happens automatically for static and instance
- "": 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 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.
Oracle’s Javadoc on Void
class : available: