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
