Community
Participate
Working Groups
According to AERI NullPointerExceptions are the most frequently occurring exception type - 4x more frequent than #2: IllegalArgumentException. AC discussed to recommend to enable Null Analysis by default in JDT but several test runs have shown that the null analysis and supporting tools are not yet ready. Static null analysis itself needs to detect more complex situations more reliably, using annotations has rough edges, external annotations (e.g. for JRE or Eclipse plugins) are not supported well enough. All in all: JDT Null Analysis is a promising technology that has the potential to significantly reduce the #1 class or errors: NullPointerException. However, I'm under the impression that the active committers could make use of a few helping hands that add adequate *tooling support* for null analysis. The external annotations handling is right now a huge pain and generating and distributing external null annotation models for arbitrary libraries is usually out of scope of JDT. Thus, I'd propose 1. setting up a "external null annotations repository" where developers can (semi-) automatically can download external null annotations for the libraries they use. 2. Setting up a sharing mechanism where users can share their (manual or automatically generated) null analysis information. This may include quick fixes inside the IDE that allow sharing of @Null annotations or sharing of (extensive) compiler analysis results, results of runtime exceptions, or integration results from tools like FindBugs or research tools. Such a service could be set up as an IDE- and tool agnostic standard to allow integrations with tools like FindBugs, PMD (and thus integrations into build systems), or even with other IDEs. Implementing this package will certainly take no less than 8 weeks of work and requires support by JDT committers working on Null analysis.
In the course of the recent AC discussion, is there interest by JDT team to have such a feature?
(In reply to Marcel Bruch from comment #1) > In the course of the recent AC discussion, is there interest by JDT team to > have such a feature? Yes, but only if Stephan is OK with it and takes the role of the buddy.
(In reply to Dani Megert from comment #2) > Yes, but only if Stephan is OK with it and takes the role of the buddy. Stephan, what do you think?
(In reply to Marcel Bruch from comment #3) > (In reply to Dani Megert from comment #2) > > Yes, but only if Stephan is OK with it and takes the role of the buddy. > > Stephan, what do you think? I'm certainly in favour of this and willing to provide support as needed. I was just reluctant to make specific promises, as I realized that triage and fixing of [1.8] compiler bugs alone is eating more time than I'm able to invest in JDT, read: for Neon I could resolve roughly 50% of my planned / assigned bugs, leaving little to no room for work on new functionality. So, what time frame are we speaking of in this bug?
(In reply to Stephan Herrmann from comment #4) > So, what time frame are we speaking of in this bug? To be defined. W/o thinking too much about it, I'd like to have a first version in early Neon+1 M builds. But we've to discuss quite a few details first before agreeing on a timeline. For instance: * how this feature should be implemented, * where the (server-side) code should live * how (i.e., by whom) such a crowd-sourced service will be operated in the long-run, * whether it needs an UI like the Babel project etc. And at the end all this needs formal agreement of the EF. Wayne, any thoughts especially on the "who will operate/maintain the system"? Would Webmasters maintain such a service? I'd expect it to be of comparable complexity like the Babel project but...
(In reply to Marcel Bruch from comment #5) > (In reply to Stephan Herrmann from comment #4) > > So, what time frame are we speaking of in this bug? > > To be defined. W/o thinking too much about it, I'd like to have a first > version in early Neon+1 M builds. I assume you meant Neon+1 (a.k.a. Oxygen) milestone builds. M stands for maintenance builds.
(In reply to Dani Megert from comment #6) > I assume you meant Neon+1 (a.k.a. Oxygen) milestone builds. Yes, Oxygen milestones.
(In reply to Marcel Bruch from comment #7) > (In reply to Dani Megert from comment #6) > > I assume you meant Neon+1 (a.k.a. Oxygen) milestone builds. > > Yes, Oxygen milestones. OK, for that time frame I can commit to supporting this initiative.
Parties interested in this subject are invited to join the discussion in https://mattermost.eclipse.org/eclipse/channels/jdt-null-analysis
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/212.
