Fw: SWT_AWT bridge fails with IllegalAccessException in Java 1.9

[Phil Race]

Hi,

I had completely overlooked this thread until now.
- Adding all the platform subclasses as 'critical API' is something that 
would
   have to be agreed to by those on the jigsaw and related projects. I 
am not
   sure it is a viable long term solution and seems undesirable even in 
the short term.

- Solutions that involve major refactoring are also not desirable and 
may be infeasible.

-  Some kind of 'API' is apparently needed.
    We would need to discuss the options and what will 'work' for both ends.
    'work' does not necessarily mean we can make something that is going 
to  require
     just one line of code changed in SWT. It may well be a bit more 
than that.

- To track this I filed https://bugs.openjdk.java.net/browse/JDK-8148109
    Any discussion about what the API might look like should be moved to 
awt-dev at openjdk.java.net

-phil.

On 12/09/2015 05:39 PM, Kevin Rushforth wrote:
> Phil will be the best person to answer this one.
>
> I will note that we have a somewhat similar issue in FX, the 
> difference being that we ship the SWT/FX bridge with the JDK, albeit 
> as a separate jar file with an external dependency on SWT (which has 
> its own challenges).
>
> -- Kevin
>
>
> Alan Bateman wrote:
>>
>>
>> On 08/12/2015 08:13, Lakshmi P Shanmugam wrote:
>>> :
>>>
>>> I would like to request for the addition of the above internal APIs 
>>> to the
>>> critical API list in JEP 260 so that are accessible for Java 1.9. Also,
>>> please provide replacement APIs for them in the future.
>>>
>>>
>> I think this needs someone with expertise in this area to comment, I 
>> hope Phil Race or Kevin Rushforth.
>>
>> In particular, I think it needs direction as to whether a standard or 
>> JDK-specific make sense here and whether now is the time to try to 
>> define that. Maybe there have been discussion on this issue in the past.
>>
>> Also it would be useful to understand whether exporting sun.awt.X11, 
>> sun.awt.windows, .. is even feasible.  I will guess that it would 
>> require major refactoring to move these packages out of java.desktop 
>> to the jdk.unsupported module. It would require everything else in 
>> these packages to move elsewhere. There is also the concern that it 
>> would result in a standard module (java.desktop) have a dependency on 
>> a JDK-specific module (jdk.unsupported).
>>
>> -Alan