RFR: 8271461: CompileCommand support for hidden class methods [v7]

[Ioi Lam]

On Thu, 5 Aug 2021 00:15:00 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Jie Fu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Move tests in MethodMatcherTest.java
>>  - Add Dean's test cases
>
> Actually, I think `java.util/*::method` should be allowed, because the wildcard is in the last component.  It's no different from `mypkg.myclass/*::method`, except that we usually think of "java.util" as a package name.
> Are there any examples of hidden classes not having '$' in the class name?  If not, then maybe that's an easy way to tighten up the hidden class checks.

@dean-long: With abf4df5d71671217ab80331bd08eb19fbc9b8963, we'll see some bizarre behavior. I think it will confuse users who are trying to use `-XX:CompileCommand`, as it's hard to explain why some of these work and others don't.

Given the method `java.lang.Class::isArray()`:

- `java/*::isArray`: no warning, does not match (it gets transformed to `java+*.isArray`)
- `java.*::isArray`: matches
- `java/*.isArray`: matches
- `java/l*::isArray`: gives warning `Error: Method pattern uses '/' together with '::'`, does not match
- `java/l*.isArray`: matches

The latest version, 6bdcff262d27665fd9e07d500819beec58a6bf91, seems just too complicated for what it tries to achieve. Also, we can have regular classes to have `$` in their class names (e.g., Java inner classes), so the above problem still exists.

I think it's better to stick with the current JDK code and have a simple rule -- if you want to match hidden classes, use `+` in the class name.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4926