Community
Participate
Working Groups
Build Identifier: M20110909-1335 A null type exists internally, but there doesn't appear to be any way to fetch an instance using the org.eclipse.jdt.core.dom API. It would be great if AST.resolveWellKnownType should include "null" in its list of supported types, and should be trivial to add. Reproducible: Always Steps to Reproduce: 1. Spend hours investigating how to create an instance of a null type, then 2. Give up and write over 300 lines of boilerplate that implements ITypeBinding. I hope it will be easier for future developers. :-)
JLS 4.1 second para reads: 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. ---- The null type does not have the name "null" and hence it would be totally wrong for the API to be extended the way suggested in comment# 0. Why doesn't the part about "... In practice, the programmer can ignore ..." not apply to you ? Planning to close this INVALID.
Perhaps if you explain what you need to do, it will make it clearer. Have you looked into whether org.eclipse.jdt.core.dom.ITypeBinding.isNullType() or org.eclipse.jdt.core.dom.NullLiteral are useful for your purpose ?
Per comment#1, closing as INVALID.
I have a Java source code translator, and unfortunately used org.eclipse.jdt.core.dom -- the internal in the org.eclipse.jdt.internal.compiler package names warned me off, though they would have been a much better choice. Like most translators, the AST is mutated over several passes before the output is generated. The problem I keep running into with org.eclipse.jdt.core.dom is that its bindings are read-only, and as far as I can tell, AST modifications can't be resolved (PLEASE tell me if I'm wrong here!). To workaround this limitation, I have a map of AST nodes to IBinding instances, which I update with each modification. That works for the most part, but the issue related to this bug report is that when creating a new NullLiteral, I haven't found an easy way to fetch the null literal binding for it. You can look up all other literal bindings using AST.resolveWellKnownType(), however. That's why I thought AST.resolveWellKnownType() API had a small hole in it, which could have been filled in less time than it took to write all these comments. :(
(In reply to comment #4) > That's why I thought AST.resolveWellKnownType() API had a small hole in it, > which could have been filled in less time than it took to write all these > comments. :( Sorry to appear pontificating: things don't work that way in JDT. As pointed out in comment#1, the null type doesn't have the name "null" and it would be wrong to modify the API this way. Olivier, What do you recommend as a suitable course of action for Tom ? (Or for JDT/Core for that matter ?)
It would be interesting to know why you need a binding for the null literal ? I guess these are for null literals that you add to the tree.
Verified for 3.8M5
