[
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)
