Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Encourage projects to use JDT null analysis & null annotations for Neon

> 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.

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.

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.

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).

Dani



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




Greetings Architecture Council,

I spent some time on analyzing and visualizing user error reports.
One result of that analysis that strikes me most is that NullPointerExceptions are the #1 root cause of all error reports.
It’s also ~4 times more popular than #2 on that list: IllegalArgumentException (*).

I wonder whether the architecture council should encourage projects to tackle these errors, e.g., by enforcing or requesting all projects to use JDT’s null analysis and @Nullable/@NonNull annotations on every public API. Is that something the AC can drive and promote?

As a second means, the EPP Committer package may enable JDT’s null analysis by default to get that started.

It would also need a few popular projects to lead the way. I’m thinking of Platform/Platform UI and JDT but… of course… it’s additional work for them… But I hope this pays out for Eclipse as a whole rather soon.
I can also imagine to ask all projects that participate in Neon to work towards this goal.

What do others think?


Cheers,
Marcel



(*) Please visit [1] to confirm that observation (Note: org.eclipse.epp.internal.logging.StandInException and org.eclipse.recommenders.internal.StandInException are not counted.
[1]
https://dev.eclipse.org/recommenders/committers/dashboard/#/dashboard/Problems
_______________________________________________
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.


Back to the top