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

 

 


Back to the top