<Swing Dev> RFR: 8167182: Exported elements referring to inaccessible types in jdk.accessibility

[Semyon Sadetsky]

+1

--Semyon


On 11/16/2016 1:33 AM, Phil Race wrote:
> Bug : https://bugs.openjdk.java.net/browse/JDK-8167182
> Webrev: http://cr.openjdk.java.net/~prr/8167182/
>
> There are three fields exposed in the accessibility docs which are of 
> types
> that are not exported :
> http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/AWTEventMonitor.html#awtListener 
>
> http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/SwingEventMonitor.html#swingListener 
>
> http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/AccessibilityEventMonitor.html#accessibilityListener 
>
>
> These fields are not intended for client use.
> The first has been deprecated since JDK 8 under
> https://bugs.openjdk.java.net/browse/JDK-8007499
> and is not used by the implementation - and is documented as such.
>
> The other two are also package private types which external code
> could use only via enabling access using core reflection.
> Furthermore those types - which are nested classes - are commented
> as being only intended to be used inside the containing class.
>
>
> Since jigsaw (the module system) will make these fields wholly unusable,
> we should either remove them from the API, or promote them to public.
> Since the latter option was never intended or not useful, instead
> the fix is to (effectively) remove these fields by making them private.
> For the first it is more of a delete and rename but the result is the 
> same.
>
> In addition, the 12 other fields updated in 8007499 and which are of 
> public types
> are updated as being "forRemoval". They were deprecated in 8, but this 
> signals
> a clear intention to remove these in JDK 10. A bug to do so will be 
> filed once
> this webrev (and a CCC) are approved to proceed that way.
> These 12 "forRemoval"s are not strictly required in this fix but since
> the other (non-public) one is being removed it seems a good opportunity
> to do that too.
> A possibility exists to go even further and remove them immediately is 
> theoretically
> available since they have already been deprecated for a major release and
> these are NOT "SE" APIs anyway - they are JDK scope utility classes.
> I am open to that if there are strong views for it and CCC will approve.
>
> -phil.
>
>
>