kasia in a nutshell

Wow, you have lots of time on your hands. :)

Well, (a) is how SQL works. In SQL, "null = null" and "null != null" both evaluate to false, which is why you have to use "is null" and "is not null" instead.

Either this is just some arbitrary convention, or there's some well-thought-out set-theoryish reason it is the case. I have no idea which, maybe someone with more knowledge of these matters would be able to find out. If it's the latter, though, it might satisfy your philosophical question.

Terminologically, "Objects" are never null. The reference to an object can be null when it points to nothing but saying that an object itself is "null" in the strict sense has no meaning whatsoever. How do you represent yourself a "null Object"? We can have null references but never null objects per se.

Okay, I missed a disclaimer: Let's pretend for sake of discussion that by stating "null object" I mean a null reference.

Why not ask Java itself?
System.out.println(null == null);

Cause then it's not an academic exercise! Sheesh.

Are two singularities the same? Is infinity equal to infinity?

In keeping with the "null reference" point, sure, all null references are equal. Behind the scenes, you're secretly playing with pointers. When you have an Object x == null, that's just Object *x == NULL (if you want turn it into C++). And NULL just means zero, or some zero-equivalent on the current machine architecture. That's why NullPointerExceptions always indicate poorly devised code: the developer who wrote the code forgot that they were dealing with pointers by another name.

The Eiffel language has a particularly strong theoretical basis, and in Eiffel the "void" object is defined as the singular instance of the class NONE. The void object is always equal to itself, as specified in section 19.7 of the Eiffel language definition.

The Java language is very similar. Section 3.10.7 of the Java 2 Language Specification says, "The null type has one value, the null reference." Since all null references are references to the same object/value, the "reflexive" rule for the equals() method - x.equals(x) yields true - would tend to suggest that null references are all equal. The only real room for equivocation is that the "reflexive" rule does say "for any non-null reference value," but I would argue that was put in because it's not possible to actually implement equals() for null.

For the mathematically inclined, there are indeed two different cardinalities of infinity. The first kind, called "Aleph_0" (pronounced Aleph NULL - the underscore denotes a subscript), is assigned to infinite sets that can be put on a one-to-one relationship with the positive intergers. That is, in some sense you can assign each object it's own ID number.

Some sets, however, are so big, that no such relationship is possible. This size of set is called "Aleph_1". An intuitive example might be the all the points in a line segment. (It depends on how good your intuition is). You cannot assign all of these points an ID number - you will run out of integers and still have points left over.

The proof is best left to the experts. Don't try this at home.

You could argue that there are many types of singularities as well, but it depends on what you mean by singularity. Those familiar with the calculus of complex numbers should be familiar with the concept of "poles of order N", where N could be some integer. In that sense, not all poles are equal.

Kasia can tell you that not all Poles are equal either.

Neither is Polish beer.

From the set theoretical perspective, comparing NULL objects is meaningless, like dividing by zero. An equivalence relation (of which "is equal to" is a specific instance) is defined as a subset of the Cartesean product of a set with itself (that meet certain other properties). For example, if we have a set of animals living at the farm, the equivalence relation is defined on PAIRs of animals.

The catch is that NULL is technically not part of the set upon which the relation is defined. That is, there is no NULL animal. If you have an animal that is NULL, you technically don't have an animal, thus no relationship is defined. The question has no meaning.

Is NULL equal to Piggy? NULL is not an animal - the question has no meaning.

Is NULL equal to NULL? NULL is not an animal in EITHER case - the question still has no meaning.

Piggy cannot sleep in human's bed.

Neither can NULL.

You might be inclined to say that "is equal" could be overloaded to operate on many different sets, yet the logic will still break down. It's mathematically impossible to construct a logically consistant set that contains "everything". The rules break down, resulting in absurdity.

Before the game begins, you have to establish well defined boundaries.

mu (http://www.catb.org/jargon/html/M/mu.html)

It’s like wondering about the value of 0^0 (zero to the power of zero); is it 1 (as f(x) → x^0 is for all other values of x), or is it undefined? There are consistent arguments for either view.

Personally, I’d take a pragmatic view: it depends on what you’re doing. For the purpose of sorting things, f.ex, I’d consider them equal. But my bias is towards inequality, ie I consider them not equal by default and only take the opposite view after deeming that the circumstances indicate it to be sensible.

Subtle bugs lurk where pieces of code that have contradictory expectations interact, though – f.ex., a piece of code that takes a sorted list as an input vs the code that sorts the list in the first place.

You know, I was going to do the math thing, but figured why take all the fun away from Paul. ;)

I agree with Aristotle\Paul. Generally, I consider NULLs in any sense to be not equal. However, out in the wacky 'real' world, you never know how some business requirement is going to make you bend or break a rule.

I can't think of an example, but I've seen stranger things...

In SQL comparing anything, including NULL, against NULL is not FALSE. But then neither is it TRUE. It's UNKNOWN. WHERE clauses select only when true, not when unknown (or false).

The way I look at UNKNOWN is that it is the set {true, false}. TRUE is the set {true} and FALSE {false}. SQL three value object (3VL) drops out of considering logical operators to act on all combinations of elements.

The way I look at nullable references is that they represent a special case set with cardinality restricted to zero and one.

So if we have a nullable reference to an object fred, then that is {fred}. A null reference is {}. {} does equal {}. However, if we try to force the references to be non-null, then the question is meaningless. Object.equals(null) probably should have been defined to throw an NPE, IMO.

I bet that didn't help.