| Sounds like we got stuck with that proposal.
Lars/Platform-UI will consider it for some APIs. Konstantin/Sapphire tried it but won’t apply it in the large yet. Dani/JDT doesn't have the resources to convert existing (JDT) APIs or generally start using annotations in their own code base. Marcel/Recommenders and AERI uses Optional in the APIs. We had trouble applying it to internal APIs because adding and maintaining external null annotations for APIs we use wasn’t easily shareable among developers.
Given that, I withdraw the proposal to ask projects to use null annotations and static null analysis for now.
Thanks for the discussion, Marcel
The reason for suggesting to raise the
severity is the assumption that someone who wants to invest time (by annotating
the code) to get rid of most of the null pointer issues also should get
rid of the potential problems since those can create holes in the story.
You can either lower the severity for
potential problems again, suppress the null warnings on methods with false
positives, or adjust the code. If you look at your code example and assume
that the declaration for 'count' is outside the visible area then you can't
immediately know whether an NPE might occur or not. Hence, using an explicit
null check would also increase the code readability.
Dani
From:
Konstantin Komissarchik
<konstantin.komissarchik@xxxxxxxxxx>
To:
Daniel Megert/Zurich/IBM@IBMCH,
"eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
Date:
29.09.2015 16:41
Subject:
RE: [eclipse.org-architecture-council]
Encourage projects touseJDTnull analysis & null annotations for Neon
When I turn on null annotations analysis,
I see this dialog and the potential null pointer access option is set to
an error afterwards, so I didn’t even get as far as trying out the annotations.
Is there a combination of settings that would allow me to get some benefit
from annotation analysis without turning on potential null pointer access
problems?
- Konstantin
From: Daniel Megert
Sent: Tuesday, September 29, 2015 1:35 AM
To: eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council] Encourage projects
touseJDTnull analysis & null annotations for Neon
Konstantin,
we know that there are cases where our analysis could do more (e.g. handling
correlations between variables). That's why we currently have two options,
one mentioning "potential" and being off by default. Having said
that, Marcel is talking about a different feature where the code gets annotated
with annotations (annotation-based null analysis).
Dani
From: Konstantin
Komissarchik <konstantin.komissarchik@xxxxxxxxxx>
To: Marcel
Bruch <marcel.bruch@xxxxxxxxxxxxxx>, "eclipse.org-architecture-council
eclipse.org" <eclipse.org-architecture-council@xxxxxxxxxxx>
Date: 28.09.2015
20:16
Subject: Re:
[eclipse.org-architecture-council] Encourage projects to useJDTnull analysis
& null annotations for Neon
Sent by: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
I expected to get further, but I am already giving up on this experiment.
I enabled null analysis in one Sapphire bundle and the project became peppered
with errors. I reviewed most of them and in all reviewed cases, what was
deemed a potential null pointer access was actually incomplete static analysis.
Here is an example:
final List<String> extensions = this.fileExtensionsService.extensions();
final int count = ( extensions == null ? 0 : extensions.size() );
if( count > 0 )
{
extensions.something(); // potential null pointer
access error here
}
I could downgrade potential null pointer access to a warning, but I don’t
want my project peppered with warnings that I have no intention of fixing.
I am against changing valid code just to make static analysis happy.
Thanks,
- Konstantin
From: Konstantin Komissarchik
Sent: Monday, September 28, 2015 9:56 AM
To: Marcel Bruch;eclipse.org-architecture-council eclipse.org
Cc: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
Subject: Re: [eclipse.org-architecture-council] Encourage projects
to useJDTnull analysis & null annotations for Neon
I am not in favor of requiring projects to use any one particular code
quality technique, there are so many, with different pluses and minuses.
Regarding the null analysis, what we don't have is hard data showing hours
expended adding annotations against pre-existing bugs detected/fixed through
this effort. I will volunteer to do this for Sapphire, track time/effect
and then blog about it. If a few other projects do this and the data shows
that the time expenditure was worthwhile, we will be able to encourage
other projects to invest in this.
- Konstantin
From: Marcel Bruch
Sent: Monday, September 28, 2015 9:39 AM
To: eclipse.org-architecture-council eclipse.org
Cc: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
Subject: Re: [eclipse.org-architecture-council] Encourage projects
to use JDTnull analysis & null annotations for Neon
> Am 28.09.2015 um 18:15 schrieb 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.
If this is done consistently and completely, one could infer that from
Javadoc comments as well.
> > 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 ;-)
It’s a difference whether a tiny leaf project is doing so or „the platform“
;-)
> > 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.
Reformulating: Since the JDT committers know their tools much better than
anyone else on the planet: how much effort would it be to provide a basic
tool that runs the null simulation / analysis on an Eclipse workspace and
outputs a text file with its findings?
And: Can an JDT committer provide that code skeleton?
From there, others (like me) can take over and build the necessary tooling
around this.
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.
_______________________________________________
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.
[attachment "98166F11165F4079A7078A4E3BE72340.png"
deleted by Daniel Megert/Zurich/IBM] [attachment "333F16709F79479EBA7BBB28F25D3B6A.png"
deleted by Daniel Megert/Zurich/IBM]
_______________________________________________ eclipse.org-architecture-council mailing list eclipse.org-architecture-council@xxxxxxxxxxxhttps://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.
-- Codetrails GmbH The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
|
