I've been looking into GROOVY-8999 since I have a better understanding of where
some of the unexpected error messages come from. What exactly is the
expectation for use of super qualifier in terms of accessible and inaccessible
members? It is strange that I can safely call "new A().@x" anywhere but not
"super.@x" from within B (when there are no accessor methods). With x private,
I would expect an error from the static type checker.
class A {
private x
def getX() { x }
}
class B extends A {
void test() {
println super.x // uses getter (expected); direct access to x if it's made
accessible -- skips getter and MOP (getProperty, propertyMissing, ...)
(unexpected)
println super.@x // uses getter (unexpected); direct access to x if it's
made accessible (expected)
println super.getX() // uses getter (expected); even if getter is
inaccessible (unexpected)
// similar story for setting x
}
}
It seems that the normal path through classgen does not handle the "super"
qualifier and switch from INVOKEVIRTUAL to INVOKESPECIAL. Therefore, there are
special cases in AsmClassGenerator, but they seem to be doing some unexpected
things.
https://issues.apache.org/jira/browse/GROOVY-8999
https://issues.apache.org/jira/browse/GROOVY-8474
https://issues.apache.org/jira/browse/GROOVY-7300
https://issues.apache.org/jira/browse/GROOVY-6097
https://issues.apache.org/jira/browse/GROOVY-4497
This e-mail is for the sole use of the intended recipient and contains
information that may be privileged and/or confidential. If you are not an
intended recipient, please notify the sender by return e-mail and delete this
e-mail and any attachments. Certain required legal entity disclosures can be
accessed on our website:
https://www.thomsonreuters.com/en/resources/disclosures.html
