Loosening requirements for super() invocation

[Nathan Reynolds]

 Let's say we have a constructor that calls final methods (or the class is
final) that belong to the class and don't leak "this" (or call other final
methods that don't leak "this").  Would this be flagged?  If so, why?  This
doesn't seem to be a leak.  I use this when the setter has some complex
logic and would rather re-use than duplicate code.  (I suppose the same
could be said if the constructor calls a static final method in the class
and passes "this").

Let's say we have a constructor that assigns all the member fields and then
leaks "this".  Would this be flagged?  If so, why?  This doesn't seem to be
a leak any more since the object is fully constructed.

On Fri, Dec 30, 2022 at 9:21 AM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Fri, Dec 30, 2022 at 10:48 AM Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>> One thing that makes me a little uncomfortable is that @SW usually is
>> used to say “the compiler can’t prove this is safe, but I am asserting it
>> is.”  But this is different; the compiler has discovered the class is
>> unsafe, and @SW is saying “I know, I know, stop telling me.”  So I think
>> there’s an additional documentation opportunity here where, for the classes
>> we had to annotate with @SW, we include an additional @apiNote of the form
>> “This class behaves badly, oops”, with a link to a common doc page
>> explaining the problem.  (While we don’t have to do this necessarily
>> immediately, the chance of it falling on the floor if we don’t are
>> higher.). Basically, what you’ve identified is that there are a  number of
>> classes in the JDK which fail to follow best practices with regard to
>> self-use from constructors.  We can’t turn back the clock, but we can mark
>> these as “don’t code like my brother”, so people see these patterns of
>> coding and realize they are not to be emulated.
>>
>
> Good point.
>
> I think it's also worth considering which scenarios require such
> documentation. We have drawn the "boundary lines" at the compilation unit
> boundary, but this means (for example) there are package-private classes
> that generate warnings. Because these classes will end up in a module,
> which requires special effort to crack open, the warnings only really apply
> to JDK developers working in that same package.
>
> Might be worth restricting this to classes that a "normal" person could
> "normally" extend, for some suitable definitions of "normal" and "normally".
>
> I also see in the code that there are two separate categories,
>> LeakingThisInConstructor and this-escape; what’s the difference?
>>
>
> Great question. I was surprised to stumble across existing code with
> @SuppressWarnings("LeakingThisInConstructor") annotations.
>
> From what I can tell, these are leftovers from about 10 years ago when
> some developers were using NetBeans, which had just such a warning. I don't
> think they are relevant any more but I didn't want to presume anything so I
> left them in there.
>
> Thinking about them more, we should probably just replace them because
> otherwise they will just continue to confuse...
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221230/09cbd39a/attachment.htm>