It depends on your definition of "release". It sounds like you're using it to mean that the object should no longer be available. Under this definition, a released object should never be used again so it should not matter what state the variables have.

Now, I think there are different approaches in the two languages.

In C++, I prefer to use RAII, thus there is no explicit release member function, instead any such code is placed in the destructor. Pervasive use of RAII and avoiding manual memory management actually results in very few objects needing custom implementations to handle the rule of three (though I usually disable copying on all non-value objects). But where I do need to write one, I would not bother trying to clear object state in a destructor.

In Java, such functions are usually unnecessary due to garbage collection. However, it may be necessary where your code interacts with a non-managed API, such as a native library for graphics, etc. The idiomatic way is have a dispose() or close(), in particular Java 7's "try with resources" is handy if you can afford to target this version (no idea about the popularity of desktop Java versions). Another case, unrelated to external resources, you might like to handle is running some custom code when objects are logically removed or "die", e.g. deregistering from event sources and perhaps notifying other objects of this new state. In that case I would again focus on making the necessary calls but not try to clear the object state.

If your worry is about someone accidentally trying to re-use a "dead" object, consider having a debug-only assertion field which can be checked. In C++ this is easier, as you could use the preprocessor to exclude the field from Release builds. In Java this is more difficult, you might want to pick a particular field, and set it's state to an invalid value (i.e. null for non-optional reference fields, -1 for an integer perhaps, NaN for a floating point value) and assert that the state is good in other methods.

That looks like it's specific for "IBM Lotus Form Server API" whatever that is (isn't Lotus IBM's Java Virtual Machine?)

In Hotspot JVM, you don't need to do that. Setting references to null might be aswell a performance hog since you'll have tons of little writes going around. Hotspot finds objects traversing from whatever main function you have and then down from there. Dead objects are never touched in this process.

Hell, I think I even saw this "setting all object pointers to null each time you release it" thing mentioned as one of the top things that might be fine to do in C++ but it shouldn't be done in Java.

EDIT: Found where I heard of it http://www.infoq.com/presentations/JVM-Mechanics