[
https://issues.apache.org/jira/browse/LUCENE-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14612125#comment-14612125
]
Uwe Schindler edited comment on LUCENE-6651 at 7/2/15 4:02 PM:
---------------------------------------------------------------
Minor updates, adding Java 8 @FunctionalInterface to AttributeReflector.
Wil commit this soon and provide a patch for branch_5x, with all
implementations but preserving the reflection inside a
AccessController.doPrivileged() for backwards compatibility.
was (Author: thetaphi):
Minor updates, adding Java 8 @FunctionalInterface to AttributeReflector.
Wil commit this soon and provide a patch for branch_5x, with all attributes but
preserving the reflection inside a AccessController.doPrivileged().
> Remove private field reflection (setAccessible) in AttributeImpl#reflectWith
> ----------------------------------------------------------------------------
>
> Key: LUCENE-6651
> URL: https://issues.apache.org/jira/browse/LUCENE-6651
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
> Affects Versions: 5.2.1
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6651-MethodHandles.patch, LUCENE-6651.patch,
> LUCENE-6651.patch
>
>
> In AttributeImpl we currently have a "default" implementation of reflectWith
> (which is used by toString() and other methods) that uses reflection to list
> all private fields of the implementation class and reports them to the
> AttributeReflector (used by Solr and Elasticsearch to show analysis output).
> Unfortunately this default implementation needs to access private fields of a
> subclass, which does not work without doing Field#setAccessible(true). And
> this is done without AccessController#doPrivileged()!
> There are 2 solutions to solve this:
> - Reimplement the whole thing with MethodHandles. MethodHandles allow to
> access private fields, if you have a MethodHandles.Lookup object created from
> inside the subclass. The idea is to add a protected constructor taking a
> Lookup object (must come from same class). This Lookup object is then used to
> build methodHandles that can be executed to report the fields. Backside: We
> have to require subclasses that want this "automatic" reflection to pass a
> Lookup object in ctor's {{super(MethodHandles.lookup())}} call. This breaks
> backwards for implementors of AttributeImpls
> - The second idea is to remove the whole reflectWith default impl and make
> the method abstract. This would require a bit more work in tons of
> AttributeImpl classes, but you already have to implement something like this
> for equals/hashCode, so its just listing all fields. This would of couse
> break backwards, too. So my plan would be to implement the missing methods
> everywhere (as if it were abstract), but keep the default implementation in
> 5.x. We just would do AccessController.doPrivileged().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
