<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 9/16/18 12:48 AM, Alan Bateman
15/09/2018 22:00, Philip Race wrote:
<blockquote type="cite">It was exported in the past .. and it was
publicly documented ..
<a class="moz-txt-link-freetext" href="http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html">http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html</a>
.. so I think Sergey was correct in his "JDK" scope.
Implementation would be for something entirely internal.
I think Sergey's changes are okay.
The main issue with com.sun.awt API is that it tried to be both an
exported and internal/unsupported API at the same time (it's
javadoc reads "This class is an implementation detail and only
meant for limited use outside of the core platform"). This doesn't
work for modules. In addition the design principles in JEP 200
make it clear that standard modules should not export a
non-standard package to all modules. If there has been extensive
use of this API then I could imagine it being refactored and moved
into a JDK-specific module but there was little evidence of usage.
So where we ended up in JDK 9 is that the API is not exported.
This means, as Mandy hinted, you can't compile against this API
(at least not without --add-exports to the compiler). Existing
code using this API will continue to run on JDK 9, 10, 11 or until
the java.desktop module is fully encapsulated or the
SecurityWarning class is removed. Sergey got there first.
Yes. Since it was decided not to export com.sun.awt API
(JDK-8051640), they are no longer supported. Is there a CSR filed
officially declaring com.sun.awt APIs are no longer supported?
Since it's already deprecated for removal, it may be worth to have a
release note for JDK-8205588 if we didn't officially declare it