<AWT Dev> [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8067092: Suppress windows-specific deprecation warnings in the java.desktop module

[Phil Race]

Yes .. no technical constraint there.
Although I was pondering going further and seeing if we can actually remove
the public method java.awt.peer.Peer Component.getPeer()
since with the module system the peer package is not accessible and this
is then even  weirder than it is now .. as it effectively documents a 
package
we don't document (any more) and you can't use in JDK 9.

-phil.

On 12/16/14 10:24 AM, Jim Graham wrote:
> Stop using them and replace them with new package private methods and 
> a cross-package accessor (similar to the SurfaceManager.ImageAccessor 
> pattern)?  What are the technical constraints preventing this?
>
> I think the getPeer() method used to be used by AWT applications to 
> tell if an app was on the screen or not, but we can easily gut the 
> method to just return any old non-null value when the peer exists 
> (even just leave it returning the true peer as long as we aren't using 
> it internally to get the peer).  Then we could independently decide if 
> its legacy uses are no longer allowed and switch it to throwing an 
> exception or returning null or uninteresting values as we see fit...
>
>             ...jim
>
> On 12/16/14 9:24 AM, Phil Race wrote:
>> Approved.
>> We really need to figure out what to do about getPeer() - for this and
>> for jigsaw ..
>>
>> -phil.
>>
>>
>> On 12/16/2014 9:10 AM, joe darcy wrote:
>>>
>>> On 12/16/2014 3:15 AM, Alan Bateman wrote:
>>>> On 16/12/2014 06:07, joe darcy wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the next step of suppressing the deprecation warnings
>>>>> the client libraries, this time in windows-specific desktop code:
>>>>>
>>>>>     JDK-8067092: Suppress windows-specific deprecation warnings in
>>>>> the java.desktop module
>>>>>     http://cr.openjdk.java.net/~darcy/8067092.0/
>>>>>
>>>>> Thanks,
>>>> Lots more getPeer :-)
>>>>
>>>> The change looks okay to me and the same techniques to reduce these
>>>> as per the other thread.
>>>>
>>>
>>> Yes, same techniques as before -- for each warning, add
>>> "@SuppressWarning("deprecation")" to the enclosing method (or to the
>>> field for a field initializer expression). Some @SuppressWarning
>>> annotations cover multiple warning instances.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>