Let's say I have a class named Class

Given that java.lang.Class already exists, let's not. Let's say you have a class named MyClass.

and I created a new null object:

That's an oxymoron.

null is a reference. It's not an object. It is, in fact, the reference that means 'I refer to no object', and is the only reference that means 'I point at nothing'.

When you write:

MyClass x = new MyClass();

Then x is a treasure map, and new MyClass() is 'create a new treasure chest and bury it in the sand'. The = in the middle says: Update the treasure map named x, so that following it would lead you to the treasure I just made (new X() means: Make new treasure and bury it).

MyClass x = null;

means you have a treasure map named x which is currently blank.

If not, is there a way for me to create the object so that all three instance variables are null?

That would imply a treasure chest of the MyClass treasure type, which has room for some scratches (int a - a number), and which contains a treasure map (the String b variable). If you want to set them all to null, well, you can't - a is a primitive (int) and those aren't treasure maps, they are the actual number. You can't not have one - a cannot be null. At best, a can be 0. b CAN be null. That means there's real treasure, but the treasure contains yet another treasure map (in java it's mostly treasure maps all the way), but that one is blank. That's different from there being no treasure at all.

More generally, the question: "Can I make a new instance of MyClass such that all fields are some value I desire" is the wrong question to ask, perhaps: The general principle is encapsulation: MyClass is an API: It's like the receptionist at a big corp's office. The receptionist decides what services are available. Even if the CEO is available, if the receptionist elects not to answer the question 'can I see the CEO right now please?', then you can't see her.

Your question boils down to: "If I storm into this office and I demand to speak to the CEO, will I be allowed to?" - the only viable answer is: Well, the receptionist would decide, so you'd have to ask him. For classes: Whatever the API lets you do, you can do. But that's all you can do.

If there is no constructor that initializes these fields to null, then, no, you can't.

If Name has a parameterless constructor, sure. Whether or not it's "empty" depends on what that constructor does or what defaults it may have.

How do you define "empty object" anyway?

For example, if you want a variable but don't want it to actually have an object, you can just declare the variable without initializing it:

Name myName;

In this case myName will be null (or "unassigned"? depends on the context), but will be of type Name and can be used as such later (once it's assigned a value).

All the variable itself does is point to a location in memory where the "object" exists. So something like Name myName doesn't "create" an object, it just creates the pointer to a memory location. new Name() actually creates an object by calling its constructor. When used together like in your example, the latter half creates the object and then the former half points to the location in memory where the object exists.

To clear the variable

According to my knowledge,

If you are going to reuse the variable, then use

               Object.clear();

If you are not going to reuse, then define

               Object=null;

Note: Compare to removeAll(), clear() is faster.

Please correct me, If I am wrong....

According to the Java spec, null is a type that can be assigned to an object variable (as a value as noted in the comment). You cannot instantiate or create variables of this type though, you must use the literal null provided by the compiler.

The whole point of a value object is that equality isn't based on identity; you could very well have two distinct blank objects. In fact, whether all blank objects are the same or different objects should be an implementation detail. For those reasons, the second approach is not good. If you look at the Java 8 APIs, there's a notion of a "value-based class" with the following properties:

• are final and immutable (though may contain references to mutable objects);
• have implementations of equals, hashCode, and toString which are computed solely from the instance's state and not from its identity or the state of any other object or variable;
• make no use of identity-sensitive operations such as reference equality (==) between instances, identity hash code of instances, or synchronization on an instances's intrinsic lock;
• are considered equal solely based on equals(), not based on reference equality (==);
• do not have accessible constructors, but are instead instantiated through factory methods which make no committment as to the identity of returned instances;
• are freely substitutable when equal, meaning that interchanging any two instances x and y that are equal according to equals() in any computation or method invocation should produce no visible change in behavior.

The documentation further adds:

A program may produce unpredictable results if it attempts to distinguish two references to equal values of a value-based class, whether directly via reference equality or indirectly via an appeal to synchronization, identity hashing, serialization, or any other identity-sensitive mechanism. Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects and should be avoided.

There's no way to disable the == operator in Java so that warning is the best you can do.

Thus, your first approach is correct, with the caveat that foo1.equals(foo2) should always be true when foo1.isBlank() and foo2.isBlank() even if foo1 != foo2.

As everyone else has said, this simply isn't possible. If it's cleaning up resources you're after, then you might consider using a pattern such as:

class A {

    private boolean cleanedUp;

    public void cleanUp() {
        // clean up any resources
        cleanedUp = true;
    }

    public boolean isCleanedUp() {
        return cleanedUp;
    }
}

And then using it like so:

A a = new A();
a.cleanUp();
if (a.isCleanedUp()) {
    ...
}

A better solution might be to implement the java.io.Closeable or java.lang.AutoCloseable interfaces depending on your circumstance:

class B implements AutoCloseable {

    private boolean closed;

    public boolean isClosed() {
        return closed;
    }

    @Override public void close() throws Exception {
        // clean up any resources
        closed = true;
    }
}

In which case you can use a try-with-resources statement:

try (B b = new B()) {
    // do stuff
} catch (Exception ex) {
    // oh crap...
}

Or you could even combine the two and do it that way, whichever you prefer.

Or lastly you could do it the way William Morrison explained (though I'd probably cheat and just use java.util.concurrent.atomic.AtomicReference instead of making my own class, and it comes with the added benefit of being a generified type), which, depending on your circumstance, may really be unnecessary. After all, you could always just do (even though it might seem a little odd):

A a = new A();

a.doStuffAndDisappear();
a = null;

if(a == null){
     //...
}