RFR JDK-8164836: fix jdeprscan violations of tools/all/RunCodingRules.java

[Stuart Marks]

Hi Jan,

Thanks for picking this up.

As you point out, the API usage in jdeprscan, and its containing module 
jdk.jdeps, really isn't the target of @DefinedBy. It's "implementing" the APIs, 
but for the purpose of getting callbacks from the annotation processing 
framework, not for the purpose of providing an implementation of the API to the 
general public. In that sense @DefinedBy doesn't really apply, so it makes sense 
to adjust the DefinedByAnalyzer to be more specific in what it's checking.

But does special-casing jdk.jdeps make sense? Or should there be some kind of 
finer-grained logic to determine when @DefinedBy should and shouldn't apply? I 
wouldn't be surprised if there are other usages of @DefinedBy outside of 
jdk.jdeps that are in a similar situation. See jdk.jshell for instance.

I've prepared a patch -- not yet posted anywhere -- that simply adds the right 
@DefinedBy annotations in jdeprscan. This is simple enough to do, even though it 
might not be the right thing.



s'marks




On 8/26/16 5:00 AM, Jan Lahoda wrote:
> Hi,
>
> The RunCodingRules test is broken after 871b60b0c091, and has been disabled. My
> proposal to fix this is to disable the DefinedByAnalyzer for classes from the
> jdk.jdeps module. This module is not AFAIK implementing the APIs, and so is not
> a primary target of the analyzer/@DefinedBy annotation. One notable alternative
> would be to disable the crules completely for jdk.jdeps, but I opted rather for
> a more limited change. (Another alternative would be to add the @DefinedBy
> annotations to classes jdk.jdeps, but that does not seem quite right to me.)
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8164836
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8164836/webrev.00/
>
> Jan