[ https://issues.apache.org/jira/browse/GROOVY-8167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Theodorou closed GROOVY-8167. ------------------------------------ Resolution: Won't Fix Assignee: Jochen Theodorou While Groovy does allow access to private fields in many cases we always restricted that to the current runtime class. It is questionable if this feature survives in the future, in many cases it won't. I don't think that FieldUtils in the current version will work on Java9. And class B might define a field of the same name as class A (this is possible without using private even in Java) In that case b.@one for a field that exists in A and B is not precise enough. You would require the class you are setting the field on. In Java this is solved by the compileTime type,but then the accessing code for A#one has to be in A and the accessing code for B#one in B - not in the test testing A and/or B. > Direct field access fails for superclass fields > ----------------------------------------------- > > Key: GROOVY-8167 > URL: https://issues.apache.org/jira/browse/GROOVY-8167 > Project: Groovy > Issue Type: Bug > Reporter: Eric Milles > Assignee: Jochen Theodorou > Priority: Major > > About half the time I need to quickly fill in a private field for a test or a > bit of prototype code, I end up having to bust out Apache Commons Lang's > {{FieldUtils}}, because the Groovy direct field access operator {{.@}} does > not allow access to fields in a super type. The operator is very handy in > preventing use of reflection code, but its potential is not fully realized. > Here is a example: > {code} > class A { private String one } > class B extends A { private String two } > B b = new B() > b.@two = '' // works as expected > b.@one = '' // fails with MissingFieldException: No such field: one for > class: B > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)