[9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

[Peter Levart]

Hi Kevin,

On 05/10/2017 03:19 AM, Kevin Rushforth wrote:
> inline
>
> Peter Levart wrote:
>> Hi Kevin,
>>
>> On 05/02/2017 02:21 AM, Kevin Rushforth wrote:
>>> This review is being cross-posted to both openjfx-dev and jigsaw-dev.
>>>
>>> Please review the proposed fix for:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8177566
>>> http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/
>>>
>>> Details of the fix as well as notes to reviewers are in the bug 
>>> report [1] (e.g., I've also generated separate webrevs for the fix 
>>> itself, the doc changes, and the test changes).
>>>
>>> -- Kevin
>>>
>>> [1] 
>>> https://bugs.openjdk.java.net/browse/JDK-8177566?focusedCommentId=14074243&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14074243
>>>
>>
>> I think it is very unusual to handle unqualified exports as something 
>> special, different from qualified exports. I know what the reasoning 
>> is: if a package is exported unconditionally (to everyone) then it is 
>> part of public API and so the trampoline may access members of that 
>> package on behalf of anyone. But such reasoning is just a consequence 
>> of the lack of a finer-grained (per-module) access support in JavaFX. 
>> I know it is too much to ask for JDK 9, but could JavaFX in say JDK 
>> 10, given current API, somehow determine on whose behalf it is making 
>> the trampoline access? If it could, then the trampoline could allow 
>> qualified exports to be effective too.
>
> The primary remedy is for the application to use a qualified "opens" 
> to the appropriate javafx module. For example, to allow the 
> JavaBeanXXXProperty classes the ability to access a class in your 
> module, your module needs to "opens my.package to javafx.base". The 
> only difference between what you propose and what was implemented is 
> qualified exports versus qualified opens, which really shouldn't be 
> too much of an issue for applications (such applications already need 
> to use qualified opens to allow access to their FXML controller class).
>
> The only reason we mention unconditional exports as an alternative is 
> for the benefit of application that happen to already have their 
> package exported unconditionally.
>
> -- Kevin

I was thinking more in the direction of who the "real" accessor is when 
some JavaBeanXXXProperty is being used to access the bean getter/setter 
methods. Could it be the one invoking the 
JavaBeanXXXProperty.get()/.set() methods? Could it be the one invoking 
the JavaBeanXXXProperty.bind(ObservableValue) ?

JavaBeanXXXProperty is a kind of "reflection" API with additional 
features. Classical Java reflection, for example, uses the "real" caller 
(the one invoking Method.invoke or Field.get/.set) to base access 
decisions on. Would this be the right approach for JavaBeanXXXProperty 
too? (injections with @FXML are a different story).

Say for example, that module A has some Java bean classes that it would 
like to expose solely to module B and module B would like to bind their 
properties to some observables. Now module A would like to expose those 
bean classes to B with simple qualified exports so that no other module 
but B could bind or access A's bean properties.

Does this make sense so far?

If qualified "opens" to the appropriate javafx module is enough for 
JavaBeanXXXProperty to access bean properties in so opened packages, 
then JavaBeanXXXProperty provides a means for anyone to access those 
getters/setters. In my view this represents an elevation of privilege. A 
qualified opens to javafx then means more than just that. It means 
getters/setters are open to anyone who dares to use JavaBeanXXXProperty 
API instead of classic reflection API.

What do you think?

Regards, Peter