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

[Kevin Rushforth]

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


> Regards, Peter
>