On Fri, 13 Jan 2023 16:06:04 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>>> Something seems to be up with the lint description for this-escape - >>> compare this: >> >> Oops, will fix - thanks. > >> The decision was to go with drawing the "warning boundary" at the >> compilation unit. The reasoning is that (a) this aligns with the compiler's >> "knowledge boundary", i.e., we can know for sure from code inspection, and >> also (b) focuses the warning on the particularly pernicious aspect of these >> bugs, which is that they arise from the non-obvious interaction among two or >> more files > > Sorry for being picky - you mention this "compilation unit" boundary before, > but this is not really the reason here. Note that in my example B constructor > calls out to a static method that is "outside" the boundary. The reason as to > why my example is not flagged is simply that "escaping" is defined as > "escaping into a subclass method", not just "escaping from the constructor > (into some other compilation unit)". Oops, you're right, I answered the wrong question so to speak. The "must involve a subclass" requirement is another dimension on which a "boundary" was declared. This was also part of the original discussion. So yes the requirement is: "requires involvement of a subclass" **AND** "that subclass lives in a separate compilation unit". ------------- PR: https://git.openjdk.org/jdk/pull/11874
