fix: Reflector should reflect record

[guanchengang]

When using Reflector to obtain the get method of a record, all methods without parameters (e.g. toString(), hashCode(), and all custom methods without parameters) are obtained simultaneously. I don't think these can be called the get methods of a record.

[coveralls]

coverage: 87.389%. remained the same
when pulling c9c637d on guanchengang:fix
into 8111b51 on mybatis:master.

[hazendaz]

@guanchengang I believe you are correct here but want to get @harawata to chime in. In meantime, can you add an extra check on your test to make sure it does NOT contain the items you are causing to be avoided. And maybe for utmost clarity, add a test that shows a dummy record using original logic wrongly picked up those other elements to demonstrate why this was important?

[guanchengang]

@hazendaz I have added extra checks for this.
However, considering that we have already modified the original logic, if we want to add new tests to it, we may need to copy the old code into the test class, which will result in a relatively large testing method, and I feel that it is a bit strange to put it here (it will not increase any test coverage). If I misunderstood your meaning, please let me know.

[epochcoder]

Question, is this behaviour explicitly for records now? I believe that if we change the reflector it should be consistent with how a normal class is reflected aswell, not _only records get their static methods and toString, etc.. _ avoided.

Could you point to a bug that initially made you want to attempt to fix this to gain more context?

[guanchengang]

I'm sorry about the slow response.
I completely agree with what you said, and I realize that I haven't considered it thoroughly enough.
In fact, when using reflector reflection records, only the accessor methods will be obtained, and in most cases, it will not cause any impact，so I did not encounter any bugs.
I just occasionally noticed the toString and hashCode method appearing when the reflector reflects the record while using debug mode.
When using normal classes, the accessor methods are all in the form of getXxx(). When using record, we only know that the field and its access method have the same name, but a property may have multiple access methods (which I did not consider at first) .So we should not avoid obtaining static methods or other no parameter methods as you said.
But whether to block toString and hashCode is still worth discussing.

In the documentation of JDK(https://docs.oracle.com/javase/specs/jls/se25/html/jls-8.html#jls-8.10.1-120)
every record class provides implementations of hashCode and toString that return representations of a record object as a whole; they cannot serve as accessor methods for record components called hashCode or toString, and there would be no way to access such record components from outside the record class
It is explicitly stated that it cannot be used as a name for record components and accessor methods.

Perhaps not dealing with it is also a good choice, as they are automatically generated and all read-only methods, and even if used, will not modify any data🤔.