Re: [eclipse.org-architecture-council] Encourage projects to use JDT nul

[Daniel Megert <daniel_megert@xxxxxxxxxx>]

> I had feared that
:-) How about simply running JDT null analysis on every source method and
let the compiler infer the possible values for parameters and method return
values? 
In our Eclipse world the API i.e. Javadoc
defines the contract, hence inferring it from the source code would be
wrong.

> So, how could we start? Is Platform (or parts of
it like JFace Databinding) leading the way, blogging about it and encouraging
people? 
I don't see why it has to be Platform
to blog about this or lead the way. Other projects are welcome to do that
work ;-)

> Do we have or get resources to run the JDT null analysis
on source code and see how far we get with this? 
Sorry, I don't fully understand that
question or at least its scope.

Dani



From:      
 Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx>
To:      
 "eclipse.org-architecture-council
eclipse.org" <eclipse.org-architecture-council@xxxxxxxxxxx>
Date:      
 28.09.2015 17:39
Subject:    
   Re: [eclipse.org-architecture-council]
Encourage projects to use        JDT null analysis
& null annotations for Neon
Sent by:    
   eclipse.org-architecture-council-bounces@xxxxxxxxxxx

---

Am 28.09.2015 um 16:58 schrieb Daniel Megert <daniel_megert@xxxxxxxxxx>:

> One result
of that analysis that strikes me most is that NullPointerExceptions are
the #1 root cause of all error reports. 

Did you look into those a little bit closer? Is the majority of them really
caused by 'null' passed into an API method? From my experience most issues
are caused by fields that become 'null' and are later unexpectedly accessed.
And a lot of additional NPEs happen in internal code. Hence just protecting
API methods will not be enough to really get more safety.


No, I did not inspect the ~3200 source code locations
where a NullPointerException occurred systematically. 
I follow all bug reports and discussions created from
error reports and generalized that with my gut feeling. 

I agree with you that null fields and internal APIs may
make a significant share here. The more null annotations we get the better
we are off. If the compiler settings do „normal“ null analysis we may
catch a few of those as well. It’s a start.


For projects like Platform and JDT it
is simply not feasible to add those annotations to existing code, even
if only restricted to API methods. 

I had feared that :-) How about simply running JDT null
analysis on every source method and let the compiler infer the possible
values for parameters and method return values? The results of this then
could be fed back to the compiler as external null annotations. It wouldn’t
be perfect but a  start… 
I’ve raised a bug about this some time ago. Stephan was
interested - but as always: It’s a matter of time.


Note that there is still work in progress
in our Null Analysis Tooling, most important being the support to have
null annotation descriptions for libraries like those from a JRE.

See the comment above.

I’m also fine with adding tool support for crowd-sourcing
null annotations. But I’m just not sure whether this would get enough
traction to make it worth the efforts...

Having said that, I'm not against encouraging
projects to use null annotations. I we do so, we also have to encourage
them to move to Java 8 to make use of Annotations on Java Types (JSR 308).


Many projects will upgrade to Java 8 anyways since the
platform made that move.

But IMHO it needs more than a „lip service“ to get this
started. So, how could we start? Is Platform (or parts of it like JFace
Databinding) leading the way, blogging about it and encouraging people?
Do we enable it by default in RCP and Committer package to get developers
used to it? Do we have or get resources to run the JDT null analysis on
source code and see how far we get with this? 

Cheers
Marcel_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.