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 useJDTnull analysis & null annotations for Neon

Maybe we in platform can start with a subset of our API where we know
people tend to make the wrong assumption? I created
https://bugs.eclipse.org/bugs/show_bug.cgi?id=478603 for IWorkbench
API in which we see frequently frequently a wrong usage.

Best regards, Lars

On Tue, Sep 29, 2015 at 10:34 AM, Daniel Megert
<daniel_megert@xxxxxxxxxx> wrote:
> 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.
>
> _______________________________________________
> 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 Platform UI and e4 project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (032) 221739404, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com


Back to the top