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-...@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
