how to tell 2 methods are override-equivalent
Hamlin Li
huaming.li at oracle.com
Wed Mar 22 09:07:31 UTC 2017
Hi Martin,
On 2017/3/22 5:50, Martin Buchholz wrote:
> My ancient script findMissingSince examined the generated javadoc for
> various jdk revisions and parsed the resulting html via regexes
> (despite
> http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__stackoverflow.com_questions_1732348_regex-2Dmatch-2Dopen-2Dtags-2Dexcept-2Dxhtml-2Dself-2Dcontained-2Dtags&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=AXDiAb80BUl4-hDaluwjLd5U4_mt4rwel55emXlCIpY&m=yQpThaVepEZ91CHqPDIwBaybI5LZPMyLd4rkqkB1HjM&s=LYN0GFQMCl0eFscx1eHrv_xCHJLvj_zR92hVy_2uJFE&e=>).
Thank you for the information.
I find some information about findMissingSince at
https://bugs.openjdk.java.net/browse/JDK-6367207, but can not find the
valid code.
>
> Whether using hacky regexes or "proper" tools aware of the java
> language, there is a need to compare method signatures.
> Erasure-equivalent methods are the "same" method.
Agree, it's the issue I'm trying to resolve.
>
> (As always, it would be nice if the resulting code were available to
> anyone.)
Agree, I will try to open it when it's good time.
For now, it's not mature enough, there are some issues to solve,
enhancements to do, and the design/implementation is specific for jdk.
When the functionality is ready, I will discuss with stakeholders and
management about it.
Thank you
-Hamlin
>
>
> On Sun, Mar 19, 2017 at 7:13 PM, Hamlin Li <huaming.li at oracle.com
> <mailto:huaming.li at oracle.com>> wrote:
>
> Hi Vicente,
>
> Thank you for responding, please check the comments inline.
>
> On 2017/3/17 21:08, Vicente Romero wrote:
>> Hi Hamlin,
>>
>> How do you obtain m2? I mean at some point it should have been
>> obtained from an executable element or similar.
> I have a java doclet which scans jdk versions iteratively, m2 was
> got in previous round of run of the tool , then it's stored in a
> file (for example when scan jdk 1.8 source code), then parsed and
> retrieved from the file again (for example when scan jdk 9 source
> code).
>> In the worst case you can always generate a simple test case and
>> try to compile it for example:
>>
>> class Test {
>> void getContent(java.lang.Class<?>[] c) {}
>> void getContent(java.lang.Class[] c) {}
>> }
>>
>> this one will fail saying that both methods have the same erasure,
> Yes, it should fail.
> In my situation, "getContent(java.lang.Class[] c) {}" is the code
> in jdk 1.8, "getContent(java.lang.Class<?>[] c) {}" is the
> corresponding code in jdk 9. When I scan jdk 9 source code, I need
> to tell that getContent(java.lang.Class<?>[] c) and
> getContent(java.lang.Class[] c) are in fact the same method,
> rather than 2 different methods.
>
> Thank you
> -Hamlin
>>
>> HTH,
>> Vicente
>>
>> On 03/16/2017 11:15 PM, Hamlin Li wrote:
>>>
>>> Hi,
>>>
>>> ( I'm not sure if this is the right alias to ask the question,
>>> please help forward if necessary. )
>>>
>>> I have a question about telling whether one method is
>>> subsignature of another one. My situation is,
>>>
>>> 1. there is a TypeElement *t1 *which represents java.net.URL,
>>> and a ExecutableElement *m1* which represents
>>> getContent(java.lang.Class*<?>*[]),
>>>
>>> 2. there is a String *t2* which is "java.net.URL", and another
>>> String *m2 *which is "getContent(java.lang.Class[])".
>>>
>>> The difference between m1 and m2 is that, m1 is an instance of
>>> ExecutableElement, m2 is an instance of String; there is a
>>> wildcard type argument in m1.
>>>
>>>
>>> Is there a way to tell whether m1 and m2 are
>>> override-equivalent, m2 is subsignature of m1?
>>>
>>> I suppose I should use
>>> javax.lang.model.util.Types.isSubsignature(ExecutableType m1,
>>> ExecutableType m2), but I don't know how can I convert
>>> ExecutableElement *m1* and String *m2* to**ExecutableType.
>>>
>>> Or I'm in wrong direction?
>>>
>>>
>>> Thank you
>>>
>>> -Hamlin
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170322/f41dd367/attachment.html>
More information about the compiler-dev
mailing list