From michael.x.mcmahon at oracle.com Wed Feb 1 00:40:34 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 01 Feb 2012 08:40:34 +0000 Subject: Code Review Request: 7141413: [macosx] Regression test java/rmi/registry/readTest/readTest.sh failing on Mac OS X In-Reply-To: <4F28440D.3040904@oracle.com> References: <4F28440D.3040904@oracle.com> Message-ID: <4F28FA82.7070703@oracle.com> On 31/01/12 19:42, Kurchi Hazra wrote: > > Hi, > > This fix updates readTest.sh file to recognize Mac OS (Darwin) as a > valid platform. > > > Bug :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141413 > > Webrev :http://cr.openjdk.java.net/~khazra/7141413/webrev.00/ > > > Thanks, > Kurchi > > > > > Looks fine. Thanks Michael. From anton.tarasov at oracle.com Wed Feb 1 01:06:09 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 01 Feb 2012 13:06:09 +0400 Subject: [7u-osx] Request for approval for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner Message-ID: <4F290081.2060704@oracle.com> Hello, A request to push the changes to jdk7u-osx. Reviewed on macosx-port-dev by Anthony Petrov, Artem Ananiev. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129732 Webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002665.html Thanks, Anton. From artem.ananiev at oracle.com Wed Feb 1 01:11:24 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 01 Feb 2012 13:11:24 +0400 Subject: [7u-osx] Request for approval for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner In-Reply-To: <4F290081.2060704@oracle.com> References: <4F290081.2060704@oracle.com> Message-ID: <4F2901BC.5050703@oracle.com> Approved. On 2/1/2012 1:06 PM, Anton V. Tarasov wrote: > Hello, > > A request to push the changes to jdk7u-osx. > Reviewed on macosx-port-dev by Anthony Petrov, Artem Ananiev. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129732 > Webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002665.html > > > Thanks, > Anton. From anton.tarasov at sun.com Wed Feb 1 01:10:02 2012 From: anton.tarasov at sun.com (anton.tarasov at sun.com) Date: Wed, 01 Feb 2012 09:10:02 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7129825: [macosx] Native activation is not changed when focusing other frame's owned window Message-ID: <20120201091022.B7979472CB@hg.openjdk.java.net> Changeset: bdf67b76a4f0 Author: ant Date: 2012-02-01 16:09 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/bdf67b76a4f0 7129825: [macosx] Native activation is not changed when focusing other frame's owned window Reviewed-by: art, dcherepanov ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWKeyboardFocusManagerPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CWrapper.m ! src/macosx/native/sun/awt/LWCToolkit.m From dmitry.cherepanov at oracle.com Wed Feb 1 02:21:42 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Wed, 01 Feb 2012 13:21:42 +0300 Subject: [7u-osx] Request for approval for 7131793: [macosx] some cleanup in OGL pipeline code In-Reply-To: <4F2668F0.4030703@oracle.com> References: <4F2668F0.4030703@oracle.com> Message-ID: <4F291236.4040104@oracle.com> Here's the new request after additional review. CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131793 Webrev: http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.3 Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002537.html Thanks, Dmitry Dmitry Cherepanov wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131793 > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.2 > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002537.html > > > Thanks, > Dmitry > From michael.x.mcmahon at oracle.com Wed Feb 1 01:19:24 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 01 Feb 2012 09:19:24 +0000 Subject: Code Review Request: 7141465:[macosx] com/sun/jdi/PrivateTransportTest.sh fails on Mac OS X In-Reply-To: <4F286045.6060609@oracle.com> References: <4F2851BB.1030902@oracle.com> <4F285587.8040706@oracle.com> <4F286045.6060609@oracle.com> Message-ID: <4F29039C.9070401@oracle.com> Looks fine. We can re-factor that code some time later. But, for today that will do fine. Thanks Michael On 31/01/12 21:42, Kurchi Hazra wrote: > Right, I did not need to change jreloc at all. Updated webrev: > > http://cr.openjdk.java.net/~khazra/7141465/webrev.02 > > > - Kurchi > > > > On 1/31/2012 1:22 PM, Scott Kovatch wrote: >> On Jan 31, 2012, at 12:56 PM, Alan Bateman wrote: >> >>> On 31/01/2012 20:40, Kurchi Hazra wrote: >>>> Hi, >>>> >>>> This fix updates com/sun/jdi/PrivateTransportTest.sh file to run on >>>> Mac OS (Darwin). >>>> >>>> >>>> Bug :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141465 >>>> >>>> Webrev :http://cr.openjdk.java.net/~khazra/7141465/webrev.00/ >>> I'mnot sure that ${TESTJAVA}/j2sdk-image/1.7.0.jdk/Contents/Home/jre >>> is right, shouldn't TESTJAVA point to the Home directory? The rest >>> of it looks okay to me. >> This will break, eventually. We need to adjust the build so the >> bundled JDK is built to j2sdk-bundles, and j2sdk-image remains stable >> throughout the build. It will also break if the name of the bundle >> changes, which is also planned. See 7133768 and 7128699, respectively. >> >> -- Scott K. >> > From michael.x.mcmahon at oracle.com Wed Feb 1 01:36:35 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 01 Feb 2012 09:36:35 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 2 new changesets Message-ID: <20120201093655.E0999472CC@hg.openjdk.java.net> Changeset: 3802c2440dd2 Author: michaelm Date: 2012-02-01 01:35 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/3802c2440dd2 7141071: TEST_BUG: update shell scripts in java/nio/charset to detect Mac OS as a valid platform Reviewed-by: alanb, michaelm ! test/java/nio/charset/coders/CheckSJISMappingProp.sh ! test/java/nio/charset/spi/basic.sh Changeset: 25c4d6676efa Author: michaelm Date: 2012-02-01 01:37 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/25c4d6676efa Merge From michael.x.mcmahon at oracle.com Wed Feb 1 01:40:03 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 01 Feb 2012 09:40:03 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7141413: [macosx] Regression test java/rmi/registry/readTest/readTest.sh failing on Mac OS X Message-ID: <20120201094013.9FD12472CD@hg.openjdk.java.net> Changeset: 5b524b43fdd1 Author: khazra Date: 2012-02-01 01:41 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5b524b43fdd1 7141413: [macosx] Regression test java/rmi/registry/readTest/readTest.sh failing on Mac OS X Reviewed-by: alanb, michaelm ! test/java/rmi/registry/readTest/readTest.sh From michael.x.mcmahon at oracle.com Wed Feb 1 02:01:40 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 01 Feb 2012 10:01:40 +0000 Subject: 7141462: ProblemList.txt updates to exclude tests that cause test runs to hang [macosx] In-Reply-To: <4F28541A.6080004@oracle.com> References: <4F28541A.6080004@oracle.com> Message-ID: <4F290D84.1090200@oracle.com> On 31/01/12 20:50, Alan Bateman wrote: > > Currently it's not possible to run some of the test targets that run > the tests in agentvm mode, in particular the jdk_util and jdk_nio make > file targets can cause jtreg to hang. I've looked briefly into these > issues and see that there are at least three separate issues: > > 1. Asynchronous close of FileChannel operations as this is not fully > implemented on Mac, in particular dup2 will hang if another thread is > doing a blocking operation > > 2. A rouge test spins doing System.gc (this test is fixed in jdk8, > just not back-ported jdk7u). > > 3. A strange hang loading libawt when > Class.forName("") triggers the load. > > In order to make some progress I would like the test that cause these > issues to the ProblemList. All it means is that they excluded when > running the tests via the Makefile. The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/7141462/webrev/ > > Thanks, > Alan. > > So, these tests relate to issues 1. and 2. above, and we still need to resolve 3 ? This change looks fine. Thanks Michael. From artem.ananiev at oracle.com Wed Feb 1 02:15:36 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 01 Feb 2012 14:15:36 +0400 Subject: [7u-osx] Request for approval for 7131793: [macosx] some cleanup in OGL pipeline code In-Reply-To: <4F291236.4040104@oracle.com> References: <4F2668F0.4030703@oracle.com> <4F291236.4040104@oracle.com> Message-ID: <4F2910C8.9060606@oracle.com> Approved. On 2/1/2012 2:21 PM, Dmitry Cherepanov wrote: > Here's the new request after additional review. > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131793 > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.3 > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002537.html > > > Thanks, > Dmitry > > Dmitry Cherepanov wrote: >> This is a request to push the following fix to jdk7u-osx: >> >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131793 >> >> Webrev: http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.2 >> >> Technical review: >> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002537.html >> >> >> Thanks, >> Dmitry >> > From artem.ananiev at oracle.com Wed Feb 1 02:18:35 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 01 Feb 2012 14:18:35 +0400 Subject: [7u-osx] Request for approval for 7122250: [macosx] mouseMoved Events test do not respond in JCK-runtime-7 interactive In-Reply-To: <4F281E5E.3020204@oracle.com> References: <4F281E5E.3020204@oracle.com> Message-ID: <4F29117B.2010302@oracle.com> Approved. On 1/31/2012 9:01 PM, Anthony Petrov wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122250 > > http://cr.openjdk.java.net/~anthony/x-13-mouseEnterExit-7122250.0/ > > Technical review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002671.html > > > -- > best regards, > Anthony > > From dmitry.cherepanov at oracle.com Wed Feb 1 02:31:32 2012 From: dmitry.cherepanov at oracle.com (dmitry.cherepanov at oracle.com) Date: Wed, 01 Feb 2012 10:31:32 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7131793: [macosx] some cleanup in OGL pipeline code Message-ID: <20120201103320.103B6472CF@hg.openjdk.java.net> Changeset: ec8c141b4c28 Author: dcherepanov Date: 2012-02-01 14:31 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/ec8c141b4c28 7131793: [macosx] some cleanup in OGL pipeline code Reviewed-by: swingler, art ! make/sun/lwawt/Makefile ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.h ! src/macosx/native/sun/java2d/opengl/CGLLayer.h ! src/macosx/native/sun/java2d/opengl/CGLLayer.m ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.h ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m ! src/share/native/sun/java2d/opengl/OGLSurfaceData.c ! src/share/native/sun/java2d/opengl/OGLSurfaceData.h From Alan.Bateman at oracle.com Wed Feb 1 02:38:53 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 Feb 2012 10:38:53 +0000 Subject: 7141462: ProblemList.txt updates to exclude tests that cause test runs to hang [macosx] In-Reply-To: <4F290D84.1090200@oracle.com> References: <4F28541A.6080004@oracle.com> <4F290D84.1090200@oracle.com> Message-ID: <4F29163D.40708@oracle.com> On 01/02/2012 10:01, Michael McMahon wrote: > > So, these tests relate to issues 1. and 2. above, and we still need to > resolve 3 ? > > This change looks fine. Yes, the four libs tests that are excluded by the patch is necessary as otherwise we can't run the tests via the make file (testing in JPRT will hang, etc.). Once the Mac changes are in jdk7u-dev then I think we have consider back-porting the Makefile changes that switch the testing to use agentvm mode. I'm not sure what to say about the AWT hang as it impacts test in random areas (jdk_util and jdk_misc batches for example). Many of us will run the tests on machines that we've ssh'ed into and this seems to be part of the issue. I would be interested in hear from the client folks as to what this is about and whether AWT_TOOLKIT=XToolkit is an effective workaround. -Alan. From anton.tarasov at sun.com Wed Feb 1 02:51:09 2012 From: anton.tarasov at sun.com (anton.tarasov at sun.com) Date: Wed, 01 Feb 2012 10:51:09 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7129732: [macosx] JCK failure: no focus transfer back to Window owner Message-ID: <20120201105121.8907A472D0@hg.openjdk.java.net> Changeset: a7595ca81597 Author: ant Date: 2012-02-01 17:50 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/a7595ca81597 7129732: [macosx] JCK failure: no focus transfer back to Window owner Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWWindowPeer.java From alexander.potochkin at sun.com Wed Feb 1 03:02:04 2012 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Wed, 01 Feb 2012 11:02:04 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124387: [macosx] Application freezes on dispose window, created by JFileChooser Message-ID: <20120201110223.59080472D1@hg.openjdk.java.net> Changeset: e9811708169f Author: alexp Date: 2012-02-01 15:25 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/e9811708169f 7124387: [macosx] Application freezes on dispose window, created by JFileChooser Reviewed-by: art ! test/javax/swing/JFileChooser/6489130/bug6489130.java From Alan.Bateman at oracle.com Wed Feb 1 03:03:12 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 Feb 2012 11:03:12 +0000 Subject: [7u-osx] Request for approval for 7141462: ProblemList.txt updates to exclude tests that cause test runs to hang [macosx] Message-ID: <4F291BF0.2070101@oracle.com> This is a request to push to the jdk7u/jdk7u-osx forest. CR: http://bugs.sun.com/view_bug.do?bug_id=7141462 (This hasn't shown up on bugs.sun.com yet but in summary this patch just adds a few tests to the problem list so that they are excluded when running the tests via the Makefile. This is necessary because in jdk7u these tests are run in samevm mode. The underlying issue for 3 of the tests is asynchronous close of FileChannel when threads are doing certain I/O operations on the channel, something that Apple's JDK6 suffers from too. The logging test is just a crazy test that run System.gc in a loop. It has been fixed in jdk8). Webrev: http://cr.openjdk.java.net/~alanb/7141462/webrev/ Reviewed-by: michaelm Thanks, Alan. From alexander.potochkin at sun.com Wed Feb 1 03:08:59 2012 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Wed, 01 Feb 2012 11:08:59 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124393: [macosx] JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click Message-ID: <20120201110917.A5BE4472D2@hg.openjdk.java.net> Changeset: d42b52b9b7f2 Author: alexp Date: 2012-02-01 15:32 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d42b52b9b7f2 7124393: [macosx] JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click Reviewed-by: anthony ! test/javax/swing/AbstractButton/6711682/bug6711682.java From alexander.potochkin at sun.com Wed Feb 1 03:15:23 2012 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Wed, 01 Feb 2012 11:15:23 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7130360: [macosx] Packed JInternalFrame invisible on Aqua L&F Message-ID: <20120201111533.6C44F472D3@hg.openjdk.java.net> Changeset: e2101806cb45 Author: alexp Date: 2012-02-01 15:38 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/e2101806cb45 7130360: [macosx] Packed JInternalFrame invisible on Aqua L&F Reviewed-by: anthony ! src/macosx/classes/com/apple/laf/AquaInternalFrameUI.java From michael.x.mcmahon at oracle.com Wed Feb 1 03:17:54 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 01 Feb 2012 11:17:54 +0000 Subject: Heads-up: Pushing jdk7u-osx to jdk7u-dev Message-ID: <4F291F62.6020002@oracle.com> Hello, This is a heads-up to let you know that the jdk7u-osx forest is being pushed to jdk7u-dev later today. From that point, it is expected that all remaining/future work on the Mac OS port for jdk7u4 will happen through jdk7u-dev (until it forks to a 7u4 specific forest). I imagine we'll continue to use this mail list for Mac specific porting issues, but changes will have to be discussed/approved via jdk7u-dev at openjdk.java.net as well. Thanks, Michael. From michael.x.mcmahon at oracle.com Wed Feb 1 03:56:42 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 01 Feb 2012 11:56:42 +0000 Subject: RFR: 7141675 Fix jcheck issues in .m sources Message-ID: <4F29287A.3040203@oracle.com> This change is just to fix some white-space/tab problems that crept into some objective C files whose filename (extension .m) is not currently known to jcheck. http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/ There is nothing to see in the webrev as white-space diferences are ignored. But the patch shows the actual changes. Thanks Michael. From michael.x.mcmahon at oracle.com Wed Feb 1 04:10:19 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 01 Feb 2012 12:10:19 +0000 Subject: [jdk7u-osx] Request for approval for CR 7141465: [macosx] com/sun/jdi/PrivateTransportTest.sh fails on Mac OS X Message-ID: <4F292BAB.1090101@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141465 Webrev: http://cr.openjdk.java.net/~khazra/7141465/webrev.02 Author: khazra Reviewed by: michaelm, skovatch Thanks, Michael. From anthony.petrov at oracle.com Wed Feb 1 04:17:17 2012 From: anthony.petrov at oracle.com (anthony.petrov at oracle.com) Date: Wed, 01 Feb 2012 12:17:17 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7122250: [macosx] mouseMoved Events test do not respond in JCK-runtime-7 interactive Message-ID: <20120201121727.82C91472D4@hg.openjdk.java.net> Changeset: 8f038c7954a4 Author: anthony Date: 2012-02-01 16:16 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/8f038c7954a4 7122250: [macosx] mouseMoved Events test do not respond in JCK-runtime-7 interactive Summary: Override AWTView -updateTrackingAreas Reviewed-by: alexp, kizune ! src/macosx/native/sun/awt/AWTView.m From paul.hohensee at oracle.com Wed Feb 1 04:22:04 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 01 Feb 2012 07:22:04 -0500 Subject: [7u-osx] Request for approval for 7141462: ProblemList.txt updates to exclude tests that cause test runs to hang [macosx] In-Reply-To: <4F291BF0.2070101@oracle.com> References: <4F291BF0.2070101@oracle.com> Message-ID: <4F292E6C.9080808@oracle.com> Approved. Paul On 2/1/12 6:03 AM, Alan Bateman wrote: > > This is a request to push to the jdk7u/jdk7u-osx forest. > > CR: http://bugs.sun.com/view_bug.do?bug_id=7141462 > > (This hasn't shown up on bugs.sun.com yet but in summary this patch > just adds a few tests to the problem list so that they are excluded > when running the tests via the Makefile. This is necessary because in > jdk7u these tests are run in samevm mode. The underlying issue for 3 > of the tests is asynchronous close of FileChannel when threads are > doing certain I/O operations on the channel, something that Apple's > JDK6 suffers from too. The logging test is just a crazy test that run > System.gc in a loop. It has been fixed in jdk8). > > Webrev: http://cr.openjdk.java.net/~alanb/7141462/webrev/ > > Reviewed-by: michaelm > > Thanks, > Alan. From anthony.petrov at oracle.com Wed Feb 1 04:25:26 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 01 Feb 2012 16:25:26 +0400 Subject: RFR: 7141675 Fix jcheck issues in .m sources In-Reply-To: <4F29287A.3040203@oracle.com> References: <4F29287A.3040203@oracle.com> Message-ID: <4F292F36.1090204@oracle.com> Hi Michael, The patch looks fine to me. It would be great to update jcheck as well so that the formatting requirements be enforced for further putbacks. -- best regards, Anthony On 2/1/2012 3:56 PM, Michael McMahon wrote: > This change is just to fix some white-space/tab problems that crept into > some objective C files whose filename (extension .m) is not currently > known to jcheck. > > http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/ > > There is nothing to see in the webrev as white-space diferences are > ignored. > But the patch shows the actual changes. > > Thanks > Michael. From alan.bateman at oracle.com Wed Feb 1 04:27:46 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 01 Feb 2012 12:27:46 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7141462: ProblemList.txt updates to exclude tests that cause test runs to hang [macosx] Message-ID: <20120201122756.ED27D472D5@hg.openjdk.java.net> Changeset: 9824fb300575 Author: alanb Date: 2012-02-01 12:27 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/9824fb300575 7141462: ProblemList.txt updates to exclude tests that cause test runs to hang [macosx] Reviewed-by: michaelm ! test/ProblemList.txt From michael.x.mcmahon at oracle.com Wed Feb 1 04:28:01 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 01 Feb 2012 12:28:01 +0000 Subject: [jdk7u-osx] Request for approval for CR 7141675 Fix jcheck issues in .m sources Message-ID: <4F292FD1.7070701@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141475 Webrev: http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/ Reviewed by: anthony Thanks, Michael. From paul.hohensee at oracle.com Wed Feb 1 04:36:24 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 01 Feb 2012 07:36:24 -0500 Subject: [jdk7u-osx] Request for approval for CR 7141465: [macosx] com/sun/jdi/PrivateTransportTest.sh fails on Mac OS X In-Reply-To: <4F292BAB.1090101@oracle.com> References: <4F292BAB.1090101@oracle.com> Message-ID: <4F2931C8.9010609@oracle.com> Approved. Paul On 2/1/12 7:10 AM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141465 > > Webrev: http://cr.openjdk.java.net/~khazra/7141465/webrev.02 > > Author: khazra > > Reviewed by: michaelm, skovatch > > Thanks, > Michael. From paul.hohensee at oracle.com Wed Feb 1 04:39:29 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 01 Feb 2012 07:39:29 -0500 Subject: [jdk7u-osx] Request for approval for CR 7141675 Fix jcheck issues in .m sources In-Reply-To: <4F292FD1.7070701@oracle.com> References: <4F292FD1.7070701@oracle.com> Message-ID: <4F293281.5050706@oracle.com> Approved. Paul On 2/1/12 7:28 AM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141475 > > Webrev: http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/ > > Reviewed by: anthony > > Thanks, > Michael. From michael.x.mcmahon at oracle.com Wed Feb 1 04:44:11 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 01 Feb 2012 12:44:11 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 2 new changesets Message-ID: <20120201124432.60200472D6@hg.openjdk.java.net> Changeset: 391dafd30fba Author: khazra Date: 2012-02-01 04:43 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/391dafd30fba 7141465: macosx] com/sun/jdi/PrivateTransportTest.sh fails on Mac OS X Reviewed-by: michaelm ! test/com/sun/jdi/PrivateTransportTest.sh Changeset: f977c4806f4c Author: michaelm Date: 2012-02-01 04:45 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/f977c4806f4c Merge From michael.x.mcmahon at oracle.com Wed Feb 1 04:54:33 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 01 Feb 2012 12:54:33 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7141675: Fix jcheck issues in .m sources Message-ID: <20120201125444.2C79B472D7@hg.openjdk.java.net> Changeset: 8878d25cce64 Author: michaelm Date: 2012-02-01 04:55 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/8878d25cce64 7141675: Fix jcheck issues in .m sources Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTEvent.m ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CDragSource.m ! src/macosx/native/sun/awt/CDropTarget.m ! src/macosx/native/sun/awt/CTrayIcon.m ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/awt/awt.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m ! src/macosx/native/sun/osxapp/NSApplicationAWT.m ! src/macosx/native/sun/osxapp/PropertiesUtilities.m ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m ! src/macosx/native/sun/osxapp/ThreadUtilities.m From sergey.bylokhov at oracle.com Wed Feb 1 05:02:56 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 01 Feb 2012 17:02:56 +0400 Subject: Request for review: 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails Message-ID: <4F293800.1020701@oracle.com> Hi Everyone, Peers shouldn't accumulate an alpha after repainting, so clearRect was added. And now we call setVisible for window after full initialization. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 Webrev can be found at: http://cr.openjdk.java.net/~serb/7131367/webrev.00/ -- Best regards, Sergey. From weijun.wang at oracle.com Wed Feb 1 05:32:47 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 01 Feb 2012 21:32:47 +0800 Subject: RFR: 7141675 Fix jcheck issues in .m sources In-Reply-To: <4F292F36.1090204@oracle.com> References: <4F29287A.3040203@oracle.com> <4F292F36.1090204@oracle.com> Message-ID: <4F293EFF.9050305@oracle.com> I'm wondering if jcheck is updated to include these .m files, will it reject the old changesets where the .m files contain trailing whitespaces? Or, should those changesets be added into the whitelist? Thanks Max On 02/01/2012 08:25 PM, Anthony Petrov wrote: > Hi Michael, > > The patch looks fine to me. It would be great to update jcheck as well > so that the formatting requirements be enforced for further putbacks. > > -- > best regards, > Anthony > > On 2/1/2012 3:56 PM, Michael McMahon wrote: >> This change is just to fix some white-space/tab problems that crept into >> some objective C files whose filename (extension .m) is not currently >> known to jcheck. >> >> http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/ >> >> There is nothing to see in the webrev as white-space diferences are >> ignored. >> But the patch shows the actual changes. >> >> Thanks >> Michael. From greg.x.brown at oracle.com Wed Feb 1 05:45:45 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 1 Feb 2012 08:45:45 -0500 Subject: Bundled app launcher changes In-Reply-To: <9B09FE7E-34D0-4BC4-A679-AB4F507C8062@apple.com> References: <01238DD0-65D6-42A5-A69F-E2DCE6B93776@oracle.com> <9B09FE7E-34D0-4BC4-A679-AB4F507C8062@apple.com> Message-ID: <2EE53971-1069-4A0E-9708-702CA2741902@oracle.com> > The "runtime" should only be specified if you are providing a full path to a different one. The "runtime" property is optional. If you don't specify it, the launcher stub will look for a shared JRE. Otherwise, the runtime you specify will be copied into the app bundle. > Also, there should be a way to specify if you only want to bundle the JRE, or if you need a full JDK. This will change the output tag in the Info.plist, and will change what is copied from what location. You can specify either a JRE or a JDK. > There should be a way to add a number of jars to the classpath, which will implicitly get copied into (bundle)/Contents/Java. Is that just by adding more tags? Yes. > Should there be an affordance for specifying non-jar/non-classpath resources that should also get copied into (bundle)/Contents/Java? I didn't think so. Java resources are generally pulled from the classpath - a Java app wouldn't usually be aware that it is running in a bundle so it wouldn't have a way to get to those resources. > I'm also not wild about the tag name . That may be ambiguous with some sort of jar coalescing. Perhaps , or . Any other suggestions? I chose "bundlejars" because the primary purpose of the task is to take a set of JARs and wrap them in an app bundle. I'm not opposed to the other suggestions, but I think "bundlejars" is appropriate. If we had to change, I think I'd prefer "bundleapp" to "createapp". The tool itself is currently called "JAR Bundler", so the task becomes "bundlejars". "bundleapp" implies that the tool should be named App Bundler, which is OK, but "createapp" -> App Creator doesn't seem appropriate. > I know you can't support this on non-Mac builders, but you should definitely plan to provide a codesigncert= argument which will sign the primary stub executable with a provided certificate. This will be Very Important to some developers. I agree. I have been thinking about that and wondering how we might support it. Any suggestions would be much appreciated. G From greg.x.brown at oracle.com Wed Feb 1 05:53:21 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 1 Feb 2012 08:53:21 -0500 Subject: Bundled app launcher changes In-Reply-To: <680DB46D-50E4-4E8C-9672-9F5E6AB2B662@gmail.com> References: <01238DD0-65D6-42A5-A69F-E2DCE6B93776@oracle.com> <9B09FE7E-34D0-4BC4-A679-AB4F507C8062@apple.com> <680DB46D-50E4-4E8C-9672-9F5E6AB2B662@gmail.com> Message-ID: > It might be worth browsing http://informagen.com/JarBundler/ for ideas on tag names. I'm familiar with this tool. I chose the same name for our Ant task since I think it accurately describes what the task does. The only difference is that I called it "bundlejars" in my Ant script rather than "jarbundler", since Ant tasks are generally defined as actions vs. nouns. G From artem.ananiev at oracle.com Wed Feb 1 06:25:10 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 01 Feb 2012 18:25:10 +0400 Subject: Request for review: 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails In-Reply-To: <4F293800.1020701@oracle.com> References: <4F293800.1020701@oracle.com> Message-ID: <4F294B46.1050400@oracle.com> On 2/1/2012 5:02 PM, Sergey Bylokhov wrote: > Hi Everyone, > Peers shouldn't accumulate an alpha after repainting, so clearRect was > added. And now we call setVisible for window after full initialization. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7131367/webrev.00/ Is replaceSurfaceData(1, null) removal from LWWindowPeer.initialize() intentional? As far as I understand, it would lead to getOn/OffScreenGraphics() to return null, until the window is visible or its opacity/insets/etc. values are changed. Is drawing into an invisible window supported now and will it be supported after your fix? Thanks, Artem From sergey.bylokhov at oracle.com Wed Feb 1 06:30:34 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 01 Feb 2012 18:30:34 +0400 Subject: Request for review: 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails In-Reply-To: <4F294B46.1050400@oracle.com> References: <4F293800.1020701@oracle.com> <4F294B46.1050400@oracle.com> Message-ID: <4F294C8A.9040905@oracle.com> 01.02.2012 18:25, Artem Ananiev wrote: > > On 2/1/2012 5:02 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Peers shouldn't accumulate an alpha after repainting, so clearRect was >> added. And now we call setVisible for window after full initialization. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7131367/webrev.00/ > > Is replaceSurfaceData(1, null) removal from LWWindowPeer.initialize() > intentional? As far as I understand, it would lead to > getOn/OffScreenGraphics() to return null, until the window is visible > or its opacity/insets/etc. values are changed. Is drawing into an > invisible window supported now and will it be supported after your fix? replaceSurfaceData will be called anyway from super.initialize()->setVisible() > > Thanks, > > Artem > -- Best regards, Sergey. From michael.x.mcmahon at oracle.com Wed Feb 1 06:44:37 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 01 Feb 2012 14:44:37 +0000 Subject: RFR: 7141675 Fix jcheck issues in .m sources In-Reply-To: <4F293EFF.9050305@oracle.com> References: <4F29287A.3040203@oracle.com> <4F292F36.1090204@oracle.com> <4F293EFF.9050305@oracle.com> Message-ID: <4F294FD5.5050508@oracle.com> Yes, that could be a problem. I think they will have to be added to the whitelist. - Michael On 01/02/12 13:32, Weijun Wang wrote: > I'm wondering if jcheck is updated to include these .m files, will it > reject the old changesets where the .m files contain trailing > whitespaces? Or, should those changesets be added into the whitelist? > > Thanks > Max > > > On 02/01/2012 08:25 PM, Anthony Petrov wrote: >> Hi Michael, >> >> The patch looks fine to me. It would be great to update jcheck as well >> so that the formatting requirements be enforced for further putbacks. >> >> -- >> best regards, >> Anthony >> >> On 2/1/2012 3:56 PM, Michael McMahon wrote: >>> This change is just to fix some white-space/tab problems that crept >>> into >>> some objective C files whose filename (extension .m) is not currently >>> known to jcheck. >>> >>> http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/ >>> >>> There is nothing to see in the webrev as white-space diferences are >>> ignored. >>> But the patch shows the actual changes. >>> >>> Thanks >>> Michael. From artem.ananiev at oracle.com Wed Feb 1 06:58:51 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 01 Feb 2012 18:58:51 +0400 Subject: Code Review Request for CR 7132367 (v1) - [macosx] ChoiceMouseWheelTest should be adapted for mac toolkit In-Reply-To: <4F2801AA.6050205@oracle.com> References: <4F2801AA.6050205@oracle.com> Message-ID: <4F29532B.2040605@oracle.com> Looks fine. Thanks, Artem On 1/31/2012 6:58 PM, Oleg Pekhovskiy wrote: > Hi guys, > > here is the second version of fix for the CR: > http://bugs.sun.com/view_bug.do?bug_id=7132367 > > Comments regarding test behavior for Mac platform added. > Issue 7141296 about improper mouse wheel work for combobox's drop-down > list added. > > Patch with changes attached. > > Thanks, > Oleg From daniel.daugherty at oracle.com Wed Feb 1 07:17:46 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 01 Feb 2012 08:17:46 -0700 Subject: RFR: 7141675 Fix jcheck issues in .m sources In-Reply-To: <4F294FD5.5050508@oracle.com> References: <4F29287A.3040203@oracle.com> <4F292F36.1090204@oracle.com> <4F293EFF.9050305@oracle.com> <4F294FD5.5050508@oracle.com> Message-ID: <4F29579A.9050002@oracle.com> That will be a problem. If jcheck is changed in such a way that an already committed changeset would be rejected, then it has to be added to the whitelist. Otherwise, a fresh clone will fail when jcheck processes the now offending changeset... Yes, this implies that jcheck has a scaling problem. As more changesets are added to a repo, the more work jcheck has to do... eventually all compute cycles will be consumed by jcheck... :-) Dan On 2/1/12 7:44 AM, Michael McMahon wrote: > Yes, that could be a problem. I think they will have to be added to > the whitelist. > > - Michael > > On 01/02/12 13:32, Weijun Wang wrote: >> I'm wondering if jcheck is updated to include these .m files, will it >> reject the old changesets where the .m files contain trailing >> whitespaces? Or, should those changesets be added into the whitelist? >> >> Thanks >> Max >> >> >> On 02/01/2012 08:25 PM, Anthony Petrov wrote: >>> Hi Michael, >>> >>> The patch looks fine to me. It would be great to update jcheck as well >>> so that the formatting requirements be enforced for further putbacks. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 2/1/2012 3:56 PM, Michael McMahon wrote: >>>> This change is just to fix some white-space/tab problems that crept >>>> into >>>> some objective C files whose filename (extension .m) is not currently >>>> known to jcheck. >>>> >>>> http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/ >>>> >>>> There is nothing to see in the webrev as white-space diferences are >>>> ignored. >>>> But the patch shows the actual changes. >>>> >>>> Thanks >>>> Michael. > From leonid.romanov at oracle.com Wed Feb 1 08:01:20 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 1 Feb 2012 20:01:20 +0400 Subject: RFR: 7141675 Fix jcheck issues in .m sources In-Reply-To: <4F29579A.9050002@oracle.com> References: <4F29287A.3040203@oracle.com> <4F292F36.1090204@oracle.com> <4F293EFF.9050305@oracle.com> <4F294FD5.5050508@oracle.com> <4F29579A.9050002@oracle.com> Message-ID: <86986C7E-AB51-4788-8BF2-AC83DD24B1FC@oracle.com> Btw, how does one strip trailing whitespaces/empty lines in XCode? On 01.02.2012, at 19:17, Daniel D. Daugherty wrote: > That will be a problem. If jcheck is changed in such a way that > an already committed changeset would be rejected, then it has > to be added to the whitelist. Otherwise, a fresh clone will fail > when jcheck processes the now offending changeset... > > Yes, this implies that jcheck has a scaling problem. As more > changesets are added to a repo, the more work jcheck has to > do... eventually all compute cycles will be consumed by > jcheck... :-) > > Dan > > > On 2/1/12 7:44 AM, Michael McMahon wrote: >> Yes, that could be a problem. I think they will have to be added to the whitelist. >> >> - Michael >> >> On 01/02/12 13:32, Weijun Wang wrote: >>> I'm wondering if jcheck is updated to include these .m files, will it reject the old changesets where the .m files contain trailing whitespaces? Or, should those changesets be added into the whitelist? >>> >>> Thanks >>> Max >>> >>> >>> On 02/01/2012 08:25 PM, Anthony Petrov wrote: >>>> Hi Michael, >>>> >>>> The patch looks fine to me. It would be great to update jcheck as well >>>> so that the formatting requirements be enforced for further putbacks. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 2/1/2012 3:56 PM, Michael McMahon wrote: >>>>> This change is just to fix some white-space/tab problems that crept into >>>>> some objective C files whose filename (extension .m) is not currently >>>>> known to jcheck. >>>>> >>>>> http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/ >>>>> >>>>> There is nothing to see in the webrev as white-space diferences are >>>>> ignored. >>>>> But the patch shows the actual changes. >>>>> >>>>> Thanks >>>>> Michael. >> From staffan.larsen at oracle.com Wed Feb 1 08:05:12 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 1 Feb 2012 17:05:12 +0100 Subject: Request for review: 7141739: [osx] Local attach fails if java.io.tmpdir is set Message-ID: Please review the following change. webrev: http://cr.openjdk.java.net/~sla/7141739/webrev.00/ bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141739 This is a followup of bug 7132199 which is fixed in jdk8 and jdk7u-dev. If the user sets -Djava.io.tmpdir to something else than /tmp, the attach framework will fail (for example jstack). The reason is that Hotspot and the jdk does not agree on which directory the well-known .java_pid and .attach_pid files should be in. On OSX Hotspot will always create these in the per-user secure temporary directory, but the jdk will look in java.io.tmpdir. This fix makes sure the jdk looks in the same location as Hotspot. Thanks, /Staffan From anthony.petrov at oracle.com Wed Feb 1 08:22:58 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 01 Feb 2012 20:22:58 +0400 Subject: Request for review: 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails In-Reply-To: <4F293800.1020701@oracle.com> References: <4F293800.1020701@oracle.com> Message-ID: <4F2966E2.9010101@oracle.com> Hi Sergey, All the other peers call super.initialize() in the beginning of their overridden initialize() methods, and making an exception just for the LWWindowPeer seems to be inconsistent. Since the only reason for that is to postpone the setVisible() call, I would suggest either introducing pre- and post-Initialize() methods (the approach is similar to XToolkit), or there might be a flag that could be reset in LWWindowPeer ctor that would indicate that LWComponentPeer.initialize() shouldn't call setVisible(). Then, the LWWindowPeer.initialize() would call setVisible() as its last step. It just seems that having the inconsistency as present in your current fix may hurt us in the future when e.g. we modify the logic in the LWComponentPeer.initialize() and would expect it to be in effect before setting additional properties for the LWWindowPeer. -- best regards, Anthony On 2/1/2012 5:02 PM, Sergey Bylokhov wrote: > Hi Everyone, > Peers shouldn't accumulate an alpha after repainting, so clearRect was > added. And now we call setVisible for window after full initialization. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7131367/webrev.00/ > From scott.kovatch at oracle.com Wed Feb 1 08:27:45 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 1 Feb 2012 08:27:45 -0800 Subject: RFR: 7141675 Fix jcheck issues in .m sources In-Reply-To: <86986C7E-AB51-4788-8BF2-AC83DD24B1FC@oracle.com> References: <4F29287A.3040203@oracle.com> <4F292F36.1090204@oracle.com> <4F293EFF.9050305@oracle.com> <4F294FD5.5050508@oracle.com> <4F29579A.9050002@oracle.com> <86986C7E-AB51-4788-8BF2-AC83DD24B1FC@oracle.com> Message-ID: <83B6FC25-9D8C-40F9-AEF1-C9215A5ED90E@oracle.com> Sadly, it doesn't, as far as I can tell. I have been using BBEdit or TextMate for Obj-C files for just that reason. I haven't tried AppCode from JetBrains yet. -- Scott K. Sent from my iPad On Feb 1, 2012, at 8:01 AM, Leonid Romanov wrote: > Btw, how does one strip trailing whitespaces/empty lines in XCode? > > On 01.02.2012, at 19:17, Daniel D. Daugherty wrote: > >> That will be a problem. If jcheck is changed in such a way that >> an already committed changeset would be rejected, then it has >> to be added to the whitelist. Otherwise, a fresh clone will fail >> when jcheck processes the now offending changeset... >> >> Yes, this implies that jcheck has a scaling problem. As more >> changesets are added to a repo, the more work jcheck has to >> do... eventually all compute cycles will be consumed by >> jcheck... :-) >> >> Dan >> >> >> On 2/1/12 7:44 AM, Michael McMahon wrote: >>> Yes, that could be a problem. I think they will have to be added to the whitelist. >>> >>> - Michael >>> >>> On 01/02/12 13:32, Weijun Wang wrote: >>>> I'm wondering if jcheck is updated to include these .m files, will it reject the old changesets where the .m files contain trailing whitespaces? Or, should those changesets be added into the whitelist? >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 02/01/2012 08:25 PM, Anthony Petrov wrote: >>>>> Hi Michael, >>>>> >>>>> The patch looks fine to me. It would be great to update jcheck as well >>>>> so that the formatting requirements be enforced for further putbacks. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 2/1/2012 3:56 PM, Michael McMahon wrote: >>>>>> This change is just to fix some white-space/tab problems that crept into >>>>>> some objective C files whose filename (extension .m) is not currently >>>>>> known to jcheck. >>>>>> >>>>>> http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/ >>>>>> >>>>>> There is nothing to see in the webrev as white-space diferences are >>>>>> ignored. >>>>>> But the patch shows the actual changes. >>>>>> >>>>>> Thanks >>>>>> Michael. >>> > From anthony.petrov at oracle.com Wed Feb 1 08:43:07 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 01 Feb 2012 20:43:07 +0400 Subject: Review request for 7124236: [macosx] Some components lost shadows after the latest fix of translucent windows. In-Reply-To: <4F283B46.5030401@oracle.com> References: <4F283B46.5030401@oracle.com> Message-ID: <4F296B9B.60904@oracle.com> Hi Dmitry, Major concern: is that possible to avoid modifications to the shared code with this fix? On 1/31/2012 11:04 PM, Dmitry Cherepanov wrote: > The cause of the problem with broken shadows is that currently > NSWindow's background color is [NSWindow clearColor] and it makes > shadows invisible. The fix implements Mike's suggestion and now we draw > pure transparent pixels into a CALayer so that the native background > color will be visible through transparent areas of the CALayer. Looks like it should work fine if background's alpha is > 0 and < 255. And what about window.setBackground(new Color(0, 0, 0, 0))? I see that in CPlatformWindow we'll actually pass these zeros (which is in fact the same as the clearColor, isn't it?) to the native system. In this case I wouldn't expect any shadow to appear since the background color set is completely transparent. Is this correct? Also, the bug evaluation mentions the click-through problem. Is it resolved with this fix? -- best regards, Anthony > > http://cr.openjdk.java.net/~dcherepanov/7124236/webrev.0/ > > Thanks, > Dmitry > From scott.kovatch at oracle.com Wed Feb 1 09:00:11 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 1 Feb 2012 09:00:11 -0800 Subject: Heads-up: Pushing jdk7u-osx to jdk7u-dev In-Reply-To: <4F291F62.6020002@oracle.com> References: <4F291F62.6020002@oracle.com> Message-ID: <9E7DE526-37D5-4BE5-9DBA-2577D935D816@oracle.com> I assume you'll send out an announcement when this is done -- I'll take care of updating the macosx-port information page. At some point I would think that the Mac-specific information should be added to the main OpenJDK pages, as the 'macosx-port' project is pretty much done now, right? Mac OS X is just another platform. -- Scott K. On Feb 1, 2012, at 3:17 AM, Michael McMahon wrote: > Hello, > > This is a heads-up to let you know that the jdk7u-osx forest is being pushed to jdk7u-dev > later today. From that point, it is expected that all remaining/future work on the Mac OS port for jdk7u4 will > happen through jdk7u-dev (until it forks to a 7u4 specific forest). > > I imagine we'll continue to use this mail list for Mac specific porting issues, but changes will have to be > discussed/approved via jdk7u-dev at openjdk.java.net as well. > > Thanks, > Michael. From sergey.bylokhov at oracle.com Wed Feb 1 09:06:35 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 01 Feb 2012 21:06:35 +0400 Subject: Request for review: 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails In-Reply-To: <4F2966E2.9010101@oracle.com> References: <4F293800.1020701@oracle.com> <4F2966E2.9010101@oracle.com> Message-ID: <4F29711B.5030509@oracle.com> 01.02.2012 20:22, Anthony Petrov ?????: > Hi Sergey, > > All the other peers call super.initialize() in the beginning of their > overridden initialize() methods, and making an exception just for the > LWWindowPeer seems to be inconsistent. Well, I believe that all other components should call super.initialize() at the end too. I just have no time to test them all. Because it is cause lots of unnecessary repaints. We shouldn't initialize components after we show them. > Since the only reason for that is to postpone the setVisible() call, I > would suggest either introducing pre- and post-Initialize() methods > (the approach is similar to XToolkit), or there might be a flag that > could be reset in LWWindowPeer ctor that would indicate that > LWComponentPeer.initialize() shouldn't call setVisible(). Then, the > LWWindowPeer.initialize() would call setVisible() as its last step. > > It just seems that having the inconsistency as present in your current > fix may hurt us in the future when e.g. we modify the logic in the > LWComponentPeer.initialize() and would expect it to be in effect > before setting additional properties for the LWWindowPeer. > > -- > best regards, > Anthony > > On 2/1/2012 5:02 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Peers shouldn't accumulate an alpha after repainting, so clearRect >> was added. And now we call setVisible for window after full >> initialization. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7131367/webrev.00/ >> -- Best regards, Sergey. From david.dehaven at oracle.com Wed Feb 1 09:06:54 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 1 Feb 2012 09:06:54 -0800 Subject: Bundled app launcher changes In-Reply-To: <9B09FE7E-34D0-4BC4-A679-AB4F507C8062@apple.com> References: <01238DD0-65D6-42A5-A69F-E2DCE6B93776@oracle.com> <9B09FE7E-34D0-4BC4-A679-AB4F507C8062@apple.com> Message-ID: <1AFCEC33-352E-4FC2-B853-8E8C93045454@oracle.com> [re-sending to list? coffee hasn't kicked in yet] > There should be a way to add a number of jars to the classpath, which will implicitly get copied into (bundle)/Contents/Java. Is that just by adding more tags? Should there be an affordance for specifying non-jar/non-classpath resources that should also get copied into (bundle)/Contents/Java? It may make sense to provide a tag for art or other Mac-specific resources to be copied into (bundle).app/Contents/Resources. Or perhaps just a tag that takes a source and a destination. > > I'm also not wild about the tag name . That may be ambiguous with some sort of jar coalescing. Perhaps , or . Any other suggestions? > > I know you can't support this on non-Mac builders, but you should definitely plan to provide a codesigncert= argument which will sign the primary stub executable with a provided certificate. This will be Very Important to some developers. And a corresponding entitlements plist file entry? -DrD- From swingler at apple.com Wed Feb 1 09:10:26 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 01 Feb 2012 09:10:26 -0800 Subject: RFR: 7141675 Fix jcheck issues in .m sources In-Reply-To: <83B6FC25-9D8C-40F9-AEF1-C9215A5ED90E@oracle.com> References: <4F29287A.3040203@oracle.com> <4F292F36.1090204@oracle.com> <4F293EFF.9050305@oracle.com> <4F294FD5.5050508@oracle.com> <4F29579A.9050002@oracle.com> <86986C7E-AB51-4788-8BF2-AC83DD24B1FC@oracle.com> <83B6FC25-9D8C-40F9-AEF1-C9215A5ED90E@oracle.com> Message-ID: <8CB975F5-9769-426F-A334-149547F8D273@apple.com> Please file bugs against Xcode if there are code formatting preferences you would like to see at . Cheers, Mike Swingler Apple Inc. On Feb 1, 2012, at 8:27 AM, Scott Kovatch wrote: > Sadly, it doesn't, as far as I can tell. I have been using BBEdit or TextMate for Obj-C files for just that reason. > > I haven't tried AppCode from JetBrains yet. > > -- Scott K. > > Sent from my iPad > > On Feb 1, 2012, at 8:01 AM, Leonid Romanov wrote: > >> Btw, how does one strip trailing whitespaces/empty lines in XCode? >> >> On 01.02.2012, at 19:17, Daniel D. Daugherty wrote: >> >>> That will be a problem. If jcheck is changed in such a way that >>> an already committed changeset would be rejected, then it has >>> to be added to the whitelist. Otherwise, a fresh clone will fail >>> when jcheck processes the now offending changeset... >>> >>> Yes, this implies that jcheck has a scaling problem. As more >>> changesets are added to a repo, the more work jcheck has to >>> do... eventually all compute cycles will be consumed by >>> jcheck... :-) >>> >>> Dan >>> >>> >>> On 2/1/12 7:44 AM, Michael McMahon wrote: >>>> Yes, that could be a problem. I think they will have to be added to the whitelist. >>>> >>>> - Michael >>>> >>>> On 01/02/12 13:32, Weijun Wang wrote: >>>>> I'm wondering if jcheck is updated to include these .m files, will it reject the old changesets where the .m files contain trailing whitespaces? Or, should those changesets be added into the whitelist? >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 02/01/2012 08:25 PM, Anthony Petrov wrote: >>>>>> Hi Michael, >>>>>> >>>>>> The patch looks fine to me. It would be great to update jcheck as well >>>>>> so that the formatting requirements be enforced for further putbacks. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 2/1/2012 3:56 PM, Michael McMahon wrote: >>>>>>> This change is just to fix some white-space/tab problems that crept into >>>>>>> some objective C files whose filename (extension .m) is not currently >>>>>>> known to jcheck. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/ >>>>>>> >>>>>>> There is nothing to see in the webrev as white-space diferences are >>>>>>> ignored. >>>>>>> But the patch shows the actual changes. >>>>>>> >>>>>>> Thanks >>>>>>> Michael. >>>> >> From sergey.bylokhov at oracle.com Wed Feb 1 10:39:07 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 01 Feb 2012 22:39:07 +0400 Subject: Review request for 7124236: [macosx] Some components lost shadows after the latest fix of translucent windows. In-Reply-To: <4F283B46.5030401@oracle.com> References: <4F283B46.5030401@oracle.com> Message-ID: <4F2986CB.1020206@oracle.com> Hi Dmitry, Mike. A few notes: - After the fix we cannot control composite over background(see CompositeTest.java), it works on windows and on macosx on jdk6. - Graphics.getBackground() now returns transparent color so clearRect, paintAll(Graphics g) etc will work differently. I have a few questions about these changes. - Is it possible to replace composite from src_over to src between layer and nswindow? I think shadow will be fixed automatically if we change composite to src, because in this case we don`t need to set nswindow background to clearColor. - If we set background of the window to clearcolor and paint something in drawRect, we will get correct shadow, but the shadow disappear if we paint the same things using layer. Why? Is it possible to make the same window using layers? http://cocoawithlove.com/2008/12/drawing-custom-window-on-mac-os-x.html. Note: It has shadow and transparent to mouse clicks. 31.01.2012 23:04, Dmitry Cherepanov wrote: > The cause of the problem with broken shadows is that currently > NSWindow's background color is [NSWindow clearColor] and it makes > shadows invisible. The fix implements Mike's suggestion and now we > draw pure transparent pixels into a CALayer so that the native > background color will be visible through transparent areas of the > CALayer. > > http://cr.openjdk.java.net/~dcherepanov/7124236/webrev.0/ > > Thanks, > Dmitry > -- Best regards, Sergey. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CompositeTest.java Url: http://mail.openjdk.java.net/pipermail/macosx-port-dev/attachments/20120201/95a698ec/CompositeTest.java From anthony.petrov at oracle.com Wed Feb 1 11:00:42 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 01 Feb 2012 23:00:42 +0400 Subject: Request for review: 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails In-Reply-To: <4F29711B.5030509@oracle.com> References: <4F293800.1020701@oracle.com> <4F2966E2.9010101@oracle.com> <4F29711B.5030509@oracle.com> Message-ID: <4F298BDA.8030600@oracle.com> On 2/1/2012 9:06 PM, Sergey Bylokhov wrote: > 01.02.2012 20:22, Anthony Petrov ?????: >> All the other peers call super.initialize() in the beginning of their >> overridden initialize() methods, and making an exception just for the >> LWWindowPeer seems to be inconsistent. > Well, I believe that all other components should call super.initialize() > at the end too. I just have no time to test them all. Because it is > cause lots of unnecessary repaints. We shouldn't initialize components > after we show them. I agree, partially. I believe that the setVisible() call should indeed follow all other initialization. However, the rest of settings which LWComponentPeer.initialize() performs should go ahead of custom initialization performed by specialized peers, because custom initializers may in theory tweak the general settings. -- best regards, Anthony >> Since the only reason for that is to postpone the setVisible() call, I >> would suggest either introducing pre- and post-Initialize() methods >> (the approach is similar to XToolkit), or there might be a flag that >> could be reset in LWWindowPeer ctor that would indicate that >> LWComponentPeer.initialize() shouldn't call setVisible(). Then, the >> LWWindowPeer.initialize() would call setVisible() as its last step. >> >> It just seems that having the inconsistency as present in your current >> fix may hurt us in the future when e.g. we modify the logic in the >> LWComponentPeer.initialize() and would expect it to be in effect >> before setting additional properties for the LWWindowPeer. >> >> -- >> best regards, >> Anthony >> >> On 2/1/2012 5:02 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> Peers shouldn't accumulate an alpha after repainting, so clearRect >>> was added. And now we call setVisible for window after full >>> initialization. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7131367/webrev.00/ >>> > > From daniel.daugherty at oracle.com Wed Feb 1 14:59:32 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 01 Feb 2012 15:59:32 -0700 Subject: Request for review: 7141739: [osx] Local attach fails if java.io.tmpdir is set In-Reply-To: References: Message-ID: <4F29C3D4.1040609@oracle.com> On 2/1/12 9:05 AM, Staffan Larsen wrote: > Please review the following change. > > webrev: http://cr.openjdk.java.net/~sla/7141739/webrev.00/ > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141739 > > This is a followup of bug 7132199 which is fixed in jdk8 and jdk7u-dev. > > If the user sets -Djava.io.tmpdir to something else than /tmp, the attach framework will fail (for example jstack). The reason is that Hotspot and the jdk does not agree on which directory the well-known .java_pid and .attach_pid files should be in. On OSX Hotspot will always create these in the per-user secure temporary directory, but the jdk will look in java.io.tmpdir. > > This fix makes sure the jdk looks in the same location as Hotspot. > > Thanks, > /Staffan Please update copyright years to 2012. src/solaris/classes/sun/tools/attach/BsdVirtualMachine.java line 73: Always creates the ".attach_pid" file in tmpdir. The HSX side matches this and always looks for the ".attach_pid" file in tmpdir. Perhaps we should change Linux and Solaris to always create and look for the ".attach_pid" file in tmpdir... src/solaris/native/sun/tools/attach/BsdVirtualMachine.c No comments. From daniel.daugherty at oracle.com Wed Feb 1 15:01:35 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 01 Feb 2012 16:01:35 -0700 Subject: Request for review: 7141739: [osx] Local attach fails if java.io.tmpdir is set In-Reply-To: <4F29C3D4.1040609@oracle.com> References: <4F29C3D4.1040609@oracle.com> Message-ID: <4F29C44F.5030406@oracle.com> Forgot to say: Thumbs up! Dan On 2/1/12 3:59 PM, Daniel D. Daugherty wrote: > On 2/1/12 9:05 AM, Staffan Larsen wrote: >> Please review the following change. >> >> webrev: http://cr.openjdk.java.net/~sla/7141739/webrev.00/ >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141739 >> >> This is a followup of bug 7132199 which is fixed in jdk8 and jdk7u-dev. >> >> If the user sets -Djava.io.tmpdir to something else than /tmp, the >> attach framework will fail (for example jstack). The reason is that >> Hotspot and the jdk does not agree on which directory the well-known >> .java_pid and .attach_pid files should be in. On OSX Hotspot will >> always create these in the per-user secure temporary directory, but >> the jdk will look in java.io.tmpdir. >> >> This fix makes sure the jdk looks in the same location as Hotspot. >> >> Thanks, >> /Staffan > > Please update copyright years to 2012. > > src/solaris/classes/sun/tools/attach/BsdVirtualMachine.java > line 73: Always creates the ".attach_pid" file in tmpdir. > The HSX side matches this and always looks for the > ".attach_pid" file in tmpdir. Perhaps we should change > Linux and Solaris to always create and look for the > ".attach_pid" file in tmpdir... > > src/solaris/native/sun/tools/attach/BsdVirtualMachine.c > No comments. From mik3hall at gmail.com Wed Feb 1 15:19:37 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 1 Feb 2012 17:19:37 -0600 Subject: JDK 7 Mac Port Preview b227 Available In-Reply-To: <4F22F2BE.50008@oracle.com> References: <4F22F2BE.50008@oracle.com> Message-ID: file "/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/bin/java" /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/bin/java: Mach-O 64-bit executable x86_64 From mik3hall at gmail.com Wed Feb 1 16:03:58 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 1 Feb 2012 18:03:58 -0600 Subject: JDK 7 Mac Port Preview b227 Available In-Reply-To: References: <4F22F2BE.50008@oracle.com> Message-ID: <9A4C3F08-35D6-4397-9915-D71BBA504731@gmail.com> On Feb 1, 2012, at 5:19 PM, Michael Hall wrote: > > file "/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/bin/java" > /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/bin/java: Mach-O 64-bit executable x86_64 Sorry, this alone may not be clear. Is the omission of i386 intentional or inadvertent in the b227 Preview? From michael.x.mcmahon at oracle.com Wed Feb 1 16:44:33 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 02 Feb 2012 00:44:33 +0000 Subject: Heads-up: Pushing jdk7u-osx to jdk7u-dev In-Reply-To: <9E7DE526-37D5-4BE5-9DBA-2577D935D816@oracle.com> References: <4F291F62.6020002@oracle.com> <9E7DE526-37D5-4BE5-9DBA-2577D935D816@oracle.com> Message-ID: <4F29DC71.6070907@oracle.com> The push is done now. Thanks, Michael. On 01/02/12 17:00, Scott Kovatch wrote: > I assume you'll send out an announcement when this is done -- I'll take care of updating the macosx-port information page. > > At some point I would think that the Mac-specific information should be added to the main OpenJDK pages, as the 'macosx-port' project is pretty much done now, right? Mac OS X is just another platform. > > -- Scott K. > > On Feb 1, 2012, at 3:17 AM, Michael McMahon wrote: > >> Hello, >> >> This is a heads-up to let you know that the jdk7u-osx forest is being pushed to jdk7u-dev >> later today. From that point, it is expected that all remaining/future work on the Mac OS port for jdk7u4 will >> happen through jdk7u-dev (until it forks to a 7u4 specific forest). >> >> I imagine we'll continue to use this mail list for Mac specific porting issues, but changes will have to be >> discussed/approved via jdk7u-dev at openjdk.java.net as well. >> >> Thanks, >> Michael. From weijun.wang at oracle.com Wed Feb 1 18:13:01 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 02 Feb 2012 10:13:01 +0800 Subject: RFR: 7141675 Fix jcheck issues in .m sources In-Reply-To: <4F29579A.9050002@oracle.com> References: <4F29287A.3040203@oracle.com> <4F292F36.1090204@oracle.com> <4F293EFF.9050305@oracle.com> <4F294FD5.5050508@oracle.com> <4F29579A.9050002@oracle.com> Message-ID: <4F29F12D.40802@oracle.com> Maybe each rule inside jcheck can have a startdate, only changsets after that need to be checked. Nobody will try to fake the date, right? -Max On 02/01/2012 11:17 PM, Daniel D. Daugherty wrote: > That will be a problem. If jcheck is changed in such a way that > an already committed changeset would be rejected, then it has > to be added to the whitelist. Otherwise, a fresh clone will fail > when jcheck processes the now offending changeset... > > Yes, this implies that jcheck has a scaling problem. As more > changesets are added to a repo, the more work jcheck has to > do... eventually all compute cycles will be consumed by > jcheck... :-) > > Dan > > > On 2/1/12 7:44 AM, Michael McMahon wrote: >> Yes, that could be a problem. I think they will have to be added to >> the whitelist. >> >> - Michael >> >> On 01/02/12 13:32, Weijun Wang wrote: >>> I'm wondering if jcheck is updated to include these .m files, will it >>> reject the old changesets where the .m files contain trailing >>> whitespaces? Or, should those changesets be added into the whitelist? >>> >>> Thanks >>> Max >>> >>> >>> On 02/01/2012 08:25 PM, Anthony Petrov wrote: >>>> Hi Michael, >>>> >>>> The patch looks fine to me. It would be great to update jcheck as well >>>> so that the formatting requirements be enforced for further putbacks. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 2/1/2012 3:56 PM, Michael McMahon wrote: >>>>> This change is just to fix some white-space/tab problems that crept >>>>> into >>>>> some objective C files whose filename (extension .m) is not currently >>>>> known to jcheck. >>>>> >>>>> http://cr.openjdk.java.net/~michaelm/7141675/webrev.1/ >>>>> >>>>> There is nothing to see in the webrev as white-space diferences are >>>>> ignored. >>>>> But the patch shows the actual changes. >>>>> >>>>> Thanks >>>>> Michael. >> From astrange at apple.com Wed Feb 1 22:15:17 2012 From: astrange at apple.com (Alex Strange) Date: Thu, 02 Feb 2012 01:15:17 -0500 Subject: Request for review 7124225: [macosx] Input lines support only current sample rate In-Reply-To: <4F27BC58.60600@oracle.com> References: <4F27BC58.60600@oracle.com> Message-ID: <6EE3266F-C480-4639-9F51-2A5894AEF6CD@apple.com> On Jan 31, 2012, at 5:03 AM, Alex Menkov wrote: > Hi all, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124225 > webrev: http://cr.openjdk.java.net/~amenkov/7124225/webrev.00/ > > Summary of the changes: implemented resampler for TargetDataLine using AudioToolbox/AudioConverter (used only if requested sample rate does not match current device sample rate). > > regards > Alex Looks ok except for two minor issues: > + if (ABS(sampleRate - hardwareSampleRate) > 1) { > + device->resampler = new Resampler(); > + You could use fabs() here and not have to define ABS(). > + if (!isSource) { > + // for target lines we should ensure that sampleRate == current device sample rate > + // (othewise we get error -10863 (kAudioUnitErr_CannotDoInCurrentContext in AUComponent.h) > + // from AudioUnitRender(in InputCallback)) I think this comment is unnecessary now (there's also a spelling error). Did you see any timestamp discontinuities in the input? I can understand it skipping some times, but not sure what could make it go backwards. From leonid.romanov at oracle.com Thu Feb 2 02:49:12 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 2 Feb 2012 14:49:12 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' Message-ID: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> Hi, Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ Thanks, Leonid. From sergey.bylokhov at oracle.com Thu Feb 2 03:56:04 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 02 Feb 2012 15:56:04 +0400 Subject: Request for review: 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails In-Reply-To: <4F298BDA.8030600@oracle.com> References: <4F293800.1020701@oracle.com> <4F2966E2.9010101@oracle.com> <4F29711B.5030509@oracle.com> <4F298BDA.8030600@oracle.com> Message-ID: <4F2A79D4.6030505@oracle.com> 01.02.2012 23:00, Anthony Petrov wrote: > On 2/1/2012 9:06 PM, Sergey Bylokhov wrote: >> 01.02.2012 20:22, Anthony Petrov ?????: >>> All the other peers call super.initialize() in the beginning of >>> their overridden initialize() methods, and making an exception just >>> for the LWWindowPeer seems to be inconsistent. >> Well, I believe that all other components should call >> super.initialize() at the end too. I just have no time to test them >> all. Because it is cause lots of unnecessary repaints. We shouldn't >> initialize components after we show them. > > I agree, partially. I believe that the setVisible() call should indeed > follow all other initialization. However, the rest of settings which > LWComponentPeer.initialize() performs should go ahead of custom > initialization performed by specialized peers, because custom > initializers may in theory tweak the general settings. Well, if custom initializer want to tweak the general settings, it should tweak it not just during initialization but during regular changes too? For example if sub class want to tweak its bounds it should do it in setBounds not in initialization. I'll create separate RFE for refactoring of peer initialization. > > -- > best regards, > Anthony > >>> Since the only reason for that is to postpone the setVisible() call, >>> I would suggest either introducing pre- and post-Initialize() >>> methods (the approach is similar to XToolkit), or there might be a >>> flag that could be reset in LWWindowPeer ctor that would indicate >>> that LWComponentPeer.initialize() shouldn't call setVisible(). Then, >>> the LWWindowPeer.initialize() would call setVisible() as its last step. >>> >>> It just seems that having the inconsistency as present in your >>> current fix may hurt us in the future when e.g. we modify the logic >>> in the LWComponentPeer.initialize() and would expect it to be in >>> effect before setting additional properties for the LWWindowPeer. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 2/1/2012 5:02 PM, Sergey Bylokhov wrote: >>>> Hi Everyone, >>>> Peers shouldn't accumulate an alpha after repainting, so clearRect >>>> was added. And now we call setVisible for window after full >>>> initialization. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7131367/webrev.00/ >>>> >> >> -- Best regards, Sergey. From artem.ananiev at oracle.com Thu Feb 2 04:16:09 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 02 Feb 2012 16:16:09 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> Message-ID: <4F2A7E89.60402@oracle.com> Some comments from my side: 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). 2. I wonder how the following piece of code is expected to work: robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. Thanks, Artem On 2/2/2012 2:49 PM, Leonid Romanov wrote: > Hi, > Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 > webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ > > Thanks, > Leonid. > > From leonid.romanov at oracle.com Thu Feb 2 04:37:17 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 2 Feb 2012 16:37:17 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <4F2A7E89.60402@oracle.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A7E89.60402@oracle.com> Message-ID: On 02.02.2012, at 16:16, Artem Ananiev wrote: > > Some comments from my side: > > 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). So, your suggestion is to use JNI field-access methods to get these cached values in native every time we need them, right? > > 2. I wonder how the following piece of code is expected to work: > > robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) > > Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. > We don't support it because it doesn't make sense: real user can't press both buttons exactly at the same time, one of the buttons would always be pressed before the other. > Thanks, > > Artem > > On 2/2/2012 2:49 PM, Leonid Romanov wrote: >> Hi, >> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >> >> Thanks, >> Leonid. >> >> From anthony.petrov at oracle.com Thu Feb 2 04:37:48 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 02 Feb 2012 16:37:48 +0400 Subject: Request for review: 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails In-Reply-To: <4F2A79D4.6030505@oracle.com> References: <4F293800.1020701@oracle.com> <4F2966E2.9010101@oracle.com> <4F29711B.5030509@oracle.com> <4F298BDA.8030600@oracle.com> <4F2A79D4.6030505@oracle.com> Message-ID: <4F2A839C.3030703@oracle.com> On 02/02/12 15:56, Sergey Bylokhov wrote: > 01.02.2012 23:00, Anthony Petrov wrote: >> On 2/1/2012 9:06 PM, Sergey Bylokhov wrote: >>> 01.02.2012 20:22, Anthony Petrov ?????: >>>> All the other peers call super.initialize() in the beginning of >>>> their overridden initialize() methods, and making an exception just >>>> for the LWWindowPeer seems to be inconsistent. >>> Well, I believe that all other components should call >>> super.initialize() at the end too. I just have no time to test them >>> all. Because it is cause lots of unnecessary repaints. We shouldn't >>> initialize components after we show them. >> >> I agree, partially. I believe that the setVisible() call should indeed >> follow all other initialization. However, the rest of settings which >> LWComponentPeer.initialize() performs should go ahead of custom >> initialization performed by specialized peers, because custom >> initializers may in theory tweak the general settings. > Well, if custom initializer want to tweak the general settings, it > should tweak it not just during initialization but during regular > changes too? For example if sub class want to tweak its bounds it should > do it in setBounds not in initialization. I'll create separate RFE for > refactoring of peer initialization. Thanks. -- best regards, Anthony >> >> -- >> best regards, >> Anthony >> >>>> Since the only reason for that is to postpone the setVisible() call, >>>> I would suggest either introducing pre- and post-Initialize() >>>> methods (the approach is similar to XToolkit), or there might be a >>>> flag that could be reset in LWWindowPeer ctor that would indicate >>>> that LWComponentPeer.initialize() shouldn't call setVisible(). Then, >>>> the LWWindowPeer.initialize() would call setVisible() as its last step. >>>> >>>> It just seems that having the inconsistency as present in your >>>> current fix may hurt us in the future when e.g. we modify the logic >>>> in the LWComponentPeer.initialize() and would expect it to be in >>>> effect before setting additional properties for the LWWindowPeer. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 2/1/2012 5:02 PM, Sergey Bylokhov wrote: >>>>> Hi Everyone, >>>>> Peers shouldn't accumulate an alpha after repainting, so clearRect >>>>> was added. And now we call setVisible for window after full >>>>> initialization. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/7131367/webrev.00/ >>>>> >>> >>> > > From alexey.menkov at oracle.com Thu Feb 2 05:15:28 2012 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 02 Feb 2012 17:15:28 +0400 Subject: Request for review 7124225: [macosx] Input lines support only current sample rate In-Reply-To: <6EE3266F-C480-4639-9F51-2A5894AEF6CD@apple.com> References: <4F27BC58.60600@oracle.com> <6EE3266F-C480-4639-9F51-2A5894AEF6CD@apple.com> Message-ID: <4F2A8C70.6070206@oracle.com> Hi Alex, Thank you for the review. I've fixed the issue you mentioned. This are minor changes so I'm going to send request to push the updated fix (http://cr.openjdk.java.net/~amenkov/7124225/webrev.01/) to 7u4 repo. Some explanation about discontinuity handling. We handle only discontinuity occurs on pause/resume of recording (AudioOutputUnitStop/AudioOutputUnitStart in terms of CoreAudio) (we don't need to reset resampler if some frames were dropped for any case). HAL starts at zero timestamp (actually the 1st data we get has "near-zero" timestamp). regards Alex On 02/02/2012 10:15, Alex Strange wrote: > > On Jan 31, 2012, at 5:03 AM, Alex Menkov > wrote: > >> Hi all, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124225 >> webrev: http://cr.openjdk.java.net/~amenkov/7124225/webrev.00/ >> >> Summary of the changes: implemented resampler for TargetDataLine using >> AudioToolbox/AudioConverter (used only if requested sample rate does >> not match current device sample rate). >> >> regards >> Alex > > Looks ok except for two minor issues: > >> + if (ABS(sampleRate - hardwareSampleRate)> 1) { >> + device->resampler = new Resampler(); >> + > You could use fabs() here and not have to define ABS(). > >> + if (!isSource) { >> + // for target lines we should ensure that sampleRate == current device sample rate >> + // (othewise we get error -10863 (kAudioUnitErr_CannotDoInCurrentContext in AUComponent.h) >> + // from AudioUnitRender(in InputCallback)) > I think this comment is unnecessary now (there's also a spelling error). > > Did you see any timestamp discontinuities in the input? I can understand > it skipping some times, but not sure what could make it go backwards. From Alexander.Potochkin at oracle.com Thu Feb 2 05:30:09 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 02 Feb 2012 17:30:09 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> Message-ID: <4F2A8FE1.2050109@oracle.com> Hello Leonid Could you comment the change in the NSEvent.nsButtonToJavaButton() method? Thanks alexp > Hi, > Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 > webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ > > Thanks, > Leonid. > > From sergey.bylokhov at oracle.com Thu Feb 2 05:34:31 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 02 Feb 2012 17:34:31 +0400 Subject: Request for review: 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails In-Reply-To: <4F2A839C.3030703@oracle.com> References: <4F293800.1020701@oracle.com> <4F2966E2.9010101@oracle.com> <4F29711B.5030509@oracle.com> <4F298BDA.8030600@oracle.com> <4F2A79D4.6030505@oracle.com> <4F2A839C.3030703@oracle.com> Message-ID: <4F2A90E7.60905@oracle.com> Done: http://monaco.us.oracle.com/detail.jsf?cr=7142091 02.02.2012 16:37, Anthony Petrov wrote: > On 02/02/12 15:56, Sergey Bylokhov wrote: >> 01.02.2012 23:00, Anthony Petrov wrote: >>> On 2/1/2012 9:06 PM, Sergey Bylokhov wrote: >>>> 01.02.2012 20:22, Anthony Petrov ?????: >>>>> All the other peers call super.initialize() in the beginning of >>>>> their overridden initialize() methods, and making an exception just >>>>> for the LWWindowPeer seems to be inconsistent. >>>> Well, I believe that all other components should call >>>> super.initialize() at the end too. I just have no time to test them >>>> all. Because it is cause lots of unnecessary repaints. We shouldn't >>>> initialize components after we show them. >>> >>> I agree, partially. I believe that the setVisible() call should indeed >>> follow all other initialization. However, the rest of settings which >>> LWComponentPeer.initialize() performs should go ahead of custom >>> initialization performed by specialized peers, because custom >>> initializers may in theory tweak the general settings. >> Well, if custom initializer want to tweak the general settings, it >> should tweak it not just during initialization but during regular >> changes too? For example if sub class want to tweak its bounds it should >> do it in setBounds not in initialization. I'll create separate RFE for >> refactoring of peer initialization. > > Thanks. > > -- > best regards, > Anthony > >>> >>> -- >>> best regards, >>> Anthony >>> >>>>> Since the only reason for that is to postpone the setVisible() call, >>>>> I would suggest either introducing pre- and post-Initialize() >>>>> methods (the approach is similar to XToolkit), or there might be a >>>>> flag that could be reset in LWWindowPeer ctor that would indicate >>>>> that LWComponentPeer.initialize() shouldn't call setVisible(). Then, >>>>> the LWWindowPeer.initialize() would call setVisible() as its last >>>>> step. >>>>> >>>>> It just seems that having the inconsistency as present in your >>>>> current fix may hurt us in the future when e.g. we modify the logic >>>>> in the LWComponentPeer.initialize() and would expect it to be in >>>>> effect before setting additional properties for the LWWindowPeer. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 2/1/2012 5:02 PM, Sergey Bylokhov wrote: >>>>>> Hi Everyone, >>>>>> Peers shouldn't accumulate an alpha after repainting, so clearRect >>>>>> was added. And now we call setVisible for window after full >>>>>> initialization. >>>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 >>>>>> Webrev can be found at: >>>>>> http://cr.openjdk.java.net/~serb/7131367/webrev.00/ >>>>>> >>>> >>>> >> >> -- Best regards, Sergey. From leonid.romanov at oracle.com Thu Feb 2 05:41:47 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 2 Feb 2012 17:41:47 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <4F2A8FE1.2050109@oracle.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A8FE1.2050109@oracle.com> Message-ID: <104337CD-49D4-4466-BEE5-E9EF2E4B58FA@oracle.com> In Cocoa, extra mouse buttons are numbered starting from 3 (0, 1, 2 are left, right and center buttons). In Java, extra mouse buttons are numbered starting from 4 (1, 2 and 3 are left, center and right). So, in order to translate NS extra button number into Java button number we just +1 it. On 02.02.2012, at 17:30, Alexander Potochkin wrote: > Hello Leonid > > Could you comment the change in the NSEvent.nsButtonToJavaButton() method? > > Thanks > alexp > >> Hi, >> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >> >> Thanks, >> Leonid. >> >> > From artem.ananiev at oracle.com Thu Feb 2 05:47:19 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 02 Feb 2012 17:47:19 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A7E89.60402@oracle.com> Message-ID: <4F2A93E7.7020008@oracle.com> On 2/2/2012 4:37 PM, Leonid Romanov wrote: > > On 02.02.2012, at 16:16, Artem Ananiev wrote: > >> Some comments from my side: >> >> 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). > > So, your suggestion is to use JNI field-access methods to get these cached values in native every time we need them, right? Access a field via JNI, or call a method via JNI, or something like this. At least, have a single copy of gsNumberOfButtons and gsButtonDownMasks and reference it both from CRobot and AWTEvent. >> 2. I wonder how the following piece of code is expected to work: >> >> robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) >> >> Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. > > We don't support it because it doesn't make sense: real user can't press both buttons exactly at the same time, one of the buttons would always be pressed before the other. Real users can't, but java.awt.Robot can. It's a robot! :) Robot.mousePress() JavaDoc explicitly states that several buttons may be pressed at once. So it would be fine to support this case... Thanks, Artem >> Thanks, >> >> Artem >> >> On 2/2/2012 2:49 PM, Leonid Romanov wrote: >>> Hi, >>> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >>> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >>> >>> Thanks, >>> Leonid. >>> >>> > From Alexander.Potochkin at oracle.com Thu Feb 2 05:51:04 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 02 Feb 2012 17:51:04 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <104337CD-49D4-4466-BEE5-E9EF2E4B58FA@oracle.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A8FE1.2050109@oracle.com> <104337CD-49D4-4466-BEE5-E9EF2E4B58FA@oracle.com> Message-ID: <4F2A94C8.5010403@oracle.com> Hello Leonid > In Cocoa, extra mouse buttons are numbered starting from 3 (0, 1, 2 are left, right and center buttons). In Java, extra mouse buttons are numbered starting from 4 (1, 2 and 3 are left, center and right). So, in order to translate NS extra button number into Java button number we just +1 it. Aga, I see it The fix looks good to me Thanks alexp > > > On 02.02.2012, at 17:30, Alexander Potochkin wrote: > >> Hello Leonid >> >> Could you comment the change in the NSEvent.nsButtonToJavaButton() method? >> >> Thanks >> alexp >> >>> Hi, >>> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >>> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >>> >>> Thanks, >>> Leonid. >>> >>> From anthony.petrov at oracle.com Thu Feb 2 06:38:48 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 02 Feb 2012 18:38:48 +0400 Subject: Request for review: 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails In-Reply-To: <4F2A90E7.60905@oracle.com> References: <4F293800.1020701@oracle.com> <4F2966E2.9010101@oracle.com> <4F29711B.5030509@oracle.com> <4F298BDA.8030600@oracle.com> <4F2A79D4.6030505@oracle.com> <4F2A839C.3030703@oracle.com> <4F2A90E7.60905@oracle.com> Message-ID: <4F2A9FF8.7050703@oracle.com> Thanks for filing the RFE. I'm OK with the current fix then. -- best regards, Anthony On 02/02/12 17:34, Sergey Bylokhov wrote: > Done: > http://monaco.us.oracle.com/detail.jsf?cr=7142091 > > 02.02.2012 16:37, Anthony Petrov wrote: >> On 02/02/12 15:56, Sergey Bylokhov wrote: >>> 01.02.2012 23:00, Anthony Petrov wrote: >>>> On 2/1/2012 9:06 PM, Sergey Bylokhov wrote: >>>>> 01.02.2012 20:22, Anthony Petrov ?????: >>>>>> All the other peers call super.initialize() in the beginning of >>>>>> their overridden initialize() methods, and making an exception just >>>>>> for the LWWindowPeer seems to be inconsistent. >>>>> Well, I believe that all other components should call >>>>> super.initialize() at the end too. I just have no time to test them >>>>> all. Because it is cause lots of unnecessary repaints. We shouldn't >>>>> initialize components after we show them. >>>> >>>> I agree, partially. I believe that the setVisible() call should indeed >>>> follow all other initialization. However, the rest of settings which >>>> LWComponentPeer.initialize() performs should go ahead of custom >>>> initialization performed by specialized peers, because custom >>>> initializers may in theory tweak the general settings. >>> Well, if custom initializer want to tweak the general settings, it >>> should tweak it not just during initialization but during regular >>> changes too? For example if sub class want to tweak its bounds it should >>> do it in setBounds not in initialization. I'll create separate RFE for >>> refactoring of peer initialization. >> >> Thanks. >> >> -- >> best regards, >> Anthony >> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>>>> Since the only reason for that is to postpone the setVisible() call, >>>>>> I would suggest either introducing pre- and post-Initialize() >>>>>> methods (the approach is similar to XToolkit), or there might be a >>>>>> flag that could be reset in LWWindowPeer ctor that would indicate >>>>>> that LWComponentPeer.initialize() shouldn't call setVisible(). Then, >>>>>> the LWWindowPeer.initialize() would call setVisible() as its last >>>>>> step. >>>>>> >>>>>> It just seems that having the inconsistency as present in your >>>>>> current fix may hurt us in the future when e.g. we modify the logic >>>>>> in the LWComponentPeer.initialize() and would expect it to be in >>>>>> effect before setting additional properties for the LWWindowPeer. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 2/1/2012 5:02 PM, Sergey Bylokhov wrote: >>>>>>> Hi Everyone, >>>>>>> Peers shouldn't accumulate an alpha after repainting, so clearRect >>>>>>> was added. And now we call setVisible for window after full >>>>>>> initialization. >>>>>>> >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 >>>>>>> Webrev can be found at: >>>>>>> http://cr.openjdk.java.net/~serb/7131367/webrev.00/ >>>>>>> >>>>> >>>>> >>> >>> > > From leonid.romanov at oracle.com Thu Feb 2 06:56:09 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 2 Feb 2012 18:56:09 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <4F2A93E7.7020008@oracle.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A7E89.60402@oracle.com> <4F2A93E7.7020008@oracle.com> Message-ID: <50334BE0-5249-49EC-B54B-520AE77EA130@oracle.com> I think caching in native is better than in java. I suggest I left a single copy of gsNumberOfButtons and gsButtonDownMasks in AWTEvent, because they seem to be events related, and modify Robot code to refer to AWTEvent's copy of gsNumberOfButtons and gsButtonDownMasks. Is it OK to you? On 02.02.2012, at 17:47, Artem Ananiev wrote: > > On 2/2/2012 4:37 PM, Leonid Romanov wrote: >> >> On 02.02.2012, at 16:16, Artem Ananiev wrote: >> >>> Some comments from my side: >>> >>> 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). >> >> So, your suggestion is to use JNI field-access methods to get these cached values in native every time we need them, right? > > Access a field via JNI, or call a method via JNI, or something like this. At least, have a single copy of gsNumberOfButtons and gsButtonDownMasks and reference it both from CRobot and AWTEvent. > >>> 2. I wonder how the following piece of code is expected to work: >>> >>> robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) >>> >>> Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. >> >> We don't support it because it doesn't make sense: real user can't press both buttons exactly at the same time, one of the buttons would always be pressed before the other. > > Real users can't, but java.awt.Robot can. It's a robot! :) > > Robot.mousePress() JavaDoc explicitly states that several buttons may be pressed at once. So it would be fine to support this case... > > Thanks, > > Artem > >>> Thanks, >>> >>> Artem >>> >>> On 2/2/2012 2:49 PM, Leonid Romanov wrote: >>>> Hi, >>>> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >>>> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >>>> >>>> Thanks, >>>> Leonid. >>>> >>>> >> From artem.ananiev at oracle.com Thu Feb 2 07:17:29 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 02 Feb 2012 19:17:29 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <50334BE0-5249-49EC-B54B-520AE77EA130@oracle.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A7E89.60402@oracle.com> <4F2A93E7.7020008@oracle.com> <50334BE0-5249-49EC-B54B-520AE77EA130@oracle.com> Message-ID: <4F2AA909.30608@oracle.com> On 2/2/2012 6:56 PM, Leonid Romanov wrote: > I think caching in native is better than in java. I suggest I left a single copy of gsNumberOfButtons and gsButtonDownMasks in AWTEvent, because they seem to be events related, and modify Robot code to refer to AWTEvent's copy of gsNumberOfButtons and gsButtonDownMasks. Is it OK to you? Sounds good. Thanks, Artem > On 02.02.2012, at 17:47, Artem Ananiev wrote: > >> >> On 2/2/2012 4:37 PM, Leonid Romanov wrote: >>> >>> On 02.02.2012, at 16:16, Artem Ananiev wrote: >>> >>>> Some comments from my side: >>>> >>>> 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). >>> >>> So, your suggestion is to use JNI field-access methods to get these cached values in native every time we need them, right? >> >> Access a field via JNI, or call a method via JNI, or something like this. At least, have a single copy of gsNumberOfButtons and gsButtonDownMasks and reference it both from CRobot and AWTEvent. >> >>>> 2. I wonder how the following piece of code is expected to work: >>>> >>>> robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) >>>> >>>> Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. >>> >>> We don't support it because it doesn't make sense: real user can't press both buttons exactly at the same time, one of the buttons would always be pressed before the other. >> >> Real users can't, but java.awt.Robot can. It's a robot! :) >> >> Robot.mousePress() JavaDoc explicitly states that several buttons may be pressed at once. So it would be fine to support this case... >> >> Thanks, >> >> Artem >> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 2/2/2012 2:49 PM, Leonid Romanov wrote: >>>>> Hi, >>>>> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >>>>> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >>>>> >>>>> Thanks, >>>>> Leonid. >>>>> >>>>> >>> > From henri.gomez at gmail.com Thu Feb 2 07:39:20 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 2 Feb 2012 16:39:20 +0100 Subject: JDK 7 Mac Port Preview b227 Available In-Reply-To: <9A4C3F08-35D6-4397-9915-D71BBA504731@gmail.com> References: <4F22F2BE.50008@oracle.com> <9A4C3F08-35D6-4397-9915-D71BBA504731@gmail.com> Message-ID: 2012/2/2 Michael Hall : > > On Feb 1, 2012, at 5:19 PM, Michael Hall wrote: > >> >> file "/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/bin/java" >> /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/bin/java: Mach-O 64-bit executable x86_64 > > Sorry, this alone may not be clear. Is the omission of i386 intentional or inadvertent in the b227 Preview? OpenJDK 1.7 from update branch is no more universal. It's a 64bits VM only. I reported it some weeks ago, but decisions to stop 32/64bits has been taken by Oracle/Apple teams. From leonid.romanov at oracle.com Thu Feb 2 07:41:09 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 2 Feb 2012 19:41:09 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <4F2AA909.30608@oracle.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A7E89.60402@oracle.com> <4F2A93E7.7020008@oracle.com> <50334BE0-5249-49EC-B54B-520AE77EA130@oracle.com> <4F2AA909.30608@oracle.com> Message-ID: <8B3C8FAD-D232-4F3E-B4F1-D8ACEE9698FD@oracle.com> Updated webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.01/ On 02.02.2012, at 19:17, Artem Ananiev wrote: > > On 2/2/2012 6:56 PM, Leonid Romanov wrote: >> I think caching in native is better than in java. I suggest I left a single copy of gsNumberOfButtons and gsButtonDownMasks in AWTEvent, because they seem to be events related, and modify Robot code to refer to AWTEvent's copy of gsNumberOfButtons and gsButtonDownMasks. Is it OK to you? > > Sounds good. > > Thanks, > > Artem > >> On 02.02.2012, at 17:47, Artem Ananiev wrote: >> >>> >>> On 2/2/2012 4:37 PM, Leonid Romanov wrote: >>>> >>>> On 02.02.2012, at 16:16, Artem Ananiev wrote: >>>> >>>>> Some comments from my side: >>>>> >>>>> 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). >>>> >>>> So, your suggestion is to use JNI field-access methods to get these cached values in native every time we need them, right? >>> >>> Access a field via JNI, or call a method via JNI, or something like this. At least, have a single copy of gsNumberOfButtons and gsButtonDownMasks and reference it both from CRobot and AWTEvent. >>> >>>>> 2. I wonder how the following piece of code is expected to work: >>>>> >>>>> robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) >>>>> >>>>> Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. >>>> >>>> We don't support it because it doesn't make sense: real user can't press both buttons exactly at the same time, one of the buttons would always be pressed before the other. >>> >>> Real users can't, but java.awt.Robot can. It's a robot! :) >>> >>> Robot.mousePress() JavaDoc explicitly states that several buttons may be pressed at once. So it would be fine to support this case... >>> >>> Thanks, >>> >>> Artem >>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 2/2/2012 2:49 PM, Leonid Romanov wrote: >>>>>> Hi, >>>>>> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >>>>>> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Leonid. >>>>>> >>>>>> >>>> >> From paul.hohensee at oracle.com Thu Feb 2 07:48:08 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 02 Feb 2012 10:48:08 -0500 Subject: JDK 7 Mac Port Preview b227 Available In-Reply-To: References: <4F22F2BE.50008@oracle.com> <9A4C3F08-35D6-4397-9915-D71BBA504731@gmail.com> Message-ID: <4F2AB038.6030101@oracle.com> Things keep changing. Just pushed to hsx/hotspot-rt and destined for 7u4 is 7123386: RFE: Preserve universal builds of HotSpot on Mac OS X Should show up in jdk7u-dev next Wed. Paul On 2/2/12 10:39 AM, Henri Gomez wrote: > 2012/2/2 Michael Hall: >> On Feb 1, 2012, at 5:19 PM, Michael Hall wrote: >> >>> file "/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/bin/java" >>> /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/bin/java: Mach-O 64-bit executable x86_64 >> Sorry, this alone may not be clear. Is the omission of i386 intentional or inadvertent in the b227 Preview? > OpenJDK 1.7 from update branch is no more universal. It's a 64bits VM only. > I reported it some weeks ago, but decisions to stop 32/64bits has been > taken by Oracle/Apple teams. From artem.ananiev at oracle.com Thu Feb 2 08:05:06 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 02 Feb 2012 20:05:06 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <8B3C8FAD-D232-4F3E-B4F1-D8ACEE9698FD@oracle.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A7E89.60402@oracle.com> <4F2A93E7.7020008@oracle.com> <50334BE0-5249-49EC-B54B-520AE77EA130@oracle.com> <4F2AA909.30608@oracle.com> <8B3C8FAD-D232-4F3E-B4F1-D8ACEE9698FD@oracle.com> Message-ID: <4F2AB432.6080602@oracle.com> On 2/2/2012 7:41 PM, Leonid Romanov wrote: > Updated webrev: > http://cr.openjdk.java.net/~leonidr/7124382/webrev.01/ You should also make sure AWTEvent is initialized before CRobot. Otherwise, gNumberOfButtons (which is referenced in initRobot()) will not have a correct value. Thanks, Artem > On 02.02.2012, at 19:17, Artem Ananiev wrote: > >> >> On 2/2/2012 6:56 PM, Leonid Romanov wrote: >>> I think caching in native is better than in java. I suggest I left a single copy of gsNumberOfButtons and gsButtonDownMasks in AWTEvent, because they seem to be events related, and modify Robot code to refer to AWTEvent's copy of gsNumberOfButtons and gsButtonDownMasks. Is it OK to you? >> >> Sounds good. >> >> Thanks, >> >> Artem >> >>> On 02.02.2012, at 17:47, Artem Ananiev wrote: >>> >>>> >>>> On 2/2/2012 4:37 PM, Leonid Romanov wrote: >>>>> >>>>> On 02.02.2012, at 16:16, Artem Ananiev wrote: >>>>> >>>>>> Some comments from my side: >>>>>> >>>>>> 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). >>>>> >>>>> So, your suggestion is to use JNI field-access methods to get these cached values in native every time we need them, right? >>>> >>>> Access a field via JNI, or call a method via JNI, or something like this. At least, have a single copy of gsNumberOfButtons and gsButtonDownMasks and reference it both from CRobot and AWTEvent. >>>> >>>>>> 2. I wonder how the following piece of code is expected to work: >>>>>> >>>>>> robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) >>>>>> >>>>>> Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. >>>>> >>>>> We don't support it because it doesn't make sense: real user can't press both buttons exactly at the same time, one of the buttons would always be pressed before the other. >>>> >>>> Real users can't, but java.awt.Robot can. It's a robot! :) >>>> >>>> Robot.mousePress() JavaDoc explicitly states that several buttons may be pressed at once. So it would be fine to support this case... >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>> On 2/2/2012 2:49 PM, Leonid Romanov wrote: >>>>>>> Hi, >>>>>>> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >>>>>>> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Leonid. >>>>>>> >>>>>>> >>>>> >>> > From sergey.bylokhov at oracle.com Thu Feb 2 08:40:11 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 02 Feb 2012 20:40:11 +0400 Subject: [7u4] Request for approval for CR 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails Message-ID: <4F2ABC6B.5000109@oracle.com> Hello, This is a request to push the following changes to jdk7u-dev. The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 Webrev can be found at: http://cr.openjdk.java.net/~serb/7131367/webrev.00/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002726.html -- Best regards, Sergey. From paul.hohensee at oracle.com Thu Feb 2 08:48:32 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 02 Feb 2012 11:48:32 -0500 Subject: JDK 7 Mac Port Preview b227 Available In-Reply-To: <4F2AB038.6030101@oracle.com> References: <4F22F2BE.50008@oracle.com> <9A4C3F08-35D6-4397-9915-D71BBA504731@gmail.com> <4F2AB038.6030101@oracle.com> Message-ID: <4F2ABE60.2040000@oracle.com> I should have added that though the binaries are universal, they don't actually contain 32-bit code. The framework for adding that is there though. Paul On 2/2/12 10:48 AM, Paul Hohensee wrote: > Things keep changing. > > Just pushed to hsx/hotspot-rt and destined for 7u4 is > > 7123386: RFE: Preserve universal builds of HotSpot on Mac OS X > > Should show up in jdk7u-dev next Wed. > > Paul > > On 2/2/12 10:39 AM, Henri Gomez wrote: >> 2012/2/2 Michael Hall: >>> On Feb 1, 2012, at 5:19 PM, Michael Hall wrote: >>> >>>> file "/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer >>>> Preview.jdk/Contents/Home/bin/java" >>>> /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer >>>> Preview.jdk/Contents/Home/bin/java: Mach-O 64-bit executable x86_64 >>> Sorry, this alone may not be clear. Is the omission of i386 >>> intentional or inadvertent in the b227 Preview? >> OpenJDK 1.7 from update branch is no more universal. It's a 64bits VM >> only. >> I reported it some weeks ago, but decisions to stop 32/64bits has been >> taken by Oracle/Apple teams. From leonid.romanov at oracle.com Thu Feb 2 08:52:34 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 2 Feb 2012 20:52:34 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <4F2AB432.6080602@oracle.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A7E89.60402@oracle.com> <4F2A93E7.7020008@oracle.com> <50334BE0-5249-49EC-B54B-520AE77EA130@oracle.com> <4F2AA909.30608@oracle.com> <8B3C8FAD-D232-4F3E-B4F1-D8ACEE9698FD@oracle.com> <4F2AB432.6080602@oracle.com> Message-ID: <5E0FE4F0-A42F-400A-949C-4AB887807937@oracle.com> Ok, I moved them to LWCToolkit: http://cr.openjdk.java.net/~leonidr/7124382/webrev.02/ On 02.02.2012, at 20:05, Artem Ananiev wrote: > > On 2/2/2012 7:41 PM, Leonid Romanov wrote: >> Updated webrev: >> http://cr.openjdk.java.net/~leonidr/7124382/webrev.01/ > > You should also make sure AWTEvent is initialized before CRobot. Otherwise, gNumberOfButtons (which is referenced in initRobot()) will not have a correct value. > > Thanks, > > Artem > >> On 02.02.2012, at 19:17, Artem Ananiev wrote: >> >>> >>> On 2/2/2012 6:56 PM, Leonid Romanov wrote: >>>> I think caching in native is better than in java. I suggest I left a single copy of gsNumberOfButtons and gsButtonDownMasks in AWTEvent, because they seem to be events related, and modify Robot code to refer to AWTEvent's copy of gsNumberOfButtons and gsButtonDownMasks. Is it OK to you? >>> >>> Sounds good. >>> >>> Thanks, >>> >>> Artem >>> >>>> On 02.02.2012, at 17:47, Artem Ananiev wrote: >>>> >>>>> >>>>> On 2/2/2012 4:37 PM, Leonid Romanov wrote: >>>>>> >>>>>> On 02.02.2012, at 16:16, Artem Ananiev wrote: >>>>>> >>>>>>> Some comments from my side: >>>>>>> >>>>>>> 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). >>>>>> >>>>>> So, your suggestion is to use JNI field-access methods to get these cached values in native every time we need them, right? >>>>> >>>>> Access a field via JNI, or call a method via JNI, or something like this. At least, have a single copy of gsNumberOfButtons and gsButtonDownMasks and reference it both from CRobot and AWTEvent. >>>>> >>>>>>> 2. I wonder how the following piece of code is expected to work: >>>>>>> >>>>>>> robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) >>>>>>> >>>>>>> Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. >>>>>> >>>>>> We don't support it because it doesn't make sense: real user can't press both buttons exactly at the same time, one of the buttons would always be pressed before the other. >>>>> >>>>> Real users can't, but java.awt.Robot can. It's a robot! :) >>>>> >>>>> Robot.mousePress() JavaDoc explicitly states that several buttons may be pressed at once. So it would be fine to support this case... >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Artem >>>>>>> >>>>>>> On 2/2/2012 2:49 PM, Leonid Romanov wrote: >>>>>>>> Hi, >>>>>>>> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >>>>>>>> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Leonid. >>>>>>>> >>>>>>>> >>>>>> >>>> >> From artem.ananiev at oracle.com Thu Feb 2 09:38:29 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 02 Feb 2012 21:38:29 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <5E0FE4F0-A42F-400A-949C-4AB887807937@oracle.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A7E89.60402@oracle.com> <4F2A93E7.7020008@oracle.com> <50334BE0-5249-49EC-B54B-520AE77EA130@oracle.com> <4F2AA909.30608@oracle.com> <8B3C8FAD-D232-4F3E-B4F1-D8ACEE9698FD@oracle.com> <4F2AB432.6080602@oracle.com> <5E0FE4F0-A42F-400A-949C-4AB887807937@oracle.com> Message-ID: <4F2ACA15.4030709@oracle.com> OK, looks fine. Thanks, Artem On 2/2/2012 8:52 PM, Leonid Romanov wrote: > Ok, I moved them to LWCToolkit: > http://cr.openjdk.java.net/~leonidr/7124382/webrev.02/ > > On 02.02.2012, at 20:05, Artem Ananiev wrote: > >> >> On 2/2/2012 7:41 PM, Leonid Romanov wrote: >>> Updated webrev: >>> http://cr.openjdk.java.net/~leonidr/7124382/webrev.01/ >> >> You should also make sure AWTEvent is initialized before CRobot. Otherwise, gNumberOfButtons (which is referenced in initRobot()) will not have a correct value. >> >> Thanks, >> >> Artem >> >>> On 02.02.2012, at 19:17, Artem Ananiev wrote: >>> >>>> >>>> On 2/2/2012 6:56 PM, Leonid Romanov wrote: >>>>> I think caching in native is better than in java. I suggest I left a single copy of gsNumberOfButtons and gsButtonDownMasks in AWTEvent, because they seem to be events related, and modify Robot code to refer to AWTEvent's copy of gsNumberOfButtons and gsButtonDownMasks. Is it OK to you? >>>> >>>> Sounds good. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>>> On 02.02.2012, at 17:47, Artem Ananiev wrote: >>>>> >>>>>> >>>>>> On 2/2/2012 4:37 PM, Leonid Romanov wrote: >>>>>>> >>>>>>> On 02.02.2012, at 16:16, Artem Ananiev wrote: >>>>>>> >>>>>>>> Some comments from my side: >>>>>>>> >>>>>>>> 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). >>>>>>> >>>>>>> So, your suggestion is to use JNI field-access methods to get these cached values in native every time we need them, right? >>>>>> >>>>>> Access a field via JNI, or call a method via JNI, or something like this. At least, have a single copy of gsNumberOfButtons and gsButtonDownMasks and reference it both from CRobot and AWTEvent. >>>>>> >>>>>>>> 2. I wonder how the following piece of code is expected to work: >>>>>>>> >>>>>>>> robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) >>>>>>>> >>>>>>>> Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. >>>>>>> >>>>>>> We don't support it because it doesn't make sense: real user can't press both buttons exactly at the same time, one of the buttons would always be pressed before the other. >>>>>> >>>>>> Real users can't, but java.awt.Robot can. It's a robot! :) >>>>>> >>>>>> Robot.mousePress() JavaDoc explicitly states that several buttons may be pressed at once. So it would be fine to support this case... >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Artem >>>>>>>> >>>>>>>> On 2/2/2012 2:49 PM, Leonid Romanov wrote: >>>>>>>>> Hi, >>>>>>>>> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >>>>>>>>> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Leonid. >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From Leonid.Romanov at oracle.com Thu Feb 2 09:37:08 2012 From: Leonid.Romanov at oracle.com (Leonid Romanov) Date: Thu, 2 Feb 2012 21:37:08 +0400 Subject: [7u4] Request for approval for CR 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' Message-ID: Hi, This is a request to push the following changes to jdk7u-dev: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.02/ The fix has been reviewed on macosx-port-dev mailing list by Artem Ananiev Thanks, Leonid. From swingler at apple.com Thu Feb 2 09:38:28 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 02 Feb 2012 09:38:28 -0800 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <4F2AB432.6080602@oracle.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A7E89.60402@oracle.com> <4F2A93E7.7020008@oracle.com> <50334BE0-5249-49EC-B54B-520AE77EA130@oracle.com> <4F2AA909.30608@oracle.com> <8B3C8FAD-D232-4F3E-B4F1-D8ACEE9698FD@oracle.com> <4F2AB432.6080602@oracle.com> Message-ID: <757DBAF1-D75A-4889-995E-91209A70BEC4@apple.com> Globally caching the number of buttons is a horrible thing to do. That number changes at runtime, all of the time. What happens if the process is started under a Screen Sharing session with no console attached (like a server), and then later gets plugged in? What happens when your Bluetooth mouse suddenly comes within range? Can this be done without statically caching the number of buttons, and returning the correct number at the time of the call? If the app wants to do the wrong thing and cache that value, you can't stop that, but you can at least enable apps that want to do the right thing to actually be able. Regards, Mike Swingler Apple Inc. On Feb 2, 2012, at 8:05 AM, Artem Ananiev wrote: > > On 2/2/2012 7:41 PM, Leonid Romanov wrote: >> Updated webrev: >> http://cr.openjdk.java.net/~leonidr/7124382/webrev.01/ > > You should also make sure AWTEvent is initialized before CRobot. Otherwise, gNumberOfButtons (which is referenced in initRobot()) will not have a correct value. > > Thanks, > > Artem > >> On 02.02.2012, at 19:17, Artem Ananiev wrote: >> >>> >>> On 2/2/2012 6:56 PM, Leonid Romanov wrote: >>>> I think caching in native is better than in java. I suggest I left a single copy of gsNumberOfButtons and gsButtonDownMasks in AWTEvent, because they seem to be events related, and modify Robot code to refer to AWTEvent's copy of gsNumberOfButtons and gsButtonDownMasks. Is it OK to you? >>> >>> Sounds good. >>> >>> Thanks, >>> >>> Artem >>> >>>> On 02.02.2012, at 17:47, Artem Ananiev wrote: >>>> >>>>> >>>>> On 2/2/2012 4:37 PM, Leonid Romanov wrote: >>>>>> >>>>>> On 02.02.2012, at 16:16, Artem Ananiev wrote: >>>>>> >>>>>>> Some comments from my side: >>>>>>> >>>>>>> 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). >>>>>> >>>>>> So, your suggestion is to use JNI field-access methods to get these cached values in native every time we need them, right? >>>>> >>>>> Access a field via JNI, or call a method via JNI, or something like this. At least, have a single copy of gsNumberOfButtons and gsButtonDownMasks and reference it both from CRobot and AWTEvent. >>>>> >>>>>>> 2. I wonder how the following piece of code is expected to work: >>>>>>> >>>>>>> robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) >>>>>>> >>>>>>> Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. >>>>>> >>>>>> We don't support it because it doesn't make sense: real user can't press both buttons exactly at the same time, one of the buttons would always be pressed before the other. >>>>> >>>>> Real users can't, but java.awt.Robot can. It's a robot! :) >>>>> >>>>> Robot.mousePress() JavaDoc explicitly states that several buttons may be pressed at once. So it would be fine to support this case... >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Artem >>>>>>> >>>>>>> On 2/2/2012 2:49 PM, Leonid Romanov wrote: >>>>>>>> Hi, >>>>>>>> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >>>>>>>> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Leonid. >>>>>>>> >>>>>>>> >>>>>> >>>> >> From artem.ananiev at oracle.com Thu Feb 2 09:46:28 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 02 Feb 2012 21:46:28 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <757DBAF1-D75A-4889-995E-91209A70BEC4@apple.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A7E89.60402@oracle.com> <4F2A93E7.7020008@oracle.com> <50334BE0-5249-49EC-B54B-520AE77EA130@oracle.com> <4F2AA909.30608@oracle.com> <8B3C8FAD-D232-4F3E-B4F1-D8ACEE9698FD@oracle.com> <4F2AB432.6080602@oracle.com> <757DBAF1-D75A-4889-995E-91209A70BEC4@apple.com> Message-ID: <4F2ACBF4.4040005@oracle.com> On 2/2/2012 9:38 PM, Mike Swingler wrote: > Globally caching the number of buttons is a horrible thing to do. That number changes at runtime, all of the time. > > What happens if the process is started under a Screen Sharing session with no console attached (like a server), and then later gets plugged in? What happens when your Bluetooth mouse suddenly comes within range? > > Can this be done without statically caching the number of buttons, and returning the correct number at the time of the call? If the app wants to do the wrong thing and cache that value, you can't stop that, but you can at least enable apps that want to do the right thing to actually be able. I completely agree, but AWT shared code is not ready for that. And we do caching on other platforms right now :( It should be addressed in a separate fix. Thanks, Artem > Regards, > Mike Swingler > Apple Inc. > > On Feb 2, 2012, at 8:05 AM, Artem Ananiev wrote: > >> >> On 2/2/2012 7:41 PM, Leonid Romanov wrote: >>> Updated webrev: >>> http://cr.openjdk.java.net/~leonidr/7124382/webrev.01/ >> >> You should also make sure AWTEvent is initialized before CRobot. Otherwise, gNumberOfButtons (which is referenced in initRobot()) will not have a correct value. >> >> Thanks, >> >> Artem >> >>> On 02.02.2012, at 19:17, Artem Ananiev wrote: >>> >>>> >>>> On 2/2/2012 6:56 PM, Leonid Romanov wrote: >>>>> I think caching in native is better than in java. I suggest I left a single copy of gsNumberOfButtons and gsButtonDownMasks in AWTEvent, because they seem to be events related, and modify Robot code to refer to AWTEvent's copy of gsNumberOfButtons and gsButtonDownMasks. Is it OK to you? >>>> >>>> Sounds good. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>>> On 02.02.2012, at 17:47, Artem Ananiev wrote: >>>>> >>>>>> >>>>>> On 2/2/2012 4:37 PM, Leonid Romanov wrote: >>>>>>> >>>>>>> On 02.02.2012, at 16:16, Artem Ananiev wrote: >>>>>>> >>>>>>>> Some comments from my side: >>>>>>>> >>>>>>>> 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). >>>>>>> >>>>>>> So, your suggestion is to use JNI field-access methods to get these cached values in native every time we need them, right? >>>>>> >>>>>> Access a field via JNI, or call a method via JNI, or something like this. At least, have a single copy of gsNumberOfButtons and gsButtonDownMasks and reference it both from CRobot and AWTEvent. >>>>>> >>>>>>>> 2. I wonder how the following piece of code is expected to work: >>>>>>>> >>>>>>>> robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) >>>>>>>> >>>>>>>> Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. >>>>>>> >>>>>>> We don't support it because it doesn't make sense: real user can't press both buttons exactly at the same time, one of the buttons would always be pressed before the other. >>>>>> >>>>>> Real users can't, but java.awt.Robot can. It's a robot! :) >>>>>> >>>>>> Robot.mousePress() JavaDoc explicitly states that several buttons may be pressed at once. So it would be fine to support this case... >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Artem >>>>>>>> >>>>>>>> On 2/2/2012 2:49 PM, Leonid Romanov wrote: >>>>>>>>> Hi, >>>>>>>>> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >>>>>>>>> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Leonid. >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From alexander.zuev at oracle.com Thu Feb 2 10:46:18 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 02 Feb 2012 21:46:18 +0300 Subject: [jdk7u-dev] Request for approval for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' Message-ID: <4F2AD9FA.5030800@oracle.com> As Leonid does not have push permission and i will have to make push for him, to speed up the process i'm asking on his behalf to approve the fix for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' to be pushed into jdk7u-dev repository. Reviewed on macosx-port-dev by Artem Ananiev. Bug description: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 Webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.02/ With best regards, Alexander Zuev From leonid.romanov at oracle.com Thu Feb 2 09:50:33 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 2 Feb 2012 21:50:33 +0400 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <757DBAF1-D75A-4889-995E-91209A70BEC4@apple.com> References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A7E89.60402@oracle.com> <4F2A93E7.7020008@oracle.com> <50334BE0-5249-49EC-B54B-520AE77EA130@oracle.com> <4F2AA909.30608@oracle.com> <8B3C8FAD-D232-4F3E-B4F1-D8ACEE9698FD@oracle.com> <4F2AB432.6080602@oracle.com> <757DBAF1-D75A-4889-995E-91209A70BEC4@apple.com> Message-ID: Btw, what is the way for obtaining the number of buttons in OS X? The only solution I'm aware of is to use IOKit to find devices whose kIOHIDPrimaryUsagePageKey is kHIDPage_GenericDesktop and whose kIOHIDPrimaryUsageKey is kHIDUsage_GD_Pointer or kHIDUsage_GD_Mouse, and then search for the element on the kHIDPage_Button usage page with the highest usage value. On 02.02.2012, at 21:38, Mike Swingler wrote: > Globally caching the number of buttons is a horrible thing to do. That number changes at runtime, all of the time. > > What happens if the process is started under a Screen Sharing session with no console attached (like a server), and then later gets plugged in? What happens when your Bluetooth mouse suddenly comes within range? > > Can this be done without statically caching the number of buttons, and returning the correct number at the time of the call? If the app wants to do the wrong thing and cache that value, you can't stop that, but you can at least enable apps that want to do the right thing to actually be able. > > Regards, > Mike Swingler > Apple Inc. > > On Feb 2, 2012, at 8:05 AM, Artem Ananiev wrote: > >> >> On 2/2/2012 7:41 PM, Leonid Romanov wrote: >>> Updated webrev: >>> http://cr.openjdk.java.net/~leonidr/7124382/webrev.01/ >> >> You should also make sure AWTEvent is initialized before CRobot. Otherwise, gNumberOfButtons (which is referenced in initRobot()) will not have a correct value. >> >> Thanks, >> >> Artem >> >>> On 02.02.2012, at 19:17, Artem Ananiev wrote: >>> >>>> >>>> On 2/2/2012 6:56 PM, Leonid Romanov wrote: >>>>> I think caching in native is better than in java. I suggest I left a single copy of gsNumberOfButtons and gsButtonDownMasks in AWTEvent, because they seem to be events related, and modify Robot code to refer to AWTEvent's copy of gsNumberOfButtons and gsButtonDownMasks. Is it OK to you? >>>> >>>> Sounds good. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>>> On 02.02.2012, at 17:47, Artem Ananiev wrote: >>>>> >>>>>> >>>>>> On 2/2/2012 4:37 PM, Leonid Romanov wrote: >>>>>>> >>>>>>> On 02.02.2012, at 16:16, Artem Ananiev wrote: >>>>>>> >>>>>>>> Some comments from my side: >>>>>>>> >>>>>>>> 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). >>>>>>> >>>>>>> So, your suggestion is to use JNI field-access methods to get these cached values in native every time we need them, right? >>>>>> >>>>>> Access a field via JNI, or call a method via JNI, or something like this. At least, have a single copy of gsNumberOfButtons and gsButtonDownMasks and reference it both from CRobot and AWTEvent. >>>>>> >>>>>>>> 2. I wonder how the following piece of code is expected to work: >>>>>>>> >>>>>>>> robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) >>>>>>>> >>>>>>>> Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. >>>>>>> >>>>>>> We don't support it because it doesn't make sense: real user can't press both buttons exactly at the same time, one of the buttons would always be pressed before the other. >>>>>> >>>>>> Real users can't, but java.awt.Robot can. It's a robot! :) >>>>>> >>>>>> Robot.mousePress() JavaDoc explicitly states that several buttons may be pressed at once. So it would be fine to support this case... >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Artem >>>>>>>> >>>>>>>> On 2/2/2012 2:49 PM, Leonid Romanov wrote: >>>>>>>>> Hi, >>>>>>>>> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >>>>>>>>> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Leonid. >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From artem.ananiev at oracle.com Thu Feb 2 09:53:49 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 02 Feb 2012 21:53:49 +0400 Subject: [7u4] Request for approval for CR 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: References: Message-ID: <4F2ACDAD.3010901@oracle.com> Mike has raised some good concerns about the current fix. However, as they should be addressed separately, I'm approving this change for 7u-dev. Could you file a new bug (not only against Mac OS X, as it's applicable to all the platforms) to refactor AWT code for extra mouse buttons support to update number of buttons on the fly, please? Thanks, Artem On 2/2/2012 9:37 PM, Leonid Romanov wrote: > Hi, > This is a request to push the following changes to jdk7u-dev: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 > webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.02/ > > The fix has been reviewed on macosx-port-dev mailing list by Artem Ananiev > > Thanks, > Leonid. > > > From swingler at apple.com Thu Feb 2 11:10:28 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 02 Feb 2012 11:10:28 -0800 Subject: Review request for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: References: <57BED71E-5872-47C5-B436-D4D9C3C3D6C7@oracle.com> <4F2A7E89.60402@oracle.com> <4F2A93E7.7020008@oracle.com> <50334BE0-5249-49EC-B54B-520AE77EA130@oracle.com> <4F2AA909.30608@oracle.com> <8B3C8FAD-D232-4F3E-B4F1-D8ACEE9698FD@oracle.com> <4F2AB432.6080602@oracle.com> <757DBAF1-D75A-4889-995E-91209A70BEC4@apple.com> Message-ID: <83F69268-6F62-4577-9CF9-5DE652A6D9EB@apple.com> When asked on the internal lists, the answer is always "why do you want to know"? Frankly, I agree, if for no other reason, that the answer changes dynamically, and you should never have a UI that actually *requires* more than a single button, but will do more if more are present. If you care about button 8, just be prepared to get it. Crawling the device tree is basically the more accurate way to come up with this meaningless statistic. Regards, Mike Swingler Apple Inc. On Feb 2, 2012, at 9:50 AM, Leonid Romanov wrote: > Btw, what is the way for obtaining the number of buttons in OS X? The only solution I'm aware of is to use IOKit to find devices whose kIOHIDPrimaryUsagePageKey is kHIDPage_GenericDesktop and whose kIOHIDPrimaryUsageKey is kHIDUsage_GD_Pointer or kHIDUsage_GD_Mouse, and then search for the element on the kHIDPage_Button usage page with the highest usage value. > > On 02.02.2012, at 21:38, Mike Swingler wrote: > >> Globally caching the number of buttons is a horrible thing to do. That number changes at runtime, all of the time. >> >> What happens if the process is started under a Screen Sharing session with no console attached (like a server), and then later gets plugged in? What happens when your Bluetooth mouse suddenly comes within range? >> >> Can this be done without statically caching the number of buttons, and returning the correct number at the time of the call? If the app wants to do the wrong thing and cache that value, you can't stop that, but you can at least enable apps that want to do the right thing to actually be able. >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Feb 2, 2012, at 8:05 AM, Artem Ananiev wrote: >> >>> >>> On 2/2/2012 7:41 PM, Leonid Romanov wrote: >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~leonidr/7124382/webrev.01/ >>> >>> You should also make sure AWTEvent is initialized before CRobot. Otherwise, gNumberOfButtons (which is referenced in initRobot()) will not have a correct value. >>> >>> Thanks, >>> >>> Artem >>> >>>> On 02.02.2012, at 19:17, Artem Ananiev wrote: >>>> >>>>> >>>>> On 2/2/2012 6:56 PM, Leonid Romanov wrote: >>>>>> I think caching in native is better than in java. I suggest I left a single copy of gsNumberOfButtons and gsButtonDownMasks in AWTEvent, because they seem to be events related, and modify Robot code to refer to AWTEvent's copy of gsNumberOfButtons and gsButtonDownMasks. Is it OK to you? >>>>> >>>>> Sounds good. >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>>> On 02.02.2012, at 17:47, Artem Ananiev wrote: >>>>>> >>>>>>> >>>>>>> On 2/2/2012 4:37 PM, Leonid Romanov wrote: >>>>>>>> >>>>>>>> On 02.02.2012, at 16:16, Artem Ananiev wrote: >>>>>>>> >>>>>>>>> Some comments from my side: >>>>>>>>> >>>>>>>>> 1. It would be fine not to store gsNumberOfButtons and gsButtonDownMasks in the native code twice. Probably, caching may be done at the Java level, e.g. in LWCToolkit? BTW, static variables in native are really painful in MVM-like environment (if we ever really support it). >>>>>>>> >>>>>>>> So, your suggestion is to use JNI field-access methods to get these cached values in native every time we need them, right? >>>>>>> >>>>>>> Access a field via JNI, or call a method via JNI, or something like this. At least, have a single copy of gsNumberOfButtons and gsButtonDownMasks and reference it both from CRobot and AWTEvent. >>>>>>> >>>>>>>>> 2. I wonder how the following piece of code is expected to work: >>>>>>>>> >>>>>>>>> robot.mousePress(BUTTON1_DOWN_MASK | BUTTON2_DOWN_MASK) >>>>>>>>> >>>>>>>>> Should we post two native events in this case (CGEventCreateMouseEvent doesn't seem to support multiple buttons at once)? It's not a question about the current fix, but rather how it works, or doesn't work, right now. >>>>>>>> >>>>>>>> We don't support it because it doesn't make sense: real user can't press both buttons exactly at the same time, one of the buttons would always be pressed before the other. >>>>>>> >>>>>>> Real users can't, but java.awt.Robot can. It's a robot! :) >>>>>>> >>>>>>> Robot.mousePress() JavaDoc explicitly states that several buttons may be pressed at once. So it would be fine to support this case... >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Artem >>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Artem >>>>>>>>> >>>>>>>>> On 2/2/2012 2:49 PM, Leonid Romanov wrote: >>>>>>>>>> Hi, >>>>>>>>>> Please, review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.00/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Leonid. >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From edvard.wendelin at oracle.com Thu Feb 2 11:44:14 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 2 Feb 2012 20:44:14 +0100 Subject: [jdk7u-dev] Request for approval for 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' In-Reply-To: <4F2AD9FA.5030800@oracle.com> References: <4F2AD9FA.5030800@oracle.com> Message-ID: <635CC6D1-778C-41D2-8080-99AFAE9DDA74@oracle.com> Approved. On Feb 2, 2012, at 7:46 PM, Alexander Zuev wrote: > As Leonid does not have push permission and i will have to make push for him, > to speed up the process i'm asking on his behalf to approve the fix for > 7124382: [macosx] Property sun.awt.enableExtraMouseButtons is always 'false' > to be pushed into jdk7u-dev repository. > > Reviewed on macosx-port-dev by Artem Ananiev. > > Bug description: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124382 > > Webrev: http://cr.openjdk.java.net/~leonidr/7124382/webrev.02/ > > With best regards, > Alexander Zuev > > From edvard.wendelin at oracle.com Thu Feb 2 13:32:34 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 2 Feb 2012 22:32:34 +0100 Subject: Mac OS X port - update Message-ID: Hi, As you might have noticed, 7u-osx [1] was pushed to 7u-dev [2] yesterday. There will be a build from 7u-dev today that QA will run Pre-integration testing on. During the coming week, we will make sure that any potential quirks found in 7u-dev as a result of the osx integration are fixed before next weeks (Thu 9th) build promotion. This means that from next week on the regular promotions will contain OS X bundles just like the other platforms. We will soon also make the jdk7u-osx [1] forest read only. All fixes related to the Mac OS X port should from now on go through jdk7u-dev [2] and jdk7u-dev at openjdk.java.net. Cheers, Edvard [1] http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ [2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ From mik3hall at gmail.com Thu Feb 2 15:20:26 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 2 Feb 2012 17:20:26 -0600 Subject: JDK 7 Mac Port Preview b227 Available In-Reply-To: <4F2ABE60.2040000@oracle.com> References: <4F22F2BE.50008@oracle.com> <9A4C3F08-35D6-4397-9915-D71BBA504731@gmail.com> <4F2AB038.6030101@oracle.com> <4F2ABE60.2040000@oracle.com> Message-ID: On Feb 2, 2012, at 10:48 AM, Paul Hohensee wrote: > I should have added that though the binaries are universal, they don't > actually contain 32-bit code. The framework for adding that is there > though. > > Paul I guess I'll wait and see where things end up. Any chance in the interim for a link to the last preview that included 32 bit? I found a b215 in /System as opposed to /Library JavaVirtualMachines but a little more current would be nice. Thanks for the response. From martijnverburg at gmail.com Thu Feb 2 16:24:54 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 3 Feb 2012 01:24:54 +0100 Subject: Mac OS X port - update In-Reply-To: References: Message-ID: This is very cool news. As an observer watching the sheer number of commits fly past I'd just like to thank the effort of all of the engineers involved more getting the OpenJDK story on the Mac to this stage, it's been seriously impressive to watch. Cheers, Martijn On 2 February 2012 22:32, Edvard Wendelin wrote: > Hi, > > As you might have noticed, 7u-osx [1] ?was pushed to 7u-dev [2] yesterday. ?There will be a build from 7u-dev today that QA will run Pre-integration testing on. During the coming week, we will make sure that any potential quirks found in 7u-dev as a result of the osx integration are fixed before next weeks (Thu 9th) ?build promotion. This means that from next week on the regular promotions will contain OS X bundles just like the other platforms. We will soon also make the jdk7u-osx [1] forest read only. All fixes related to the Mac OS X port should from now ?on go through jdk7u-dev [2] and jdk7u-dev at openjdk.java.net. > > > Cheers, > Edvard > > [1] http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ > [2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ From david.holmes at oracle.com Thu Feb 2 18:10:53 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 03 Feb 2012 12:10:53 +1000 Subject: Mac OS X port - update In-Reply-To: References: Message-ID: <4F2B422D.20907@oracle.com> Edvard, On 3/02/2012 7:32 AM, Edvard Wendelin wrote: > Hi, > > As you might have noticed, 7u-osx [1] was pushed to 7u-dev [2] yesterday. There will be a build from 7u-dev today that QA will run Pre-integration testing on. During the coming week, we will make sure that any potential quirks found in 7u-dev as a result of the osx integration are fixed before next weeks (Thu 9th) build promotion. This means that from next week on the regular promotions will contain OS X bundles just like the other platforms. We will soon also make the jdk7u-osx [1] forest read only. All fixes related to the Mac OS X port should from now on go through jdk7u-dev [2] and jdk7u-dev at openjdk.java.net. I am concerned. There was some discussion when various changes went into 7u-osx regarding the suitability of the changes for inclusion in the mainline repositories ie 7u-dev. It was my understanding that there would be a more extensive review and, if necessary, clean up process, before those changes were merged into the mainline 7u-dev. I have only seen that happen for a couple of specific issues. David ----- > > Cheers, > Edvard > > [1] http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ > [2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ From weijun.wang at oracle.com Thu Feb 2 21:26:36 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 03 Feb 2012 13:26:36 +0800 Subject: error building jdk7u-osx on lion: run-generator... Message-ID: <4F2B700C.4050908@oracle.com> Hi All I've just updated my Mac to Lion, installed Xcode and Java. I cloned the jdk7u-dev repos and run make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` but it failed. What's wrong here? Thanks Max ------------------------------- run-generator: [mkdir] Created dir: /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/src/jobjc [exec] Current OS is Mac OS X [exec] Executing 'ruby' with arguments: [exec] './rungen' [exec] 'install' [exec] 'JObjC.jar' [exec] '/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.dst/Debug' [exec] '/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build' [exec] 'ppc i386 x86_64' [exec] '/Users/ww155710/work/osx-jdk/build/macosx-amd64/stable_bridge_metadata' [exec] [exec] The ' characters around the executable and arguments are [exec] not part of the command. [exec] ENV['JAVA_HOME'] = /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home [exec] java -fullversion = openjdk full version "1.7.0-internal-ww155710_2012_02_03_10_54-b00" [exec] jobjc_jar = JObjC.jar [exec] libpath = /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.dst/Debug [exec] objroot = /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build [exec] ARCHS = ppc i386 x86_64 [exec] STABLE_GEN_DIR = /Users/ww155710/work/osx-jdk/build/macosx-amd64/stable_bridge_metadata [exec] java -classpath /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/bin/core:/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/bin/generator com.apple.internal.jobjc.generator.BootClassPathMinus JObjC.jar [exec] bootclasspath is: [exec] Error occurred during initialization of VM [exec] java/lang/NoClassDefFoundError: java/lang/invoke/MethodHandle [exec] java -d64 -Xms128m -Xmx512m -Djava.library.path=/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.dst/Debug -Xbootclasspath:Error occurred during initialization of VM [exec] java/lang/NoClassDefFoundError: java/lang/invoke/MethodHandle -classpath /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/bin/core:/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/bin/generator -ea com.apple.internal.jobjc.generator.Generator dst=/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/src/jobjc frameworks=/Users/ww155710/work/osx-jdk/build/macosx-amd64/stable_bridge_metadata [exec] Error occurred during initialization of VM [exec] java/lang/NoClassDefFoundError: java/lang/Object [exec] sh: line 1: java/lang/NoClassDefFoundError:: No such file or directory [exec] ./rungen:67:in `raise': exception class/object expected (TypeError) [exec] from ./rungen:67 BUILD FAILED /Users/ww155710/work/osx-jdk/jdk/src/macosx/native/jobjc/build.xml:187: exec returned: 1 at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:646) at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:672) at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:498) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Total time: 31 seconds make[4]: *** [/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/JObjC.jar] Error 1 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [jdk-build] Error 2 make: *** [build_product_image] Error 2 From kirk at kodewerk.com Thu Feb 2 22:48:01 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 3 Feb 2012 07:48:01 +0100 Subject: Mac OS X port - update In-Reply-To: References: Message-ID: +1 Regards, Kirk On 2012-02-03, at 1:24 AM, Martijn Verburg wrote: > This is very cool news. As an observer watching the sheer number of > commits fly past I'd just like to thank the effort of all of the > engineers involved more getting the OpenJDK story on the Mac to this > stage, it's been seriously impressive to watch. > > Cheers, > Martijn > > On 2 February 2012 22:32, Edvard Wendelin wrote: >> Hi, >> >> As you might have noticed, 7u-osx [1] was pushed to 7u-dev [2] yesterday. There will be a build from 7u-dev today that QA will run Pre-integration testing on. During the coming week, we will make sure that any potential quirks found in 7u-dev as a result of the osx integration are fixed before next weeks (Thu 9th) build promotion. This means that from next week on the regular promotions will contain OS X bundles just like the other platforms. We will soon also make the jdk7u-osx [1] forest read only. All fixes related to the Mac OS X port should from now on go through jdk7u-dev [2] and jdk7u-dev at openjdk.java.net. >> >> >> Cheers, >> Edvard >> >> [1] http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ >> [2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ From henri.gomez at gmail.com Fri Feb 3 00:32:46 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 3 Feb 2012 09:32:46 +0100 Subject: Mac OS X port - update In-Reply-To: References: Message-ID: Very good news, I'll add a new build process on http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ for openjdk-osx-build project. Stay tuned 2012/2/3 Kirk Pepperdine : > +1 > > Regards, > Kirk > > On 2012-02-03, at 1:24 AM, Martijn Verburg wrote: > >> This is very cool news. ?As an observer watching the sheer number of >> commits fly past I'd just like to thank the effort of all of the >> engineers involved more getting the OpenJDK story on the Mac to this >> stage, it's been seriously impressive to watch. >> >> Cheers, >> Martijn >> >> On 2 February 2012 22:32, Edvard Wendelin wrote: >>> Hi, >>> >>> As you might have noticed, 7u-osx [1] ?was pushed to 7u-dev [2] yesterday. ?There will be a build from 7u-dev today that QA will run Pre-integration testing on. During the coming week, we will make sure that any potential quirks found in 7u-dev as a result of the osx integration are fixed before next weeks (Thu 9th) ?build promotion. This means that from next week on the regular promotions will contain OS X bundles just like the other platforms. We will soon also make the jdk7u-osx [1] forest read only. All fixes related to the Mac OS X port should from now ?on go through jdk7u-dev [2] and jdk7u-dev at openjdk.java.net. >>> >>> >>> Cheers, >>> Edvard >>> >>> [1] http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ >>> [2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ > From dmitry.cherepanov at oracle.com Fri Feb 3 02:07:36 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 03 Feb 2012 13:07:36 +0300 Subject: Review request for 7119760: (mac) The OpenGL queue flusher thread is created in the wrong thread group Message-ID: <4F2BB1E8.8000003@oracle.com> Hello, The cause of the issue is that the flusher thread belongs to the applet's thread group and the flusher thread dies when the applet quits and new applet fails to start (when it reuses the same instance of the JVM). The fix creates the flusher thread in the root thread group. http://cr.openjdk.java.net/~dcherepanov/7119760/webrev.0/ Thanks, Dmitry From henri.gomez at gmail.com Fri Feb 3 01:05:26 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 3 Feb 2012 10:05:26 +0100 Subject: JDK 7 Mac Port Preview b227 Available In-Reply-To: <4F2ABE60.2040000@oracle.com> References: <4F22F2BE.50008@oracle.com> <9A4C3F08-35D6-4397-9915-D71BBA504731@gmail.com> <4F2AB038.6030101@oracle.com> <4F2ABE60.2040000@oracle.com> Message-ID: > I should have added that though the binaries are universal, they don't > actually contain 32-bit code. ?The framework for adding that is there > though. Good news. Some Java applications don't require huge heap and using -d32 help save memory. Is it planned to be added back ? Should we add an issue somewhere to ask it and track progress on it ? Thanks From weijun.wang at oracle.com Fri Feb 3 01:06:37 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 03 Feb 2012 17:06:37 +0800 Subject: Mac OS X port - update In-Reply-To: References: Message-ID: <4F2BA39D.9010202@oracle.com> A question: The wiki does not mention install Apple JDK after Xcode for 10.7.3. Does this mean the step is not necessary anymore. So the yellow background text can be removed now? Thanks Max On 02/03/2012 04:32 PM, Henri Gomez wrote: > Very good news, I'll add a new build process on > http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ for openjdk-osx-build > project. > > Stay tuned > > 2012/2/3 Kirk Pepperdine: >> +1 >> >> Regards, >> Kirk >> >> On 2012-02-03, at 1:24 AM, Martijn Verburg wrote: >> >>> This is very cool news. As an observer watching the sheer number of >>> commits fly past I'd just like to thank the effort of all of the >>> engineers involved more getting the OpenJDK story on the Mac to this >>> stage, it's been seriously impressive to watch. >>> >>> Cheers, >>> Martijn >>> >>> On 2 February 2012 22:32, Edvard Wendelin wrote: >>>> Hi, >>>> >>>> As you might have noticed, 7u-osx [1] was pushed to 7u-dev [2] yesterday. There will be a build from 7u-dev today that QA will run Pre-integration testing on. During the coming week, we will make sure that any potential quirks found in 7u-dev as a result of the osx integration are fixed before next weeks (Thu 9th) build promotion. This means that from next week on the regular promotions will contain OS X bundles just like the other platforms. We will soon also make the jdk7u-osx [1] forest read only. All fixes related to the Mac OS X port should from now on go through jdk7u-dev [2] and jdk7u-dev at openjdk.java.net. >>>> >>>> >>>> Cheers, >>>> Edvard >>>> >>>> [1] http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ >>>> [2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ >> From weijun.wang at oracle.com Fri Feb 3 01:09:06 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 03 Feb 2012 17:09:06 +0800 Subject: error building jdk7u-osx on lion: run-generator... In-Reply-To: <4F2B700C.4050908@oracle.com> References: <4F2B700C.4050908@oracle.com> Message-ID: <4F2BA432.3020206@oracle.com> Maybe it's because I installed the Apple JDK after Xcode? I see that line removed from the wiki now. If so, shall I just reinstall Xcode? OS is 10.7.3 now. Thanks Max On 02/03/2012 01:26 PM, Weijun Wang wrote: > Hi All > > I've just updated my Mac to Lion, installed Xcode and Java. I cloned the > jdk7u-dev repos and run > > make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true > ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` > HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` > > but it failed. What's wrong here? > > Thanks > Max > > ------------------------------- > run-generator: > [mkdir] Created dir: > /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/src/jobjc > [exec] Current OS is Mac OS X > [exec] Executing 'ruby' with arguments: > [exec] './rungen' > [exec] 'install' > [exec] 'JObjC.jar' > [exec] '/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.dst/Debug' > [exec] '/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build' > [exec] 'ppc i386 x86_64' > [exec] > '/Users/ww155710/work/osx-jdk/build/macosx-amd64/stable_bridge_metadata' > [exec] > [exec] The ' characters around the executable and arguments are > [exec] not part of the command. > [exec] ENV['JAVA_HOME'] = > /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home > [exec] java -fullversion = openjdk full version > "1.7.0-internal-ww155710_2012_02_03_10_54-b00" > [exec] jobjc_jar = JObjC.jar > [exec] libpath = > /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.dst/Debug > [exec] objroot = > /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build > [exec] ARCHS = ppc i386 x86_64 > [exec] STABLE_GEN_DIR = > /Users/ww155710/work/osx-jdk/build/macosx-amd64/stable_bridge_metadata > [exec] java -classpath > /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/bin/core:/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/bin/generator > com.apple.internal.jobjc.generator.BootClassPathMinus JObjC.jar > [exec] bootclasspath is: > [exec] Error occurred during initialization of VM > [exec] java/lang/NoClassDefFoundError: java/lang/invoke/MethodHandle > [exec] java -d64 -Xms128m -Xmx512m > -Djava.library.path=/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.dst/Debug > -Xbootclasspath:Error occurred during initialization of VM > [exec] java/lang/NoClassDefFoundError: java/lang/invoke/MethodHandle > -classpath > /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/bin/core:/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/bin/generator > -ea com.apple.internal.jobjc.generator.Generator > dst=/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/src/jobjc frameworks=/Users/ww155710/work/osx-jdk/build/macosx-amd64/stable_bridge_metadata > > [exec] Error occurred during initialization of VM > [exec] java/lang/NoClassDefFoundError: java/lang/Object > [exec] sh: line 1: java/lang/NoClassDefFoundError:: No such file or > directory > [exec] ./rungen:67:in `raise': exception class/object expected (TypeError) > [exec] from ./rungen:67 > > BUILD FAILED > /Users/ww155710/work/osx-jdk/jdk/src/macosx/native/jobjc/build.xml:187: > exec returned: 1 > at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:646) > at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:672) > at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:498) > at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:390) > at org.apache.tools.ant.Target.performTasks(Target.java:411) > at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) > at org.apache.tools.ant.Project.executeTarget(Project.java:1368) > at > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > > at org.apache.tools.ant.Project.executeTargets(Project.java:1251) > at org.apache.tools.ant.Main.runBuild(Main.java:809) > at org.apache.tools.ant.Main.startAnt(Main.java:217) > at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) > at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) > > Total time: 31 seconds > make[4]: *** > [/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/JObjC.jar] > Error 1 > make[3]: *** [all] Error 1 > make[2]: *** [all] Error 1 > make[1]: *** [jdk-build] Error 2 > make: *** [build_product_image] Error 2 From david.katleman at sun.com Fri Feb 3 01:14:36 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 03 Feb 2012 09:14:36 +0000 Subject: hg: jdk7u/jdk7u-osx: Added tag jdk7u4-b228 for changeset 74f31fdf52d6 Message-ID: <20120203091436.2A4DF47349@hg.openjdk.java.net> Changeset: 5bab590afe9a Author: katleman Date: 2012-02-02 15:25 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/rev/5bab590afe9a Added tag jdk7u4-b228 for changeset 74f31fdf52d6 ! .hgtags From david.katleman at sun.com Fri Feb 3 01:14:44 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 03 Feb 2012 09:14:44 +0000 Subject: hg: jdk7u/jdk7u-osx/corba: Added tag jdk7u4-b228 for changeset ddc6a8c79faa Message-ID: <20120203091445.33D104734A@hg.openjdk.java.net> Changeset: 6edb2cae04cb Author: katleman Date: 2012-02-02 15:25 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/6edb2cae04cb Added tag jdk7u4-b228 for changeset ddc6a8c79faa ! .hgtags From david.katleman at sun.com Fri Feb 3 01:15:56 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 03 Feb 2012 09:15:56 +0000 Subject: hg: jdk7u/jdk7u-osx/hotspot: Added tag jdk7u4-b228 for changeset 615c22773d4c Message-ID: <20120203091600.C38D54734B@hg.openjdk.java.net> Changeset: 0dcf44daaae6 Author: katleman Date: 2012-02-02 15:25 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/0dcf44daaae6 Added tag jdk7u4-b228 for changeset 615c22773d4c ! .hgtags From david.katleman at sun.com Fri Feb 3 01:17:28 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 03 Feb 2012 09:17:28 +0000 Subject: hg: jdk7u/jdk7u-osx/jaxp: Added tag jdk7u4-b228 for changeset 3d9734845366 Message-ID: <20120203091731.206D94734C@hg.openjdk.java.net> Changeset: 01e4d47544aa Author: katleman Date: 2012-02-02 15:25 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/01e4d47544aa Added tag jdk7u4-b228 for changeset 3d9734845366 ! .hgtags From david.katleman at sun.com Fri Feb 3 01:17:39 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 03 Feb 2012 09:17:39 +0000 Subject: hg: jdk7u/jdk7u-osx/jaxws: Added tag jdk7u4-b228 for changeset 163c1e712d5e Message-ID: <20120203091739.BB3AC4734D@hg.openjdk.java.net> Changeset: 96adf51d66b3 Author: katleman Date: 2012-02-02 15:25 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxws/rev/96adf51d66b3 Added tag jdk7u4-b228 for changeset 163c1e712d5e ! .hgtags From david.katleman at sun.com Fri Feb 3 01:17:53 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 03 Feb 2012 09:17:53 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: Added tag jdk7u4-b228 for changeset 8878d25cce64 Message-ID: <20120203091813.27F984734E@hg.openjdk.java.net> Changeset: 25c30855814c Author: katleman Date: 2012-02-02 15:25 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/25c30855814c Added tag jdk7u4-b228 for changeset 8878d25cce64 ! .hgtags From david.katleman at sun.com Fri Feb 3 01:19:30 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 03 Feb 2012 09:19:30 +0000 Subject: hg: jdk7u/jdk7u-osx/langtools: Added tag jdk7u4-b228 for changeset 3fa78bea37a3 Message-ID: <20120203091935.48D5F4734F@hg.openjdk.java.net> Changeset: 0b2dbd460412 Author: katleman Date: 2012-02-02 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/0b2dbd460412 Added tag jdk7u4-b228 for changeset 3fa78bea37a3 ! .hgtags From weijun.wang at oracle.com Fri Feb 3 02:17:41 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 03 Feb 2012 18:17:41 +0800 Subject: Mac OS X port - update In-Reply-To: <4F2BA39D.9010202@oracle.com> References: <4F2BA39D.9010202@oracle.com> Message-ID: <4F2BB445.3040908@oracle.com> Sorry, I just found out that the new Xcode has no JDK at all, so an Apple JDK is still needed. I guess it just does not matter which one should be installed first now. -Max On 02/03/2012 05:06 PM, Weijun Wang wrote: > A question: > > The wiki does not mention install Apple JDK after Xcode for 10.7.3. Does > this mean the step is not necessary anymore. > > So the yellow background text can be removed now? > > Thanks > Max > > > On 02/03/2012 04:32 PM, Henri Gomez wrote: >> Very good news, I'll add a new build process on >> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ for openjdk-osx-build >> project. >> >> Stay tuned >> >> 2012/2/3 Kirk Pepperdine: >>> +1 >>> >>> Regards, >>> Kirk >>> >>> On 2012-02-03, at 1:24 AM, Martijn Verburg wrote: >>> >>>> This is very cool news. As an observer watching the sheer number of >>>> commits fly past I'd just like to thank the effort of all of the >>>> engineers involved more getting the OpenJDK story on the Mac to this >>>> stage, it's been seriously impressive to watch. >>>> >>>> Cheers, >>>> Martijn >>>> >>>> On 2 February 2012 22:32, Edvard >>>> Wendelin wrote: >>>>> Hi, >>>>> >>>>> As you might have noticed, 7u-osx [1] was pushed to 7u-dev [2] >>>>> yesterday. There will be a build from 7u-dev today that QA will run >>>>> Pre-integration testing on. During the coming week, we will make >>>>> sure that any potential quirks found in 7u-dev as a result of the >>>>> osx integration are fixed before next weeks (Thu 9th) build >>>>> promotion. This means that from next week on the regular promotions >>>>> will contain OS X bundles just like the other platforms. We will >>>>> soon also make the jdk7u-osx [1] forest read only. All fixes >>>>> related to the Mac OS X port should from now on go through >>>>> jdk7u-dev [2] and jdk7u-dev at openjdk.java.net. >>>>> >>>>> >>>>> Cheers, >>>>> Edvard >>>>> >>>>> [1] http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ >>>>> [2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ >>> From weijun.wang at oracle.com Fri Feb 3 02:54:38 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 03 Feb 2012 18:54:38 +0800 Subject: error building jdk7u-osx on lion: run-generator... In-Reply-To: <4F2BA432.3020206@oracle.com> References: <4F2B700C.4050908@oracle.com> <4F2BA432.3020206@oracle.com> Message-ID: <4F2BBCEE.3040104@oracle.com> Found the reason (thanks to Alan Bateman), I have the building jdk on top of PATH, and it gets called by rungen, but the runtime is still not complete at the time. I've filed a bug on this: 7142426: [macosx] cannot build if the not-yet-build jdk is in PATH Thanks Max On 02/03/2012 05:09 PM, Weijun Wang wrote: > Maybe it's because I installed the Apple JDK after Xcode? I see that > line removed from the wiki now. > > If so, shall I just reinstall Xcode? OS is 10.7.3 now. > > Thanks > Max > > On 02/03/2012 01:26 PM, Weijun Wang wrote: >> Hi All >> >> I've just updated my Mac to Lion, installed Xcode and Java. I cloned the >> jdk7u-dev repos and run >> >> make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true >> ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` >> HOTSPOT_BUILD_JOBS=`sysctl -n hw.ncpu` >> >> but it failed. What's wrong here? >> >> Thanks >> Max >> >> ------------------------------- >> run-generator: >> [mkdir] Created dir: >> /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/src/jobjc >> [exec] Current OS is Mac OS X >> [exec] Executing 'ruby' with arguments: >> [exec] './rungen' >> [exec] 'install' >> [exec] 'JObjC.jar' >> [exec] '/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.dst/Debug' >> [exec] '/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build' >> [exec] 'ppc i386 x86_64' >> [exec] >> '/Users/ww155710/work/osx-jdk/build/macosx-amd64/stable_bridge_metadata' >> [exec] >> [exec] The ' characters around the executable and arguments are >> [exec] not part of the command. >> [exec] ENV['JAVA_HOME'] = >> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home >> [exec] java -fullversion = openjdk full version >> "1.7.0-internal-ww155710_2012_02_03_10_54-b00" >> [exec] jobjc_jar = JObjC.jar >> [exec] libpath = >> /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.dst/Debug >> [exec] objroot = >> /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build >> [exec] ARCHS = ppc i386 x86_64 >> [exec] STABLE_GEN_DIR = >> /Users/ww155710/work/osx-jdk/build/macosx-amd64/stable_bridge_metadata >> [exec] java -classpath >> /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/bin/core:/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/bin/generator >> >> com.apple.internal.jobjc.generator.BootClassPathMinus JObjC.jar >> [exec] bootclasspath is: >> [exec] Error occurred during initialization of VM >> [exec] java/lang/NoClassDefFoundError: java/lang/invoke/MethodHandle >> [exec] java -d64 -Xms128m -Xmx512m >> -Djava.library.path=/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.dst/Debug >> >> -Xbootclasspath:Error occurred during initialization of VM >> [exec] java/lang/NoClassDefFoundError: java/lang/invoke/MethodHandle >> -classpath >> /Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/bin/core:/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/bin/generator >> >> -ea com.apple.internal.jobjc.generator.Generator >> dst=/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/src/jobjc >> frameworks=/Users/ww155710/work/osx-jdk/build/macosx-amd64/stable_bridge_metadata >> >> >> [exec] Error occurred during initialization of VM >> [exec] java/lang/NoClassDefFoundError: java/lang/Object >> [exec] sh: line 1: java/lang/NoClassDefFoundError:: No such file or >> directory >> [exec] ./rungen:67:in `raise': exception class/object expected >> (TypeError) >> [exec] from ./rungen:67 >> >> BUILD FAILED >> /Users/ww155710/work/osx-jdk/jdk/src/macosx/native/jobjc/build.xml:187: >> exec returned: 1 >> at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:646) >> at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:672) >> at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:498) >> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) >> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> >> >> at java.lang.reflect.Method.invoke(Method.java:597) >> at >> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >> >> at org.apache.tools.ant.Task.perform(Task.java:348) >> at org.apache.tools.ant.Target.execute(Target.java:390) >> at org.apache.tools.ant.Target.performTasks(Target.java:411) >> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) >> at org.apache.tools.ant.Project.executeTarget(Project.java:1368) >> at >> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >> >> >> at org.apache.tools.ant.Project.executeTargets(Project.java:1251) >> at org.apache.tools.ant.Main.runBuild(Main.java:809) >> at org.apache.tools.ant.Main.startAnt(Main.java:217) >> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) >> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) >> >> Total time: 31 seconds >> make[4]: *** >> [/Users/ww155710/work/osx-jdk/build/macosx-amd64/JObjC.build/JObjC.jar] >> Error 1 >> make[3]: *** [all] Error 1 >> make[2]: *** [all] Error 1 >> make[1]: *** [jdk-build] Error 2 >> make: *** [build_product_image] Error 2 From dmitry.cherepanov at oracle.com Fri Feb 3 04:05:21 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 03 Feb 2012 15:05:21 +0300 Subject: Review request for 7124236: [macosx] Some components lost shadows after the latest fix of translucent windows. In-Reply-To: <4F296B9B.60904@oracle.com> References: <4F283B46.5030401@oracle.com> <4F296B9B.60904@oracle.com> Message-ID: <4F2BCD81.5080509@oracle.com> Anthony Petrov wrote: > Hi Dmitry, > > Major concern: is that possible to avoid modifications to the shared > code with this fix? I'm afraid that this is a necessary change if we want to create a CALayer where the background is fully transparent. Also, having fully transparent background in CALayer seems to be necessary to implement http://java.net/jira/browse/MACOSX_PORT-764 . I'm currently trying to come up with a fix for the native textured background and likely I'll submit a separate review request for MACOSX_PORT-764. > > On 1/31/2012 11:04 PM, Dmitry Cherepanov wrote: >> The cause of the problem with broken shadows is that currently >> NSWindow's background color is [NSWindow clearColor] and it makes >> shadows invisible. The fix implements Mike's suggestion and now we >> draw pure transparent pixels into a CALayer so that the native >> background color will be visible through transparent areas of the >> CALayer. > > Looks like it should work fine if background's alpha is > 0 and < 255. > And what about window.setBackground(new Color(0, 0, 0, 0))? I see that > in CPlatformWindow we'll actually pass these zeros (which is in fact > the same as the clearColor, isn't it?) to the native system. In this > case I wouldn't expect any shadow to appear since the background color > set is completely transparent. Is this correct? I would also expect that there shouldn't be any shadow after setting window.setBackground(new Color(0, 0, 0, 0)) and this is how it behaves now. > > Also, the bug evaluation mentions the click-through problem. Is it > resolved with this fix? The patch doesn't solve the click-through problem. I've spent a while investigating this issue and there's a number of mailing threads (for example, [1] and [2]) mentioning that OpenGL content is opaque to events. Thanks, Dmitry [1] http://lists.apple.com/archives/cocoa-dev/2009/Apr/msg01945.html [2] http://lists.apple.com/archives/mac-opengl/2010/Mar/msg00038.html From dmitry.cherepanov at oracle.com Fri Feb 3 04:24:02 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 03 Feb 2012 15:24:02 +0300 Subject: Review request for 7124236: [macosx] Some components lost shadows after the latest fix of translucent windows. In-Reply-To: References: <4F283B46.5030401@oracle.com> Message-ID: <4F2BD1E2.5040904@oracle.com> Mike Swingler wrote: > On Jan 31, 2012, at 11:04 AM, Dmitry Cherepanov wrote: > > >> The cause of the problem with broken shadows is that currently NSWindow's background color is [NSWindow clearColor] and it makes shadows invisible. The fix implements Mike's suggestion and now we draw pure transparent pixels into a CALayer so that the native background color will be visible through transparent areas of the CALayer. >> >> http://cr.openjdk.java.net/~dcherepanov/7124236/webrev.0/ >> I'm trying to resolve a regression reproducible with the patch applied. The problem comes up when application creates a top-level with a transparent background (alpha != 0) and then starts rendering something fully transparent with SRC composite in paint's callback (the example [1] draws a fully transparent circle). My understanding is that the content of the CALayer is going to be composited with the top-level's background using SRC-OVER composite and the application's drawing will be missed. Seems like it closely relates to your suggestion about the coordination between the NSWindow's back-buffer drawing and drawing into the CALayer. Could you please share your ideas about what's the right way to fix it? Thanks, Dmitry [1] http://cr.openjdk.java.net/~dcherepanov/7124236/NonOpaqueCircle.java From Alan.Bateman at oracle.com Fri Feb 3 03:23:03 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 Feb 2012 11:23:03 +0000 Subject: Mac OS X port - update In-Reply-To: <4F2B422D.20907@oracle.com> References: <4F2B422D.20907@oracle.com> Message-ID: <4F2BC397.5090208@oracle.com> On 03/02/2012 02:10, David Holmes wrote: > > I am concerned. There was some discussion when various changes went > into 7u-osx regarding the suitability of the changes for inclusion in > the mainline repositories ie 7u-dev. It was my understanding that > there would be a more extensive review and, if necessary, clean up > process, before those changes were merged into the mainline 7u-dev. I > have only seen that happen for a couple of specific issues. You're right, there were several concerns about some areas of the code when jdk7u-osx was setup. One was the launcher and that has since been sorted out by Kumar, another was the jnilib support, which has been temporarily removed pending a cleaner implementation. I think it's worth compiling an updated list of things that should be cleaned up although from a stability point of view then some of them may be work for jdk8 rather than 7u. -Alan From anthony.petrov at oracle.com Fri Feb 3 04:22:00 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 03 Feb 2012 16:22:00 +0400 Subject: Review request for 7124236: [macosx] Some components lost shadows after the latest fix of translucent windows. In-Reply-To: <4F2BCD81.5080509@oracle.com> References: <4F283B46.5030401@oracle.com> <4F296B9B.60904@oracle.com> <4F2BCD81.5080509@oracle.com> Message-ID: <4F2BD168.5000507@oracle.com> Hi Dmitry, On 2/3/2012 4:05 PM, Dmitry Cherepanov wrote: >> Major concern: is that possible to avoid modifications to the shared >> code with this fix? > > I'm afraid that this is a necessary change if we want to create a > CALayer where the background is fully transparent. Also, having fully > transparent background in CALayer seems to be necessary to implement > http://java.net/jira/browse/MACOSX_PORT-764 . I'm currently trying to > come up with a fix for the native textured background and likely I'll > submit a separate review request for MACOSX_PORT-764. I wonder how are we going to differentiate between the fully transparent background of the layer which is supposed to make the native textured background shine through, and fully transparent areas painted by user's code explicitly. Those user areas must actually be fully transparent visually, too. Do you have an idea how to resolve that? Also, I see that 764 is basically an RFE. Does it make sense to fix it in JDK8 rather than in 7u? In this case changes to the shared code would be all fine. >> On 1/31/2012 11:04 PM, Dmitry Cherepanov wrote: >>> The cause of the problem with broken shadows is that currently >>> NSWindow's background color is [NSWindow clearColor] and it makes >>> shadows invisible. The fix implements Mike's suggestion and now we >>> draw pure transparent pixels into a CALayer so that the native >>> background color will be visible through transparent areas of the >>> CALayer. >> >> Looks like it should work fine if background's alpha is > 0 and < 255. >> And what about window.setBackground(new Color(0, 0, 0, 0))? I see that >> in CPlatformWindow we'll actually pass these zeros (which is in fact >> the same as the clearColor, isn't it?) to the native system. In this >> case I wouldn't expect any shadow to appear since the background color >> set is completely transparent. Is this correct? > > I would also expect that there shouldn't be any shadow after setting > window.setBackground(new Color(0, 0, 0, 0)) and this is how it behaves now. To me this seems like the most common use case for transparent windows. Are we, or rather are developers OK with missing window shadows in that case? From developer's perspective it seems that shadow must be present regardless of the background color set to the window. >> Also, the bug evaluation mentions the click-through problem. Is it >> resolved with this fix? > > The patch doesn't solve the click-through problem. I've spent a while > investigating this issue and there's a number of mailing threads (for > example, [1] and [2]) mentioning that OpenGL content is opaque to events. This basically means that with current implementation transparent windows behave on the Mac the same way they do on X11 which is far from being... hmmm... convenient. To worsen thing, Mac doesn't support Shapes, which makes it absolutely impossible to implement normal non-opaque windows with click-through capability on Mac OS with AWT/Swing. I think this is a problem. The thread [1] mentions that using renderInContext: can actually produce satisfying results - i.e. make visually transparent areas transparent for mouse clicks, too. And this is actually what we really want, isn't it? -- best regards, Anthony > [1] http://lists.apple.com/archives/cocoa-dev/2009/Apr/msg01945.html > > [2] http://lists.apple.com/archives/mac-opengl/2010/Mar/msg00038.html From dmitry.cherepanov at oracle.com Fri Feb 3 06:21:23 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 03 Feb 2012 17:21:23 +0300 Subject: Review request for 7124236: [macosx] Some components lost shadows after the latest fix of translucent windows. In-Reply-To: <4F2BD168.5000507@oracle.com> References: <4F283B46.5030401@oracle.com> <4F296B9B.60904@oracle.com> <4F2BCD81.5080509@oracle.com> <4F2BD168.5000507@oracle.com> Message-ID: <4F2BED63.7000408@oracle.com> Anthony Petrov wrote: > The thread [1] mentions that using renderInContext: can actually > produce satisfying results - i.e. make visually transparent areas > transparent for mouse clicks, too. And this is actually what we really > want, isn't it? > I saw this method too. I've carried out some quick experiments but I haven't managed to make it working. If you think that we should try it, let me look at that again. Thanks, Dmitry > >> [1] http://lists.apple.com/archives/cocoa-dev/2009/Apr/msg01945.html From anthony.petrov at oracle.com Fri Feb 3 05:22:09 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 03 Feb 2012 17:22:09 +0400 Subject: Review request for 7142120: [macosx] Some JCK tests for SplashScreen fail on Mac OS X due to incorrect positioning of the splash Message-ID: <4F2BDF81.7050805@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7142120 at: http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.0/ The fix is fairly simple: use NSScreen -frame instead of -visibleFrame. In this case the splash screen is positioned in the geometrical center of the screen. Visually this looks less pleasant (we may want to file an RFE in the future), but makes tests happy which is what we need right now. All the failing tests now pass well with this fix applied. -- best regards, Anthony From anthony.petrov at oracle.com Fri Feb 3 05:24:37 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 03 Feb 2012 17:24:37 +0400 Subject: Review request for 7124236: [macosx] Some components lost shadows after the latest fix of translucent windows. In-Reply-To: <4F2BED63.7000408@oracle.com> References: <4F283B46.5030401@oracle.com> <4F296B9B.60904@oracle.com> <4F2BCD81.5080509@oracle.com> <4F2BD168.5000507@oracle.com> <4F2BED63.7000408@oracle.com> Message-ID: <4F2BE015.7080804@oracle.com> On 2/3/2012 6:21 PM, Dmitry Cherepanov wrote: > Anthony Petrov wrote: >> The thread [1] mentions that using renderInContext: can actually >> produce satisfying results - i.e. make visually transparent areas >> transparent for mouse clicks, too. And this is actually what we really >> want, isn't it? >> > > I saw this method too. I've carried out some quick experiments but I > haven't managed to make it working. If you think that we should try it, > let me look at that again. I think we should ask Apple guys on what they can suggest regarding this issue. We really need to be able to make visually fully non-opaque areas transparent for mouse clicks. Mike, any ideas? -- best regards, Anthony >>> [1] http://lists.apple.com/archives/cocoa-dev/2009/Apr/msg01945.html From Alexander.Potochkin at oracle.com Fri Feb 3 05:28:01 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Fri, 03 Feb 2012 17:28:01 +0400 Subject: Review request for 7124308: [macosx] JSlider thumb moves to the right direction when it's used as a JTable cell editor Message-ID: <4F2BE0E1.6020807@oracle.com> Hello Please review the following fix: http://cr.openjdk.java.net/~alexp/7124308/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124308 this bug is actually a duplicate of http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6348946 which was fixed for our Lafs (the fix was exactly the same for BasicSliderUI) and now I forward port it to AquaSliderUI Thanks alexp From anthony.petrov at oracle.com Fri Feb 3 06:04:41 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 03 Feb 2012 18:04:41 +0400 Subject: Review request for 7124308: [macosx] JSlider thumb moves to the right direction when it's used as a JTable cell editor In-Reply-To: <4F2BE0E1.6020807@oracle.com> References: <4F2BE0E1.6020807@oracle.com> Message-ID: <4F2BE979.9030001@oracle.com> Looks fine. -- best regards, Anthony On 2/3/2012 5:28 PM, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7124308/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124308 > > this bug is actually a duplicate of > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6348946 > which was fixed for our Lafs > (the fix was exactly the same for BasicSliderUI) > > and now I forward port it to AquaSliderUI > > Thanks > alexp From sergey.bylokhov at oracle.com Fri Feb 3 06:46:52 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 03 Feb 2012 18:46:52 +0400 Subject: [7u4] Request for approval for CR 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails Message-ID: <4F2BF35C.7020000@oracle.com> Hello, This is a request to push the following changes to jdk7u-dev. The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 Webrev can be found at: http://cr.openjdk.java.net/~serb/7131367/webrev.00/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002726.html -- Best regards, Sergey. From kumar.x.srinivasan at oracle.COM Fri Feb 3 07:28:34 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 03 Feb 2012 07:28:34 -0800 Subject: Mac OS X port - update In-Reply-To: <4F2BC397.5090208@oracle.com> References: <4F2B422D.20907@oracle.com> <4F2BC397.5090208@oracle.com> Message-ID: <4F2BFD22.6030502@oracle.COM> On 2/3/2012 3:23 AM, Alan Bateman wrote: > On 03/02/2012 02:10, David Holmes wrote: >> >> I am concerned. There was some discussion when various changes went >> into 7u-osx regarding the suitability of the changes for inclusion in >> the mainline repositories ie 7u-dev. It was my understanding that >> there would be a more extensive review and, if necessary, clean up >> process, before those changes were merged into the mainline 7u-dev. I >> have only seen that happen for a couple of specific issues. > You're right, there were several concerns about some areas of the code > when jdk7u-osx was setup. One was the launcher and that has since been > sorted out by Kumar, another was the jnilib support, which has Right! I am planning on forward porting these changes to jdk8, shortly. :-) Kumar > been temporarily removed pending a cleaner implementation. I think > it's worth compiling an updated list of things that should be cleaned > up although from a stability point of view then some of them may be > work for jdk8 rather than 7u. > > -Alan From Alan.Bateman at oracle.com Fri Feb 3 07:36:24 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 Feb 2012 15:36:24 +0000 Subject: Mac OS X port - update In-Reply-To: <4F2BFD22.6030502@oracle.COM> References: <4F2B422D.20907@oracle.com> <4F2BC397.5090208@oracle.com> <4F2BFD22.6030502@oracle.COM> Message-ID: <4F2BFEF8.9060803@oracle.com> On 03/02/2012 15:28, Kumar Srinivasan wrote: > On 2/3/2012 3:23 AM, Alan Bateman wrote: >> On 03/02/2012 02:10, David Holmes wrote: >>> >>> I am concerned. There was some discussion when various changes went >>> into 7u-osx regarding the suitability of the changes for inclusion >>> in the mainline repositories ie 7u-dev. It was my understanding that >>> there would be a more extensive review and, if necessary, clean up >>> process, before those changes were merged into the mainline 7u-dev. >>> I have only seen that happen for a couple of specific issues. >> You're right, there were several concerns about some areas of the >> code when jdk7u-osx was setup. One was the launcher and that has >> since been sorted out by Kumar, another was the jnilib support, which >> has > Right! I am planning on forward porting these changes to jdk8, > shortly. :-) I think Michael plans to get everything into jdk8 soon so I would suggest sync'ing up with him before bringing over individual areas. -Alan From kumar.x.srinivasan at oracle.COM Fri Feb 3 07:40:09 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 03 Feb 2012 07:40:09 -0800 Subject: Mac OS X port - update In-Reply-To: <4F2BFEF8.9060803@oracle.com> References: <4F2B422D.20907@oracle.com> <4F2BC397.5090208@oracle.com> <4F2BFD22.6030502@oracle.COM> <4F2BFEF8.9060803@oracle.com> Message-ID: <4F2BFFD9.3050101@oracle.COM> On 2/3/2012 7:36 AM, Alan Bateman wrote: > On 03/02/2012 15:28, Kumar Srinivasan wrote: >> On 2/3/2012 3:23 AM, Alan Bateman wrote: >>> On 03/02/2012 02:10, David Holmes wrote: >>>> >>>> I am concerned. There was some discussion when various changes went >>>> into 7u-osx regarding the suitability of the changes for inclusion >>>> in the mainline repositories ie 7u-dev. It was my understanding >>>> that there would be a more extensive review and, if necessary, >>>> clean up process, before those changes were merged into the >>>> mainline 7u-dev. I have only seen that happen for a couple of >>>> specific issues. >>> You're right, there were several concerns about some areas of the >>> code when jdk7u-osx was setup. One was the launcher and that has >>> since been sorted out by Kumar, another was the jnilib support, >>> which has >> Right! I am planning on forward porting these changes to jdk8, >> shortly. :-) > I think Michael plans to get everything into jdk8 soon so I would > suggest sync'ing up with him before bringing over individual areas. That sounds good, thanks! and I was not aware of this. Kumar > > -Alan From jason.uh at oracle.com Fri Feb 3 08:14:36 2012 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 03 Feb 2012 08:14:36 -0800 Subject: Review Request: 7142516 [macosx] test script to recognize Mac OS X Message-ID: <4F2C07EC.4030305@oracle.com> A simple change to add Darwin as a recognized OS to a recently added script (test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh): Webrev: http://cr.openjdk.java.net/~juh/7142516/webrev.00/ Thanks, Jason From philip.race at oracle.com Fri Feb 3 09:30:30 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 03 Feb 2012 09:30:30 -0800 Subject: Review request for 7119760: (mac) The OpenGL queue flusher thread is created in the wrong thread group In-Reply-To: <4F2BB1E8.8000003@oracle.com> References: <4F2BB1E8.8000003@oracle.com> Message-ID: <4F2C19B6.4000802@oracle.com> Looks OK to me. We've had to do the same a in fair number of places across 2D/AWT in the past. See sun/font/SunFontManager.java for example. I can only suppose this one was overlooked because the opengl pipeline was not being used in the browser until now. -phil. On 2/3/2012 2:07 AM, Dmitry Cherepanov wrote: > Hello, > > The cause of the issue is that the flusher thread belongs to the > applet's thread group and the flusher thread dies when the applet > quits and new applet fails to start (when it reuses the same instance > of the JVM). The fix creates the flusher thread in the root thread group. > > http://cr.openjdk.java.net/~dcherepanov/7119760/webrev.0/ > > Thanks, > Dmitry > From scott.kovatch at oracle.com Fri Feb 3 10:21:14 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 3 Feb 2012 10:21:14 -0800 Subject: Review request for 7119760: (mac) The OpenGL queue flusher thread is created in the wrong thread group In-Reply-To: <4F2C19B6.4000802@oracle.com> References: <4F2BB1E8.8000003@oracle.com> <4F2C19B6.4000802@oracle.com> Message-ID: <8EAB1D04-6D26-403C-AEAA-8B5AD4E42E52@oracle.com> This bug has been there for a long time. Unfortunately for me I thought this was a bug in how we implemented blocking of the main thread until the second applet starts up. -- Scott On Feb 3, 2012, at 9:30 AM, Phil Race wrote: > Looks OK to me. We've had to do the same a in fair number of places across 2D/AWT > in the past. See sun/font/SunFontManager.java for example. > > I can only suppose this one was overlooked because the opengl pipeline was not being used > in the browser until now. > > -phil. > > On 2/3/2012 2:07 AM, Dmitry Cherepanov wrote: >> Hello, >> >> The cause of the issue is that the flusher thread belongs to the applet's thread group and the flusher thread dies when the applet quits and new applet fails to start (when it reuses the same instance of the JVM). The fix creates the flusher thread in the root thread group. >> >> http://cr.openjdk.java.net/~dcherepanov/7119760/webrev.0/ >> >> Thanks, >> Dmitry >> > From james.holmlund at oracle.com Fri Feb 3 11:11:27 2012 From: james.holmlund at oracle.com (Jim Holmlund) Date: Fri, 03 Feb 2012 11:11:27 -0800 Subject: Mac OS X port - update In-Reply-To: <4F2BFFD9.3050101@oracle.COM> References: <4F2B422D.20907@oracle.com> <4F2BC397.5090208@oracle.com> <4F2BFD22.6030502@oracle.COM> <4F2BFEF8.9060803@oracle.com> <4F2BFFD9.3050101@oracle.COM> Message-ID: <4F2C315F.8050608@oracle.com> On 2/3/2012 7:40 AM, Kumar Srinivasan wrote: > On 2/3/2012 7:36 AM, Alan Bateman wrote: >> On 03/02/2012 15:28, Kumar Srinivasan wrote: >>> On 2/3/2012 3:23 AM, Alan Bateman wrote: >>>> On 03/02/2012 02:10, David Holmes wrote: >>>>> >>>>> I am concerned. There was some discussion when various changes went into 7u-osx regarding the >>>>> suitability of the changes for inclusion in the mainline repositories ie 7u-dev. It was my >>>>> understanding that there would be a more extensive review and, if necessary, clean up process, >>>>> before those changes were merged into the mainline 7u-dev. I have only seen that happen for a >>>>> couple of specific issues. >>>> You're right, there were several concerns about some areas of the code when jdk7u-osx was >>>> setup. One was the launcher and that has since been sorted out by Kumar, another was the jnilib >>>> support, which has >>> Right! I am planning on forward porting these changes to jdk8, shortly. :-) >> I think Michael plans to get everything into jdk8 soon so I would suggest sync'ing up with him >> before bringing over individual areas. > > That sounds good, thanks! and I was not aware of this. > I wasn't aware of this either. Is this official, and we don't need to port our own changes to jdk8? - jjh > Kumar > >> >> -Alan > From paul.hohensee at oracle.com Fri Feb 3 11:16:35 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 03 Feb 2012 14:16:35 -0500 Subject: JDK 7 Mac Port Preview b227 Available In-Reply-To: References: <4F22F2BE.50008@oracle.com> <9A4C3F08-35D6-4397-9915-D71BBA504731@gmail.com> <4F2AB038.6030101@oracle.com> <4F2ABE60.2040000@oracle.com> Message-ID: <4F2C3293.6060608@oracle.com> There are currently no plans for Oracle to add it back. The community might want to. I've filed an RFE for this, which should show up on bugs.sun.com a day or so from now. 7142580: Add 32-bit support to the Mac OS X port Paul On 2/3/12 4:05 AM, Henri Gomez wrote: >> I should have added that though the binaries are universal, they don't >> actually contain 32-bit code. The framework for adding that is there >> though. > Good news. > > Some Java applications don't require huge heap and using -d32 help save memory. > Is it planned to be added back ? > Should we add an issue somewhere to ask it and track progress on it ? > > Thanks From michael.x.mcmahon at oracle.com Fri Feb 3 13:23:21 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 03 Feb 2012 21:23:21 +0000 Subject: RFR: 7142617 De-optimize fdlibm compilation [macosx] Message-ID: <4F2C5049.8010607@oracle.com> Can I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/7142617/webrev.1/ fdlibm needs to be compiled with optimization disabled, as on Linux. Thanks Michael. From swingler at apple.com Fri Feb 3 15:12:37 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 03 Feb 2012 15:12:37 -0800 Subject: Review request for 7142120: [macosx] Some JCK tests for SplashScreen fail on Mac OS X due to incorrect positioning of the splash In-Reply-To: <4F2BDF81.7050805@oracle.com> References: <4F2BDF81.7050805@oracle.com> Message-ID: On Feb 3, 2012, at 5:22 AM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7142120 at: > > http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.0/ > > The fix is fairly simple: use NSScreen -frame instead of -visibleFrame. In this case the splash screen is positioned in the geometrical center of the screen. Visually this looks less pleasant (we may want to file an RFE in the future), but makes tests happy which is what we need right now. > > All the failing tests now pass well with this fix applied. Also [NSScreen mainScreen] gives you the screen that the "main" (aka "active") window is on. You really should use the 0'th screen to get the "primary" screen with the menu bar and the Dock. Regards, Mike Swingler Apple Inc. From swingler at apple.com Fri Feb 3 16:41:08 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 03 Feb 2012 16:41:08 -0800 Subject: Mac OS X port - update In-Reply-To: <4F2BB445.3040908@oracle.com> References: <4F2BA39D.9010202@oracle.com> <4F2BB445.3040908@oracle.com> Message-ID: <6B030C10-B638-47CB-98D4-F56092E2EF35@apple.com> Xcode has never installed Java, so you will still need some form of Java to get the build going, but that doesn't mean it can't be OpenJDK itself. There is still the issue that the only place to get the "current" JavaRuntimeSupport.framework headers is from the Apple Java package, however now that 10.7.3 is shipped to customers, we would like to get the current headers into the 10.7 SDK which is shipped with Xcode. After that, OpenJDK 7 should be able to bootstrap itself on a clean 10.7.3 machine, with no Apple Java installed. Exciting times, Mike Swingler Apple Inc. On Feb 3, 2012, at 2:17 AM, Weijun Wang wrote: > Sorry, I just found out that the new Xcode has no JDK at all, so an Apple JDK is still needed. I guess it just does not matter which one should be installed first now. > > -Max > > On 02/03/2012 05:06 PM, Weijun Wang wrote: >> A question: >> >> The wiki does not mention install Apple JDK after Xcode for 10.7.3. Does >> this mean the step is not necessary anymore. >> >> So the yellow background text can be removed now? >> >> Thanks >> Max >> >> >> On 02/03/2012 04:32 PM, Henri Gomez wrote: >>> Very good news, I'll add a new build process on >>> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ for openjdk-osx-build >>> project. >>> >>> Stay tuned >>> >>> 2012/2/3 Kirk Pepperdine: >>>> +1 >>>> >>>> Regards, >>>> Kirk >>>> >>>> On 2012-02-03, at 1:24 AM, Martijn Verburg wrote: >>>> >>>>> This is very cool news. As an observer watching the sheer number of >>>>> commits fly past I'd just like to thank the effort of all of the >>>>> engineers involved more getting the OpenJDK story on the Mac to this >>>>> stage, it's been seriously impressive to watch. >>>>> >>>>> Cheers, >>>>> Martijn >>>>> >>>>> On 2 February 2012 22:32, Edvard >>>>> Wendelin wrote: >>>>>> Hi, >>>>>> >>>>>> As you might have noticed, 7u-osx [1] was pushed to 7u-dev [2] >>>>>> yesterday. There will be a build from 7u-dev today that QA will run >>>>>> Pre-integration testing on. During the coming week, we will make >>>>>> sure that any potential quirks found in 7u-dev as a result of the >>>>>> osx integration are fixed before next weeks (Thu 9th) build >>>>>> promotion. This means that from next week on the regular promotions >>>>>> will contain OS X bundles just like the other platforms. We will >>>>>> soon also make the jdk7u-osx [1] forest read only. All fixes >>>>>> related to the Mac OS X port should from now on go through >>>>>> jdk7u-dev [2] and jdk7u-dev at openjdk.java.net. >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Edvard >>>>>> >>>>>> [1] http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ >>>>>> [2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ >>>> From joe.darcy at oracle.com Fri Feb 3 16:54:08 2012 From: joe.darcy at oracle.com (Joseph Darcy) Date: Fri, 03 Feb 2012 16:54:08 -0800 Subject: RFR: 7142617 De-optimize fdlibm compilation [macosx] In-Reply-To: <4F2C5049.8010607@oracle.com> References: <4F2C5049.8010607@oracle.com> Message-ID: <4F2C81B0.7080705@oracle.com> Looks fine, -Joe On 2/3/2012 1:23 PM, Michael McMahon wrote: > Can I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/7142617/webrev.1/ > > fdlibm needs to be compiled with optimization disabled, as on Linux. > > Thanks > Michael. From chris.hegarty at oracle.com Fri Feb 3 23:38:02 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 04 Feb 2012 07:38:02 +0000 Subject: RFR: 7142617 De-optimize fdlibm compilation [macosx] In-Reply-To: <4F2C5049.8010607@oracle.com> References: <4F2C5049.8010607@oracle.com> Message-ID: <4F2CE05A.40801@oracle.com> Looks good. -Chris. On 02/ 3/12 09:23 PM, Michael McMahon wrote: > Can I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/7142617/webrev.1/ > > fdlibm needs to be compiled with optimization disabled, as on Linux. > > Thanks > Michael. From edvard.wendelin at oracle.com Mon Feb 6 00:52:12 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 6 Feb 2012 09:52:12 +0100 Subject: [7u4] Request for approval for CR 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails In-Reply-To: <4F2BF35C.7020000@oracle.com> References: <4F2BF35C.7020000@oracle.com> Message-ID: Approved. On Feb 3, 2012, at 3:46 PM, Sergey Bylokhov wrote: > Hello, > This is a request to push the following changes to jdk7u-dev. > The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7131367/webrev.00/ > Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002726.html > > -- > Best regards, Sergey. > From edvard.wendelin at oracle.com Mon Feb 6 00:53:22 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 6 Feb 2012 09:53:22 +0100 Subject: [7u4] Request for approval for CR 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails In-Reply-To: <4F2BF35C.7020000@oracle.com> References: <4F2BF35C.7020000@oracle.com> Message-ID: <77D6848B-CC80-4474-BD8B-7E31B05A81FB@oracle.com> Could you update the copyright year before you push? Cheers, Edvard On Feb 3, 2012, at 3:46 PM, Sergey Bylokhov wrote: > Hello, > This is a request to push the following changes to jdk7u-dev. > The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7131367/webrev.00/ > Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002726.html > > -- > Best regards, Sergey. > From andrew.brygin at oracle.com Mon Feb 6 01:07:48 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Mon, 06 Feb 2012 13:07:48 +0400 Subject: Review request for 7142780: [macosx] Font2DTest demo throws NPE Message-ID: <4F2F9864.4000304@oracle.com> Hello, please take a look to a fix for CR 7142780: http://cr.openjdk.java.net/~bae/7142780/webrev/ The Font2DTest creates a bogus image in order to get a blank cursor (FontPanel.java, lines 495 - 498). This image can not be loaded and triggers an error when MediaTracker tries to prepare the image. As soon as the error is detected, the conversion of toolkit image to CImage is aborted, and the CImage.Creator.createFromImage returns null. So, CCustomCursor.getImageData need to be modified in order to be able to handle a null result of the createFormImage. However, in order to avoid numerous calls to createFromImage in case of faulty image, we can check the status of image loading in the constructor, and set a flag to indicate whether given image can be used as a cursor. Thanks, Andrew From dmitry.cherepanov at oracle.com Mon Feb 6 02:11:05 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 06 Feb 2012 13:11:05 +0300 Subject: [7u4] Request for approval for 7119760: [macosx] The OpenGL queue flusher thread is created in the wrong thread group Message-ID: <4F2FA739.1070007@oracle.com> This is a request to push the following fix to jdk7u-dev: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7119760 Webrev: http://cr.openjdk.java.net/~dcherepanov/7119760/webrev.0 Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002790.html Thanks, Dmitry From edvard.wendelin at oracle.com Mon Feb 6 03:52:45 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 06 Feb 2012 12:52:45 +0100 Subject: [7u4] Request for approval for 7119760: [macosx] The OpenGL queue flusher thread is created in the wrong thread group In-Reply-To: <4F2FA739.1070007@oracle.com> References: <4F2FA739.1070007@oracle.com> Message-ID: <4F2FBF0D.7000604@oracle.com> Approved. On 02/06/2012 11:11 AM, Dmitry Cherepanov wrote: > This is a request to push the following fix to jdk7u-dev: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7119760 > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7119760/webrev.0 > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002790.html > > Thanks, > Dmitry From alexander.zuev at oracle.com Mon Feb 6 05:02:00 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 06 Feb 2012 16:02:00 +0300 Subject: Review request for 7142780: [macosx] Font2DTest demo throws NPE In-Reply-To: <4F2F9864.4000304@oracle.com> References: <4F2F9864.4000304@oracle.com> Message-ID: <4F2FCF48.6030205@oracle.com> Looks fine to me. On 2/6/12 12:07, Andrew Brygin wrote: > Hello, > > please take a look to a fix for CR 7142780: > > http://cr.openjdk.java.net/~bae/7142780/webrev/ > > The Font2DTest creates a bogus image in order to get a blank cursor > (FontPanel.java, lines 495 - 498). This image can not be loaded and > triggers > an error when MediaTracker tries to prepare the image. As soon as the > error > is detected, the conversion of toolkit image to CImage is aborted, and > the > CImage.Creator.createFromImage returns null. So, > CCustomCursor.getImageData > need to be modified in order to be able to handle a null result of the > createFormImage. > > However, in order to avoid numerous calls to createFromImage in case > of faulty > image, we can check the status of image loading in the constructor, > and set a flag > to indicate whether given image can be used as a cursor. > > Thanks, > Andrew From anthony.petrov at oracle.com Mon Feb 6 04:40:13 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 06 Feb 2012 16:40:13 +0400 Subject: Review request for 7142120: [macosx] Some JCK tests for SplashScreen fail on Mac OS X due to incorrect positioning of the splash In-Reply-To: References: <4F2BDF81.7050805@oracle.com> Message-ID: <4F2FCA2D.7030507@oracle.com> Hi Mike, Thanks for the review. Here's an updated fix: http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.1/ -- best regards, Anthony On 2/4/2012 3:12 AM, Mike Swingler wrote: > On Feb 3, 2012, at 5:22 AM, Anthony Petrov wrote: > >> Hello, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7142120 at: >> >> http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.0/ >> >> The fix is fairly simple: use NSScreen -frame instead of -visibleFrame. In this case the splash screen is positioned in the geometrical center of the screen. Visually this looks less pleasant (we may want to file an RFE in the future), but makes tests happy which is what we need right now. >> >> All the failing tests now pass well with this fix applied. > > Also [NSScreen mainScreen] gives you the screen that the "main" (aka "active") window is on. You really should use the 0'th screen to get the "primary" screen with the menu bar and the Dock. > > Regards, > Mike Swingler > Apple Inc. > From andrew.brygin at oracle.com Mon Feb 6 05:17:32 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Mon, 06 Feb 2012 17:17:32 +0400 Subject: [7u4] Request for approval for 7142780: [macosx] Font2DTest demo throws NPE Message-ID: <4F2FD2EC.1030604@oracle.com> This is a request to push the following fix to jdk7u-dev: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142780 Webrev: http://cr.openjdk.java.net/~bae/7142780/webrev/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002828.html Thanks, Andrew From edvard.wendelin at oracle.com Mon Feb 6 05:21:47 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 06 Feb 2012 14:21:47 +0100 Subject: [7u4] Request for approval for 7142780: [macosx] Font2DTest demo throws NPE In-Reply-To: <4F2FD2EC.1030604@oracle.com> References: <4F2FD2EC.1030604@oracle.com> Message-ID: <4F2FD3EB.6070609@oracle.com> Approved. On 02/06/2012 02:17 PM, Andrew Brygin wrote: > This is a request to push the following fix to jdk7u-dev: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142780 > > Webrev: http://cr.openjdk.java.net/~bae/7142780/webrev/ > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002828.html > > Thanks, > Andrew From sergey.bylokhov at oracle.com Mon Feb 6 05:41:58 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 06 Feb 2012 17:41:58 +0400 Subject: [7u4] Request for approval for CR 7131367 [macosx] reg test test/java/awt/Window/TranslucentJAppletTest fails In-Reply-To: <77D6848B-CC80-4474-BD8B-7E31B05A81FB@oracle.com> References: <4F2BF35C.7020000@oracle.com> <77D6848B-CC80-4474-BD8B-7E31B05A81FB@oracle.com> Message-ID: <4F2FD8A6.2070704@oracle.com> 06.02.2012 12:53, Edvard Wendelin wrote: > Could you update the copyright year before you push? done http://cr.openjdk.java.net/~serb/7131367/webrev.01/ > > > Cheers, > Edvard > > > On Feb 3, 2012, at 3:46 PM, Sergey Bylokhov wrote: > >> Hello, >> This is a request to push the following changes to jdk7u-dev. >> The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131367 >> Webrev can be found at: http://cr.openjdk.java.net/~serb/7131367/webrev.00/ >> Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002726.html >> >> -- >> Best regards, Sergey. >> > -- Best regards, Sergey. From Alexander.Potochkin at oracle.com Mon Feb 6 06:53:36 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 06 Feb 2012 18:53:36 +0400 Subject: [7u4] Request for approval for 7124308: [macosx] JSlider thumb moves to the right direction when it's used as a JTable cell editor Message-ID: <4F2FE970.30702@oracle.com> This is a request to push the following fix to jdk 7u4: http://cr.openjdk.java.net/~alexp/7124308/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124308 the fix was approved by Anthony Petrov Thanks alexp From edvard.wendelin at oracle.com Mon Feb 6 06:59:05 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 06 Feb 2012 15:59:05 +0100 Subject: [7u4] Request for approval for 7124308: [macosx] JSlider thumb moves to the right direction when it's used as a JTable cell editor In-Reply-To: <4F2FE970.30702@oracle.com> References: <4F2FE970.30702@oracle.com> Message-ID: <4F2FEAB9.5030200@oracle.com> Approved. On 02/06/2012 03:53 PM, Alexander Potochkin wrote: > This is a request to push the following fix to jdk 7u4: > http://cr.openjdk.java.net/~alexp/7124308/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124308 > > the fix was approved by Anthony Petrov > > Thanks > alexp From artem.ananiev at oracle.com Mon Feb 6 08:17:37 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 06 Feb 2012 20:17:37 +0400 Subject: Review request for 7142120: [macosx] Some JCK tests for SplashScreen fail on Mac OS X due to incorrect positioning of the splash In-Reply-To: <4F2BDF81.7050805@oracle.com> References: <4F2BDF81.7050805@oracle.com> Message-ID: <4F2FFD21.90003@oracle.com> On 2/3/2012 5:22 PM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7142120 at: > > http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.0/ > > The fix is fairly simple: use NSScreen -frame instead of -visibleFrame. > In this case the splash screen is positioned in the geometrical center > of the screen. Visually this looks less pleasant (we may want to file an > RFE in the future), but makes tests happy which is what we need right now. So what exactly do the tests expect? Does the test calculates the expected splashscreen position and compares to the value of SplashScreen.getBounds()? Does the latter method returns an incorrect value? What I see in JavaDoc is just: "The window is positioned at the center of the screen." It's unclear if the center of the screen should or should not include screen insets. Thanks, Artem > All the failing tests now pass well with this fix applied. > > -- > best regards, > Anthony From Alexander.Potochkin at oracle.com Mon Feb 6 08:20:08 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 06 Feb 2012 20:20:08 +0400 Subject: Review request for 7141281: [macosx] GridBagLayout baseline issue Message-ID: <4F2FFDB8.7010600@oracle.com> Hello Please review the following fix: http://cr.openjdk.java.net/~alexp/7141281/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141281 With http://java.net/jira/browse/MACOSX_PORT-626 JSpinner now supports setFont() method. We also need a baseline support, copied from BasicSpinnerUI. Thanks alexp From artem.ananiev at oracle.com Mon Feb 6 08:38:33 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 06 Feb 2012 20:38:33 +0400 Subject: Mac OS X port - update In-Reply-To: <4F2C315F.8050608@oracle.com> References: <4F2B422D.20907@oracle.com> <4F2BC397.5090208@oracle.com> <4F2BFD22.6030502@oracle.COM> <4F2BFEF8.9060803@oracle.com> <4F2BFFD9.3050101@oracle.COM> <4F2C315F.8050608@oracle.com> Message-ID: <4F300209.6090906@oracle.com> On 2/3/2012 11:11 PM, Jim Holmlund wrote: > > On 2/3/2012 7:40 AM, Kumar Srinivasan wrote: >> On 2/3/2012 7:36 AM, Alan Bateman wrote: >>> On 03/02/2012 15:28, Kumar Srinivasan wrote: >>>> On 2/3/2012 3:23 AM, Alan Bateman wrote: >>>>> On 03/02/2012 02:10, David Holmes wrote: >>>>>> >>>>>> I am concerned. There was some discussion when various changes >>>>>> went into 7u-osx regarding the suitability of the changes for >>>>>> inclusion in the mainline repositories ie 7u-dev. It was my >>>>>> understanding that there would be a more extensive review and, if >>>>>> necessary, clean up process, before those changes were merged into >>>>>> the mainline 7u-dev. I have only seen that happen for a couple of >>>>>> specific issues. >>>>> You're right, there were several concerns about some areas of the >>>>> code when jdk7u-osx was setup. One was the launcher and that has >>>>> since been sorted out by Kumar, another was the jnilib support, >>>>> which has >>>> Right! I am planning on forward porting these changes to jdk8, >>>> shortly. :-) >>> I think Michael plans to get everything into jdk8 soon so I would >>> suggest sync'ing up with him before bringing over individual areas. >> >> That sounds good, thanks! and I was not aware of this. >> > I wasn't aware of this either. Is this official, and we don't need to > port our own changes to jdk8? Right now, JDK8 doesn't contain Mac OS X specific code, it cannot be built or run on Mac, so I don't see how individual fixes can be fw-ported. Instead, I would expect bulk migration from 7u to 8 similar to what Michael/Alex did for macosx-port to 7u-osx and 7u-osx to 7u-dev. Thanks, Artem > - jjh > >> Kumar >> >>> >>> -Alan >> From artem.ananiev at oracle.com Mon Feb 6 08:45:18 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 06 Feb 2012 20:45:18 +0400 Subject: Review request for 7141281: [macosx] GridBagLayout baseline issue In-Reply-To: <4F2FFDB8.7010600@oracle.com> References: <4F2FFDB8.7010600@oracle.com> Message-ID: <4F30039E.5010003@oracle.com> On 2/6/2012 8:20 PM, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7141281/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141281 > > With http://java.net/jira/browse/MACOSX_PORT-626 > JSpinner now supports setFont() method. > We also need a baseline support, copied from BasicSpinnerUI. Does it make sense to call super.getX() methods, given that the returned values are ignored anyway? Thanks, Artem > Thanks > alexp > > From anthony.petrov at oracle.com Mon Feb 6 08:49:45 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 06 Feb 2012 20:49:45 +0400 Subject: Review request for 7142120: [macosx] Some JCK tests for SplashScreen fail on Mac OS X due to incorrect positioning of the splash In-Reply-To: <4F2FFD21.90003@oracle.com> References: <4F2BDF81.7050805@oracle.com> <4F2FFD21.90003@oracle.com> Message-ID: <4F3004A9.6010904@oracle.com> Hi Artem, BTW, the updated webrev is at http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.1/ Please find my comments inline. On 2/6/2012 8:17 PM, Artem Ananiev wrote: > > On 2/3/2012 5:22 PM, Anthony Petrov wrote: >> Hello, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7142120 >> at: >> >> http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.0/ >> >> The fix is fairly simple: use NSScreen -frame instead of -visibleFrame. >> In this case the splash screen is positioned in the geometrical center >> of the screen. Visually this looks less pleasant (we may want to file an >> RFE in the future), but makes tests happy which is what we need right >> now. > > So what exactly do the tests expect? Does the test calculates the > expected splashscreen position and compares to the value of > SplashScreen.getBounds()? Does the latter method returns an incorrect > value? > > What I see in JavaDoc is just: "The window is positioned at the center > of the screen." It's unclear if the center of the screen should or > should not include screen insets. The test uses a 100x100 pixels image as a splash screen image. It then calls the GraphicsDevice.getDisplayMode().getWidth/Height() methods and expects to find the splash screen in the geometrical center of the screen (using SplashScreen.getBounds()). I.e. the screen insets are ignored. Given that the tests pass on Windows, Linux, and Solaris, it makes sense to implement the same behavior on Mac OS X as well. -- best regards, Anthony > > Thanks, > > Artem > >> All the failing tests now pass well with this fix applied. >> >> -- >> best regards, >> Anthony From james.holmlund at oracle.com Mon Feb 6 08:50:14 2012 From: james.holmlund at oracle.com (Jim Holmlund) Date: Mon, 06 Feb 2012 08:50:14 -0800 Subject: Mac OS X port - update In-Reply-To: <4F300209.6090906@oracle.com> References: <4F2B422D.20907@oracle.com> <4F2BC397.5090208@oracle.com> <4F2BFD22.6030502@oracle.COM> <4F2BFEF8.9060803@oracle.com> <4F2BFFD9.3050101@oracle.COM> <4F2C315F.8050608@oracle.com> <4F300209.6090906@oracle.com> Message-ID: <4F3004C6.2040800@oracle.com> On 2/6/2012 8:38 AM, Artem Ananiev wrote: > > On 2/3/2012 11:11 PM, Jim Holmlund wrote: >> >> On 2/3/2012 7:40 AM, Kumar Srinivasan wrote: >>> On 2/3/2012 7:36 AM, Alan Bateman wrote: >>>> On 03/02/2012 15:28, Kumar Srinivasan wrote: >>>>> On 2/3/2012 3:23 AM, Alan Bateman wrote: >>>>>> On 03/02/2012 02:10, David Holmes wrote: >>>>>>> >>>>>>> I am concerned. There was some discussion when various changes >>>>>>> went into 7u-osx regarding the suitability of the changes for >>>>>>> inclusion in the mainline repositories ie 7u-dev. It was my >>>>>>> understanding that there would be a more extensive review and, if >>>>>>> necessary, clean up process, before those changes were merged into >>>>>>> the mainline 7u-dev. I have only seen that happen for a couple of >>>>>>> specific issues. >>>>>> You're right, there were several concerns about some areas of the >>>>>> code when jdk7u-osx was setup. One was the launcher and that has >>>>>> since been sorted out by Kumar, another was the jnilib support, >>>>>> which has >>>>> Right! I am planning on forward porting these changes to jdk8, >>>>> shortly. :-) >>>> I think Michael plans to get everything into jdk8 soon so I would >>>> suggest sync'ing up with him before bringing over individual areas. >>> >>> That sounds good, thanks! and I was not aware of this. >>> >> I wasn't aware of this either. Is this official, and we don't need to >> port our own changes to jdk8? > > Right now, JDK8 doesn't contain Mac OS X specific code, it cannot be built or run on Mac, so I > don't see how individual fixes can be fw-ported. Instead, I would expect bulk migration from 7u to > 8 similar to what Michael/Alex did for macosx-port to 7u-osx and 7u-osx to 7u-dev. > The fixes I made to the langtools repo consisted of making a makefile or two and some shell script tests aware of macos. These changes could be ported to jdk8, without breaking anything, but as you say, there would be no way to test the changes. So, I'll let this proposed bulk migration port the changes. - jjh > Thanks, > > Artem > >> - jjh >> >>> Kumar >>> >>>> >>>> -Alan >>> From artem.ananiev at oracle.com Mon Feb 6 09:12:02 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 06 Feb 2012 21:12:02 +0400 Subject: Mac OS X port - update In-Reply-To: <4F3004C6.2040800@oracle.com> References: <4F2B422D.20907@oracle.com> <4F2BC397.5090208@oracle.com> <4F2BFD22.6030502@oracle.COM> <4F2BFEF8.9060803@oracle.com> <4F2BFFD9.3050101@oracle.COM> <4F2C315F.8050608@oracle.com> <4F300209.6090906@oracle.com> <4F3004C6.2040800@oracle.com> Message-ID: <4F3009E2.2090500@oracle.com> On 2/6/2012 8:50 PM, Jim Holmlund wrote: > > On 2/6/2012 8:38 AM, Artem Ananiev wrote: >> >> On 2/3/2012 11:11 PM, Jim Holmlund wrote: >>> >>> On 2/3/2012 7:40 AM, Kumar Srinivasan wrote: >>>> On 2/3/2012 7:36 AM, Alan Bateman wrote: >>>>> On 03/02/2012 15:28, Kumar Srinivasan wrote: >>>>>> On 2/3/2012 3:23 AM, Alan Bateman wrote: >>>>>>> On 03/02/2012 02:10, David Holmes wrote: >>>>>>>> >>>>>>>> I am concerned. There was some discussion when various changes >>>>>>>> went into 7u-osx regarding the suitability of the changes for >>>>>>>> inclusion in the mainline repositories ie 7u-dev. It was my >>>>>>>> understanding that there would be a more extensive review and, if >>>>>>>> necessary, clean up process, before those changes were merged into >>>>>>>> the mainline 7u-dev. I have only seen that happen for a couple of >>>>>>>> specific issues. >>>>>>> You're right, there were several concerns about some areas of the >>>>>>> code when jdk7u-osx was setup. One was the launcher and that has >>>>>>> since been sorted out by Kumar, another was the jnilib support, >>>>>>> which has >>>>>> Right! I am planning on forward porting these changes to jdk8, >>>>>> shortly. :-) >>>>> I think Michael plans to get everything into jdk8 soon so I would >>>>> suggest sync'ing up with him before bringing over individual areas. >>>> >>>> That sounds good, thanks! and I was not aware of this. >>>> >>> I wasn't aware of this either. Is this official, and we don't need to >>> port our own changes to jdk8? >> >> Right now, JDK8 doesn't contain Mac OS X specific code, it cannot be >> built or run on Mac, so I don't see how individual fixes can be >> fw-ported. Instead, I would expect bulk migration from 7u to 8 similar >> to what Michael/Alex did for macosx-port to 7u-osx and 7u-osx to 7u-dev. >> > The fixes I made to the langtools repo consisted of making a makefile or > two and some shell script tests aware of macos. These changes could be > ported to jdk8, without breaking anything, but as you say, there would > be no way to test the changes. So, I'll let this proposed bulk migration > port the changes. You're right. Moreover, any change like this would become a conflict when merging from 7u to 8. Thanks, Artem > - jjh > >> Thanks, >> >> Artem >> >>> - jjh >>> >>>> Kumar >>>> >>>>> >>>>> -Alan >>>> From kumar.x.srinivasan at oracle.COM Mon Feb 6 09:31:02 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 06 Feb 2012 09:31:02 -0800 Subject: Mac OS X port - update In-Reply-To: <4F3009E2.2090500@oracle.com> References: <4F2B422D.20907@oracle.com> <4F2BC397.5090208@oracle.com> <4F2BFD22.6030502@oracle.COM> <4F2BFEF8.9060803@oracle.com> <4F2BFFD9.3050101@oracle.COM> <4F2C315F.8050608@oracle.com> <4F300209.6090906@oracle.com> <4F3004C6.2040800@oracle.com> <4F3009E2.2090500@oracle.com> Message-ID: <4F300E56.5030600@oracle.COM> >>> Right now, JDK8 doesn't contain Mac OS X specific code, it cannot be >>> built or run on Mac, so I don't see how individual fixes can be >>> fw-ported. Instead, I would expect bulk migration from 7u to 8 similar >>> to what Michael/Alex did for macosx-port to 7u-osx and 7u-osx to >>> 7u-dev. >>> >> The fixes I made to the langtools repo consisted of making a makefile or >> two and some shell script tests aware of macos. These changes could be >> ported to jdk8, without breaking anything, but as you say, there would >> be no way to test the changes. So, I'll let this proposed bulk migration >> port the changes. > > You're right. Moreover, any change like this would become a conflict > when merging from 7u to 8. For this very reason, I think we need to do this relatively quickly, as the source base in jdk8 is diverging or will diverge rapidly. Kumar > > Thanks, > > Artem > >> - jjh >> >>> Thanks, >>> >>> Artem >>> >>>> - jjh >>>> >>>>> Kumar >>>>> >>>>>> >>>>>> -Alan >>>>> From sergey.bylokhov at oracle.com Mon Feb 6 13:57:00 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 07 Feb 2012 01:57:00 +0400 Subject: NSEvent methods Message-ID: <4F304CAC.3090706@oracle.com> Hello, Everybody. I want to rename methods in NSEvent.java and corresponding native methodsas follows: nsButtonToJavaButton -> nsToJavaButton npEventTypeToJavaEventType -> npToJavaEventType nsEventTypeToJavaEventType -> nsToJavaEventType nsMouseModifiersToJavaMouseModifiers -> nsToJavaMouseModifiers nsKeyModifiersToJavaKeyModifiers -> nsToJavaKeyModifiers nsKeyInfoToJavaKeyInfo -> nsToJavaKeyInfo nsKeyModifiersToJavaKeyInfo -> nsToJavaKeyInfo Does anybody have objections about it? -- Best regards, Sergey. From michael.x.mcmahon at oracle.com Mon Feb 6 14:31:21 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 06 Feb 2012 22:31:21 +0000 Subject: RFR 7142950: jdk7u cannot bootstrap Mac OS build [macosx] Message-ID: <4F3054B9.5070009@oracle.com> There are a few problems with the Mac build at the moment. 1. If SKIP_BOOT_CYCLE=false then the build fails, due to two problems:- 1) top level Makefile doesn't know about Mac OS image directory structure 2) it also fails due to problem 2. below 2. General bootstrapping problem. The build currently cannot use itself as the bootstrap JDK due to an assumption in the framework classes that "os.arch" is x86_64, whereas we currently set it to amd64. The change is to fix that code to expect amd64. There is a related question then about what the correct value for os.arch should be. I'd like to raise this in a separate discussion and hopefully fix these build problems independently of that. 3. jvm.cfg is currently being taken from the solaris src tree even though a macos version of the file is there. Fix that problem too. The macos source jvm.cfg is changed to be the same as the solaris/amd64 version (ie. the one that was being used, and which makes -client UNKNOWN) The following webrevs address these issues. Top level repo ------------------ http://cr.openjdk.java.net/~michaelm/7142950/top/webrev.1/ JDK repo ------------ http://cr.openjdk.java.net/~michaelm/7142950/jdk/webrev.1/ From michael.x.mcmahon at oracle.com Mon Feb 6 14:51:02 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 06 Feb 2012 22:51:02 +0000 Subject: os.arch "amd64" or "x86_64"? Message-ID: <4F305956.2000507@oracle.com> Following from the last message, I just want to get opinions on this question. Currently, the os.arch system property is set to "amd64" in common with the other platforms (solaris, windows and Linux) when running on an amd64/x86_64 CPU. However, the property is set to "x86_64" in Apple's Java 6 runtime. So, the question is, what/if any compatibility issues could there be, if we maintain this behavior? On the other hand there probably should be a good reason to change it so it's different from the other 64 bit platforms. Thanks, Michael. From swpalmer at gmail.com Mon Feb 6 15:00:15 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 6 Feb 2012 18:00:15 -0500 Subject: os.arch "amd64" or "x86_64"? In-Reply-To: <4F305956.2000507@oracle.com> References: <4F305956.2000507@oracle.com> Message-ID: <-8564745364809231623@unknownmsgid> Just letting you know that changing this would break my builds as I use that property as part of a classifier for Maven artifacts containing a zip of native libraries for JNI. (Including the JavaFX runtime that we have deployed to our private repo) Scott On 2012-02-06, at 5:51 PM, Michael McMahon wrote: > Following from the last message, I just want to get opinions on this question. > Currently, the os.arch system property is set to "amd64" in common with the > other platforms (solaris, windows and Linux) when running on an amd64/x86_64 CPU. > However, the property is set to "x86_64" in Apple's Java 6 runtime. > > So, the question is, what/if any compatibility issues could there be, if we maintain > this behavior? On the other hand there probably should be a good reason to change it > so it's different from the other 64 bit platforms. > > Thanks, > Michael. From daniel.daugherty at oracle.com Mon Feb 6 15:04:12 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 06 Feb 2012 16:04:12 -0700 Subject: os.arch "amd64" or "x86_64"? In-Reply-To: <4F305956.2000507@oracle.com> References: <4F305956.2000507@oracle.com> Message-ID: <4F305C6C.9000404@oracle.com> We should match the value used by Apple's Java 6 runtime to avoid any unnecessary compatibility problems with programs that currently run on Apple's Java 6... Also, Oracle's RE group has been migrating away from using 'amd64' to using 'x64'. Currently, 'amd64' in the promoted binaries and bundles directories is a symbolic link to the 'x64' directories. Dan > Following from the last message, I just want to get opinions on this > question. > Currently, the os.arch system property is set to "amd64" in common > with the > other platforms (solaris, windows and Linux) when running on an > amd64/x86_64 CPU. > However, the property is set to "x86_64" in Apple's Java 6 runtime. > > So, the question is, what/if any compatibility issues could there be, > if we maintain > this behavior? On the other hand there probably should be a good > reason to change it > so it's different from the other 64 bit platforms. > > Thanks, > Michael. From daniel.daugherty at oracle.com Mon Feb 6 15:06:11 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 06 Feb 2012 16:06:11 -0700 Subject: RFR 7142950: jdk7u cannot bootstrap Mac OS build [macosx] In-Reply-To: <4F3054B9.5070009@oracle.com> References: <4F3054B9.5070009@oracle.com> Message-ID: <4F305CE3.6060204@oracle.com> > There are a few problems with the Mac build at the moment. > > 1. If SKIP_BOOT_CYCLE=false then the build fails, due to two problems:- > 1) top level Makefile doesn't know about Mac OS image directory > structure > 2) it also fails due to problem 2. below > > 2. General bootstrapping problem. The build currently cannot use > itself as > the bootstrap JDK due to an assumption in the framework classes that > "os.arch" is x86_64, whereas we currently set it to amd64. The > change is to > fix that code to expect amd64. There is a related question then > about what the > correct value for os.arch should be. I'd like to raise this in a > separate discussion > and hopefully fix these build problems independently of that. Please don't change to expect "amd64". That's the wrong direction (IMHO)... Dan > 3. jvm.cfg is currently being taken from the solaris src tree even though > a macos version of the file is there. Fix that problem too. The macos > source jvm.cfg is changed to be the same as the solaris/amd64 version > (ie. the one that was being used, and which makes -client UNKNOWN) > > The following webrevs address these issues. > > Top level repo > ------------------ > http://cr.openjdk.java.net/~michaelm/7142950/top/webrev.1/ > > JDK repo > ------------ > http://cr.openjdk.java.net/~michaelm/7142950/jdk/webrev.1/ From scott.kovatch at oracle.com Mon Feb 6 15:07:19 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 6 Feb 2012 15:07:19 -0800 Subject: os.arch "amd64" or "x86_64"? In-Reply-To: <4F305956.2000507@oracle.com> References: <4F305956.2000507@oracle.com> Message-ID: <04472581-D0D8-4DF7-B5F2-0A2713DDAD36@oracle.com> On Feb 6, 2012, at 2:51 PM, Michael McMahon wrote: > Following from the last message, I just want to get opinions on this question. > Currently, the os.arch system property is set to "amd64" in common with the > other platforms (solaris, windows and Linux) when running on an amd64/x86_64 CPU. > However, the property is set to "x86_64" in Apple's Java 6 runtime. > > So, the question is, what/if any compatibility issues could there be, if we maintain > this behavior? On the other hand there probably should be a good reason to change it > so it's different from the other 64 bit platforms. Web Start is the main area of compatibility that I know of. By changing it to 'amd64' developers would need to rev their JNLP files to handle the new value for os.arch on the Mac. For bundled applications Apple supported per-architecture JVM options in the application's Info.plist, but developers will need to rebundle with JDK 7 anyway. It won't be an issue unless we need to support universal binaries for non-Oracle-provided JDK distributions. -- Scott K. From daniel.daugherty at oracle.com Mon Feb 6 15:14:09 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 06 Feb 2012 16:14:09 -0700 Subject: os.arch "amd64" or "x86_64"? In-Reply-To: <4F305C6C.9000404@oracle.com> References: <4F305956.2000507@oracle.com> <4F305C6C.9000404@oracle.com> Message-ID: <4F305EC1.2080209@oracle.com> BTW, there's an open bug for this one also: 7130404 [macosx] "os.arch" value should be "x86_64" for compatibility with Apple Jim is working on 7130404... Dan > We should match the value used by Apple's Java 6 runtime to avoid > any unnecessary compatibility problems with programs that currently > run on Apple's Java 6... > > Also, Oracle's RE group has been migrating away from using 'amd64' > to using 'x64'. Currently, 'amd64' in the promoted binaries and > bundles directories is a symbolic link to the 'x64' directories. > > Dan > >> Following from the last message, I just want to get opinions on this >> question. >> Currently, the os.arch system property is set to "amd64" in common >> with the >> other platforms (solaris, windows and Linux) when running on an >> amd64/x86_64 CPU. >> However, the property is set to "x86_64" in Apple's Java 6 runtime. >> >> So, the question is, what/if any compatibility issues could there be, >> if we maintain >> this behavior? On the other hand there probably should be a good >> reason to change it >> so it's different from the other 64 bit platforms. >> >> Thanks, >> Michael. From scott.kovatch at oracle.com Mon Feb 6 15:21:00 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 6 Feb 2012 15:21:00 -0800 Subject: RFR 7142950: jdk7u cannot bootstrap Mac OS build [macosx] In-Reply-To: <4F3054B9.5070009@oracle.com> References: <4F3054B9.5070009@oracle.com> Message-ID: <32131CAD-A904-4DA1-8E8D-ADBDD73A6279@oracle.com> On Feb 6, 2012, at 2:31 PM, Michael McMahon wrote: > There are a few problems with the Mac build at the moment. > > 1. If SKIP_BOOT_CYCLE=false then the build fails, due to two problems:- > 1) top level Makefile doesn't know about Mac OS image directory structure > 2) it also fails due to problem 2. below > 2. General bootstrapping problem. The build currently cannot use itself as > the bootstrap JDK due to an assumption in the framework classes that > "os.arch" is x86_64, whereas we currently set it to amd64. The change is to > fix that code to expect amd64. There is a related question then about what the > correct value for os.arch should be. I'd like to raise this in a separate discussion > and hopefully fix these build problems independently of that. I was going to propose that we fix the image directory issues by building into the image directories the same way on all platforms and have the mac build copy the image directories into j2sdk-bundle. (7133768) I'm pretty sure that even with this change you can't build rt.jar because the jar tool gets moved out from underneath the running build when the bundle is constructed. I don't think your changes would interfere with my proposed fix for 7133768, though. And, the other changes for generating the folder name dynamically are very much welcome. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From steve.x.northover at oracle.com Mon Feb 6 16:05:29 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Mon, 06 Feb 2012 19:05:29 -0500 Subject: os.arch "amd64" or "x86_64"? In-Reply-To: <04472581-D0D8-4DF7-B5F2-0A2713DDAD36@oracle.com> References: <4F305956.2000507@oracle.com> <04472581-D0D8-4DF7-B5F2-0A2713DDAD36@oracle.com> Message-ID: <4F306AC9.1000701@oracle.com> Please don't change this. People rely on values like this and you will break them -- guaranteed. Steve On 06/02/2012 6:07 PM, Scott Kovatch wrote: > On Feb 6, 2012, at 2:51 PM, Michael McMahon wrote: > >> Following from the last message, I just want to get opinions on this question. >> Currently, the os.arch system property is set to "amd64" in common with the >> other platforms (solaris, windows and Linux) when running on an amd64/x86_64 CPU. >> However, the property is set to "x86_64" in Apple's Java 6 runtime. >> >> So, the question is, what/if any compatibility issues could there be, if we maintain >> this behavior? On the other hand there probably should be a good reason to change it >> so it's different from the other 64 bit platforms. > Web Start is the main area of compatibility that I know of. By changing it to 'amd64' developers would need to rev their JNLP files to handle the new value for os.arch on the Mac. > > For bundled applications Apple supported per-architecture JVM options in the application's Info.plist, but developers will need to rebundle with JDK 7 anyway. It won't be an issue unless we need to support universal binaries for non-Oracle-provided JDK distributions. > > -- Scott K. > From kelly.ohair at oracle.com Mon Feb 6 16:33:45 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 6 Feb 2012 16:33:45 -0800 Subject: os.arch "amd64" or "x86_64"? In-Reply-To: <4F306AC9.1000701@oracle.com> References: <4F305956.2000507@oracle.com> <04472581-D0D8-4DF7-B5F2-0A2713DDAD36@oracle.com> <4F306AC9.1000701@oracle.com> Message-ID: When you say don't change this, could you be clear what os.arch setting you want? I'm advocating changing the existing code to use x86_64, so we match Apple's JDK6. -kto On Feb 6, 2012, at 4:05 PM, steve.x.northover at oracle.com wrote: > Please don't change this. People rely on values like this and you will break them -- guaranteed. > > Steve > > On 06/02/2012 6:07 PM, Scott Kovatch wrote: >> On Feb 6, 2012, at 2:51 PM, Michael McMahon wrote: >> >>> Following from the last message, I just want to get opinions on this question. >>> Currently, the os.arch system property is set to "amd64" in common with the >>> other platforms (solaris, windows and Linux) when running on an amd64/x86_64 CPU. >>> However, the property is set to "x86_64" in Apple's Java 6 runtime. >>> >>> So, the question is, what/if any compatibility issues could there be, if we maintain >>> this behavior? On the other hand there probably should be a good reason to change it >>> so it's different from the other 64 bit platforms. >> Web Start is the main area of compatibility that I know of. By changing it to 'amd64' developers would need to rev their JNLP files to handle the new value for os.arch on the Mac. >> >> For bundled applications Apple supported per-architecture JVM options in the application's Info.plist, but developers will need to rebundle with JDK 7 anyway. It won't be an issue unless we need to support universal binaries for non-Oracle-provided JDK distributions. >> >> -- Scott K. >> From steve.x.northover at oracle.com Mon Feb 6 16:47:08 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Mon, 06 Feb 2012 19:47:08 -0500 Subject: os.arch "amd64" or "x86_64"? In-Reply-To: References: <4F305956.2000507@oracle.com> <04472581-D0D8-4DF7-B5F2-0A2713DDAD36@oracle.com> <4F306AC9.1000701@oracle.com> Message-ID: <4F30748C.5070701@oracle.com> Sorry. I meant "please match Apple's JDK6". Thanks! Steve On 06/02/2012 7:33 PM, Kelly O'Hair wrote: > When you say don't change this, could you be clear what os.arch setting you want? > > I'm advocating changing the existing code to use x86_64, so we match Apple's JDK6. > > -kto > > On Feb 6, 2012, at 4:05 PM, steve.x.northover at oracle.com wrote: > >> Please don't change this. People rely on values like this and you will break them -- guaranteed. >> >> Steve >> >> On 06/02/2012 6:07 PM, Scott Kovatch wrote: >>> On Feb 6, 2012, at 2:51 PM, Michael McMahon wrote: >>> >>>> Following from the last message, I just want to get opinions on this question. >>>> Currently, the os.arch system property is set to "amd64" in common with the >>>> other platforms (solaris, windows and Linux) when running on an amd64/x86_64 CPU. >>>> However, the property is set to "x86_64" in Apple's Java 6 runtime. >>>> >>>> So, the question is, what/if any compatibility issues could there be, if we maintain >>>> this behavior? On the other hand there probably should be a good reason to change it >>>> so it's different from the other 64 bit platforms. >>> Web Start is the main area of compatibility that I know of. By changing it to 'amd64' developers would need to rev their JNLP files to handle the new value for os.arch on the Mac. >>> >>> For bundled applications Apple supported per-architecture JVM options in the application's Info.plist, but developers will need to rebundle with JDK 7 anyway. It won't be an issue unless we need to support universal binaries for non-Oracle-provided JDK distributions. >>> >>> -- Scott K. >>> From swpalmer at gmail.com Mon Feb 6 16:53:54 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 6 Feb 2012 19:53:54 -0500 Subject: os.arch "amd64" or "x86_64"? In-Reply-To: References: <4F305956.2000507@oracle.com> <04472581-D0D8-4DF7-B5F2-0A2713DDAD36@oracle.com> <4F306AC9.1000701@oracle.com> Message-ID: I am using x86_64 with JDK 6 builds on OS X? So that is the value that "people are relying on" for the OS X platform, and therefore the value that must be preserved in JDK 7. The JDK 6 "java" command on OS X mentions this value as well, so it technically isn't even restricted to internal developer details (though most non-developers on OS X would never run "java" from the command line). >java -? ? where options include: -d32 use a 32-bit data model if available -d64 use a 64-bit data model if available (implies -server, only for x86_64) ? Regards, Scott P. On 2012-02-06, at 7:33 PM, Kelly O'Hair wrote: > When you say don't change this, could you be clear what os.arch setting you want? > > I'm advocating changing the existing code to use x86_64, so we match Apple's JDK6. > > -kto > > On Feb 6, 2012, at 4:05 PM, steve.x.northover at oracle.com wrote: > >> Please don't change this. People rely on values like this and you will break them -- guaranteed. >> >> Steve >> >> On 06/02/2012 6:07 PM, Scott Kovatch wrote: >>> On Feb 6, 2012, at 2:51 PM, Michael McMahon wrote: >>> >>>> Following from the last message, I just want to get opinions on this question. >>>> Currently, the os.arch system property is set to "amd64" in common with the >>>> other platforms (solaris, windows and Linux) when running on an amd64/x86_64 CPU. >>>> However, the property is set to "x86_64" in Apple's Java 6 runtime. >>>> >>>> So, the question is, what/if any compatibility issues could there be, if we maintain >>>> this behavior? On the other hand there probably should be a good reason to change it >>>> so it's different from the other 64 bit platforms. >>> Web Start is the main area of compatibility that I know of. By changing it to 'amd64' developers would need to rev their JNLP files to handle the new value for os.arch on the Mac. >>> >>> For bundled applications Apple supported per-architecture JVM options in the application's Info.plist, but developers will need to rebundle with JDK 7 anyway. It won't be an issue unless we need to support universal binaries for non-Oracle-provided JDK distributions. >>> >>> -- Scott K. >>> > From edvard.wendelin at oracle.com Mon Feb 6 23:05:31 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 7 Feb 2012 08:05:31 +0100 Subject: Mac OS X port - update In-Reply-To: References: Message-ID: <61207844-8CCD-4218-A415-03461018B74B@oracle.com> Thanks to Lana's integration, The Mac OS port is now in the jdk7u master. Additionally Alejandro has a few Hotspot fixes he wants to get in before Thursday's build. The next step is to merge it into JDK 8. I'll let you know as soon as I know more about how and when that will happen. Cheers, Edvard On Feb 2, 2012, at 10:32 PM, Edvard Wendelin wrote: > Hi, > > As you might have noticed, 7u-osx [1] was pushed to 7u-dev [2] yesterday. There will be a build from 7u-dev today that QA will run Pre-integration testing on. During the coming week, we will make sure that any potential quirks found in 7u-dev as a result of the osx integration are fixed before next weeks (Thu 9th) build promotion. This means that from next week on the regular promotions will contain OS X bundles just like the other platforms. We will soon also make the jdk7u-osx [1] forest read only. All fixes related to the Mac OS X port should from now on go through jdk7u-dev [2] and jdk7u-dev at openjdk.java.net. > > > Cheers, > Edvard > > [1] http://hg.openjdk.java.net/jdk7u/jdk7u-osx/ > [2] http://hg.openjdk.java.net/jdk7u/jdk7u-dev/ From michael.x.mcmahon at oracle.com Tue Feb 7 01:08:58 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 07 Feb 2012 09:08:58 +0000 Subject: os.arch "amd64" or "x86_64"? In-Reply-To: References: <4F305956.2000507@oracle.com> <04472581-D0D8-4DF7-B5F2-0A2713DDAD36@oracle.com> <4F306AC9.1000701@oracle.com> Message-ID: <4F30EA2A.3010706@oracle.com> Yes, I think people are missing the point that it is currently amd64 and we have to change it, to restore the old behavior. But, it seems to be clear all right that compatibility for existing code is the primary consideration. So, I agree we should change it back to x86_64. However, even though Oracle's RE is pushing in the same direction in relation to the naming of the bundles, I'd think it is very unlikely that the other platforms will be changing their os.arch from amd64 any time soon. Thanks, Michael. On 07/02/12 00:33, Kelly O'Hair wrote: > When you say don't change this, could you be clear what os.arch setting you want? > > I'm advocating changing the existing code to use x86_64, so we match Apple's JDK6. > > -kto > > On Feb 6, 2012, at 4:05 PM, steve.x.northover at oracle.com wrote: > >> Please don't change this. People rely on values like this and you will break them -- guaranteed. >> >> Steve >> >> On 06/02/2012 6:07 PM, Scott Kovatch wrote: >>> On Feb 6, 2012, at 2:51 PM, Michael McMahon wrote: >>> >>>> Following from the last message, I just want to get opinions on this question. >>>> Currently, the os.arch system property is set to "amd64" in common with the >>>> other platforms (solaris, windows and Linux) when running on an amd64/x86_64 CPU. >>>> However, the property is set to "x86_64" in Apple's Java 6 runtime. >>>> >>>> So, the question is, what/if any compatibility issues could there be, if we maintain >>>> this behavior? On the other hand there probably should be a good reason to change it >>>> so it's different from the other 64 bit platforms. >>> Web Start is the main area of compatibility that I know of. By changing it to 'amd64' developers would need to rev their JNLP files to handle the new value for os.arch on the Mac. >>> >>> For bundled applications Apple supported per-architecture JVM options in the application's Info.plist, but developers will need to rebundle with JDK 7 anyway. It won't be an issue unless we need to support universal binaries for non-Oracle-provided JDK distributions. >>> >>> -- Scott K. >>> From alexander.zuev at oracle.com Tue Feb 7 05:48:30 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 07 Feb 2012 16:48:30 +0300 Subject: Review request for 7142120: [macosx] Some JCK tests for SplashScreen fail on Mac OS X due to incorrect positioning of the splash In-Reply-To: <4F3004A9.6010904@oracle.com> References: <4F2BDF81.7050805@oracle.com> <4F2FFD21.90003@oracle.com> <4F3004A9.6010904@oracle.com> Message-ID: <4F312BAE.7010802@oracle.com> Looks Ok to me (assuming that even if we start program on the second screen the splashscreen should have been placed on main screen where dock and menu bar are). WBR, Alex On 2/6/12 19:49, Anthony Petrov wrote: > Hi Artem, > > BTW, the updated webrev is at > http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.1/ > > Please find my comments inline. > > On 2/6/2012 8:17 PM, Artem Ananiev wrote: >> >> On 2/3/2012 5:22 PM, Anthony Petrov wrote: >>> Hello, >>> >>> Please review a fix for >>> http://bugs.sun.com/view_bug.do?bug_id=7142120 at: >>> >>> http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.0/ >>> >>> The fix is fairly simple: use NSScreen -frame instead of -visibleFrame. >>> In this case the splash screen is positioned in the geometrical center >>> of the screen. Visually this looks less pleasant (we may want to >>> file an >>> RFE in the future), but makes tests happy which is what we need >>> right now. >> >> So what exactly do the tests expect? Does the test calculates the >> expected splashscreen position and compares to the value of >> SplashScreen.getBounds()? Does the latter method returns an incorrect >> value? >> >> What I see in JavaDoc is just: "The window is positioned at the >> center of the screen." It's unclear if the center of the screen >> should or should not include screen insets. > > The test uses a 100x100 pixels image as a splash screen image. It then > calls the GraphicsDevice.getDisplayMode().getWidth/Height() methods > and expects to find the splash screen in the geometrical center of the > screen (using SplashScreen.getBounds()). I.e. the screen insets are > ignored. > > Given that the tests pass on Windows, Linux, and Solaris, it makes > sense to implement the same behavior on Mac OS X as well. > > -- > best regards, > Anthony > >> >> Thanks, >> >> Artem >> >>> All the failing tests now pass well with this fix applied. >>> >>> -- >>> best regards, >>> Anthony From sergey.bylokhov at oracle.com Tue Feb 7 05:41:05 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 07 Feb 2012 17:41:05 +0400 Subject: NSEvent methods In-Reply-To: <4F304CAC.3090706@oracle.com> References: <4F304CAC.3090706@oracle.com> Message-ID: <4F3129F1.1090009@oracle.com> 07.02.2012 1:57, Sergey Bylokhov wrote: > Hello, Everybody. > I want to rename methods in NSEvent.java and corresponding native > methodsas follows: > > nsButtonToJavaButton -> nsToJavaButton > npEventTypeToJavaEventType -> npToJavaEventType > nsEventTypeToJavaEventType -> nsToJavaEventType > nsMouseModifiersToJavaMouseModifiers -> nsToJavaMouseModifiers > nsKeyModifiersToJavaKeyModifiers -> nsToJavaKeyModifiers > nsKeyInfoToJavaKeyInfo -> nsToJavaKeyInfo > nsKeyModifiersToJavaKeyInfo -> nsToJavaKeyInfo Ok. I'll rename them except the last one. > > Does anybody have objections about it? > -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Feb 7 06:16:01 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 07 Feb 2012 18:16:01 +0400 Subject: [7u4] Request for approval for 7142120: [macosx] Some JCK tests for SplashScreen fail on Mac OS X due to incorrect positioning of the splash Message-ID: <4F313221.9040803@oracle.com> This is a request to push the following fix to jdk7u-dev: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142120 http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.1/ Technical review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002808.html -- best regards, Anthony From artem.ananiev at oracle.com Tue Feb 7 07:04:19 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 07 Feb 2012 19:04:19 +0400 Subject: [7u4] Request for approval for 7142120: [macosx] Some JCK tests for SplashScreen fail on Mac OS X due to incorrect positioning of the splash In-Reply-To: <4F313221.9040803@oracle.com> References: <4F313221.9040803@oracle.com> Message-ID: <4F313D73.2000704@oracle.com> Approved. On 2/7/2012 6:16 PM, Anthony Petrov wrote: > This is a request to push the following fix to jdk7u-dev: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142120 > > http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.1/ > > Technical review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002808.html > > > -- > best regards, > Anthony > > > From gregg at wonderly.org Tue Feb 7 08:23:37 2012 From: gregg at wonderly.org (Gregg Wonderly) Date: Tue, 07 Feb 2012 10:23:37 -0600 Subject: Review request for 7142120: [macosx] Some JCK tests for SplashScreen fail on Mac OS X due to incorrect positioning of the splash In-Reply-To: <4F312BAE.7010802@oracle.com> References: <4F2BDF81.7050805@oracle.com> <4F2FFD21.90003@oracle.com> <4F3004A9.6010904@oracle.com> <4F312BAE.7010802@oracle.com> Message-ID: <4F315009.6000905@wonderly.org> This seems very distracting to me, to have the screen sliding around, without the users "control". This can cause focus changes and very gnarly results for people who are constantly multitasking, quickly switching between contexts. I have a JDK6 app, in particular, which is a network app, and when it disconnects, it pops up a dialog telling the user this occurs. That dialog, pops up on the active screen, I think, but the problem is, that if I click on the window (on another screen), it switches me to the screen with the dialog. If I then try to click on the dialog button, the app BEEPS at me when I click "okay". The only way to close the app, is to move the app to the screen that the dialog is on. Somehow, this should all work "better", in terms of managing how "context" sensitive actions are joined with the context of a window/frame component. When a dialog is brought up, and made "current", it steals focus. If I am touch typing, and type a "space", the dialog closes before I can read it. I'd really like to have something different happen, and for example, just having the jumping icon in the app bar would be quite indicative of me needing to take action on something. Gregg Wonderlyw On 2/7/2012 7:48 AM, Alexander Zuev wrote: > Looks Ok to me (assuming that even if we start program on the second screen > the splashscreen should have been placed on main screen where dock and menu > bar are). > > WBR, > Alex > > On 2/6/12 19:49, Anthony Petrov wrote: >> Hi Artem, >> >> BTW, the updated webrev is at >> http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.1/ >> >> Please find my comments inline. >> >> On 2/6/2012 8:17 PM, Artem Ananiev wrote: >>> >>> On 2/3/2012 5:22 PM, Anthony Petrov wrote: >>>> Hello, >>>> >>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7142120 at: >>>> >>>> http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.0/ >>>> >>>> The fix is fairly simple: use NSScreen -frame instead of -visibleFrame. >>>> In this case the splash screen is positioned in the geometrical center >>>> of the screen. Visually this looks less pleasant (we may want to file an >>>> RFE in the future), but makes tests happy which is what we need right now. >>> >>> So what exactly do the tests expect? Does the test calculates the expected >>> splashscreen position and compares to the value of SplashScreen.getBounds()? >>> Does the latter method returns an incorrect value? >>> >>> What I see in JavaDoc is just: "The window is positioned at the center of >>> the screen." It's unclear if the center of the screen should or should not >>> include screen insets. >> >> The test uses a 100x100 pixels image as a splash screen image. It then calls >> the GraphicsDevice.getDisplayMode().getWidth/Height() methods and expects to >> find the splash screen in the geometrical center of the screen (using >> SplashScreen.getBounds()). I.e. the screen insets are ignored. >> >> Given that the tests pass on Windows, Linux, and Solaris, it makes sense to >> implement the same behavior on Mac OS X as well. >> >> -- >> best regards, >> Anthony >> >>> >>> Thanks, >>> >>> Artem >>> >>>> All the failing tests now pass well with this fix applied. >>>> >>>> -- >>>> best regards, >>>> Anthony > > From Alexander.Potochkin at oracle.com Tue Feb 7 08:48:46 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 07 Feb 2012 20:48:46 +0400 Subject: Review request for 7141281: [macosx] GridBagLayout baseline issue In-Reply-To: <4F30039E.5010003@oracle.com> References: <4F2FFDB8.7010600@oracle.com> <4F30039E.5010003@oracle.com> Message-ID: <4F3155EE.8000505@oracle.com> Hello Artem > > On 2/6/2012 8:20 PM, Alexander Potochkin wrote: >> Hello >> >> Please review the following fix: >> http://cr.openjdk.java.net/~alexp/7141281/webrev.00/ >> >> the bug's description is here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141281 >> >> With http://java.net/jira/browse/MACOSX_PORT-626 >> JSpinner now supports setFont() method. >> We also need a baseline support, copied from BasicSpinnerUI. > > Does it make sense to call super.getX() methods, given that the > returned values are ignored anyway? > Both super methods check the parameters and throw an exception if they are not valid Thanks alexp > Thanks, > > Artem > >> Thanks >> alexp >> >> From artem.ananiev at oracle.com Tue Feb 7 09:12:43 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 07 Feb 2012 21:12:43 +0400 Subject: Review request for 7141281: [macosx] GridBagLayout baseline issue In-Reply-To: <4F3155EE.8000505@oracle.com> References: <4F2FFDB8.7010600@oracle.com> <4F30039E.5010003@oracle.com> <4F3155EE.8000505@oracle.com> Message-ID: <4F315B8B.6030904@oracle.com> On 2/7/2012 8:48 PM, Alexander Potochkin wrote: > Hello Artem >> >> On 2/6/2012 8:20 PM, Alexander Potochkin wrote: >>> Hello >>> >>> Please review the following fix: >>> http://cr.openjdk.java.net/~alexp/7141281/webrev.00/ >>> >>> the bug's description is here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141281 >>> >>> With http://java.net/jira/browse/MACOSX_PORT-626 >>> JSpinner now supports setFont() method. >>> We also need a baseline support, copied from BasicSpinnerUI. >> >> Does it make sense to call super.getX() methods, given that the >> returned values are ignored anyway? > > Both super methods check the parameters and throw an exception if they > are not valid OK. Thanks for clarifying that. Artem > Thanks > alexp > >> Thanks, >> >> Artem >> >>> Thanks >>> alexp >>> >>> > From kelly.ohair at oracle.com Tue Feb 7 09:40:37 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 7 Feb 2012 09:40:37 -0800 Subject: os.arch "amd64" or "x86_64"? In-Reply-To: <4F30EA2A.3010706@oracle.com> References: <4F305956.2000507@oracle.com> <04472581-D0D8-4DF7-B5F2-0A2713DDAD36@oracle.com> <4F306AC9.1000701@oracle.com> <4F30EA2A.3010706@oracle.com> Message-ID: <247F4ADF-4C19-400C-BA15-1BB383DCE349@oracle.com> On Feb 7, 2012, at 1:08 AM, Michael McMahon wrote: > I'd think it is very unlikely > that the other platforms will be changing their os.arch from amd64 any time soon. Understood, and I agree. -kto From Alexander.Potochkin at oracle.com Tue Feb 7 09:45:48 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 07 Feb 2012 21:45:48 +0400 Subject: [7u4] Request for approval for 7141281: [macosx] GridBagLayout baseline issue Message-ID: <4F31634C.1070909@oracle.com> Hello This is a request to push the following fix to jdk 7u4: http://cr.openjdk.java.net/~alexp/7141281/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141281 the fix was approved by Artem Ananiev Thanks alexp From michael.x.mcmahon at oracle.com Tue Feb 7 09:55:29 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 07 Feb 2012 17:55:29 +0000 Subject: Review Request: 7142516 [macosx] test script to recognize Mac OS X In-Reply-To: <4F2C07EC.4030305@oracle.com> References: <4F2C07EC.4030305@oracle.com> Message-ID: <4F316591.2@oracle.com> On 03/02/12 16:14, Jason Uh wrote: > A simple change to add Darwin as a recognized OS to a recently added > script > (test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh): > > > Webrev: http://cr.openjdk.java.net/~juh/7142516/webrev.00/ > > > Thanks, > Jason Looks fine. Thanks, Michael. From sergey.bylokhov at oracle.com Tue Feb 7 10:31:45 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 07 Feb 2012 22:31:45 +0400 Subject: Request for review: 7124543 [macosx] Horizontal scrolling doesn't work Message-ID: <4F316E11.6080801@oracle.com> Hi Everyone, - Now we take into account native horizontal scroll event and invert the SHIFT modifier state. - scrollAmount was changed from 3 to 1 to be closer to apple jdk 6. - small cleanup. Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124543 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124543/webrev.00/ -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Feb 7 11:45:21 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 07 Feb 2012 23:45:21 +0400 Subject: Request for review: 7124543 [macosx] Horizontal scrolling doesn't work In-Reply-To: <4F316E11.6080801@oracle.com> References: <4F316E11.6080801@oracle.com> Message-ID: <4F317F51.1090101@oracle.com> Hi Sergey, On 2/7/2012 10:31 PM, Sergey Bylokhov wrote: > - Now we take into account native horizontal scroll event and invert the > SHIFT modifier state. It looks like with your fix you actually add the SHIFT modifier almost unconditionally at line 102 in CPlatformResponder.java, rather than invert it. It will even be added for regular vertical scrolling events. Is this correct? Also, if an argument list of a method spans several lines we usually tend to insert a line break before the opening '{' for better readability. It would be great to follow this formatting practice with this fix as well. (No need to reformat everything, just those methods which prototypes you've already modified with your fix.) -- best regards, Anthony > - scrollAmount was changed from 3 to 1 to be closer to apple jdk 6. > - small cleanup. > > Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124543 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124543/webrev.00/ > From kurchi.subhra.hazra at oracle.com Tue Feb 7 11:47:02 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 07 Feb 2012 11:47:02 -0800 Subject: Code Review Request: 7133488: (cs) java/nio/charset/Charset/NIOCharsetAvailabilityTest.java fails on MacOSX Message-ID: <4F317FB6.6000605@oracle.com> Hi, This change enables recognizing COMPOUND_TEXT as an extended charset on Mac OS. In addition, we remove NIOCharsetAvailabilityTest.java test from ProblemList.txt since it will now pass on Mac OS X. Bug: http://monaco.us.oracle.com/detail.jsf?cr=7133488 Webrev: http://cr.openjdk.java.net/~khazra/7133488/webrev.03/ Thanks, Kurchi From swingler at apple.com Tue Feb 7 12:30:05 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 07 Feb 2012 12:30:05 -0800 Subject: Review request for 7142120: [macosx] Some JCK tests for SplashScreen fail on Mac OS X due to incorrect positioning of the splash In-Reply-To: <4F315009.6000905@wonderly.org> References: <4F2BDF81.7050805@oracle.com> <4F2FFD21.90003@oracle.com> <4F3004A9.6010904@oracle.com> <4F312BAE.7010802@oracle.com> <4F315009.6000905@wonderly.org> Message-ID: <9888BCBA-6957-4BE4-AD4B-C94004AC4B04@apple.com> My suggestion is to not show a dialog at all (particularly for a common situation like network disconnect, which should happen all the time on a portable). Instead, if you could simply augment the UI of the application (perhaps disable some controls, or show a prominent indicator), you could evade the problem and create a more pleasant experience that doesn't disrupt the users workflow by design. AppKit has separated out the concepts of how windows can have "key focus", can be "main" (the darker appearance with the thicker shadow), and be in different stacking order as independent concepts. Usually when you are typing along and a dialog comes up from another app, it may be atop other windows, but it hasn't necessarily stolen key focus. Utility windows can also be on top of "main" windows but key focus has to be explicitly granted by clicking into them. Java does not distinguish between key and main (it only has "focused"), and only has the rough concept of "always on top", which doesn't mesh well with the app-level ordering of Mac OS X. It's unfortunate, but AWT/Swing does not have suitable primitives to give developers so they can do the right thing. Of the primitives that do exist with regards to parent/child ordering, there are some key decisions that have to run counter to how Mac OS X convention works to pass the TCK, and prevent us from doing the most intuitive thing with respect to spaces and the full screen experience. On Java SE 6, we do try to prevent Java apps from jacking control from other applications, however if you are already in the app, and it shows a dialog, the mandatory Java behavior to be able to focus all controls means that the OK button can be dismissed with both space and return (whereas in native Cocoa apps, it would only be dismissible with return, unless you turned on "focus all controls" in the keyboard preference pane). The combination of all of these factors leads to an subconsciously irritating experience which is often impossible to communicate to others who do not live on Mac OS X, and is unfortunately irreconcilable with the current API and TCK requirements. My best advice would be to evade the problems where you can in your apps UI design, and just make the whole thing a non-issue. Regards, Mike Swingler Apple Inc. On Feb 7, 2012, at 8:23 AM, Gregg Wonderly wrote: > This seems very distracting to me, to have the screen sliding around, without the users "control". This can cause focus changes and very gnarly results for people who are constantly multitasking, quickly switching between contexts. > > I have a JDK6 app, in particular, which is a network app, and when it disconnects, it pops up a dialog telling the user this occurs. That dialog, pops up on the active screen, I think, but the problem is, that if I click on the window (on another screen), it switches me to the screen with the dialog. If I then try to click on the dialog button, the app BEEPS at me when I click "okay". The only way to close the app, is to move the app to the screen that the dialog is on. > > Somehow, this should all work "better", in terms of managing how "context" sensitive actions are joined with the context of a window/frame component. > > When a dialog is brought up, and made "current", it steals focus. If I am touch typing, and type a "space", the dialog closes before I can read it. I'd really like to have something different happen, and for example, just having the jumping icon in the app bar would be quite indicative of me needing to take action on something. > > Gregg Wonderlyw > > On 2/7/2012 7:48 AM, Alexander Zuev wrote: >> Looks Ok to me (assuming that even if we start program on the second screen the splashscreen should have been placed on main screen where dock and menu bar are). >> >> WBR, >> Alex >> >> On 2/6/12 19:49, Anthony Petrov wrote: >>> Hi Artem, >>> >>> BTW, the updated webrev is at http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.1/ >>> >>> Please find my comments inline. >>> >>> On 2/6/2012 8:17 PM, Artem Ananiev wrote: >>>> >>>> On 2/3/2012 5:22 PM, Anthony Petrov wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7142120 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/x-14-splashScreen-7142120.0/ >>>>> >>>>> The fix is fairly simple: use NSScreen -frame instead of -visibleFrame. >>>>> In this case the splash screen is positioned in the geometrical center >>>>> of the screen. Visually this looks less pleasant (we may want to file an >>>>> RFE in the future), but makes tests happy which is what we need right now. >>>> >>>> So what exactly do the tests expect? Does the test calculates the expected splashscreen position and compares to the value of SplashScreen.getBounds()? Does the latter method returns an incorrect value? >>>> >>>> What I see in JavaDoc is just: "The window is positioned at the center of the screen." It's unclear if the center of the screen should or should not include screen insets. >>> >>> The test uses a 100x100 pixels image as a splash screen image. It then calls the GraphicsDevice.getDisplayMode().getWidth/Height() methods and expects to find the splash screen in the geometrical center of the screen (using SplashScreen.getBounds()). I.e. the screen insets are ignored. >>> >>> Given that the tests pass on Windows, Linux, and Solaris, it makes sense to implement the same behavior on Mac OS X as well. >>> >>> -- >>> best regards, >>> Anthony >>> >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>>> All the failing tests now pass well with this fix applied. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >> >> > From Alan.Bateman at oracle.com Tue Feb 7 12:56:19 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Feb 2012 20:56:19 +0000 Subject: Code Review Request: 7133488: (cs) java/nio/charset/Charset/NIOCharsetAvailabilityTest.java fails on MacOSX In-Reply-To: <4F317FB6.6000605@oracle.com> References: <4F317FB6.6000605@oracle.com> Message-ID: <4F318FF3.2090503@oracle.com> On 07/02/2012 19:47, Kurchi Hazra wrote: > > Hi, > > This change enables recognizing COMPOUND_TEXT as an extended charset > on Mac OS. In addition, we remove NIOCharsetAvailabilityTest.java test > from ProblemList.txt since it will now pass on Mac OS X. > > Bug: http://monaco.us.oracle.com/detail.jsf?cr=7133488 > > Webrev: http://cr.openjdk.java.net/~khazra/7133488/webrev.03/ Looks fine to me. -Alan From kurchi.subhra.hazra at oracle.com Tue Feb 7 13:51:28 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 07 Feb 2012 13:51:28 -0800 Subject: [7u4] Request for approval for 7133488: (cs) java/nio/charset/Charset/NIOCharsetAvailabilityTest.java fails on MacOSX Message-ID: <4F319CE0.2070104@oracle.com> This is a request to push the following fix to jdk 7u4: Bug:http://monaco.us.oracle.com/detail.jsf?cr=7133488 Webrev:http://cr.openjdk.java.net/~khazra/7133488/webrev.03/ Reviewed by: alanb This changeset will be pushed on my behalf by Michael McMahon (michaelm). Thanks, Kurchi From edvard.wendelin at oracle.com Tue Feb 7 14:20:23 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 7 Feb 2012 23:20:23 +0100 Subject: [7u4] Request for approval for 7141281: [macosx] GridBagLayout baseline issue In-Reply-To: <4F31634C.1070909@oracle.com> References: <4F31634C.1070909@oracle.com> Message-ID: <83C72B29-8493-4BA6-B7FC-6A0077EC6EC5@oracle.com> Approved. On Feb 7, 2012, at 6:45 PM, Alexander Potochkin wrote: > Hello > > This is a request to push the following fix to jdk 7u4: > http://cr.openjdk.java.net/~alexp/7141281/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141281 > > the fix was approved by Artem Ananiev > > Thanks > alexp From edvard.wendelin at oracle.com Tue Feb 7 14:21:00 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 7 Feb 2012 23:21:00 +0100 Subject: [7u4] Request for approval for 7133488: (cs) java/nio/charset/Charset/NIOCharsetAvailabilityTest.java fails on MacOSX In-Reply-To: <4F319CE0.2070104@oracle.com> References: <4F319CE0.2070104@oracle.com> Message-ID: <3D6BA089-250A-464D-A7EB-8F6EE9DE0B7F@oracle.com> Approved. On Feb 7, 2012, at 10:51 PM, Kurchi Hazra wrote: > > This is a request to push the following fix to jdk 7u4: > > Bug:http://monaco.us.oracle.com/detail.jsf?cr=7133488 > > > Webrev:http://cr.openjdk.java.net/~khazra/7133488/webrev.03/ > > > Reviewed by: alanb > > This changeset will be pushed on my behalf by Michael McMahon (michaelm). > > Thanks, > Kurchi > > > > > > From dalibor.topic at oracle.com Tue Feb 7 15:43:54 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 08 Feb 2012 00:43:54 +0100 Subject: [7u4] Request for approval for 7133488: (cs) java/nio/charset/Charset/NIOCharsetAvailabilityTest.java fails on MacOSX In-Reply-To: <4F319CE0.2070104@oracle.com> References: <4F319CE0.2070104@oracle.com> Message-ID: <4F31B73A.1070105@oracle.com> On 2/7/12 10:51 PM, Kurchi Hazra wrote: > > This is a request to push the following fix to jdk 7u4: > > Bug:http://monaco.us.oracle.com/detail.jsf?cr=7133488 I can't access that system. Is the bug available on bugs.sun.com? cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From kurchi.subhra.hazra at oracle.com Tue Feb 7 15:48:15 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 07 Feb 2012 15:48:15 -0800 Subject: [7u4] Request for approval for 7133488: (cs) java/nio/charset/Charset/NIOCharsetAvailabilityTest.java fails on MacOSX In-Reply-To: <4F31B73A.1070105@oracle.com> References: <4F319CE0.2070104@oracle.com> <4F31B73A.1070105@oracle.com> Message-ID: <4F31B83F.4070509@oracle.com> Hi, Here's a link on bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133488 - Kurchi On 2/7/2012 3:43 PM, Dalibor Topic wrote: > On 2/7/12 10:51 PM, Kurchi Hazra wrote: >> This is a request to push the following fix to jdk 7u4: >> >> Bug:http://monaco.us.oracle.com/detail.jsf?cr=7133488 > I can't access that system. Is the bug available on bugs.sun.com? > > cheers, > dalibor topic > > -- -Kurchi From dalibor.topic at oracle.com Tue Feb 7 16:46:34 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 08 Feb 2012 01:46:34 +0100 Subject: [7u4] Request for approval for 7133488: (cs) java/nio/charset/Charset/NIOCharsetAvailabilityTest.java fails on MacOSX In-Reply-To: <4F31B83F.4070509@oracle.com> References: <4F319CE0.2070104@oracle.com> <4F31B73A.1070105@oracle.com> <4F31B83F.4070509@oracle.com> Message-ID: <4F31C5EA.40003@oracle.com> On 2/8/12 12:48 AM, Kurchi Hazra wrote: > Hi, > > Here's a link on bugs.sun.com: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133488 Thanks, Kurchi. Please make sure to use bugs.sun.com for future requests. cheers, dalibor topic > - Kurchi > > > On 2/7/2012 3:43 PM, Dalibor Topic wrote: >> On 2/7/12 10:51 PM, Kurchi Hazra wrote: >>> This is a request to push the following fix to jdk 7u4: >>> >>> Bug:http://monaco.us.oracle.com/detail.jsf?cr=7133488 >> I can't access that system. Is the bug available on bugs.sun.com? >> >> cheers, >> dalibor topic >> >> > -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From paul.hohensee at oracle.com Tue Feb 7 17:01:56 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 07 Feb 2012 20:01:56 -0500 Subject: [7u4] Request for approval for 7133488: (cs) java/nio/charset/Charset/NIOCharsetAvailabilityTest.java fails on MacOSX In-Reply-To: <4F319CE0.2070104@oracle.com> References: <4F319CE0.2070104@oracle.com> Message-ID: <4F31C984.4020303@oracle.com> Approved. Paul On 2/7/12 4:51 PM, Kurchi Hazra wrote: > > This is a request to push the following fix to jdk 7u4: > > Bug:http://monaco.us.oracle.com/detail.jsf?cr=7133488 > > > Webrev:http://cr.openjdk.java.net/~khazra/7133488/webrev.03/ > > > Reviewed by: alanb > > This changeset will be pushed on my behalf by Michael McMahon (michaelm). > > Thanks, > Kurchi > > > > > > From sergey.bylokhov at oracle.com Tue Feb 7 23:53:08 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 08 Feb 2012 11:53:08 +0400 Subject: Request for review: 7124543 [macosx] Horizontal scrolling doesn't work In-Reply-To: <4F317F51.1090101@oracle.com> References: <4F316E11.6080801@oracle.com> <4F317F51.1090101@oracle.com> Message-ID: <4F3229E4.50005@oracle.com> 07.02.2012 23:45, Anthony Petrov ?????: > Hi Sergey, > > On 2/7/2012 10:31 PM, Sergey Bylokhov wrote: >> - Now we take into account native horizontal scroll event and invert >> the SHIFT modifier state. > > It looks like with your fix you actually add the SHIFT modifier almost > unconditionally at line 102 in CPlatformResponder.java, rather than > invert it. It will even be added for regular vertical scrolling > events. Is this correct? We post vertical scroll event in line 97. And in line 102 we post horizontal event only. The rules for horizontal scrolling: 1 If shift modifier was not set by the user we should use native horizontal deltaX 2 If shift modifier was set by the user we should use vertical deltaY,but if it equal to 0.0 we should use horizontal deltaX. 3 Shift modifier should always be set before event post. > Also, if an argument list of a method spans several lines we usually > tend to insert a line break before the opening '{' for better readability. I just strictly follow the rules from sun java codeconv. Most(if not all) of our peers on mac use this conversion. > It would be great to follow this formatting practice with this fix as > well. (No need to reformat everything, just those methods which > prototypes you've already modified with your fix.) > > -- > best regards, > Anthony > >> - scrollAmount was changed from 3 to 1 to be closer to apple jdk 6. >> - small cleanup. >> >> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124543 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7124543/webrev.00/ >> -- Best regards, Sergey. From anton.tarasov at oracle.com Wed Feb 8 01:49:00 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 08 Feb 2012 13:49:00 +0400 Subject: Review request for 7142565 - [macosx] Many special keys processed twice in text fields Message-ID: <4F32450C.8000609@oracle.com> Hello, Please review a fix for 7142565. webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ Key-equivalent events (typically with modifiers, but not only) are delivered to NSWindow with performKeyEquivalent: The latter always returns NO (to let NSWindow process system key events like Cmd+Q). According to the spec "if a key-equivalent is not recognized, NSWindow sends it as an NSKeyDown event to the first responder". (However, it doesn't send NSKeyDown for Control-key events.) Instead of inspecting a key-equivalent event to determine if it should be propagated further or not, another simple workaround is suggested. It's to store a pointer to the latest processed key event in AWTView and compare the current event to the previous one. In case the event objects are the same, ignore the second (current) one. Thanks, Anton. From sergey.bylokhov at oracle.com Wed Feb 8 02:05:09 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 08 Feb 2012 14:05:09 +0400 Subject: Request for review: 7124528 [macosx] Selection is not cleared properly in text component. Message-ID: <4F3248D5.1010105@oracle.com> Hi Everyone, Now we reset selection in text components on focuslost event. Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124528 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124528/webrev.00/ -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Feb 8 02:28:58 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 08 Feb 2012 14:28:58 +0400 Subject: Request for review: 7124543 [macosx] Horizontal scrolling doesn't work In-Reply-To: <4F3229E4.50005@oracle.com> References: <4F316E11.6080801@oracle.com> <4F317F51.1090101@oracle.com> <4F3229E4.50005@oracle.com> Message-ID: <4F324E6A.70601@oracle.com> Thanks for clarifying that. -- best regards, Anthony On 2/8/2012 11:53 AM, Sergey Bylokhov wrote: > 07.02.2012 23:45, Anthony Petrov ?????: >> Hi Sergey, >> >> On 2/7/2012 10:31 PM, Sergey Bylokhov wrote: >>> - Now we take into account native horizontal scroll event and invert >>> the SHIFT modifier state. >> >> It looks like with your fix you actually add the SHIFT modifier almost >> unconditionally at line 102 in CPlatformResponder.java, rather than >> invert it. It will even be added for regular vertical scrolling >> events. Is this correct? > We post vertical scroll event in line 97. And in line 102 we post > horizontal event only. > The rules for horizontal scrolling: > 1 If shift modifier was not set by the user we should use native > horizontal deltaX > 2 If shift modifier was set by the user we should use vertical > deltaY,but if it equal to 0.0 we should use horizontal deltaX. > 3 Shift modifier should always be set before event post. > >> Also, if an argument list of a method spans several lines we usually >> tend to insert a line break before the opening '{' for better >> readability. > I just strictly follow the rules from sun java codeconv. Most(if not > all) of our peers on mac use this conversion. >> It would be great to follow this formatting practice with this fix as >> well. (No need to reformat everything, just those methods which >> prototypes you've already modified with your fix.) >> >> -- >> best regards, >> Anthony >> >>> - scrollAmount was changed from 3 to 1 to be closer to apple jdk 6. >>> - small cleanup. >>> >>> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124543 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7124543/webrev.00/ >>> > > From anthony.petrov at oracle.com Wed Feb 8 02:35:03 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 08 Feb 2012 14:35:03 +0400 Subject: Review request for 7142565 - [macosx] Many special keys processed twice in text fields In-Reply-To: <4F32450C.8000609@oracle.com> References: <4F32450C.8000609@oracle.com> Message-ID: <4F324FD7.3030504@oracle.com> Hi Anton, The fix looks fine. Unless there are consistency considerations, you could move the declaration of the static variable into the method's body to localize the logic around this not-retained object pointer (and avoid adding any comments about that, too.) I'll leave this up to you and other reviewers. -- best regards, Anthony On 2/8/2012 1:49 PM, Anton V. Tarasov wrote: > Hello, > > Please review a fix for 7142565. > > webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ > > Key-equivalent events (typically with modifiers, but not only) are > delivered to NSWindow with > performKeyEquivalent: The latter always returns NO (to let NSWindow > process system key events like > Cmd+Q). According to the spec "if a key-equivalent is not recognized, > NSWindow sends it as an > NSKeyDown event to the first responder". (However, it doesn't send > NSKeyDown for Control-key > events.) > > Instead of inspecting a key-equivalent event to determine if it should > be propagated further or not, > another simple workaround is suggested. It's to store a pointer to the > latest processed key event in > AWTView and compare the current event to the previous one. In case the > event objects are the same, > ignore the second (current) one. > > Thanks, > Anton. > > From leonid.romanov at oracle.com Wed Feb 8 02:41:53 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 8 Feb 2012 14:41:53 +0400 Subject: Review request for 7142565 - [macosx] Many special keys processed twice in text fields In-Reply-To: <4F32450C.8000609@oracle.com> References: <4F32450C.8000609@oracle.com> Message-ID: <3C5C817C-AD09-4ECC-9768-3B57B9C65F57@oracle.com> Could you please verify that your fix works with key events synthesized by Robot? It is quite possible that for Robot the same NSEvent instance would be reused. On 08.02.2012, at 13:49, Anton V. Tarasov wrote: > Hello, > > Please review a fix for 7142565. > > webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ > > Key-equivalent events (typically with modifiers, but not only) are delivered to NSWindow with > performKeyEquivalent: The latter always returns NO (to let NSWindow process system key events like > Cmd+Q). According to the spec "if a key-equivalent is not recognized, NSWindow sends it as an > NSKeyDown event to the first responder". (However, it doesn't send NSKeyDown for Control-key > events.) > > Instead of inspecting a key-equivalent event to determine if it should be propagated further or not, > another simple workaround is suggested. It's to store a pointer to the latest processed key event in > AWTView and compare the current event to the previous one. In case the event objects are the same, > ignore the second (current) one. > > Thanks, > Anton. > > From mik3hall at gmail.com Wed Feb 8 03:19:08 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 8 Feb 2012 05:19:08 -0600 Subject: Best way to determine openjdk jvm Message-ID: <1D1F47D3-B2D1-4A30-A570-7D2924F40355@gmail.com> I am looking at... Mac OS X Port Using jsadebug, jinfo, jmap https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port+Using+jsadebug,+jinfo,+jmap Which appears to require a openjdk specific signing certificate, or sudo. Assuming you wanted to provide the cert, I would further assume you would still need to determine at runtime if you had the features available - meaning a openjdk runtime. Would checking this system property be the best, recommended, way to do that? java.runtime.name=OpenJDK Runtime Environment From anton.tarasov at oracle.com Wed Feb 8 08:07:19 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 08 Feb 2012 19:07:19 +0300 Subject: Review request for 7142565 - [macosx] Many special keys processed twice in text fields In-Reply-To: <4F324FD7.3030504@oracle.com> References: <4F32450C.8000609@oracle.com> <4F324FD7.3030504@oracle.com> Message-ID: <4F329DB7.6080109@oracle.com> On 2/8/12 1:35 PM, Anthony Petrov wrote: > Hi Anton, > > The fix looks fine. > > Unless there are consistency considerations, you could move the > declaration of the static variable into the method's body to localize > the logic around this not-retained object pointer (and avoid adding > any comments about that, too.) I'll leave this up to you and other > reviewers. I put it to the top anticipating comments like you got for your fix (which I looked at). But ok, let's narrow the scope. http://cr.openjdk.java.net/~ant/7142565/webrev.1/ Thanks, Anton. > > -- > best regards, > Anthony > > On 2/8/2012 1:49 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please review a fix for 7142565. >> >> webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ >> >> Key-equivalent events (typically with modifiers, but not only) are >> delivered to NSWindow with >> performKeyEquivalent: The latter always returns NO (to let NSWindow >> process system key events like >> Cmd+Q). According to the spec "if a key-equivalent is not recognized, >> NSWindow sends it as an >> NSKeyDown event to the first responder". (However, it doesn't send >> NSKeyDown for Control-key >> events.) >> >> Instead of inspecting a key-equivalent event to determine if it >> should be propagated further or not, >> another simple workaround is suggested. It's to store a pointer to >> the latest processed key event in >> AWTView and compare the current event to the previous one. In case >> the event objects are the same, >> ignore the second (current) one. >> >> Thanks, >> Anton. >> >> From anthony.petrov at oracle.com Wed Feb 8 07:10:08 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 08 Feb 2012 19:10:08 +0400 Subject: Review request for 7142565 - [macosx] Many special keys processed twice in text fields In-Reply-To: <4F329DB7.6080109@oracle.com> References: <4F32450C.8000609@oracle.com> <4F324FD7.3030504@oracle.com> <4F329DB7.6080109@oracle.com> Message-ID: <4F329050.1000606@oracle.com> Looks perfect. Thank you! -- best regards, Anthony On 2/8/2012 8:07 PM, Anton V. Tarasov wrote: > On 2/8/12 1:35 PM, Anthony Petrov wrote: >> Hi Anton, >> >> The fix looks fine. >> >> Unless there are consistency considerations, you could move the >> declaration of the static variable into the method's body to localize >> the logic around this not-retained object pointer (and avoid adding >> any comments about that, too.) I'll leave this up to you and other >> reviewers. > I put it to the top anticipating comments like you got for your fix > (which I looked at). But ok, let's narrow the scope. > > http://cr.openjdk.java.net/~ant/7142565/webrev.1/ > > Thanks, > Anton. >> >> -- >> best regards, >> Anthony >> >> On 2/8/2012 1:49 PM, Anton V. Tarasov wrote: >>> Hello, >>> >>> Please review a fix for 7142565. >>> >>> webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ >>> >>> Key-equivalent events (typically with modifiers, but not only) are >>> delivered to NSWindow with >>> performKeyEquivalent: The latter always returns NO (to let NSWindow >>> process system key events like >>> Cmd+Q). According to the spec "if a key-equivalent is not recognized, >>> NSWindow sends it as an >>> NSKeyDown event to the first responder". (However, it doesn't send >>> NSKeyDown for Control-key >>> events.) >>> >>> Instead of inspecting a key-equivalent event to determine if it >>> should be propagated further or not, >>> another simple workaround is suggested. It's to store a pointer to >>> the latest processed key event in >>> AWTView and compare the current event to the previous one. In case >>> the event objects are the same, >>> ignore the second (current) one. >>> >>> Thanks, >>> Anton. >>> >>> > From anton.tarasov at oracle.com Wed Feb 8 08:12:47 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 08 Feb 2012 19:12:47 +0300 Subject: Review request for 7142565 - [macosx] Many special keys processed twice in text fields In-Reply-To: <3C5C817C-AD09-4ECC-9768-3B57B9C65F57@oracle.com> References: <4F32450C.8000609@oracle.com> <3C5C817C-AD09-4ECC-9768-3B57B9C65F57@oracle.com> Message-ID: <4F329EFF.8070304@oracle.com> On 2/8/12 1:41 PM, Leonid Romanov wrote: > Could you please verify that your fix works with key events synthesized by Robot? It is quite possible that for Robot the same NSEvent instance would be reused. That's quite good question. I checked it with a small test, all is Ok. Looked at the Robot code - it creates a new key event every time (CGEventCreateKeyboardEvent). Thanks, Anton. > > > On 08.02.2012, at 13:49, Anton V. Tarasov wrote: > >> Hello, >> >> Please review a fix for 7142565. >> >> webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ >> >> Key-equivalent events (typically with modifiers, but not only) are delivered to NSWindow with >> performKeyEquivalent: The latter always returns NO (to let NSWindow process system key events like >> Cmd+Q). According to the spec "if a key-equivalent is not recognized, NSWindow sends it as an >> NSKeyDown event to the first responder". (However, it doesn't send NSKeyDown for Control-key >> events.) >> >> Instead of inspecting a key-equivalent event to determine if it should be propagated further or not, >> another simple workaround is suggested. It's to store a pointer to the latest processed key event in >> AWTView and compare the current event to the previous one. In case the event objects are the same, >> ignore the second (current) one. >> >> Thanks, >> Anton. >> >> From swingler at apple.com Wed Feb 8 07:35:02 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 08 Feb 2012 07:35:02 -0800 Subject: Review request for 7142565 - [macosx] Many special keys processed twice in text fields In-Reply-To: <4F329EFF.8070304@oracle.com> References: <4F32450C.8000609@oracle.com> <3C5C817C-AD09-4ECC-9768-3B57B9C65F57@oracle.com> <4F329EFF.8070304@oracle.com> Message-ID: The safer thing to to is to create an retained property on an instance of a class you pin statically, then, you can be ensured that the Obj-C runtime's property generator will do the correct (and atomic from any thread) retain/release dance. The AWTToolkit looks like a reasonable class to make an instance out of that you can do an unbalanced retain on, and then pin in a static (since the very next thing you do is call +eventCountPlusPlus on it). Just a suggestion, Mike Swingler Apple Inc. On Feb 8, 2012, at 8:12 AM, Anton V. Tarasov wrote: > On 2/8/12 1:41 PM, Leonid Romanov wrote: >> Could you please verify that your fix works with key events synthesized by Robot? It is quite possible that for Robot the same NSEvent instance would be reused. > That's quite good question. I checked it with a small test, all is Ok. Looked at the Robot code - it creates a new key event every time (CGEventCreateKeyboardEvent). > > Thanks, > Anton. > >> >> >> On 08.02.2012, at 13:49, Anton V. Tarasov wrote: >> >>> Hello, >>> >>> Please review a fix for 7142565. >>> >>> webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ >>> >>> Key-equivalent events (typically with modifiers, but not only) are delivered to NSWindow with >>> performKeyEquivalent: The latter always returns NO (to let NSWindow process system key events like >>> Cmd+Q). According to the spec "if a key-equivalent is not recognized, NSWindow sends it as an >>> NSKeyDown event to the first responder". (However, it doesn't send NSKeyDown for Control-key >>> events.) >>> >>> Instead of inspecting a key-equivalent event to determine if it should be propagated further or not, >>> another simple workaround is suggested. It's to store a pointer to the latest processed key event in >>> AWTView and compare the current event to the previous one. In case the event objects are the same, >>> ignore the second (current) one. >>> >>> Thanks, >>> Anton. >>> >>> > From Alexander.Potochkin at oracle.com Wed Feb 8 07:47:45 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Wed, 08 Feb 2012 19:47:45 +0400 Subject: Request for review: 7124543 [macosx] Horizontal scrolling doesn't work In-Reply-To: <4F316E11.6080801@oracle.com> References: <4F316E11.6080801@oracle.com> Message-ID: <4F329921.6030401@oracle.com> Hello Sergey > Hi Everyone, > - Now we take into account native horizontal scroll event and invert > the SHIFT modifier state. > - scrollAmount was changed from 3 to 1 to be closer to apple jdk 6. There is one more "3" hardcoded for mouseWheelEvent, see LWComponentPeer.createDelegateEvent() could you also change it please? Thanks alexp > - small cleanup. > > Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124543 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124543/webrev.00/ > From swingler at apple.com Wed Feb 8 08:03:24 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 08 Feb 2012 08:03:24 -0800 Subject: Request for review: 7124528 [macosx] Selection is not cleared properly in text component. In-Reply-To: <4F3248D5.1010105@oracle.com> References: <4F3248D5.1010105@oracle.com> Message-ID: On Feb 8, 2012, at 2:05 AM, Sergey Bylokhov wrote: > Hi Everyone, > Now we reset selection in text components on focuslost event. > > Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124528 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124528/webrev.00/ That bug isn't publicly accessible. Could you give us the gist of it? Thanks, Mike Swingler Apple Inc. From sergey.bylokhov at oracle.com Wed Feb 8 08:04:33 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 08 Feb 2012 20:04:33 +0400 Subject: Request for review: 7124528 [macosx] Selection is not cleared properly in text component. In-Reply-To: References: <4F3248D5.1010105@oracle.com> Message-ID: <4F329D11.9080203@oracle.com> 08.02.2012 20:03, Mike Swingler wrote: > On Feb 8, 2012, at 2:05 AM, Sergey Bylokhov wrote: > >> Hi Everyone, >> Now we reset selection in text components on focuslost event. >> >> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124528 >> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124528/webrev.00/ > That bug isn't publicly accessible. Could you give us the gist of it? jira: http://java.net/jira/browse/MACOSX_PORT-616 > > Thanks, > Mike Swingler > Apple Inc. > -- Best regards, Sergey. From scott.kovatch at oracle.com Wed Feb 8 08:14:54 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 8 Feb 2012 08:14:54 -0800 Subject: When does receiveRenderServer: fail? Message-ID: Mike, Under what conditions does [JRSRenderServer recieveRenderServer:] fail? In our automated tests this occasionally returns 0, so the embedded frame creation fails. My guess is that the applet tag isn't quite right so the browser doesn't allocate a port for the remote connection, but I haven't looked into it at any depth yet. -- Scott ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From artem.ananiev at oracle.com Wed Feb 8 08:18:05 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 08 Feb 2012 20:18:05 +0400 Subject: [7u4] Request for approval for 7141281: [macosx] GridBagLayout baseline issue In-Reply-To: <4F31634C.1070909@oracle.com> References: <4F31634C.1070909@oracle.com> Message-ID: <4F32A03D.8000900@oracle.com> Approved. On 2/7/2012 9:45 PM, Alexander Potochkin wrote: > Hello > > This is a request to push the following fix to jdk 7u4: > http://cr.openjdk.java.net/~alexp/7141281/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141281 > > the fix was approved by Artem Ananiev > > Thanks > alexp From swingler at apple.com Wed Feb 8 08:16:57 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 08 Feb 2012 08:16:57 -0800 Subject: Request for review: 7124528 [macosx] Selection is not cleared properly in text component. In-Reply-To: <4F329D11.9080203@oracle.com> References: <4F3248D5.1010105@oracle.com> <4F329D11.9080203@oracle.com> Message-ID: On Feb 8, 2012, at 8:04 AM, Sergey Bylokhov wrote: > 08.02.2012 20:03, Mike Swingler wrote: >> On Feb 8, 2012, at 2:05 AM, Sergey Bylokhov wrote: >> >>> Hi Everyone, >>> Now we reset selection in text components on focuslost event. >>> >>> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124528 >>> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124528/webrev.00/ >> That bug isn't publicly accessible. Could you give us the gist of it? > jira: > http://java.net/jira/browse/MACOSX_PORT-616 Thanks. After this fix, does the text field completely select it's contents when it is re-focused by tabbing into it? If so, this fix looks good. Cheers, Mike Swingler Apple Inc. From swingler at apple.com Wed Feb 8 08:19:30 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 08 Feb 2012 08:19:30 -0800 Subject: When does receiveRenderServer: fail? In-Reply-To: References: Message-ID: <37963150-F0E8-4539-B239-24B24D33F087@apple.com> On Feb 8, 2012, at 8:14 AM, Scott Kovatch wrote: > Mike, > > Under what conditions does [JRSRenderServer recieveRenderServer:] fail? In our automated tests this occasionally returns 0, so the embedded frame creation fails. > > My guess is that the applet tag isn't quite right so the browser doesn't allocate a port for the remote connection, but I haven't looked into it at any depth yet. I don't know. Bino may have an idea. Does this only show up in automated testing? If so, what is kicking off the browser and Java processes? I hope this isn't just a side effect of being in the wrong bootstrap context. Regards, Mike Swingler Apple Inc. From sergey.bylokhov at oracle.com Wed Feb 8 09:14:28 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 08 Feb 2012 21:14:28 +0400 Subject: Request for review: 7124528 [macosx] Selection is not cleared properly in text component. In-Reply-To: References: <4F3248D5.1010105@oracle.com> <4F329D11.9080203@oracle.com> Message-ID: <4F32AD74.4070608@oracle.com> 08.02.2012 20:16, Mike Swingler ?????: > On Feb 8, 2012, at 8:04 AM, Sergey Bylokhov wrote: > >> 08.02.2012 20:03, Mike Swingler wrote: >>> On Feb 8, 2012, at 2:05 AM, Sergey Bylokhov wrote: >>> >>>> Hi Everyone, >>>> Now we reset selection in text components on focuslost event. >>>> >>>> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124528 >>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124528/webrev.00/ >>> That bug isn't publicly accessible. Could you give us the gist of it? >> jira: >> http://java.net/jira/browse/MACOSX_PORT-616 > > Thanks. After this fix, does the text field completely select it's contents when it is re-focused by tabbing into it? Under aqua l&f text components reselect text if cursor was at first or at last position. AquaCaret.java public void focusGained(final FocusEvent e) { .... final int dot = getDot(); final int mark = getMark(); if (dot == mark) { if (dot == 0) { component.setCaretPosition(end); component.moveCaretPosition(0); } else if (dot == end) { component.setCaretPosition(0); component.moveCaretPosition(end); } } .... If this is wrong behavior we probably should change it in aqua? > > If so, this fix looks good. > > Cheers, > Mike Swingler > Apple Inc. > -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Feb 8 09:16:52 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 08 Feb 2012 21:16:52 +0400 Subject: Review request for 7142565 - [macosx] Many special keys processed twice in text fields In-Reply-To: References: <4F32450C.8000609@oracle.com> <3C5C817C-AD09-4ECC-9768-3B57B9C65F57@oracle.com> <4F329EFF.8070304@oracle.com> Message-ID: <4F32AE04.9070307@oracle.com> Hi Mike, We don't actually need to retain the object because we don't use it in any way. The only reason to save the pointer is to compare it with another pointer. Retaining the object would be a waste of RAM. Now that Anton has updated his fix and put the declaration of the variable immediately before the if() statement (see [1]), there's absolutely no confusion about this static symbol now because the code is concentrated in five consecutive lines, and the scope of the new variable is limited to the method's body. [1] http://cr.openjdk.java.net/~ant/7142565/webrev.1/ -- best regards, Anthony On 2/8/2012 7:35 PM, Mike Swingler wrote: > The safer thing to to is to create an retained property on an instance of a class you pin statically, then, you can be ensured that the Obj-C runtime's property generator will do the correct (and atomic from any thread) retain/release dance. > > The AWTToolkit looks like a reasonable class to make an instance out of that you can do an unbalanced retain on, and then pin in a static (since the very next thing you do is call +eventCountPlusPlus on it). > > Just a suggestion, > Mike Swingler > Apple Inc. > > On Feb 8, 2012, at 8:12 AM, Anton V. Tarasov wrote: > >> On 2/8/12 1:41 PM, Leonid Romanov wrote: >>> Could you please verify that your fix works with key events synthesized by Robot? It is quite possible that for Robot the same NSEvent instance would be reused. >> That's quite good question. I checked it with a small test, all is Ok. Looked at the Robot code - it creates a new key event every time (CGEventCreateKeyboardEvent). >> >> Thanks, >> Anton. >> >>> >>> On 08.02.2012, at 13:49, Anton V. Tarasov wrote: >>> >>>> Hello, >>>> >>>> Please review a fix for 7142565. >>>> >>>> webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ >>>> >>>> Key-equivalent events (typically with modifiers, but not only) are delivered to NSWindow with >>>> performKeyEquivalent: The latter always returns NO (to let NSWindow process system key events like >>>> Cmd+Q). According to the spec "if a key-equivalent is not recognized, NSWindow sends it as an >>>> NSKeyDown event to the first responder". (However, it doesn't send NSKeyDown for Control-key >>>> events.) >>>> >>>> Instead of inspecting a key-equivalent event to determine if it should be propagated further or not, >>>> another simple workaround is suggested. It's to store a pointer to the latest processed key event in >>>> AWTView and compare the current event to the previous one. In case the event objects are the same, >>>> ignore the second (current) one. >>>> >>>> Thanks, >>>> Anton. >>>> >>>> > From scott.kovatch at oracle.com Wed Feb 8 09:30:02 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 8 Feb 2012 09:30:02 -0800 Subject: When does receiveRenderServer: fail? In-Reply-To: <37963150-F0E8-4539-B239-24B24D33F087@apple.com> References: <37963150-F0E8-4539-B239-24B24D33F087@apple.com> Message-ID: <2FE4679D-9542-4A2B-96DC-E30663657886@oracle.com> On Feb 8, 2012, at 8:19 AM, Mike Swingler wrote: > On Feb 8, 2012, at 8:14 AM, Scott Kovatch wrote: > >> Mike, >> >> Under what conditions does [JRSRenderServer recieveRenderServer:] fail? In our automated tests this occasionally returns 0, so the embedded frame creation fails. >> >> My guess is that the applet tag isn't quite right so the browser doesn't allocate a port for the remote connection, but I haven't looked into it at any depth yet. > > I don't know. Bino may have an idea. > > Does this only show up in automated testing? If so, what is kicking off the browser and Java processes? I hope this isn't just a side effect of being in the wrong bootstrap context. So, the answer to my original question is "when you pass in nil." :-) After some off-list discussion and some debugging I found that I have a race condition I need to work out. Sorry for the false alarm. -- Scott K. From sergey.bylokhov at oracle.com Wed Feb 8 09:40:31 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 08 Feb 2012 21:40:31 +0400 Subject: Request for review: 7124543 [macosx] Horizontal scrolling doesn't work In-Reply-To: <4F329921.6030401@oracle.com> References: <4F316E11.6080801@oracle.com> <4F329921.6030401@oracle.com> Message-ID: <4F32B38F.1030502@oracle.com> 08.02.2012 19:47, Alexander Potochkin wrote: > Hello Sergey >> Hi Everyone, >> - Now we take into account native horizontal scroll event and invert >> the SHIFT modifier state. >> - scrollAmount was changed from 3 to 1 to be closer to apple jdk 6. > > There is one more "3" hardcoded for mouseWheelEvent, > see LWComponentPeer.createDelegateEvent() new version http://cr.openjdk.java.net/~serb/7124543/webrev.01/ > could you also change it please? > > Thanks > alexp > >> - small cleanup. >> >> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124543 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7124543/webrev.00/ >> > -- Best regards, Sergey. From swingler at apple.com Wed Feb 8 09:48:50 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 08 Feb 2012 09:48:50 -0800 Subject: Review request for 7142565 - [macosx] Many special keys processed twice in text fields In-Reply-To: <4F32AE04.9070307@oracle.com> References: <4F32450C.8000609@oracle.com> <3C5C817C-AD09-4ECC-9768-3B57B9C65F57@oracle.com> <4F329EFF.8070304@oracle.com> <4F32AE04.9070307@oracle.com> Message-ID: Ok, as long as nobody is sending any messages to it, the retain/release dance doesn't need to be done. I'd suggest changing the name to sUnretainedLastKeyEvent, and changing the type to (id) so nobody is tempted to try to message it in the future. Thanks, Mike Swingler Apple Inc. On Feb 8, 2012, at 9:16 AM, Anthony Petrov wrote: > Hi Mike, > > We don't actually need to retain the object because we don't use it in any way. The only reason to save the pointer is to compare it with another pointer. Retaining the object would be a waste of RAM. > > Now that Anton has updated his fix and put the declaration of the variable immediately before the if() statement (see [1]), there's absolutely no confusion about this static symbol now because the code is concentrated in five consecutive lines, and the scope of the new variable is limited to the method's body. > > [1] http://cr.openjdk.java.net/~ant/7142565/webrev.1/ > > -- > best regards, > Anthony > > On 2/8/2012 7:35 PM, Mike Swingler wrote: >> The safer thing to to is to create an retained property on an instance of a class you pin statically, then, you can be ensured that the Obj-C runtime's property generator will do the correct (and atomic from any thread) retain/release dance. >> The AWTToolkit looks like a reasonable class to make an instance out of that you can do an unbalanced retain on, and then pin in a static (since the very next thing you do is call +eventCountPlusPlus on it). >> Just a suggestion, >> Mike Swingler >> Apple Inc. >> On Feb 8, 2012, at 8:12 AM, Anton V. Tarasov wrote: >>> On 2/8/12 1:41 PM, Leonid Romanov wrote: >>>> Could you please verify that your fix works with key events synthesized by Robot? It is quite possible that for Robot the same NSEvent instance would be reused. >>> That's quite good question. I checked it with a small test, all is Ok. Looked at the Robot code - it creates a new key event every time (CGEventCreateKeyboardEvent). >>> >>> Thanks, >>> Anton. >>> >>>> >>>> On 08.02.2012, at 13:49, Anton V. Tarasov wrote: >>>> >>>>> Hello, >>>>> >>>>> Please review a fix for 7142565. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ >>>>> >>>>> Key-equivalent events (typically with modifiers, but not only) are delivered to NSWindow with >>>>> performKeyEquivalent: The latter always returns NO (to let NSWindow process system key events like >>>>> Cmd+Q). According to the spec "if a key-equivalent is not recognized, NSWindow sends it as an >>>>> NSKeyDown event to the first responder". (However, it doesn't send NSKeyDown for Control-key >>>>> events.) >>>>> >>>>> Instead of inspecting a key-equivalent event to determine if it should be propagated further or not, >>>>> another simple workaround is suggested. It's to store a pointer to the latest processed key event in >>>>> AWTView and compare the current event to the previous one. In case the event objects are the same, >>>>> ignore the second (current) one. >>>>> >>>>> Thanks, >>>>> Anton. >>>>> >>>>> From anthony.petrov at oracle.com Wed Feb 8 09:50:55 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 08 Feb 2012 21:50:55 +0400 Subject: Review request for 7142565 - [macosx] Many special keys processed twice in text fields In-Reply-To: References: <4F32450C.8000609@oracle.com> <3C5C817C-AD09-4ECC-9768-3B57B9C65F57@oracle.com> <4F329EFF.8070304@oracle.com> <4F32AE04.9070307@oracle.com> Message-ID: <4F32B5FF.1080508@oracle.com> Sounds reasonable to me. -- best regards, Anthony On 2/8/2012 9:48 PM, Mike Swingler wrote: > Ok, as long as nobody is sending any messages to it, the retain/release dance doesn't need to be done. I'd suggest changing the name to sUnretainedLastKeyEvent, and changing the type to (id) so nobody is tempted to try to message it in the future. > > Thanks, > Mike Swingler > Apple Inc. > > On Feb 8, 2012, at 9:16 AM, Anthony Petrov wrote: > >> Hi Mike, >> >> We don't actually need to retain the object because we don't use it in any way. The only reason to save the pointer is to compare it with another pointer. Retaining the object would be a waste of RAM. >> >> Now that Anton has updated his fix and put the declaration of the variable immediately before the if() statement (see [1]), there's absolutely no confusion about this static symbol now because the code is concentrated in five consecutive lines, and the scope of the new variable is limited to the method's body. >> >> [1] http://cr.openjdk.java.net/~ant/7142565/webrev.1/ >> >> -- >> best regards, >> Anthony >> >> On 2/8/2012 7:35 PM, Mike Swingler wrote: >>> The safer thing to to is to create an retained property on an instance of a class you pin statically, then, you can be ensured that the Obj-C runtime's property generator will do the correct (and atomic from any thread) retain/release dance. >>> The AWTToolkit looks like a reasonable class to make an instance out of that you can do an unbalanced retain on, and then pin in a static (since the very next thing you do is call +eventCountPlusPlus on it). >>> Just a suggestion, >>> Mike Swingler >>> Apple Inc. >>> On Feb 8, 2012, at 8:12 AM, Anton V. Tarasov wrote: >>>> On 2/8/12 1:41 PM, Leonid Romanov wrote: >>>>> Could you please verify that your fix works with key events synthesized by Robot? It is quite possible that for Robot the same NSEvent instance would be reused. >>>> That's quite good question. I checked it with a small test, all is Ok. Looked at the Robot code - it creates a new key event every time (CGEventCreateKeyboardEvent). >>>> >>>> Thanks, >>>> Anton. >>>> >>>>> On 08.02.2012, at 13:49, Anton V. Tarasov wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Please review a fix for 7142565. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ >>>>>> >>>>>> Key-equivalent events (typically with modifiers, but not only) are delivered to NSWindow with >>>>>> performKeyEquivalent: The latter always returns NO (to let NSWindow process system key events like >>>>>> Cmd+Q). According to the spec "if a key-equivalent is not recognized, NSWindow sends it as an >>>>>> NSKeyDown event to the first responder". (However, it doesn't send NSKeyDown for Control-key >>>>>> events.) >>>>>> >>>>>> Instead of inspecting a key-equivalent event to determine if it should be propagated further or not, >>>>>> another simple workaround is suggested. It's to store a pointer to the latest processed key event in >>>>>> AWTView and compare the current event to the previous one. In case the event objects are the same, >>>>>> ignore the second (current) one. >>>>>> >>>>>> Thanks, >>>>>> Anton. >>>>>> >>>>>> > From swingler at apple.com Wed Feb 8 10:51:17 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 08 Feb 2012 10:51:17 -0800 Subject: Request for review: 7124528 [macosx] Selection is not cleared properly in text component. In-Reply-To: <4F32AD74.4070608@oracle.com> References: <4F3248D5.1010105@oracle.com> <4F329D11.9080203@oracle.com> <4F32AD74.4070608@oracle.com> Message-ID: On Feb 8, 2012, at 9:14 AM, Sergey Bylokhov wrote: > 08.02.2012 20:16, Mike Swingler ?????: >> On Feb 8, 2012, at 8:04 AM, Sergey Bylokhov wrote: >> >>> 08.02.2012 20:03, Mike Swingler wrote: >>>> On Feb 8, 2012, at 2:05 AM, Sergey Bylokhov wrote: >>>> >>>>> Hi Everyone, >>>>> Now we reset selection in text components on focuslost event. >>>>> >>>>> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124528 >>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124528/webrev.00/ >>>> That bug isn't publicly accessible. Could you give us the gist of it? >>> jira: >>> http://java.net/jira/browse/MACOSX_PORT-616 >> >> Thanks. After this fix, does the text field completely select it's contents when it is re-focused by tabbing into it? > Under aqua l&f text components reselect text if cursor was at first or at last position. > AquaCaret.java > public void focusGained(final FocusEvent e) { > .... > final int dot = getDot(); > final int mark = getMark(); > if (dot == mark) { > if (dot == 0) { > component.setCaretPosition(end); > component.moveCaretPosition(0); > } else if (dot == end) { > component.setCaretPosition(0); > component.moveCaretPosition(end); > } > } This was a compromise to pass the TCK for Swing components, and does not reflect the ideal state. Native AppKit single-line text fields (and the Java SE 6 AWT text fields) always select the content completely when you tab back into them, regardless of the last selection or cursor location. If you are already planning to change the selection state, just select-all. Just try out the behavior in a new compose message window in Mail.app. Regards, Mike Swingler Apple Inc. From swingler at apple.com Wed Feb 8 10:53:10 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 08 Feb 2012 10:53:10 -0800 Subject: Best way to determine openjdk jvm In-Reply-To: <1D1F47D3-B2D1-4A30-A570-7D2924F40355@gmail.com> References: <1D1F47D3-B2D1-4A30-A570-7D2924F40355@gmail.com> Message-ID: <99CD9B7B-AB31-4ED0-8445-AD27EF3CCB2C@apple.com> On Feb 8, 2012, at 3:19 AM, Michael Hall wrote: > I am looking at... > Mac OS X Port Using jsadebug, jinfo, jmap > https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port+Using+jsadebug,+jinfo,+jmap > > Which appears to require a openjdk specific signing certificate, or sudo. > Assuming you wanted to provide the cert, I would further assume you would still need to determine at runtime if you had the features available - meaning a openjdk runtime. > Would checking this system property be the best, recommended, way to do that? > java.runtime.name=OpenJDK Runtime Environment I don't understand what you are asking. The signing certificate is only required at build time to sign the Mach-o binary of the JDK debugging tools. What do you need to know at runtime when you are using the tools? Curious, Mike Swingler Apple Inc. From kurchi.subhra.hazra at oracle.com Wed Feb 8 10:58:25 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 08 Feb 2012 10:58:25 -0800 Subject: [7u4] Request for approval for 7142234: [macosx] closed/java/util/TimeZone/CheckTzdataVersion.sh fails on Mac OS X In-Reply-To: <6582CC16-D6F7-4630-A53E-2FE56CF82B92@oracle.com> References: <4F2FC1E0.3040401@oracle.com> <6582CC16-D6F7-4630-A53E-2FE56CF82B92@oracle.com> Message-ID: <4F32C5D1.9080303@oracle.com> This is a request to push the following fix to jdk 7u4: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142234 Webrev:http://cr.openjdk.java.net/~khazra/7142234/webrev.02/ Reviewed by: ohair, michaelm This changeset will be pushed on my behalf by Michael McMahon (michaelm). Thanks, Kurchi From paul.hohensee at oracle.com Wed Feb 8 13:50:35 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 08 Feb 2012 16:50:35 -0500 Subject: [7u4] Request for approval for 7142234: [macosx] closed/java/util/TimeZone/CheckTzdataVersion.sh fails on Mac OS X In-Reply-To: <4F32C5D1.9080303@oracle.com> References: <4F2FC1E0.3040401@oracle.com> <6582CC16-D6F7-4630-A53E-2FE56CF82B92@oracle.com> <4F32C5D1.9080303@oracle.com> Message-ID: <4F32EE2B.8070709@oracle.com> Approved. Paul On 2/8/12 1:58 PM, Kurchi Hazra wrote: > This is a request to push the following fix to jdk 7u4: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142234 > > Webrev:http://cr.openjdk.java.net/~khazra/7142234/webrev.02/ > > > Reviewed by: ohair, michaelm > > This changeset will be pushed on my behalf by Michael McMahon (michaelm). > > Thanks, > Kurchi > > From mik3hall at gmail.com Wed Feb 8 14:51:45 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 8 Feb 2012 16:51:45 -0600 Subject: Best way to determine openjdk jvm In-Reply-To: <99CD9B7B-AB31-4ED0-8445-AD27EF3CCB2C@apple.com> References: <1D1F47D3-B2D1-4A30-A570-7D2924F40355@gmail.com> <99CD9B7B-AB31-4ED0-8445-AD27EF3CCB2C@apple.com> Message-ID: <4541B3D4-C3B7-4FA0-94EE-8B427B87F604@gmail.com> On Feb 8, 2012, at 12:53 PM, Mike Swingler wrote: > On Feb 8, 2012, at 3:19 AM, Michael Hall wrote: > >> I am looking at... >> Mac OS X Port Using jsadebug, jinfo, jmap >> https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port+Using+jsadebug,+jinfo,+jmap >> >> Which appears to require a openjdk specific signing certificate, or sudo. >> Assuming you wanted to provide the cert, I would further assume you would still need to determine at runtime if you had the features available - meaning a openjdk runtime. >> Would checking this system property be the best, recommended, way to do that? >> java.runtime.name=OpenJDK Runtime Environment > > I don't understand what you are asking. The signing certificate is only required at build time to sign the Mach-o binary of the JDK debugging tools. What do you need to know at runtime when you are using the tools? I may of misunderstood. You are saying this provides instrumentation only for a jdk that you build? I thought it was saying this made the tools available for any running jvm's on the machine without having to sudo. If I am now understanding right you are saying you can't assume non-root use unless you built the jdk yourself with the signing cert? Wouldn't it be possible to set up a certificate and make it available with KeyChain or otherwise for other platforms that could be runtime checked for the authorization. Otherwise I guess I am thinking of trying something like Greg Guerin's old AuthKit JNI that used OS X Authorization services (IIRC) to sort of do an authentication dialog equivalent of a sudo. This if I want to looking at providing anything that wraps the tools use from an application. It still requires admin user of course, and is I'm pretty sure OS X specific. But what I am wondering is how would you approach distributed application use of the tools? From scott.kovatch at oracle.com Wed Feb 8 22:08:37 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 8 Feb 2012 22:08:37 -0800 Subject: No text when using an MB Pro? Message-ID: Folks, Has anyone else encountered the problem of text not being drawn in Swing apps on a MacBook Pro? Frequently this happens after running on an external monitor but then disconnecting it and using the MBP's display. Now and then it happens even after I reboot with no monitor connected. I would file a bug, but unfortunately this keeps me from using Bugster right now. :-\ I will try some kind of web-based system in the morning. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From anton.tarasov at oracle.com Thu Feb 9 02:13:30 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 09 Feb 2012 14:13:30 +0400 Subject: Review request for 7142565 - [macosx] Many special keys processed twice in text fields In-Reply-To: References: <4F32450C.8000609@oracle.com> <3C5C817C-AD09-4ECC-9768-3B57B9C65F57@oracle.com> <4F329EFF.8070304@oracle.com> <4F32AE04.9070307@oracle.com> Message-ID: <4F339C4A.9070605@oracle.com> Hi Mike, On 08.02.2012 21:48, Mike Swingler wrote: > Ok, as long as nobody is sending any messages to it, the retain/release dance doesn't need to be done. I'd suggest changing the name to sUnretainedLastKeyEvent, and changing the type to (id) so nobody is tempted to try to message it in the future. I'm ok with it. Here is the latest version: http://cr.openjdk.java.net/~ant/7142565/webrev.2/ Thanks for the review! Anton. > > Thanks, > Mike Swingler > Apple Inc. > > On Feb 8, 2012, at 9:16 AM, Anthony Petrov wrote: > >> Hi Mike, >> >> We don't actually need to retain the object because we don't use it in any way. The only reason to save the pointer is to compare it with another pointer. Retaining the object would be a waste of RAM. >> >> Now that Anton has updated his fix and put the declaration of the variable immediately before the if() statement (see [1]), there's absolutely no confusion about this static symbol now because the code is concentrated in five consecutive lines, and the scope of the new variable is limited to the method's body. >> >> [1] http://cr.openjdk.java.net/~ant/7142565/webrev.1/ >> >> -- >> best regards, >> Anthony >> >> On 2/8/2012 7:35 PM, Mike Swingler wrote: >>> The safer thing to to is to create an retained property on an instance of a class you pin statically, then, you can be ensured that the Obj-C runtime's property generator will do the correct (and atomic from any thread) retain/release dance. >>> The AWTToolkit looks like a reasonable class to make an instance out of that you can do an unbalanced retain on, and then pin in a static (since the very next thing you do is call +eventCountPlusPlus on it). >>> Just a suggestion, >>> Mike Swingler >>> Apple Inc. >>> On Feb 8, 2012, at 8:12 AM, Anton V. Tarasov wrote: >>>> On 2/8/12 1:41 PM, Leonid Romanov wrote: >>>>> Could you please verify that your fix works with key events synthesized by Robot? It is quite possible that for Robot the same NSEvent instance would be reused. >>>> That's quite good question. I checked it with a small test, all is Ok. Looked at the Robot code - it creates a new key event every time (CGEventCreateKeyboardEvent). >>>> >>>> Thanks, >>>> Anton. >>>> >>>>> On 08.02.2012, at 13:49, Anton V. Tarasov wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Please review a fix for 7142565. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ >>>>>> >>>>>> Key-equivalent events (typically with modifiers, but not only) are delivered to NSWindow with >>>>>> performKeyEquivalent: The latter always returns NO (to let NSWindow process system key events like >>>>>> Cmd+Q). According to the spec "if a key-equivalent is not recognized, NSWindow sends it as an >>>>>> NSKeyDown event to the first responder". (However, it doesn't send NSKeyDown for Control-key >>>>>> events.) >>>>>> >>>>>> Instead of inspecting a key-equivalent event to determine if it should be propagated further or not, >>>>>> another simple workaround is suggested. It's to store a pointer to the latest processed key event in >>>>>> AWTView and compare the current event to the previous one. In case the event objects are the same, >>>>>> ignore the second (current) one. >>>>>> >>>>>> Thanks, >>>>>> Anton. >>>>>> >>>>>> From Alexander.Potochkin at oracle.com Thu Feb 9 03:31:04 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 09 Feb 2012 15:31:04 +0400 Subject: Request for review: 7124543 [macosx] Horizontal scrolling doesn't work In-Reply-To: <4F32B38F.1030502@oracle.com> References: <4F316E11.6080801@oracle.com> <4F329921.6030401@oracle.com> <4F32B38F.1030502@oracle.com> Message-ID: <4F33AE78.3070908@oracle.com> Hello Sergey Looks good! Thanks alexp > 08.02.2012 19:47, Alexander Potochkin wrote: >> Hello Sergey >>> Hi Everyone, >>> - Now we take into account native horizontal scroll event and invert >>> the SHIFT modifier state. >>> - scrollAmount was changed from 3 to 1 to be closer to apple jdk 6. >> >> There is one more "3" hardcoded for mouseWheelEvent, >> see LWComponentPeer.createDelegateEvent() > new version > http://cr.openjdk.java.net/~serb/7124543/webrev.01/ >> could you also change it please? >> >> Thanks >> alexp >> >>> - small cleanup. >>> >>> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124543 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7124543/webrev.00/ >>> >> > > From sergey.bylokhov at oracle.com Thu Feb 9 04:35:09 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 09 Feb 2012 16:35:09 +0400 Subject: [7u4] Request for approval: 7124543 [macosx] Horizontal scrolling doesn't work Message-ID: <4F33BD7D.6000008@oracle.com> Hello, This is a request to push the following changes to jdk7u-dev. The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov and Alexander Potochkin. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124543 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124543/webrev.01 Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002871.html -- Best regards, Sergey. From edvard.wendelin at oracle.com Thu Feb 9 05:05:57 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 9 Feb 2012 14:05:57 +0100 Subject: [7u4] Request for approval: 7124543 [macosx] Horizontal scrolling doesn't work In-Reply-To: <4F33BD7D.6000008@oracle.com> References: <4F33BD7D.6000008@oracle.com> Message-ID: Approved. On Feb 9, 2012, at 1:35 PM, Sergey Bylokhov wrote: > Hello, > This is a request to push the following changes to jdk7u-dev. > The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov and Alexander Potochkin. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124543 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124543/webrev.01 > Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002871.html > > -- > Best regards, Sergey. > From dmitry.cherepanov at oracle.com Thu Feb 9 06:25:09 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Thu, 09 Feb 2012 17:25:09 +0300 Subject: Review request for 7124337: [macosx] FileDialog fails to select multiple files Message-ID: <4F33D745.90109@oracle.com> Hello, The fix enables support for multiple file selection in AWT FileDialog. The fix also provides ability to select files from different folders and for this reason, there are some changes to the shared code. I've tested the changes with native file dialogs on other platforms and I haven't found any problems. http://cr.openjdk.java.net/~dcherepanov/7124337/webrev.0/ Thanks, Dmitry From anthony.petrov at oracle.com Thu Feb 9 05:48:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 09 Feb 2012 17:48:49 +0400 Subject: Review request for 7124337: [macosx] FileDialog fails to select multiple files In-Reply-To: <4F33D745.90109@oracle.com> References: <4F33D745.90109@oracle.com> Message-ID: <4F33CEC1.9090408@oracle.com> Hi Dmitry, The fix looks good to me. -- best regards, Anthony On 02/09/12 18:25, Dmitry Cherepanov wrote: > Hello, > > The fix enables support for multiple file selection in AWT FileDialog. > The fix also provides ability to select files from different folders and > for this reason, there are some changes to the shared code. I've tested > the changes with native file dialogs on other platforms and I haven't > found any problems. > > http://cr.openjdk.java.net/~dcherepanov/7124337/webrev.0/ > > Thanks, > Dmitry > From anton.tarasov at oracle.com Thu Feb 9 06:53:54 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 09 Feb 2012 18:53:54 +0400 Subject: [7u-dev] Request for approval for 7142565 - [macosx] Many special keys processed twice in text fields Message-ID: <4F33DE02.7030607@oracle.com> Hello, A request to push the changes to jdk7u-dev. Reviewed on macosx-port-dev by Anthony Petrov, Mike Swingler. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142565 Webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.2/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002913.html Thanks, Anton. From sergey.bylokhov at oracle.com Thu Feb 9 07:08:49 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 09 Feb 2012 19:08:49 +0400 Subject: Request for review: 7124528 [macosx] Selection is not cleared properly in text component. In-Reply-To: References: <4F3248D5.1010105@oracle.com> <4F329D11.9080203@oracle.com> <4F32AD74.4070608@oracle.com> Message-ID: <4F33E181.5010305@oracle.com> 08.02.2012 22:51, Mike Swingler wrote: > On Feb 8, 2012, at 9:14 AM, Sergey Bylokhov wrote: > >> 08.02.2012 20:16, Mike Swingler ?????: >>> On Feb 8, 2012, at 8:04 AM, Sergey Bylokhov wrote: >>> >>>> 08.02.2012 20:03, Mike Swingler wrote: >>>>> On Feb 8, 2012, at 2:05 AM, Sergey Bylokhov wrote: >>>>> >>>>>> Hi Everyone, >>>>>> Now we reset selection in text components on focuslost event. >>>>>> >>>>>> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124528 >>>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124528/webrev.00/ >>>>> That bug isn't publicly accessible. Could you give us the gist of it? >>>> jira: >>>> http://java.net/jira/browse/MACOSX_PORT-616 >>> Thanks. After this fix, does the text field completely select it's contents when it is re-focused by tabbing into it? >> Under aqua l&f text components reselect text if cursor was at first or at last position. >> AquaCaret.java >> public void focusGained(final FocusEvent e) { >> .... >> final int dot = getDot(); >> final int mark = getMark(); >> if (dot == mark) { >> if (dot == 0) { >> component.setCaretPosition(end); >> component.moveCaretPosition(0); >> } else if (dot == end) { >> component.setCaretPosition(0); >> component.moveCaretPosition(end); >> } >> } > This was a compromise to pass the TCK for Swing components, and does not reflect the ideal state. > > Native AppKit single-line text fields (and the Java SE 6 AWT text fields) always select the content completely when you tab back into them, regardless of the last selection or cursor location. If you are already planning to change the selection state, just select-all. Looks like I found workaround. in jdk 6 when the textfield loses focus, the caret position will be set to 0. If we reset it too, text will be reselected automatically. New version: http://cr.openjdk.java.net/~serb/7124528/webrev.01/ > > Just try out the behavior in a new compose message window in Mail.app. > > Regards, > Mike Swingler > Apple Inc. > -- Best regards, Sergey. From vanjab at icetec.biz Thu Feb 9 07:32:08 2012 From: vanjab at icetec.biz (Bucic Vanja) Date: Thu, 9 Feb 2012 10:32:08 -0500 Subject: No text when using an MB Pro? In-Reply-To: References: Message-ID: I have been seeing this behavior for a long time, when using Netbeans. Everything that would draw a string would draw a blank, and sometimes it would take some time to encounter a trigger that would make it all go blank. Once it goes blank it never recovers. I made an attempt to figure it out, but was unsuccessful. This was on a MacPro1,1 with a dual monitor setup. On Feb 9, 2012, at 1:08 AM, Scott Kovatch wrote: > Folks, > > Has anyone else encountered the problem of text not being drawn in Swing apps on a MacBook Pro? Frequently this happens after running on an external monitor but then disconnecting it and using the MBP's display. Now and then it happens even after I reboot with no monitor connected. > > I would file a bug, but unfortunately this keeps me from using Bugster right now. :-\ I will try some kind of web-based system in the morning. > > -- Scott K. > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > > From scott.kovatch at oracle.com Thu Feb 9 08:08:23 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 9 Feb 2012 08:08:23 -0800 Subject: No text when using an MB Pro? In-Reply-To: References: Message-ID: <0F2E31AA-3328-48C0-A66D-989D99E073EE@oracle.com> That corresponds pretty well with what I've seen. An app will start up fine but eventually something happens and text stops drawing altogether. 7125754 is specific to deploy, but the symptoms are the same. -- Scott On Feb 9, 2012, at 7:32 AM, Bucic Vanja wrote: > I have been seeing this behavior for a long time, when using Netbeans. > Everything that would draw a string would draw a blank, and sometimes it would take some time to encounter a trigger that would make it all go blank. Once it goes blank it never recovers. > I made an attempt to figure it out, but was unsuccessful. > > This was on a MacPro1,1 with a dual monitor setup. > > On Feb 9, 2012, at 1:08 AM, Scott Kovatch wrote: > >> Folks, >> >> Has anyone else encountered the problem of text not being drawn in Swing apps on a MacBook Pro? Frequently this happens after running on an external monitor but then disconnecting it and using the MBP's display. Now and then it happens even after I reboot with no monitor connected. >> >> I would file a bug, but unfortunately this keeps me from using Bugster right now. :-\ I will try some kind of web-based system in the morning. >> >> -- Scott K. >> >> ---------------------------------------- >> Scott Kovatch >> scott.kovatch at oracle.com >> Santa Clara/Pleasanton, CA >> >> > From swingler at apple.com Thu Feb 9 08:35:54 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 09 Feb 2012 08:35:54 -0800 Subject: Request for review: 7124528 [macosx] Selection is not cleared properly in text component. In-Reply-To: <4F33E181.5010305@oracle.com> References: <4F3248D5.1010105@oracle.com> <4F329D11.9080203@oracle.com> <4F32AD74.4070608@oracle.com> <4F33E181.5010305@oracle.com> Message-ID: On Feb 9, 2012, at 7:08 AM, Sergey Bylokhov wrote: > 08.02.2012 22:51, Mike Swingler wrote: >> On Feb 8, 2012, at 9:14 AM, Sergey Bylokhov wrote: >> >>> 08.02.2012 20:16, Mike Swingler ?????: >>>> On Feb 8, 2012, at 8:04 AM, Sergey Bylokhov wrote: >>>> >>>>> 08.02.2012 20:03, Mike Swingler wrote: >>>>>> On Feb 8, 2012, at 2:05 AM, Sergey Bylokhov wrote: >>>>>> >>>>>>> Hi Everyone, >>>>>>> Now we reset selection in text components on focuslost event. >>>>>>> >>>>>>> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7124528 >>>>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124528/webrev.00/ >>>>>> That bug isn't publicly accessible. Could you give us the gist of it? >>>>> jira: >>>>> http://java.net/jira/browse/MACOSX_PORT-616 >>>> Thanks. After this fix, does the text field completely select it's contents when it is re-focused by tabbing into it? >>> Under aqua l&f text components reselect text if cursor was at first or at last position. >>> AquaCaret.java >>> public void focusGained(final FocusEvent e) { >>> .... >>> final int dot = getDot(); >>> final int mark = getMark(); >>> if (dot == mark) { >>> if (dot == 0) { >>> component.setCaretPosition(end); >>> component.moveCaretPosition(0); >>> } else if (dot == end) { >>> component.setCaretPosition(0); >>> component.moveCaretPosition(end); >>> } >>> } >> This was a compromise to pass the TCK for Swing components, and does not reflect the ideal state. >> >> Native AppKit single-line text fields (and the Java SE 6 AWT text fields) always select the content completely when you tab back into them, regardless of the last selection or cursor location. If you are already planning to change the selection state, just select-all. > Looks like I found workaround. in jdk 6 when the textfield loses focus, the caret position will be set to 0. If we reset it too, text will be reselected automatically. > New version: > http://cr.openjdk.java.net/~serb/7124528/webrev.01/ Looks great. Regards, Mike Swingler Apple Inc. From swingler at apple.com Thu Feb 9 08:42:02 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 09 Feb 2012 08:42:02 -0800 Subject: Review request for 7142565 - [macosx] Many special keys processed twice in text fields In-Reply-To: <4F339C4A.9070605@oracle.com> References: <4F32450C.8000609@oracle.com> <3C5C817C-AD09-4ECC-9768-3B57B9C65F57@oracle.com> <4F329EFF.8070304@oracle.com> <4F32AE04.9070307@oracle.com> <4F339C4A.9070605@oracle.com> Message-ID: Looks great. Mike Swingler Apple Inc. On Feb 9, 2012, at 2:13 AM, Anton V. Tarasov wrote: > Hi Mike, > > On 08.02.2012 21:48, Mike Swingler wrote: >> Ok, as long as nobody is sending any messages to it, the retain/release dance doesn't need to be done. I'd suggest changing the name to sUnretainedLastKeyEvent, and changing the type to (id) so nobody is tempted to try to message it in the future. > > I'm ok with it. Here is the latest version: > > http://cr.openjdk.java.net/~ant/7142565/webrev.2/ > > Thanks for the review! > > Anton. > >> >> Thanks, >> Mike Swingler >> Apple Inc. >> >> On Feb 8, 2012, at 9:16 AM, Anthony Petrov wrote: >> >>> Hi Mike, >>> >>> We don't actually need to retain the object because we don't use it in any way. The only reason to save the pointer is to compare it with another pointer. Retaining the object would be a waste of RAM. >>> >>> Now that Anton has updated his fix and put the declaration of the variable immediately before the if() statement (see [1]), there's absolutely no confusion about this static symbol now because the code is concentrated in five consecutive lines, and the scope of the new variable is limited to the method's body. >>> >>> [1] http://cr.openjdk.java.net/~ant/7142565/webrev.1/ >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 2/8/2012 7:35 PM, Mike Swingler wrote: >>>> The safer thing to to is to create an retained property on an instance of a class you pin statically, then, you can be ensured that the Obj-C runtime's property generator will do the correct (and atomic from any thread) retain/release dance. >>>> The AWTToolkit looks like a reasonable class to make an instance out of that you can do an unbalanced retain on, and then pin in a static (since the very next thing you do is call +eventCountPlusPlus on it). >>>> Just a suggestion, >>>> Mike Swingler >>>> Apple Inc. >>>> On Feb 8, 2012, at 8:12 AM, Anton V. Tarasov wrote: >>>>> On 2/8/12 1:41 PM, Leonid Romanov wrote: >>>>>> Could you please verify that your fix works with key events synthesized by Robot? It is quite possible that for Robot the same NSEvent instance would be reused. >>>>> That's quite good question. I checked it with a small test, all is Ok. Looked at the Robot code - it creates a new key event every time (CGEventCreateKeyboardEvent). >>>>> >>>>> Thanks, >>>>> Anton. >>>>> >>>>>> On 08.02.2012, at 13:49, Anton V. Tarasov wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Please review a fix for 7142565. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/ >>>>>>> >>>>>>> Key-equivalent events (typically with modifiers, but not only) are delivered to NSWindow with >>>>>>> performKeyEquivalent: The latter always returns NO (to let NSWindow process system key events like >>>>>>> Cmd+Q). According to the spec "if a key-equivalent is not recognized, NSWindow sends it as an >>>>>>> NSKeyDown event to the first responder". (However, it doesn't send NSKeyDown for Control-key >>>>>>> events.) >>>>>>> >>>>>>> Instead of inspecting a key-equivalent event to determine if it should be propagated further or not, >>>>>>> another simple workaround is suggested. It's to store a pointer to the latest processed key event in >>>>>>> AWTView and compare the current event to the previous one. In case the event objects are the same, >>>>>>> ignore the second (current) one. >>>>>>> >>>>>>> Thanks, >>>>>>> Anton. >>>>>>> >>>>>>> > From alexander.zuev at oracle.com Thu Feb 9 10:05:20 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 09 Feb 2012 21:05:20 +0300 Subject: Request for review for 7144064: [macosx] "Could not find class" error in JTree's ctor when called in headless mode Message-ID: <4F340AE0.2020302@oracle.com> Hello, please review my fix for bug 7144064: [macosx] "Could not find class" error in JTree's ctor when called in headless mode Bug description is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144064 Webrev can be found here: http://cr.openjdk.java.net/~kizune/7144064/webrev/ With best regards, Alexander Zuev From sergey.bylokhov at oracle.com Thu Feb 9 09:11:43 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 09 Feb 2012 21:11:43 +0400 Subject: Request for review: 7125657 [macosx] SpreadSheet demo has the broken display when clicking outside of the table Message-ID: <4F33FE4F.3050702@oracle.com> Hi Everyone, There is no reason to paint native part of the peer on Update event. Note that we paint it in the XToolkit but most of the code(and this demo) is working, because XPanel.paintPeer is noop. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125657 Webrev can be found at: http://cr.openjdk.java.net/~serb/7125657/webrev.00 -- Best regards, Sergey. From Andrey.Pikalev at oracle.com Thu Feb 9 09:28:54 2012 From: Andrey.Pikalev at oracle.com (Andrey Pikalev) Date: Thu, 09 Feb 2012 21:28:54 +0400 Subject: No text when using an MB Pro? In-Reply-To: <0F2E31AA-3328-48C0-A66D-989D99E073EE@oracle.com> References: <0F2E31AA-3328-48C0-A66D-989D99E073EE@oracle.com> Message-ID: <4F340256.5010803@oracle.com> Do we have a non-deploy bug id for this issue? Can someone file it? Thanks, Andrey. On 2/9/2012 8:08 PM, Scott Kovatch wrote: > That corresponds pretty well with what I've seen. An app will start up fine but eventually something happens and text stops drawing altogether. > > 7125754 is specific to deploy, but the symptoms are the same. > > -- Scott > > On Feb 9, 2012, at 7:32 AM, Bucic Vanja wrote: > >> I have been seeing this behavior for a long time, when using Netbeans. >> Everything that would draw a string would draw a blank, and sometimes it would take some time to encounter a trigger that would make it all go blank. Once it goes blank it never recovers. >> I made an attempt to figure it out, but was unsuccessful. >> >> This was on a MacPro1,1 with a dual monitor setup. >> >> On Feb 9, 2012, at 1:08 AM, Scott Kovatch wrote: >> >>> Folks, >>> >>> Has anyone else encountered the problem of text not being drawn in Swing apps on a MacBook Pro? Frequently this happens after running on an external monitor but then disconnecting it and using the MBP's display. Now and then it happens even after I reboot with no monitor connected. >>> >>> I would file a bug, but unfortunately this keeps me from using Bugster right now. :-\ I will try some kind of web-based system in the morning. >>> >>> -- Scott K. >>> >>> ---------------------------------------- >>> Scott Kovatch >>> scott.kovatch at oracle.com >>> Santa Clara/Pleasanton, CA >>> >>> >> > From scott.kovatch at oracle.com Thu Feb 9 09:28:14 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 9 Feb 2012 09:28:14 -0800 Subject: Build failure in JObjC Message-ID: <297DFA25-C89E-4A80-8174-2EFAA102FB52@oracle.com> Hello, I updated my jdk7u-dev forest last night and I can no longer build JObjC. I'm also on 10.7.3. Any ideas? Does JObjC have an owner, either in the community or within Oracle? -- Scott [exec] java -d64 -Xms128m -Xmx512m -Djava.library.path=/Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.dst/Debug -Xbootclasspath:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/sunrsasign.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/classes -classpath /Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/bin/core:/Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/bin/generator -ea com.apple.internal.jobjc.generator.Generator dst=/Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/src/jobjc frameworks=/Users/skovatch/src/jdk7u-dev/build/macosx-universal/stable_bridge_metadata [exec] ./rungen:67:in `raise': exception class/object expected (TypeError) [exec] from ./rungen:67 [exec] Cleaning up: /Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/src/jobjc [exec] Outputting classes to: /Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/src/jobjc [exec] Searching for bridged frameworks in: /Users/skovatch/src/jdk7u-dev/build/macosx-universal/stable_bridge_metadata [exec] found 0 frameworks [exec] Parsing XML [exec] Parsing dependencies [exec] Parsing types [exec] SORBB -- Getting Struct offsets @W32 [exec] SORBB -- Getting Struct offsets @W64 [exec] Parsing classes [exec] Parsing constants [exec] Parsing functions [exec] --1-- Generator: consolidateClassesForFrameworks [exec] --2-- Resolving duplicate classes: [exec] Determining super classes: [exec] --1-- Generator: TypeCache load [exec] --1-- Generator: disambiguateMethodNames [exec] Exception in thread "main" java.lang.NullPointerException [exec] at com.apple.internal.jobjc.generator.MethodDisambiguator.disambiguateMethodNamesFor(MethodDisambiguator.java:50) [exec] at com.apple.internal.jobjc.generator.MethodDisambiguator.disambiguateMethodNames(MethodDisambiguator.java:43) [exec] at com.apple.internal.jobjc.generator.Generator.main(Generator.java:66) From scott.kovatch at oracle.com Thu Feb 9 09:44:11 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 9 Feb 2012 09:44:11 -0800 Subject: No text when using an MB Pro? In-Reply-To: <4F340256.5010803@oracle.com> References: <0F2E31AA-3328-48C0-A66D-989D99E073EE@oracle.com> <4F340256.5010803@oracle.com> Message-ID: <7E53B54B-293D-4722-9DA4-4F5E77BF6C4D@oracle.com> Just filed 7144207. I had a small AWT example that readily reproduces it. -- Scott On Feb 9, 2012, at 9:28 AM, Andrey Pikalev wrote: > Do we have a non-deploy bug id for this issue? Can someone file it? > > Thanks, > Andrey. > > On 2/9/2012 8:08 PM, Scott Kovatch wrote: >> That corresponds pretty well with what I've seen. An app will start up fine but eventually something happens and text stops drawing altogether. >> >> 7125754 is specific to deploy, but the symptoms are the same. >> >> -- Scott >> >> On Feb 9, 2012, at 7:32 AM, Bucic Vanja wrote: >> >>> I have been seeing this behavior for a long time, when using Netbeans. >>> Everything that would draw a string would draw a blank, and sometimes it would take some time to encounter a trigger that would make it all go blank. Once it goes blank it never recovers. >>> I made an attempt to figure it out, but was unsuccessful. >>> >>> This was on a MacPro1,1 with a dual monitor setup. >>> >>> On Feb 9, 2012, at 1:08 AM, Scott Kovatch wrote: >>> >>>> Folks, >>>> >>>> Has anyone else encountered the problem of text not being drawn in Swing apps on a MacBook Pro? Frequently this happens after running on an external monitor but then disconnecting it and using the MBP's display. Now and then it happens even after I reboot with no monitor connected. >>>> >>>> I would file a bug, but unfortunately this keeps me from using Bugster right now. :-\ I will try some kind of web-based system in the morning. >>>> >>>> -- Scott K. >>>> >>>> ---------------------------------------- >>>> Scott Kovatch >>>> scott.kovatch at oracle.com >>>> Santa Clara/Pleasanton, CA >>>> >>>> >>> >> From michael.x.mcmahon at oracle.com Thu Feb 9 11:53:44 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 09 Feb 2012 19:53:44 +0000 Subject: Build failure in JObjC In-Reply-To: <297DFA25-C89E-4A80-8174-2EFAA102FB52@oracle.com> References: <297DFA25-C89E-4A80-8174-2EFAA102FB52@oracle.com> Message-ID: <4F342448.2030908@oracle.com> I saw that error too yesterday and assumed it was caused by (my incomplete work for) 7142950 You could try the completed patch from the webrev today and see if it fixes it for you. Also, did you update to 10.7.3 recently? I updated yesterday and wonder if that might be the cause. - Michael On 09/02/12 17:28, Scott Kovatch wrote: > Hello, > > I updated my jdk7u-dev forest last night and I can no longer build JObjC. I'm also on 10.7.3. Any ideas? > > Does JObjC have an owner, either in the community or within Oracle? > > -- Scott > > [exec] java -d64 -Xms128m -Xmx512m -Djava.library.path=/Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.dst/Debug -Xbootclasspath:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/sunrsasign.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/classes -classpath /Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/bin/core:/Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/bin/generator -ea com.apple.internal.jobjc.generator.Generator dst=/Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/src/jobjc frameworks=/Users/skovatch/src/jdk7u-dev/build/macosx-universal/stable_bridge_metadata > [exec] ./rungen:67:in `raise': exception class/object expected (TypeError) > [exec] from ./rungen:67 > [exec] Cleaning up: /Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/src/jobjc > [exec] Outputting classes to: /Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/src/jobjc > [exec] Searching for bridged frameworks in: /Users/skovatch/src/jdk7u-dev/build/macosx-universal/stable_bridge_metadata > [exec] found 0 frameworks > [exec] Parsing XML > [exec] Parsing dependencies > [exec] Parsing types > [exec] SORBB -- Getting Struct offsets @W32 > [exec] SORBB -- Getting Struct offsets @W64 > [exec] Parsing classes > [exec] Parsing constants > [exec] Parsing functions > [exec] --1-- Generator: consolidateClassesForFrameworks > [exec] --2-- Resolving duplicate classes: > [exec] Determining super classes: > [exec] --1-- Generator: TypeCache load > [exec] --1-- Generator: disambiguateMethodNames > [exec] Exception in thread "main" java.lang.NullPointerException > [exec] at com.apple.internal.jobjc.generator.MethodDisambiguator.disambiguateMethodNamesFor(MethodDisambiguator.java:50) > [exec] at com.apple.internal.jobjc.generator.MethodDisambiguator.disambiguateMethodNames(MethodDisambiguator.java:43) > [exec] at com.apple.internal.jobjc.generator.Generator.main(Generator.java:66) > From scott.kovatch at oracle.com Thu Feb 9 12:02:08 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 9 Feb 2012 12:02:08 -0800 Subject: Build failure in JObjC In-Reply-To: <4F342448.2030908@oracle.com> References: <297DFA25-C89E-4A80-8174-2EFAA102FB52@oracle.com> <4F342448.2030908@oracle.com> Message-ID: I don't have anything related to your patch installed, so that's not it. 10.7.3 sounds like a culprit, given where it's failing. -- Scott On Feb 9, 2012, at 11:53 AM, Michael McMahon wrote: > I saw that error too yesterday and assumed it was caused by (my incomplete work for) 7142950 > You could try the completed patch from the webrev today and see if it fixes it for you. > > Also, did you update to 10.7.3 recently? I updated yesterday and wonder if that > might be the cause. > > - Michael > > On 09/02/12 17:28, Scott Kovatch wrote: >> Hello, >> >> I updated my jdk7u-dev forest last night and I can no longer build JObjC. I'm also on 10.7.3. Any ideas? >> >> Does JObjC have an owner, either in the community or within Oracle? >> >> -- Scott >> >> [exec] java -d64 -Xms128m -Xmx512m -Djava.library.path=/Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.dst/Debug -Xbootclasspath:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/sunrsasign.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/classes -classpath /Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/bin/core:/Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/bin/generator -ea com.apple.internal.jobjc.generator.Generator dst=/Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/src/jobjc frameworks=/Users/skovatch/src/jdk7u-dev/build/macosx-universal/stable_bridge_metadata >> [exec] ./rungen:67:in `raise': exception class/object expected (TypeError) >> [exec] from ./rungen:67 >> [exec] Cleaning up: /Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/src/jobjc >> [exec] Outputting classes to: /Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/src/jobjc >> [exec] Searching for bridged frameworks in: /Users/skovatch/src/jdk7u-dev/build/macosx-universal/stable_bridge_metadata >> [exec] found 0 frameworks >> [exec] Parsing XML >> [exec] Parsing dependencies >> [exec] Parsing types >> [exec] SORBB -- Getting Struct offsets @W32 >> [exec] SORBB -- Getting Struct offsets @W64 >> [exec] Parsing classes >> [exec] Parsing constants >> [exec] Parsing functions >> [exec] --1-- Generator: consolidateClassesForFrameworks >> [exec] --2-- Resolving duplicate classes: >> [exec] Determining super classes: >> [exec] --1-- Generator: TypeCache load >> [exec] --1-- Generator: disambiguateMethodNames >> [exec] Exception in thread "main" java.lang.NullPointerException >> [exec] at com.apple.internal.jobjc.generator.MethodDisambiguator.disambiguateMethodNamesFor(MethodDisambiguator.java:50) >> [exec] at com.apple.internal.jobjc.generator.MethodDisambiguator.disambiguateMethodNames(MethodDisambiguator.java:43) >> [exec] at com.apple.internal.jobjc.generator.Generator.main(Generator.java:66) >> > > From henri.gomez at gmail.com Thu Feb 9 12:03:24 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 9 Feb 2012 21:03:24 +0100 Subject: Build failure in JObjC In-Reply-To: <4F342448.2030908@oracle.com> References: <297DFA25-C89E-4A80-8174-2EFAA102FB52@oracle.com> <4F342448.2030908@oracle.com> Message-ID: Strange, I'm also on 10.7.3 and builded / packaged one today : [exec] java -d64 -Xms128m -Xmx512m -Djava.library.path=/Users/henri/Documents/jenkins/data/jobs/openjdk-jdk7u-jdk7u-dev/workspace/build/macosx-amd64/JObjC.dst/Debug -Xbootclasspath:/Library/Java/JavaVirtualMachines/1.6.0_30-b12-404.jdk/Contents/Classes/jsfd.jar:/Library/Java/JavaVirtualMachines/1.6.0_30-b12-404.jdk/Contents/Classes/classes.jar:/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/Resources/Java/JavaRuntimeSupport.jar:/Library/Java/JavaVirtualMachines/1.6.0_30-b12-404.jdk/Contents/Classes/ui.jar:/Library/Java/JavaVirtualMachines/1.6.0_30-b12-404.jdk/Contents/Classes/laf.jar:/Library/Java/JavaVirtualMachines/1.6.0_30-b12-404.jdk/Contents/Classes/sunrsasign.jar:/Library/Java/JavaVirtualMachines/1.6.0_30-b12-404.jdk/Contents/Classes/jsse.jar:/Library/Java/JavaVirtualMachines/1.6.0_30-b12-404.jdk/Contents/Classes/jce.jar:/Library/Java/JavaVirtualMachines/1.6.0_30-b12-404.jdk/Contents/Classes/charsets.jar -classpath /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk7u-jdk7u-dev/workspace/build/macosx-amd64/JObjC.build/bin/core:/Users/henri/Documents/jenkins/data/jobs/openjdk-jdk7u-jdk7u-dev/workspace/build/macosx-amd64/JObjC.build/bin/generator -ea com.apple.internal.jobjc.generator.Generator dst=/Users/henri/Documents/jenkins/data/jobs/openjdk-jdk7u-jdk7u-dev/workspace/build/macosx-amd64/JObjC.build/src/jobjc frameworks=/Users/henri/Documents/jenkins/data/jobs/openjdk-jdk7u-jdk7u-dev/workspace/build/macosx-amd64/stable_bridge_metadata [exec] Cleaning up: /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk7u-jdk7u-dev/workspace/build/macosx-amd64/JObjC.build/src/jobjc [exec] Outputting classes to: /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk7u-jdk7u-dev/workspace/build/macosx-amd64/JObjC.build/src/jobjc [exec] Searching for bridged frameworks in: /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk7u-jdk7u-dev/workspace/build/macosx-amd64/stable_bridge_metadata [exec] found 3 frameworks [exec] Parsing XML [exec] Generator at x86_64 loaded AppKit () [exec] Generator at x86_64 loaded CoreFoundation () [exec] Generator at x86_64 loaded Foundation () [exec] Parsing dependencies [exec] Warning: unresolved dependency: AppKit -> ApplicationServices [exec] Warning: unresolved dependency: AppKit -> AudioToolbox [exec] Warning: unresolved dependency: AppKit -> AudioUnit [exec] Warning: unresolved dependency: AppKit -> CoreData [exec] Warning: unresolved dependency: AppKit -> Foundation [exec] Warning: unresolved dependency: AppKit -> HIToolbox [exec] Warning: unresolved dependency: AppKit -> QuartzCore [exec] Warning: unresolved dependency: AppKit -> Security [exec] Warning: unresolved dependency: AppKit -> SpeechRecognition [exec] Warning: unresolved dependency: AppKit -> CoreAudio [exec] Warning: unresolved dependency: AppKit -> DiskArbitration [exec] Warning: unresolved dependency: AppKit -> IOKit [exec] Warning: unresolved dependency: AppKit -> CoreServices [exec] Warning: unresolved dependency: AppKit -> CoreFoundation [exec] Warning: unresolved dependency: Foundation -> CFNetwork [exec] Warning: unresolved dependency: Foundation -> SystemConfiguration [exec] Unresolved dependencies lead to unresolved types. [exec] Parsing types [exec] SORBB -- Getting Struct offsets @W32 [exec] SOR 'AppKit NSEdgeInsets:16 0 4 8 12' [exec] SOR 'CoreFoundation CFAllocatorContext:36 0 4 8 12 16 20 24 28 32' [exec] SOR 'CoreFoundation CFArrayCallBacks:20 0 4 8 12 16' [exec] SOR 'CoreFoundation CFBagCallBacks:24 0 4 8 12 16 20' [exec] SOR 'CoreFoundation CFBinaryHeapCallBacks:20 0 4 8 12 16' [exec] SOR 'CoreFoundation CFBinaryHeapCompareContext:20 0 4 8 12 16' Note I'm using 1.6.0_30-b12-404, ie latest 'stable' JDK 6 not the latest dev release From sergey.bylokhov at oracle.com Thu Feb 9 13:20:40 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 10 Feb 2012 01:20:40 +0400 Subject: Request for review: 7125657 [macosx] SpreadSheet demo has the broken display when clicking outside of the table Message-ID: <4F3438A8.40000@oracle.com> Hi Everyone, There is no reason to paint native part of the peer on Update event. Note that we paint it in the XToolkit but most of the code(and this demo) is working, because XPanel.paintPeer is noop. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125657 Webrev can be found at: http://cr.openjdk.java.net/~serb/7125657/webrev.00 -- Best regards, Sergey. From michael.x.mcmahon at oracle.com Thu Feb 9 13:59:47 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 09 Feb 2012 21:59:47 +0000 Subject: RFR 7142950: jdk7u cannot bootstrap Mac OS build [macosx] In-Reply-To: <32131CAD-A904-4DA1-8E8D-ADBDD73A6279@oracle.com> References: <4F3054B9.5070009@oracle.com> <32131CAD-A904-4DA1-8E8D-ADBDD73A6279@oracle.com> Message-ID: <4F3441D3.1010508@oracle.com> Hi, http://cr.openjdk.java.net/~michaelm/7142950/jdk/webrev.2/ This is an updated webrev based on the contribution/suggestion from Scott Kovatch. It changes the build image directories on Mac, to have the same format/directory structure as the other platforms (ie. it removes the Contents/Home stuff). That directory structure required by Mac bundles is now generated in specific bundle directories and these are used by the install. A consequence of this change is that anyone who has adjusted scripts that used the built j2sdk-image, or j2re-image to know about the mac specific paths will have to change that back again. This version of the change is almost agnostic on the "os.arch" setting. The only dependency is on 'src/macosx/bin/amd64/jvm.cfg'. That will have to be renamed to x86_64/jvm.cfg when 'os.arch' is changed. No other change is required. With this change, jdk only, and incremental builds should work again. If you are using the previous output from a control build as bootstrap or import jdk for a subsequent jdk only build, then it is possible you could run into the build problem described in 6967648. The workaround is to rename the top-level build directory to some other name before doing the jdk build. Thanks, Michael On 06/02/12 23:21, Scott Kovatch wrote: > On Feb 6, 2012, at 2:31 PM, Michael McMahon wrote: > >> There are a few problems with the Mac build at the moment. >> >> 1. If SKIP_BOOT_CYCLE=false then the build fails, due to two problems:- >> 1) top level Makefile doesn't know about Mac OS image directory >> structure >> 2) it also fails due to problem 2. below >> 2. General bootstrapping problem. The build currently cannot use >> itself as >> the bootstrap JDK due to an assumption in the framework classes that >> "os.arch" is x86_64, whereas we currently set it to amd64. The >> change is to >> fix that code to expect amd64. There is a related question then >> about what the >> correct value for os.arch should be. I'd like to raise this in a >> separate discussion >> and hopefully fix these build problems independently of that. > I was going to propose that we fix the image directory issues by > building into the image directories the same way on all platforms and > have the mac build copy the image directories into j2sdk-bundle. > (7133768) I'm pretty sure that even with this change you can't build > rt.jar because the jar tool gets moved out from underneath the running > build when the bundle is constructed. > > I don't think your changes would interfere with my proposed fix for > 7133768, though. And, the other changes for generating the folder name > dynamically are very much welcome. > > -- Scott K. > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > From scott.kovatch at oracle.com Thu Feb 9 22:05:57 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 9 Feb 2012 22:05:57 -0800 Subject: Build failure in JObjC In-Reply-To: References: <297DFA25-C89E-4A80-8174-2EFAA102FB52@oracle.com> <4F342448.2030908@oracle.com> Message-ID: Well, I'm now building again, but I'm still confused as to why it succeeded. I was using 'remake' which is based on gnumake 3.8.2, but when I went back to make it built successfully. I also made sure 1.6.0_30 was my Java 6 JDK. I had been building with both of those tools for a while without any problems. The problem was that there was nothing in the stable_bridge_metadata folder -- the metadata generation phase didn't happen. Switching to 10.7.3 might have done that because the frameworks were updated, but it was a clean build, too. If I see it again I'll file a bug. -- Scott On Feb 9, 2012, at 12:02 PM, Scott Kovatch wrote: > I don't have anything related to your patch installed, so that's not it. > > 10.7.3 sounds like a culprit, given where it's failing. > > -- Scott > > On Feb 9, 2012, at 11:53 AM, Michael McMahon wrote: > >> I saw that error too yesterday and assumed it was caused by (my incomplete work for) 7142950 >> You could try the completed patch from the webrev today and see if it fixes it for you. >> >> Also, did you update to 10.7.3 recently? I updated yesterday and wonder if that >> might be the cause. >> >> - Michael >> >> On 09/02/12 17:28, Scott Kovatch wrote: >>> Hello, >>> >>> I updated my jdk7u-dev forest last night and I can no longer build JObjC. I'm also on 10.7.3. Any ideas? >>> >>> Does JObjC have an owner, either in the community or within Oracle? >>> >>> -- Scott >>> >>> [exec] java -d64 -Xms128m -Xmx512m -Djava.library.path=/Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.dst/Debug -Xbootclasspath:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/sunrsasign.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/1.7.0-b228.jdk/Contents/Home/jre/classes -classpath /Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/bin/core:/Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/bin/generator -ea com.apple.internal.jobjc.generator.Generator dst=/Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/src/jobjc frameworks=/Users/skovatch/src/jdk7u-dev/build/macosx-universal/stable_bridge_metadata >>> [exec] ./rungen:67:in `raise': exception class/object expected (TypeError) >>> [exec] from ./rungen:67 >>> [exec] Cleaning up: /Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/src/jobjc >>> [exec] Outputting classes to: /Users/skovatch/src/jdk7u-dev/build/macosx-universal/JObjC.build/src/jobjc >>> [exec] Searching for bridged frameworks in: /Users/skovatch/src/jdk7u-dev/build/macosx-universal/stable_bridge_metadata >>> [exec] found 0 frameworks >>> [exec] Parsing XML >>> [exec] Parsing dependencies >>> [exec] Parsing types >>> [exec] SORBB -- Getting Struct offsets @W32 >>> [exec] SORBB -- Getting Struct offsets @W64 >>> [exec] Parsing classes >>> [exec] Parsing constants >>> [exec] Parsing functions >>> [exec] --1-- Generator: consolidateClassesForFrameworks >>> [exec] --2-- Resolving duplicate classes: >>> [exec] Determining super classes: >>> [exec] --1-- Generator: TypeCache load >>> [exec] --1-- Generator: disambiguateMethodNames >>> [exec] Exception in thread "main" java.lang.NullPointerException >>> [exec] at com.apple.internal.jobjc.generator.MethodDisambiguator.disambiguateMethodNamesFor(MethodDisambiguator.java:50) >>> [exec] at com.apple.internal.jobjc.generator.MethodDisambiguator.disambiguateMethodNames(MethodDisambiguator.java:43) >>> [exec] at com.apple.internal.jobjc.generator.Generator.main(Generator.java:66) >>> >> >> > From edvard.wendelin at oracle.com Thu Feb 9 23:42:44 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 10 Feb 2012 08:42:44 +0100 Subject: [7u-dev] Request for approval for 7142565 - [macosx] Many special keys processed twice in text fields In-Reply-To: <4F33DE02.7030607@oracle.com> References: <4F33DE02.7030607@oracle.com> Message-ID: <42DE6DF2-B672-4ED4-AFE2-BA7E2A0DDF13@oracle.com> Approved. On Feb 9, 2012, at 3:53 PM, Anton V. Tarasov wrote: > Hello, > > A request to push the changes to jdk7u-dev. > Reviewed on macosx-port-dev by Anthony Petrov, Mike Swingler. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142565 > Webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.2/ > > Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002913.html > > Thanks, > Anton. From anthony.petrov at oracle.com Fri Feb 10 04:13:04 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 10 Feb 2012 16:13:04 +0400 Subject: Request for review for 7144064: [macosx] "Could not find class" error in JTree's ctor when called in headless mode In-Reply-To: <4F340AE0.2020302@oracle.com> References: <4F340AE0.2020302@oracle.com> Message-ID: <4F3509D0.1040108@oracle.com> Looks fine. -- best regards, Anthony On 2/9/2012 10:05 PM, Alexander Zuev wrote: > Hello, > > please review my fix for bug 7144064: [macosx] "Could not find class" > error in JTree's ctor when called in headless mode > > Bug description is > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144064 > > Webrev can be found here: > http://cr.openjdk.java.net/~kizune/7144064/webrev/ > > With best regards, > Alexander Zuev From greg.x.brown at oracle.com Fri Feb 10 04:25:52 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 10 Feb 2012 07:25:52 -0500 Subject: Bundled app launcher changes In-Reply-To: <01238DD0-65D6-42A5-A69F-E2DCE6B93776@oracle.com> References: <01238DD0-65D6-42A5-A69F-E2DCE6B93776@oracle.com> Message-ID: Hi all, Here's an updated version of the sample Ant task Scott sent earlier. The task has been renamed to "bundleapp" rather than "bundlejars", and the element has been replaced with , which is now a file set that can point to either class directories or JAR files: Other changes include: - "destDir" attribute renamed "outputdirectory" - "mainclass" attribute renamed "mainclassname" - element renamed