There is a Java Void -- uppercase V-- reference type. The only situation I have ever seen it used is to parameterize Callables

final Callable<Void> callable = new Callable<Void>() {
            public Void call() {
                return null;

Are there any other uses for the Java Void reference type? Can it ever be assigned anything other than null? If yes, do you have examples?

11 Answers 11


Void has become convention for a generic argument that you are not interested in. There is no reason why you should use any other non-instantiable type, such as System.

It is also often used in for example Map values (although Collections.newSetFromMap uses Boolean as maps don't have to accept null values) and java.security.PrivilegedAction.

I wrote a weblog entry on Void a few years back.

  • who made that convention? the docs state docs.oracle.com/javase/tutorial/java/generics/types.html "Type Parameter Naming Conventions By convention, type parameter names are single, uppercase letters." – barlop Feb 12 '15 at 6:29
  • 4
    @barlop It's the argument not the parameter name. That is, it is the type java.lang.Void. / Josh Bloch popularised the convention, though once you've seen it, it is the obvious choice. – Tom Hawtin - tackline Feb 13 '15 at 19:21
  • 2
    That blog entry is dead – mFeinstein Oct 17 '18 at 21:23

You can create instance of Void using reflections, but they are not useful for anything. Void is a way to indicate a generic method returns nothing.

Constructor<Void> constructor = Void.class.getDeclaredConstructor();
Void v = constructor.newInstance();
System.out.println("I have a " + v);

prints something like

I have a java.lang.Void@75636731
  • 21
    +1 for instantiating a class that the documentation says is uninstantiable. I've done this too and I agree that instantiated Voids are useless. – Luke Woodward Mar 13 '09 at 21:55
  • 1
    Constructor<Void> cv = Void.class.getDeclaredConstructor(); cv.setAccessible(true); Void v = cv.newInstance(); System.out.println(v); // ;) – Peter Lawrey Mar 14 '09 at 21:53
  • As an exercise, try creating a new Class using reflections and see what happens. – Peter Lawrey Mar 14 '09 at 21:54
  • I got a java.lang.InstantiationException from sun.reflect.InstantiationExceptionConstructorAccessorImpl . :( – Luke Woodward Mar 14 '09 at 22:57
  • 7
    This is implementation specific and may change at any time. There's no guarantee that the class has a no-arg constructor and even if it does have one that may do anything (perhaps System.exit(0)). I tend to write utility classes with a constructor as private Void() { throw new Error(); }. Some may prefer a no-value enum. – Tom Hawtin - tackline Nov 4 '11 at 21:32

Future<Void> works like charm. :)

  • 6
    It's more common (for example, in Guava) to use Future<?>, as the future will often have a legitimate value (of non-Void type) but is used in a context that doesn't care about the value. – David Phillips Apr 18 '13 at 18:21
  • 1
    CompletableFuture<Void> works like a charm as well. – andrybak May 10 '17 at 12:39

Given that there are no public constructors, I would say it can't be assigned anything other than null. I've only used it as a placeholder for "I don't need to use this generic parameter," as your example shows.

It could also be used in reflection, from what its Javadoc says:


  • Funny enough to see Oracle/Sun describe it that way as null is an instance of all types. Anyhow, as you said, the pure meaning of it is "I could write any type here as I am not interested in it, so I will put Void to make sure people who read my code understand exactly that" – Snicolas Jul 24 '13 at 22:55

All the primitive wrapper classes (Integer, Byte, Boolean, Double, etc.) contain a reference to the corresponding primitive class in a static TYPE field, for example:

Integer.TYPE == int.class
Byte.TYPE == byte.class
Boolean.TYPE == boolean.class
Double.TYPE == double.class

Void was initially created as somewhere to put a reference to the void type:

Void.TYPE == void.class

However, you don't really gain anything by using Void.TYPE. When you use void.class it's much clearer that you're doing something with the void type.

As an aside, the last time I tried it, BeanShell didn't recognise void.class, so you have to use Void.TYPE there.

  • 8
    So there's both a Void.class and a void.class! – Tom Anderson Dec 19 '09 at 20:24

When you use the visitor pattern it can be cleaner to use Void instead of Object when you want to be sure that the return value will be null


public interface LeavesVisitor<OUT>
   OUT visit(Leaf1 leaf);

   OUT visit(Leaf2 leaf);

When you will implement your visitor you can explicitly set OUT to be Void so that you know your visitor will always return null, instead of using Object

public class MyVoidVisitor implements LeavesVisitor<Void>
    Void visit(Leaf1 leaf){
        //...do what you want on your leaf
        return null;

    Void visit(Leaf2 leaf){
        //...do what you want on your leaf
        return null;

Before generics, it was created for the reflection API, to hold TYPE returned by Method.getReturnType() for a void method, corresponding to the other primitive type classes.

EDIT: From the JavaDoc of Void: "The Void class is an uninstantiable placeholder class to hold a reference to the Class object representing the Java keyword void". Prior to Generics, I am aware of no use other than reflection.

  • I don't believe this. I don't have a 1.4 or earlier JVM in front of me now, but I believe that Method.getReturnType() has always returned void.class for a void method. – Luke Woodward Mar 14 '09 at 22:02
  • @Pour: I am saying that before generics, the only use I am aware of is to hold TYPE (as in Void.TYPE), which was used in reflection's Method.getReturnType() for a void method. – Lawrence Dol Jul 9 '10 at 16:57
  • It somehow does not return Void. Please see stackoverflow.com/questions/34248693/… – Alireza Fattahi Dec 13 '15 at 8:17

As you can't instantiate Void, you can use Apache commons Null object, so

Null aNullObject = ObjectUtils.Null;
Null noObjectHere = null;

in the first line, you have an object, so aNullObject != null holds, while in the second line there is no reference, so noObjectHere == null holds

To answer the poster's original question, the usage for this is to differentiate between "the nothing" and "nothing", which are completely different things.

PS: Say no to Null object pattern


Void is create to wrap its primitive void type. Every primitive type has it's corresponding Reference type. Void is used to instantiate a generic class or use of a generic method, A generic arguments witch you are not interested in. and here is an example ...

public void onNewRegistration() {
    newRegistrationService.createNewUser(view.getUsername(), view.getPassword(),
            view.getInitialAmount(), view.getCurrency(), new AsyncCallback<Void>() {
      public void onFailure(Throwable caught) {


      public void onSuccess(Void result) {
        eventBus.fireEvent(new NewRegistrationSuccessEvent());

here,as you can see, i don't want anything from the server that i am asking to create a new registrations,but public interface AsyncCallback<T> { .... } is a generic interface so i provide Void since generics don't accept primitive types


It is also commonly used on Async-IO completion callbacks when you dont have the need for an Attachment object. In that case you specify null to the IO operation and implement CompletionHandler<Integer,Void>.


It may be rare case but once, I used Void in aspect classes.

This was an aspect which runs after methods that has an @Log annotation, and logs the method returned and some info if the method return type is not void.

 @AfterReturning(value = "@annotation(log)", 
       returning = "returnValue", 
       argNames = "joinPoint, log, returnValue"
    public void afterReturning(final JoinPoint joinPoint, final Log log,
            final Object returnValue) {

            Class<?> returnType = ((MethodSignature) joinPoint.getSignature())
           if (Void.class.isAssignableFrom (returnType)) ) {
            //Do some log

Your Answer

