I was reading an article linked from a slashdot story, and came across this little tidbit:

Take the latest version of Java, which
tries to make null-pointer checking
easier by offering shorthand syntax
for the endless pointer testing. Just
adding a question mark to each method
invocation automatically includes a
test for null pointers, replacing a
rat's nest of if-then statements, such
as:

I've scoured the internet (okay, I spent at least 15 minutes googling variations on "java question mark") and got nothing. So, my question: is there any official documentation on this? I found that C# has a similar operator (the "??" operator), but I'd like to get the documentation for the language I'm working in. Or, is this just a use of the ternary operator that I've never seen before.

The article is wrong. infoworld.com/print/145292 I believe a Project Coin submission was submitted for it. But it wasn't selected (for reasons mentioned in the article - if you want to do that sort of thing, use C# or something), and certainly isn't in the current version of the Java language.
–
Tom Hawtin - tacklineDec 8 '10 at 17:05

1

That's not the same as the C# ?? operator: ?? coalesces nulls, i.e. A ?? B == (A != null) ? A : B. This appears to evaluate a property on an object if the object reference is not null, i.e. A?.B == (A != null) ? A.B : null.
–
RupDec 8 '10 at 17:07

1

@Erty: as a huge user of the @NotNull annotation, which is basically everywhere in the code I write, I don't know very well anymore what NPEs are (except when using badly desing APIs). Yet I find this "shortcut notation" cute and interesting. Of course the article is right when it states: After all, it doesn't eliminate the root of the problem: the proliferation of null values due to fast and loose programming. 'null' doesn't exist at the OOA/OOD level. It's another Java-idiosynchratic nonsense that can mostly be worked around. To me it's @NotNull everywhere.
–
SyntaxT3rr0rDec 8 '10 at 17:08

Why the downvote? This answer is 100% correct as far as I know... if you know something different, please say so.
–
ColinDDec 8 '10 at 17:05

but obviously at one point it has been submitted (see Tom Hawtin's comments) and will maybe make it into the language. So a "This syntax does not exist yet in Java" would be more appropriate.
–
SyntaxT3rr0rDec 8 '10 at 17:11

1

@Webinator: It's not going to be in Java 7 or 8, and there are no other "upcoming versions" at this time. I also find it kind of unlikely that it will make it in, since it encourages rather bad practices. I also don't think "yet" is necessary, since "does not exist in Java" is not the same as "will never exist in Java".
–
ColinDDec 8 '10 at 17:12

4

@Webinator: several posters have commented that a proposal was submitted but rejected. Thus the answer is 100% accurate. Upvoting to counteract the down vote.
–
JeremyPDec 8 '10 at 17:16

That's actually Groovy's safe-dereference operator. You can't use it in pure Java (sadly), so that post is simply wrong (or more likely slightly misleading, if it's claiming Groovy to be the "latest version of Java").

I'm not sure this would even work; if, say, the person reference was null, what would the runtime replace it with? A new Person? That would require the Person to have some default initialization that you'd expect in this case. You may avoid null reference exceptions but you'd still get unpredictable behavior if you didn't plan for these types of setups.

The ?? operator in C# might be best termed the "coalesce" operator; you can chain several expressions and it will return the first that isn't null. Unfortunately, Java doesn't have it. I think the best you could do is use the ternary operator to perform null checks and evaluate an alternative to the entire expression if any member in the chain is null:

"what would the runtime replace it with?" ... reading the question might help :-P It would replace it with null. In general, the idea seems to be that person?.getName evaluates to null if person is null or to person.getName if not. So it's pretty much like replacing "" with null in all your examples.
–
subsubFeb 4 '13 at 15:35

A NullReferenceException could also been thrown in getName() or getGivenName() which you won't know if you simply return an empty string for all occurrences.
–
Jimmy T.Dec 14 '13 at 23:32

I will have to try this. SI have serious doubts about this whole "Optional" business. Seems like a nasty hack.
–
GGB667Jun 5 '14 at 17:49

The whole purpose of the Elvis Operator proposal was to do this in one line. This approach is no better than the "if(!=null) approach above. In fact I would argue it is worse as it is not a straight forward. Additionally you should avoid throwing and catching errors due to the overhead.
–
JustinKSUOct 17 '14 at 13:22

The problem with this style is that the NullPointerException may not have come from where you expected it to. And thus it may hide a real bug.
–
DarronDec 8 '10 at 18:25

1

@Darron, Can you give an example of a getter you have written which could throw an NPE and how you would want to handle it differently?
–
Peter LawreyDec 8 '10 at 20:29

2

you run it into a separate variable and test it with an if as normal. The idea behind this operator is to eliminate that uglyness. Darron is right, your solution might hide and throw away exceptions you want to throw. Such as if getName() threw an exception internally that you do not want to throw away.
–
Mike MillerDec 9 '10 at 19:27

1

Not any exception, it would have to be a NullPointerException. You are trying to protect yourself from a situation you haven't begun to explain how it might occur in a real application.
–
Peter LawreyDec 10 '10 at 9:36

In a real application Person could be a proxy accessing a DB or some non-heap memory and there could be a bug somewhere... Not very realistic, but, Peter, I'd bet you've never written a piece of code like above.
–
maaartinusApr 16 '14 at 13:15