Re: Retiring this awt-dev list on 30th September 2021

Reminder. -phil On 9/15/21 11:09 AM, Philip Race wrote: As described below -Phil. Forwarded Message Subject: Retiring 2d, awt, beans, sound and swing mailing lists on 30th September 2021 Date: Wed, 15 Sep 2021 11:05:09 -0700 From: Philip Race To: client-libs

Retiring this awt-dev list on 30th September 2021

As described below -Phil. Forwarded Message Subject: Retiring 2d, awt, beans, sound and swing mailing lists on 30th September 2021 Date: Wed, 15 Sep 2021 11:05:09 -0700 From: Philip Race To: client-libs-...@openjdk.java.net Since : 1) The old client groups

Fwd: Project Wakefield announcement and welcome

FYI Forwarded Message Subject:Project Wakefield announcement and welcome Date: Wed, 1 Sep 2021 14:59:30 -0700 From: Philip Race To: wakefield-...@openjdk.java.net Hi all, The project has been recorded in the OpenJDK census : https://openjdk.java.net

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

ompatible change is being made solely to find out what breaks. Alan On Jul 8, 2021, at 2:39 PM, Philip Race wrote: Changing the name seems to have at least been useful to find cases such as this which I suspect are very, very rare. My Java code sets up a secondary run loop.

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

Changing the name seems to have at least been useful to find cases such as this which I suspect are very, very rare. > My Java code sets up a secondary run loop. But JDK only enters that mode if *it* creates a secondary run loop. >  The AppKit implementation of the file dialog calls Java

FYI: A CFD for a Wayland project has been posted to disc...@openjdk.java.net

https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html -phil.

Re: VM shutdown upon X server termination

So if it returns and exit() is immediately called, how does that cause a crash ? It seems to be just the same as if the handler called exit() directly and so did not return. I would have thought a crash more likely if it didn't return and tried to keep the program running, which might be

Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS.

Heads up to anyone who is testing JDK 17 for running apps on macOS. Starting with build 19 [1], JDK 17 for macOS is *temporarily* switched from using OpenGL to using Apple's Metal API for Java 2D rendering. This should be invisible to applications. We expect to revert this temporary switch in

Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application

It is something of a new paradigm (yes its been there since 10.12, that's not what I mean) so we should make sure its supportable. The system dialog UI talks of "documents" which might tell us something about the mindset of the folks who designed it. I also find it surprising it is a global

Re: Clarification regarding PageFormat and Paper getImageable* functions orientation consideration

Wrong list. That is a 2D API. -phil. On 3/22/21 12:09 PM, Rajat Mahajan wrote: Hi all, *_Issue:_* *__* I am working on https://bugs.openjdk.java.net/browse/JDK-8203395  and this bug is about *“PageFormat showing wrong printer margins in

Re: Legacy Apple com.apple.eio.FileManager (in module java.desktop) removed at jdk 16?

te: On Mar 18, 2021, at 3:29 PM, Philip Race wrote: I think this is because of https://bugs.openjdk.java.net/browse/JDK-8256299 JDK 16 release notes here : http://jdk.java.net/16/release-notes I think I ran into a couple related issues. I had a check to see if default Toolkit gave m

Re: Legacy Apple com.apple.eio.FileManager (in module java.desktop) removed at jdk 16?

I think this is because of https://bugs.openjdk.java.net/browse/JDK-8256299 JDK 16   release notes here : http://jdk.java.net/16/release-notes -phil On 3/18/21 1:07 PM, Michael Hall wrote: If I remember correctly this group ended up the keepers of this code. If that is not right please point

Re: New candidate JEP: 398: Deprecate the Applet API for Removal

I should clarify my response that there's no time frame being set here for the actual removal so there should be ample time to do that re-writing. phil. On 3/5/21 2:59 PM, Philip Race wrote: I actually counted almost 100 such open tests. You need to remember JApplet too. And these open

Re: New candidate JEP: 398: Deprecate the Applet API for Removal

I actually counted almost 100 such open tests. You need to remember JApplet too. And these open jtreg tests do not account for all of it by any means. There are a couple of options - although I  think re-writing is the only truly viable one. But definitely re-working all of those is one

Project Lanai (New Metal Java 2D Rendering pipeline for macOS) EA build 10 has been released

All, We have prepared an EA 10 build of Project Lanai for JEP 382 [1] incorporating fixes to feed back during the ongoing code review [2] EA 10 can be downloaded from https://jdk.java.net/lanai/. Note the open issues and testing suggestions given there. Please test with your apps and

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v7]

I have worked out how to pass this option to at least the jtreg tests for the lanai headful mach5 job, so once this is fixed we can check it out in jtreg and get some level of confidence  that we are checking all the important cases. Note that we know some tests will fail just because it spits

Project Lanai (New Metal Java 2D Rendering pipeline for macOS) FINAL planned EA build has been released

All, The Lanai project has reached the stage where we are aiming to move the JEP [1] to Proposed-To-Target [2] to JDK 17 very soon. We have made one final planned EA release which includes all the latest fixes. So please visit https://jdk.java.net/lanai/ and download the EA 9 build and

Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU

From the CSR ; >This change also improves the startup performance, on my current new > laptop mbp 16 + BigSur 11.1 the switching discrete/integrated causes unexpected delays up to 10 seconds. This also has to be a bug. I thought it had gone away. Have we reported that to Apple ? If not we

Re: RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code [v7]

Ah .. not my call .. complicated. -phil. On 12/18/20, 4:40 PM, Alan Snyder wrote: If it’s better than JNF, as you suggest, perhaps it should be released and supported. Alan On Dec 18, 2020, at 4:28 PM, Philip Race wrote: Not something I'd considered as a goal. I suppose its part

Re: RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code [v7]

Not something I'd considered as a goal. I suppose its part of OpenJDK which means it will be there for anyone to use under the GPL2+CP ... but there's no thought of delivering it like we deliver jni.h with the binary JDK distribution. -phil. On 12/18/20, 4:23 PM, Alan Snyder wrote: I use

Re: RFR: 8257853: Remove dependencies on JNF's JNI utility functions in AWT and 2D code [v6]

But is not "contributed" which makes it 3rd party code which in the long term is problematic. 3rd party orphaned code is something of a pain, so this is best for the long term to just do what we'd do if it never existed and there is plenty of time in JDK 17 to work out the kinks. Also I am

EA8 build of Project Lanai (Java 2D Metal rendering pipeline for macOS) is now posted

The EA 8 build of Project Lanai [1] was posted today at https://jdk.java.net/lanai/ EA 8 Build 17-lanai+1-2 (2020/12/12) Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues. One particular request : To anyone who has a mac still running 10.12 - we don't expect Metal

EA7 build of Project Lanai (Java 2D Metal rendering pipeline for macOS) is now posted

The EA 7 build of Project Lanai [1] was posted today at https://jdk.java.net/lanai/ EA 7 Build 16-lanai+3-278 (2020/11/17) Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues. EA 7 contains the following new bug fixes relative to EA 6 # 8256331: Lanai:

EA6 build of Project Lanai (Java 2D Metal rendering pipeline for macOS) is now posted

I am a bit slow in sending out the announcement, but https://jdk.java.net/lanai/ is now hosting the EA 6 build of Lanai EA 6 Build 16-lanai+2-229 (2020/10/4) Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues. EA 6 contains the following new bug fixes relative to

EA5 build of Project Lanai (Metal rendering pipeline for macOS) is now posted

After some technical hiccups which delayed it, https://jdk.java.net/lanai/ is now hosting the EA 5 build of Lanai EA 5 Build 16-lanai+1-129 (2020/9/7) Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues. EA 5 contains the following new bug fixes relative to EA 4

Re: IMPORTANT - PLEASE READ - Retiring the jdk/client repo next week

-created as github pull requests. -phil. On 9/1/20, 8:58 AM, Philip Race wrote: As per the notifiication last week, as of NOW there should be NO MORE pushes to the hg://openjdk.java.net/jdk/client forest. --- So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to jdk/client should

Re: [16] RFR 8252470: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails on Windows

, Philip Race <mailto:philip.r...@oracle.com>> wrote: Looks Ok to me but please confirm that all related tests pass. -phil. On 8/28/20, 12:54 PM, Dmitry Markov wrote: Hello, Could you review the fix for JDK 16, please? bug: https://bugs.openjdk.java.net/browse/JDK-8252470 web

Re: [16] RFR 8252470: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails on Windows

Looks Ok to me but please confirm that all related tests pass. -phil. On 8/28/20, 12:54 PM, Dmitry Markov wrote: Hello, Could you review the fix for JDK 16, please? bug: https://bugs.openjdk.java.net/browse/JDK-8252470 webrev: http://cr.openjdk.java.net/~dmarkov/8252470/webrev.00/

Re: RFR: 8252349 Delete the "sun.awt.X11.checkSTRUT" property

+1 -phil. On 8/26/20, 12:34 AM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8252349 Fix: http://cr.openjdk.java.net/~serb/8252349/webrev.00 This property was added to the XToolkit as a workaround for the possible bugs

IMPORTANT - PLEASE READ - Retiring the jdk/client repo next week

All, Contingent on Project Skara (ie mercurial ->git / githib) going active for the JDK project on schedule on 5th September, we intend to retire the jdk/client repo/forest as part of this transition. In other words, once mercurial is shut down and we move to git there will ONLY be the main

Re: RFR[8250855]: 'Address reliance on default constructors in the Java 2D APIs'

Neither of awt-dev or jdk-dev is the right list for this fix. Please move the review to 2d-dev. -phil. On 8/17/20, 4:50 AM, Lance Andersen wrote: Hi Daniel On Aug 17, 2020, at 7:30 AM, Daniel Fuchs wrote: On 17/08/2020 12:16, Lance Andersen wrote: The description for almost all of the

Re: RFR: 8250856 Address reliance on default constructors in the AWT APIs

Approved. I fixed a typo error in your CSR .. it was missing some words. -phil. On 8/5/20, 5:53 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8250856 CSR: https://bugs.openjdk.java.net/browse/JDK-8251211 Fix:

RFR: 8240487 : Cleanup whitespace in .cc, .hh, .m, and .mm files

Bug: https://bugs.openjdk.java.net/browse/JDK-8240487 Webrev: http://cr.openjdk.java.net/~prr/8240487/ In advance of the move to Project Skara/git it is desirable to clean up whitespace in source files that are not currently checked by jcheck so we can add these extensions to jcheck at that

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.02/ If you are ok this, I will push it to jdk/client. Thanks, Yasumasa On 2020/07/29 10:21, Philip Race wrote: The change in WFontConfiguration looks good but I have no idea what the change in WComponentPeer is supposed to achieve. "new

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

07/29 9:49, Philip Race wrote: On 7/28/20, 5:35 PM, Yasumasa Suenaga wrote: Hi Phil, Thanks for explanation. findFontWithCharset() does not have comments, so I cannot evaluate my proposal whether it breaks important behavior, but I almost agree with your change. However... sequence.allfont

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

if (componentFontName.endsWith(charset)) { ``` The following code is pointless as you said, so I agree with you to remove it. if (fontName ==null) { fontName = findFontWithCharset(fontDescriptors,"DEFAULT_CHARSET"); } Thanks, Yasumasa On 2020/07/28 15:15, Philip R

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

this there : if (fontName ==null) { if (fontDescriptors.length >0) { return fontDescriptors[0].getNativeName(); }else { fontName ="Arial,ANSI_CHARSET"; } } Not very satisfactory but then we can remove the comment about maybe returning NULL

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

FAULT_CHARSET does not work at this point. If we do not pass -Dfile.encoding=UTF-8, `charset` in WFontConfiguration::findFontWithCharset is set to "windows-31j" and it can find out valid font when Windows is set to Japanese locale. I can share minidump for further investigation. What sho

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

Hi, You're avoiding a crash but I don't yet know what *exactly* caused the crash. Some Java code not handling DEFAULT_CHARSET is obviously not the exact cause. This just starts it and something bad presumably happens later in native code. And I don't yet understand why (we think) this

Re: RFR [16] 8246248: TransferHandler.exportToClipboard prints stacktrace even if succeeded

PS I also don't think statically initialising a logger even if it is never needed is a good idea. -phil. On 7/20/20, 9:04 AM, Philip Race wrote: No, not approved. This fix is using sun.util from inside Java,base. We need to remove the existing cases of this usage. Not add new ones. -phil

Re: RFR [16] 8246248: TransferHandler.exportToClipboard prints stacktrace even if succeeded

No, not approved. This fix is using sun.util from inside Java,base. We need to remove the existing cases of this usage. Not add new ones. -phil. On 7/20/20, 8:53 AM, Sergey Bylokhov wrote: Firstly, as the issue was observed with JPEG flavor with alpha component, I have tested with regular

Re: [15] RFR : 8249278 : Revert JDK-8226253 which breaks the spec of AccessibleState.SHOWING for JList

11y/8249278/webrev.1> Regards, Ambarish. *From:*Philip Race *Sent:* Wednesday, July 15, 2020 2:00 AM *To:* Ambarish Rapte ; swing-...@openjdk.java.net *Cc:* awt-dev@openjdk.java.net *Subject:* Re: [15] RFR : 8249278 : Revert JDK-8226253 adding swing-dev which is the correct list for this

Re: [15] RFR : 8249278 : Revert JDK-8226253

adding swing-dev which is the correct list for this Swing change. It looks like a faithful backout of https://bugs.openjdk.java.net/browse/JDK-8226253 https://hg.openjdk.java.net/jdk/jdk/rev/3ea8a0c5c264 except that the (c) year is remaining 2020 .. which I think just indicates the silliness of

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

, Philip Race <mailto:philip.r...@oracle.com>> wrote: one more update to the tests cr.openjdk.java.net/~prr/8240654.2/ <http://cr.openjdk.java.net/%7Eprr/8240654.2/> I added @requires vm.gc.Z per the VM folks, ZGC needs Windows Server 2019 or the same vintage Window 10. if

Re: RFR: 8182043 Access to Windows Large Icons

Icon has API that returns size. I was wondering how problematic this is for returning an Icon backed by an MRI But this being a Swing API I suspect the reason for it is so Swing can lay out. So it does not want to know the real icon size in "device" pixels. That would actually be a problem not

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

the GDIWinSD_Unlock via BitBlt. Not sure this code might be affected by this bug or not. BTW I just realized that the test depends on the blit of Swing backbuffer to the window, it does not force usage of "memory->GDI" blit by itself. On 6/11/20 12:05 pm, Philip Race wrote: You

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

(AnyColor, SrcNoEa, AnyInt) sun.java2d.windows.GDIBlitLoops::Blit(IntRgb, SrcNoEa, "GDI") java.awt.Rectangle[x=0,y=0,width=1920,height=1017] -phil On 6/11/2020 11:35 AM, Sergey Bylokhov wrote: On 6/11/20 9:55 am, Philip Race wrote: I have confirmed hit a different code path. It goes through gen

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

it then it is drawn. With the fix everything is fine. -- Kevin On 6/11/2020 10:48 AM, Philip Race wrote: Updated webrev here http://cr.openjdk.java.net/~prr/8240654.1/index.html The only changes are to the tests - to add -Dsun.java2d.uiScale=1 to the onscreen test and to add printer

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

think I would like this fix anyway. We really don't need to lock down the VM in these cases. -phil. On 6/11/20, 9:55 AM, Philip Race wrote: I have confirmed hit a different code path. It goes through generic 2D s/w loops in this case. ie we don't use GDIBlitLoops at all. The code in sun/java2d

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

, Philip Race wrote: Or, maybe we hit a different code path. I'll check that. uiScale=1 is the way to ensure we hit this code path. -phil. On 6/11/20, 7:44 AM, Philip Race wrote: Can I get clarification here. > I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

tch, and everything looks good with the patch. -- Kevin On 6/10/2020 1:48 PM, Philip Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8240654 Webrev: http://cr.openjdk.java.net/~prr/8240654/index.html This is for JDK 15 so review ASAP please since RDP 1 and the test cycle are loom

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

Or, maybe we hit a different code path. I'll check that. uiScale=1 is the way to ensure we hit this code path. -phil. On 6/11/20, 7:44 AM, Philip Race wrote: Can I get clarification here. > I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

now) it doesn’t pass/close the window. Only after I click on Print button and then close print dialog it allows me to click on Pass button. Also how does these tests behave in our internal CI machines? Thanks, Jay On 11-Jun-2020, at 2:18 AM, Philip Race <mailto:philip.r...@oracle.com>> wro

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

printer on this test ? But can't you print to file using Windows built in print to pdf ? Also how does these tests behave in our internal CI machines? The printing one is manual so it is never going to pass there. -phil Thanks, Jay On 11-Jun-2020, at 2:18 AM, Philip Race <mailto:phili

RFR: 8240654 : ZGC can cause severe UI application repaint issues

Bug: https://bugs.openjdk.java.net/browse/JDK-8240654 Webrev: http://cr.openjdk.java.net/~prr/8240654/index.html This is for JDK 15 so review ASAP please since RDP 1 and the test cycle are looming. This is not a fix for a JDK bug. It is a bunch of workarounds for a Microsoft Windows bug

Re: RFR: 8198626: java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac

Hi, I don't see how sometimes not disposing the frame would have caused the failure cited in the bug report. > Execution failed: Applet thread threw exception: java.lang.RuntimeException: robotSema hasn't been triggered Shouldn't we be doing something about that too ? -phil On 5/31/20,

Re: RFR: 8243925 Toolkit#getScreenInsets() returns wrong value on HiDPI screens (Windows)

The whole point is to test a headful config and in any case :- https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Toolkit.html#getScreenInsets(java.awt.GraphicsConfiguration) publicInsets

Project Lana EA build now available at https://jdk.java.net/lanai/ - feedback requested.

The first EA build of Project Lanai is available at https://jdk.java.net/lanai/ This is a new Java2D graphics pipeline for macOS. It can run the usual client demos, such as SwingSet2 and J2Ddemo, and even a large app like an IDE, although not without glitches. The EA download page has a link

Re: RFR: 8243925 Toolkit#getScreenInsets() returns wrong value on HiDPI screens (Windows)

+1 -phil. On 4/29/20, 2:40 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8243925 Fix: http://cr.openjdk.java.net/~serb/8243925/webrev.02 One more place when we return the data in pixels, without proper conversation to

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (client/desktop)

This is all +1 from me. -phil. On 5/6/20, 5:50 PM, Mikael Vidstedt wrote: Sergey/Shura, thank you for the reviews. I reverted the Jemmy changes, and found some additional Sun Studio cleanups. New webrev here: webrev:

Re: 8244292: Headful clients failing with --illegal-access=deny

All looks fine to me. -phil. On 5/4/20, 8:23 AM, Alan Bateman wrote: I ran the headful tests with --illegal-access=deny to shake out any issues in advance of changing the default in the future. There are 4 tests that need their @modules tags updated because the tests access non-public

Re: RFR: 8232744 j.awt.Window::setShape(Shape) paints visible artifacts outside of the given shape

Looks good, you can finalize the CSR. -phil. On 4/29/20, 4:00 PM, Sergey Bylokhov wrote: After the discussion the fix is updated: Bug: https://bugs.openjdk.java.net/browse/JDK-8232744 CSR: https://bugs.openjdk.java.net/browse/JDK-8244156 Fix:

Re: RFR: 8238575 DragSourceEvent.getLocation() returns wrong value on HiDPI screens (Windows)

All looks good to me. -phil On 2/17/20, 3:00 AM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8238575 Fix: http://cr.openjdk.java.net/~serb/8238575/webrev.00 One more place where we forgot to scale of device

Re: RFR: 7185258 [macosx] Deadlock in SunToolKit.realSync()

not block EDT for a long time timeout = XX; } return nativeSyncQueue(timeout); I think that it could be useful to minimize blocking EDT, so decided to merge this part to the current fix: http://cr.openjdk.java.net/~serb/7185258/webrev.02/ On 4/7/20 3:04 pm, Philip

Re: RFR: 8242174 [macos] The NestedModelessDialogTest test make the macOS unstable

+1 from me. -phil On 4/19/20, 7:07 AM, Sergey Bylokhov wrote: On 4/13/20 11:21 pm, Sergey Bylokhov wrote: Looks like a few tests for menu mnemonics started to fail intermittently after this fix, I will double-check the root cause. Had to spend some time analyzing the new test failures, here

Re: RFR: 8232744 j.awt.Window::setShape(Shape) paints visible artifacts outside of the given shape

gt; purposes of this specification are not considered part of the top-level window. -phil. On 4/14/20, 12:55 AM, Sergey Bylokhov wrote: On 4/13/20 8:38 am, Philip Race wrote: we just do not specify what is "AWT-defined window" means and why for example the JDialog/JFileChooser/etc are AWT-defined.

Re: [15] Review request for 8242498: Invalid "sun.awt.TimedWindowEvent" object leads to JVM crash

1594 !env->IsInstanceOf(jOpposite, windowCls)) { I am not entirely sure what this does if windowCls is NULL but the docs don't mention any exceptions :- https://docs.oracle.com/en/java/javase/14/docs/specs/jni/functions.html#isinstanceof So I think it will just return false -

Re: RFR: 8232744 j.awt.Window::setShape(Shape) paints visible artifacts outside of the given shape

On 4/8/20, 7:53 PM, Sergey Bylokhov wrote: On 4/8/20 5:36 pm, Philip Race wrote: I have never seen "AWT-defined window" term, I assume we never used it before is it clear enough? Usually, we use "Top level window" which will cover AWT and Swing. But the poin

Re: RFR: 8240290 Clean the "libawt_xawt" library from code for macOS and headless mode

to prevent runtime link errors I thought that the purpose .. I extracted it to the separate bug https://bugs.openjdk.java.net/browse/JDK-8242559 -phil. On 4/7/20, 3:20 PM, Philip Race wrote: This fix is conflating two things 1) removing the macos references 2) making the build fail

Re: RFR: 8232744 j.awt.Window::setShape(Shape) paints visible artifacts outside of the given shape

On 4/8/20, 5:27 PM, Sergey Bylokhov wrote: On 4/8/20 5:14 pm, Philip Race wrote: I was trying to make it flow better and avoid some repetition I did not think it necessary to enumerate subclasses> What motivates you to include "behavior" ? To cover cases like ani

Re: RFR: 8232744 j.awt.Window::setShape(Shape) paints visible artifacts outside of the given shape

PM, Sergey Bylokhov wrote: On 4/6/20 12:24 pm, Philip Race wrote: If we have to add anything I prefer the following : Visual effects such as halos, shadows, motion effects and animations may be added by the desktop and affect the actual or perceived position, dimensions or shape of

Re: RFR: 8240290 Clean the "libawt_xawt" library from code for macOS and headless mode

PS meaning do (1) first, and revisit (2) later. And I am not sure (2) is - or was always an error. The code can use these fns as stubs to prevent runtime link errors I thought that the purpose .. -phil. On 4/7/20, 3:20 PM, Philip Race wrote: This fix is conflating two things 1) removing

Re: RFR: 8240290 Clean the "libawt_xawt" library from code for macOS and headless mode

This fix is conflating two things 1) removing the macos references 2) making the build fail if they are used in a headless build I'd prefer to see these unrelated fixes separated -phil. On 3/2/20, 3:36 AM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk/client. Bug:

Re: RFR: 8239819 XToolkit: Misread of screen information memory

So the code is correct, and just your comment wrong ? +1 if I understand you correctly. -phil. On 3/15/20, 8:50 PM, Sergey Bylokhov wrote: On 3/14/20 6:50 pm, Philip Race wrote: + params.add(BORDER_PIXEL, Long.valueOf(0)); ? Why do we need to set it at all if its invisible ? And does

Re: RFR: 7185258 [macosx] Deadlock in SunToolKit.realSync()

There were previous attempts to fix this on mac : https://mail.openjdk.java.net/pipermail/awt-dev/2013-December/006719.html https://mail.openjdk.java.net/pipermail/awt-dev/2014-January/006809.html https://mail.openjdk.java.net/pipermail/awt-dev/2014-February/007047.html which you reviewed. Can

Re: RFR: 8196019 java/awt/Window/Grab/GrabTest.java fails on Windows

+1 -phil On 4/6/20, 5:20 AM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8196019 Fix: http://cr.openjdk.java.net/~serb/8196019/webrev.00 Two issues were fixed: - On Windows, the mouse may click on the minimize/maximize

Re: RFR: 8232744 j.awt.Window::setShape(Shape) paints visible artifacts outside of the given shape

This is just common sense. I am shocked we need to document it. The shape of the window is the shape we defined, the rest is window manager decoration. The existing text "Only the parts that belong to the given Shape remain visible and clickable" seems adequate to me. I don't suppose the

Re: RFR: 8241797 Add some tests to the problem list

OK I guess if you are seeing them fail .. although I don't recall seeing any of these fail in any of the last few weeks of nightly testing. How often do you think these fail ? -phil. On 3/30/20, 3:12 AM, Jayathirth D v wrote: Looks good to me. Thanks, Jay On 30-Mar-2020, at 3:39 PM, Sergey

Re: RFR: 7131400 [macosx] Desktop.edit(a directory) should throw IOException

One might consider what is happening on mac to be the preferred behaviour for edit() I am not sure I would consider this a bug to open finder on a folder. How would you be able to achieve that after this change ? Can't we open Explorer on Windows to align behaviour ? The print() case it seems

Re: RFR: 8239819 XToolkit: Misread of screen information memory

So the net result is hard-coding +params.add(BORDER_PIXEL, Long.valueOf(0)); ? Why do we need to set it at all if its invisible ? And does that mean its hidden / overwritten or something else. Also the code says BORDER, but below you wrote BACKGROUND. Please clarify. -phil.

RFR: 8240977: ProblemList failing jtreg tests on macos

https://bugs.openjdk.java.net/browse/JDK-8240977 Adding just one test that fails way too often :- diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -121,6 +121,7 @@

Re: RFR: 8226806 [macOS 10.14] Methods of Java Robot should be called from appropriate thread

Looks fine. -phil On 3/12/20, 5:14 PM, Sergey Bylokhov wrote: Any volunteers to review? This could be a reason of test instability. On 3/5/20 12:52 am, Sergey Bylokhov wrote: Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8226806 Fix:

Re: RFR: 8219578 No associated icon for the leaf node of Jtree

OK. CSR is reviewed. -phil. On 3/4/20, 5:37 PM, Sergey Bylokhov wrote: webrev and CSR are updated: Fix: http://cr.openjdk.java.net/~serb/8219578/webrev.01 CSR: https://bugs.openjdk.java.net/browse/JDK-8240554 On 3/4/20 5:07 pm, Philip Race wrote: I suggest changing + * The documentation

Re: RFR: 8219578 No associated icon for the leaf node of Jtree

I suggest changing + * The documentation in this module includes links to overviews, tutorials, + * examples, guides, and other documentation. This is done for convenience. + * Information at these external resources is not part of JavaSE API + * Specification. to + * The documentation in this

Re: RFR: 8176040 Documentation of java.awt.Rectangle.add(java.awt.Point) is wrong.

Or add(p, new Dimension(1,1)); which might be a better option in the 2nd case. -phil. On 3/2/20, 10:21 AM, Sergey Bylokhov wrote: Looks fine. On 3/2/20 10:11 am, Alexander Zuev wrote: Hello! Please review fix for the jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8176040

Re: [15] Review Request: 8237222 [macos] java/awt/Focus/UnaccessibleChoice/AccessibleChoiceTest.java fails

+1 -phil On 1/30/20, 6:03 AM, Tejpal Rebari wrote: Looks good to me. Regards, Tejpal On 24-Jan-2020, at 3:05 PM, Sergey Bylokhov wrote: Hello. Please review the fix for JDK 15. Bug: https://bugs.openjdk.java.net/browse/JDK-8237222 Fix: http://cr.openjdk.java.net/~serb/8237222/webrev.00

RFR: 823872: Add failing client jtreg tests to the Problem List

Bug: https://bugs.openjdk.java.net/browse/JDK-8238721 Webrev : http://cr.openjdk.java.net/~prr/8238721/ -phil.

Re: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS

That didn't answer all my questions, at least not in a way that I can understand. How is this useful given that we disable jtreg failure handlers for the headful tests ? -phil. On 12/30/19, 11:33 AM, Sergey Bylokhov wrote: On 12/23/19 9:15 pm, Phil Race wrote: I am not sure what the right

Re: [14] Review Request: 8232226 [macos 10.15] test/jdk/java/awt/color/EqualityTest/EqualityTest.java may fail

+1 -phil On 12/4/19, 7:34 PM, Sergey Bylokhov wrote: Any volunteers to review? =) On 10/17/19 11:23 pm, Sergey Bylokhov wrote: Hello. Please review the fix for JDK 14. Bug: https://bugs.openjdk.java.net/browse/JDK-8232226 Fix: http://cr.openjdk.java.net/~serb/8232226/webrev.00 This test

Re: [14] Review Request: 8234137 The "AutoTestOnTop.java" test may run external applications

+1 -phil On 12/4/19, 7:29 PM, Sergey Bylokhov wrote: Any volunteers to review? =) On 11/17/19 10:18 pm, Sergey Bylokhov wrote: Hello. Please review the fix for JDK 14. Bug: https://bugs.openjdk.java.net/browse/JDK-8234137 Fix: http://cr.openjdk.java.net/~serb/8234137/webrev.03 A few issues

Re: [14] Review Request: 8231438 [macos] The dark mode is not supported yet

# If no value is set then light mode will be used # if "system" value is set then the current appearance of the macOS will be used # Other possible values are "NSAppearanceNameAqua", "NSAppearanceNameDarkAqua": see What happens if a value is set but it is none of the above ? The spec. should

Re: [14] Review Request: 8231438 [macos] The dark mode is not supported yet

Approved. -phil On 12/3/19, 11:46 AM, Sergey Bylokhov wrote: On 12/3/19 12:21 am, Prasanta Sadhukhan wrote: Fix looks ok to me but if dark mode is not being supported, why do we need to update the test to work on dark mode? I think we need to have some test to check if jdk returns

Re: [14] Review Request: 8185041 Incorrect GPL header in pnglibconf.h

+1 -phil. On 10/7/19, 12:16 PM, Sergey Bylokhov wrote: Hello. Please review the fix for JDK 14. Bug: https://bugs.openjdk.java.net/browse/JDK-8185041 Fix: http://cr.openjdk.java.net/~serb/8185041/webrev.00 The file header has been updated and formatted as other files of libpng library.

Re: [14] RFR JDK-8234786: Fix for JDK-8214578 breaks OS X 10.12 compatibility

+1 -phil On 11/25/19, 9:25 PM, Prasanta Sadhukhan wrote: Hi All, Please review a fix for a compatibility issue introduced in JDK-8214578 where a type alias NSTextInputSourceIdentifier is used which is only present from osx10.13 onwards thereby breaking compatibility with osx10.12. Fix is

Re: [14] RFR JDK-8233696:[TESTBUG]Some jtreg tests fail when CAPS_LOCK is ON

It would at least be nice if tests could report : expected "a", got "A" .. as that will be a helpful clue if we get more such failures. -phil. On 11/14/19 1:25 AM, Jayathirth D V wrote: Hi Sergey, Thanks for the clarification. If test behavior has to be that it should fail when CAPS_LOCK is

Re: RFC: JDK-8231991: Mouse wheel change focus on awt/swing windows

OK. The incremental fix looks reasonable to me and the testing I've done is promising. We are currently getting a very large number of failures (not just the tests we pointed out) so let's get this pushed ASAP. -phil. On 11/13/19 1:39 PM, Philip Race wrote: Hi, I'll also apply

Re: [14] Review Request: 8232433 [macos 10.15] java/awt/Window/LocationAtScreenCorner/LocationAtScreenCorner.java may fail

It looks reasonable, but we can be surprised .. if you have run all headful tests on macos that might signal a problem then +1 ... -phil. On 10/18/19, 5:10 PM, Sergey Bylokhov wrote: Hello. Please review the fix for JDK 14. Bug: https://bugs.openjdk.java.net/browse/JDK-8232433 Fix:

Re: RFC: JDK-8231991: Mouse wheel change focus on awt/swing windows

Hi, I'll also apply this and submit a job to our test system. -phil. On 11/13/19, 12:46 PM, Mario Torre wrote: Hi Phil, Ok, I got it and I feel very stupid now. The issue was indeed in my original patch, two problems in fact, and I really don't know how I made this mistake let alone made it

Re: [14] Review Request: 8233657 Intermittent NPE in Component.validate()

OK .. +1 -phil. On 11/7/19, 1:02 PM, Sergey Bylokhov wrote: On 11/7/19 6:29 am, Philip Race wrote: The fix seems fine but if the app isn't setting null how are we getting null here ? We get null here only if the test/app sets the null value, in which case this null value will be ignored

Re: [14] Review Request: 8233657 Intermittent NPE in Component.validate()

The fix seems fine but if the app isn't setting null how are we getting null here ? Frequent hierarchy validation does not in itself explain that to me. -phil. On 11/6/19, 2:48 PM, Sergey Bylokhov wrote: Hello. Please review the fix for JDK 14. Bug:

  1   2   3   >