current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 4 down vote favorite

It is not System.Object or System.sObject, because we can pass null to methods which require System.String as a parameter, and cannot pass System.Object there.

Following code demonstrated difference between System.Object and th type of the null literal:

'abc'.contains(null); // compiler does not complain
 boolean b;
'abc'.contains(b?null:null); // compiler does not complain
 Object o = b?null:null;
'abc'.contains(o); // compiler error

So the question is, what type null literal and expression b?null:null have? Is there a standard library function like typOf, so that I could call typOf(null)?

share|improve this question
1  
Can you provide a little more context, maybe share some of the offending code, it'll help troubleshoot but it sounds like you are sending a null argument to a method. – Jenny B 2 days ago
    
I sort of get what you are asking.so null is just a blank reference i guess which does not have memory allocated.The type we say is of reference and not of the null value. – Mr.Frodo 2 days ago
    
related: stackoverflow.com/questions/2707322/what-is-null-in-java – Charles Koppelman 2 days ago
1  
@CharlesKoppelman Already linked to that in my answer. :) – Adrian Larson 2 days ago
up vote 3 down vote

It matches every type. Take a look at What is null in Java? for some more background.

There is also a special null type, the type of the expression null, which has no name. Because the null type has no name, it is impossible to declare a variable of the null type or to cast to the null type. The null reference is the only possible value of an expression of null type. The null reference can always be cast to any reference type. In practice, the programmer can ignore the null type and just pretend that null is merely a special literal that can be of any reference type.

Also, try the following with any right operand as the ReferenceType:

null instanceof String

You will get the message:

Operation instanceof is always true since an instance of NULL is always an instance of String

As noted by @sfdcfox, a specific instance of null is not of any type specifically:

String s = null;
Object o = s;
system.assertEquals(false, o instanceof String);
share|improve this answer
    
True, but you might want to mention that a null value in a variable always returns false (at least in the later API versions). – sfdcfox 2 days ago
    
I don't follow you. You're saying a specific null instance is not an instanceof anything? @sfdcfox – Adrian Larson 2 days ago
    
Object o; System.assertEquals(false, o instanceof String); – sfdcfox 2 days ago
    
Well, that doesn't have any reason be true anyway. Tricky because instantiation is what lends o its Type in the first place. To my eye, the question is centered around the null reference specifically. – Adrian Larson 2 days ago
1  
Believe me, I'm glad it's no longer true. It created all sorts of problems when it used to be. I just think it's useful to note that "null", as a reference, is both no type (as I demonstrated), and every type (as you demonstrated). It's a very magical type, indeed. – sfdcfox 2 days ago
up vote 3 down vote

I think what it comes down to is that the compiler doesn't handle the typing for you with an Object the way that it does with NULL.

It would be possible for the language designers to build this functionality, but would be extremely complex since you can use the Object type to create variables and assign them values, but you can't with the NULL type.

The literal NULL always has the same value and this value is applicable to all types. An Object can have many different values which are mostly not applicable to other types.

As for using an Object as a String, if you do know that your object variable does in fact happen to be a string (or at least should be a string), you can indicate that to the compiler by using a typecast. 

Object o = 'A String Literal';
try{
    ((String) o).subString(0,8);
} catch(TypeException e){
    ...
}
share|improve this answer
1  
1.2 is a Decimal, and 1.2d is a Double. The compiler masks this difference for you, because they are generally interchangeable. They are not the same thing. Notably, assigning a Double to a Decimal may cause data loss. Null, conversely, is always the same thing (namely, the absence of any thing). You might consider it a parent of Object (e.g. it represents all possible types). – sfdcfox 2 days ago
    
As a somewhat arbitrary example, consider this runtime exception: Double b = 99999999999999999999999999999999999999999999999999999999999999999999999999999999‌​999999999999999999999999999999999999999999999999999999999999999999999999999999999‌​999999999999999999999999999999999999999999999999999999999999999999999999999999999‌​999999999999999999999999999999999999999999999999999999999999999999999999999999999‌​999999999999999999999999999999999999999999999999999999999999999999999999999999999‌​9999999999999999999999999999999999999999999999999999.0d; Decimal a = (Decimal)b; – sfdcfox 2 days ago
    
@sfdcfox True, all good points. – martin 2 days ago
    
@sfdcfox Decided to get rid of that part. Looking back on it now, the compiler's handling of numeric literals isn't that great of an analogy. – martin yesterday

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.