JDK 13 RFR of JDK-8146726 : Improve AbstractProcessor to issue warnings for repeated information

Stuart Marks stuart.marks at oracle.com
Tue Apr 30 00:14:08 UTC 2019


Hi Joe,

Some nitpicky comments for you in AbstractProcessor.java. :-)

I'm finding the boolean flags to be fairly confusing. Consider the 'initialized' 
field. This has a synchronized getter; getSupportedAnnotationTypes() calls the 
getter and stores the result in a local for use within this method. However, 
arrayToSet() accesses the 'initialized' field directly, and it's called 
(unsynchronized) from getSupportedOptions() as well as 
getSupportedAnnotationTypes().

First, there's a potential memory visibility problem here, if you're concerned 
about multithreaded access. (At least some of the code in this class seems to 
try to handle thread-safety.) Second, the 'initialized' state is accessed from 
two different levels in the method call hierarchy, e.g. 
getSupportedAnnotationTypes() and arrayToSet(). This isn't necessarily a 
problem, but it does make me pause to try to think about what it means.

Another flag is 'stripModulePrefixes' (parameter to arrayToSet()) and its 
dependent local variable 'stripped' which is set if anything was actually 
stripped from this element. These make arrayToSet() a bit of a puzzle for me. I 
think the following are true:

1) if we aren't stripping module prefixes, we'll issue a warning on any duplicates.

2) if we are stripping module prefixes, we won't issue a warning if a prefixes 
was stripped from this element.

My first inclination is to think that there are really two different 
arrayToSet() methods wanted here. The first doesn't strip and may issue 
warnings, and the second does strip and doesn't issue warnings. It seems to me 
that two separate methods might be simpler than one bigger method with a bunch 
of flags.

But that's not what the current implementation does. However, the current 
implementation doesn't quite make sense to me either. For example, the comment 
says that if module names are stripped, warnings aren't issued because they'd be 
spurious if the array is ["foo/a.B", "bar/a.B"]. However, I'm not sure this 
logic makes sense. It seems to me that if the array is

     ["a.B", "foo/a.B"]

then no warning is issued, but if the array is

     ["foo/a.B", "a.B"]

the a warning is issued. Am I reading this correctly, and is this the right 
behavior?

s'marks


On 4/25/19 8:56 AM, Joe Darcy wrote:
> PS Amended webrev at
> 
>      http://cr.openjdk.java.net/~darcy/8146726.5/
> 
> I added a bit of logic to avoid issuing a duplicate warning when the module name 
> is stripped off to avoid spurious warnings in a case like
> 
>      "foo/a.B"    "bar/a.B"
> 
> The intention of the revision of the semantics of this method in JDK 9 was to 
> allow convenient and warning-free usage with and without modules.
> 
> Thanks,
> 
> -Joe
> 
> On 4/24/2019 7:08 PM, Joe Darcy wrote:
>> Hello,
>>
>> Returning to JDK-8146726, based on previous review feedback I've changed the 
>> title to "Improve AbstractProcessor to issue warnings for repeated 
>> information" and reworked the fix:
>>
>>     http://cr.openjdk.java.net/~darcy/8146726.4/
>>
>> Thanks,
>>
>> -Joe
>>
>>


More information about the compiler-dev mailing list