eclipse warnings

[Kevin Rushforth]

Yes it might be worth looking at the possible null reference warnings. 
Maybe file an umbrella Task to look through the warnings and decide what 
to do with them? I don't think I like the "SuppressWarnings" as one of 
the remedies, but we can discuss that further once we have a list.

-- Kevin

On 12/4/2023 9:12 AM, Andy Goryachev wrote:
>
> The last two are just unnecessary code, I see no problems turning this 
> warning off.
>
> But the 'potential null access' one, though being a bit overeager, 
> might warrant a deeper scrutiny, as it might point to real bugs.  I 
> would suggest to turn this warning on and fix or mark the occurences 
> with "SuppressWarning" where appropriate.
>
> But you do have a good point about review cycles.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin 
> Rushforth <kevin.rushforth at oracle.com>
> *Date: *Monday, December 4, 2023 at 09:05
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: eclipse warnings
>
> We did a few of these sort of cleanup fixes a year or so ago.
>
> In general, this sort of cleanup *might* be useful, but also causes 
> some code churn and takes review cycles to ensure that there is no 
> unintentional side effect.
>
> The last two might be OK cleanup tasks, but I wouldn't make them a 
> high priority. Worth noting is that a seemingly redundant null check 
> or instanceof check is not always a bad thing, so I wouldn't clean up 
> all of them.
>
> The first group is the more interesting one. In some cases a potential 
> null access can highlight actual bugs. However, I oppose any automated 
> solution for these, since adding a null check where you don't expect a 
> null (even if you IDE thinks it might be possible) can hide the root 
> cause of a problem.
>
> We aren't going to enforce these, though, so you'll likely need to 
> configure your IDE to be less picky.
>
> -- Kevin
>
> On 12/4/2023 8:34 AM, Andy Goryachev wrote:
>
>     Dear colleagues:
>
>     Imported the openjfx project into another workspace with a more
>     stringent error checking and discovered a few issues:
>
>      1. potential null pointer access: 295
>      2. unnecessary cast or instanceof: 190
>      3. redundant null check: 61
>
>     Do we want to clean these up?
>
>     -andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20231204/1dd3ce8e/attachment-0001.htm>