RFR(13): JDK-8217047: Provide a way to inject missing parameter names

[Jan Lahoda]

Hi Jon,

Thanks for the comments. I tried to improve the javadoc, added implNote, 
and fixed Flags and MissingInfoHandler.

Regarding ClassReader always creating ParamSymbols, as the ParamSymbol 
is not bigger than VarSymbol, I opted for simplicity and a more uniform 
representation. But I can change that to use VarSymbol when the name is 
known, should be simple.

Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8217047/webrev.03/

Updated specdiff:
http://cr.openjdk.java.net/~jlahoda/8217047/specdiff.03/overview-summary.html

How does this look?

Thanks,
     Jan

On 16.3.2019 01:32, Jonathan Gibbons wrote:
> Nice.  Minor comments...
>
> The {@linkplain}don't seem to be working as expected;  I suspect you
> need to import the type names. Also, you should use parens and arg types
> on links to methods; if you don't want the `(arg-types)` to show up in
> the docs, use the form of {@linkplain} that allows you to specify the
> text to be linked.
>
> The new method in JavacTask should have an implNote that says, "This
> Implementation does nothing." or words to that effect.
>
> (Aside: we have a more general problem with implNotes, that we have
> places where the default is to do nothing or throw UOE, but the reality
> is that the real-world impl of these methods does something useful. I
> don't know how/where we should document that behavior. But that's a
> bigger question for another time and another review.)
>
> Flags.java
>
> typo: friedly
>
> ClassReader ... just curious, you always create a new ParamSymbol, even
> when you could use a VarSymbol (because you have already filled in the
> name).  I guess the code is neater/more consistent the way you have it.
>
> MissingInfoHandler ... no class-level doc comment. I realize it's an
> internal class but even so ...
>
> -- Jon
>
>
> On 01/21/2019 04:32 AM, Jan Lahoda wrote:
>> Hi,
>>
>> When a type is load from a classfile, and some or all of its methods
>> have neither the MethodParameters or LocalVariableTable attributes,
>> then the parameters of the methods have an artificial synthesized
>> name, which is visible through VariableElement.getSimpleName().
>>
>> The proposal here is to allow to plug in an external provider that
>> could provide more user-friendly names lazily/on demand. These could
>> originate e.g. in adjacent sources.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217437
>> Webrev: http://cr.openjdk.java.net/~jlahoda/8217047/webrev.01/
>> Specdiff:
>> http://cr.openjdk.java.net/~jlahoda/8217047/specdiff.01/overview-summary.html
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8217437
>>
>> What do you think?
>>
>> Thanks,
>>     Jan
>