From anthony.petrov at oracle.com Thu Mar 1 06:44:48 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 01 Mar 2012 18:44:48 +0400 Subject: A list of windows in the dock menu? Message-ID: <4F4F8B60.9090808@oracle.com> Hi Mike, The dock menu for a Java app displays a list of Java top-level windows when run with Apple JDK. However, with 7u4 the list won't show. According to the documentation, app's "open documents" are listed in the menu. Does this mean we have to associate an NSDocument with each instance of AWTWindow class? Or is there any other way to make the list visible in the menu? -- best regards, Anthony From greg.x.brown at oracle.com Thu Mar 1 06:56:25 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Thu, 1 Mar 2012 09:56:25 -0500 Subject: Custom JRE help? Message-ID: Hi all, I meant to respond to this question when it was posted but it fell off my radar: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003228.html I have been working on an Ant task that will co-bundle a JRE with a Java application. It is still in development, but it is usable. The source code is here: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/file/tip/src/macosx/bundle/ Running "ant" will compile the task to appbundler/bin/appbundler-1.0.jar. Put this in your Ant lib directory (e.g. ~/bin/apache-ant-1.8.2/lib). You'll need to declare the task in your build script in order to use it. See the test-hello and test-swingset targets in build.xml for an example. Hope this helps, Greg From michael.x.mcmahon at oracle.com Thu Mar 1 07:07:21 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 01 Mar 2012 15:07:21 +0000 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F4C160D.2030701@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> Message-ID: <4F4F90A9.5060306@oracle.com> Thanks for all the comments. Take it all have been acted on as suggested except as indicated below: ---------------------------- On 27/02/12 23:47, David Holmes wrote: > Hi Michael, > > Partial review of jdk changes. Sorry but it is too large to go through > everything in detail. > > General meta comment: When this stuff went into 7u my biggest > complaint was that it introduced a mass of new platform-specific stuff > in places that weren't otherwise platform specific. That still seems > to be the case. I was really hoping/expecting that these issues could > be resolved before it was merged with JDK8 otherwise they will never > be fixed. Eg jdk/make/common/Rules.gmk, > jdk/make/common/shared/Defs-java.gmk. It seems to me that many of the > specializations could be placed into the platform-specific gmk file(s) > instead of polluting the shared ones. In some case though (eg > Makefiles where we have to change SUBDIR) it indicates we need a > better way to specialize things. > > Ditto for the Java code. I really hate to see platform specific > changes added to Java code that previously was platform independent. > Thanks for all the comments. I think we have removed the most egregious changes to the shared code. In most cases what remains are changes in files that already have (other) platform specific changes. For files that have introduced mac specific changes where there weren't any platform specific code before then I think I agree with Alan, it might be better for the component teams to deal with this in their own time. We certainly have some work to do in networking/core libs for that. Also, build changes may end up being moot anyway, given the up coming build-infra work. I'm making the other changes per your specific comments. ------------- John Rose wrote: > Here's a quick comment (or bug report) on one makefile, make/tools/freetypecheck/Makefile. > Is this only a problem for people who make builds with OPENJDK=true? Thanks for pointing that out. It only affected OPENJDK builds. All the testing I had done so far was just on closed builds. I'm taking the patch mentioned by Henri as it keeps the original build options on other platforms. ---------------- Latest webrev at: http://cr.openjdk.java.net/~michaelm/7113349/jdk8/webrev.4/ Thanks, Michael From scott.kovatch at oracle.com Thu Mar 1 08:22:04 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 1 Mar 2012 08:22:04 -0800 Subject: A list of windows in the dock menu? In-Reply-To: <4F4F8B60.9090808@oracle.com> References: <4F4F8B60.9090808@oracle.com> Message-ID: On Mar 1, 2012, at 6:44 AM, Anthony Petrov wrote: > Hi Mike, > > The dock menu for a Java app displays a list of Java top-level windows when run with Apple JDK. However, with 7u4 the list won't show. > > According to the documentation, app's "open documents" are listed in the menu. Does this mean we have to associate an NSDocument with each instance of AWTWindow class? Or is there any other way to make the list visible in the menu? All you need to do is have a menu named 'Window' in the nib file, and Cocoa will take care of updating it with all of the open windows, and adding it to the dock icon. The window has to have a title, I believe. That's how it used to work, anyway. Aren't we using the shared DefaultApp.nib? -- Scott K. From Alexander.Potochkin at oracle.com Thu Mar 1 08:51:14 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 01 Mar 2012 20:51:14 +0400 Subject: Review request for 7147078: [macosx] Echo char set in TextField doesn't prevent word jumping Message-ID: <4F4FA902.6010904@oracle.com> Hello Please review the following fix: http://cr.openjdk.java.net/~alexp/7147078/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147078 Thanks alexp From swingler at apple.com Thu Mar 1 09:05:21 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 01 Mar 2012 09:05:21 -0800 Subject: A list of windows in the dock menu? In-Reply-To: References: <4F4F8B60.9090808@oracle.com> Message-ID: <485B3A7B-596A-43F9-B71B-8A513DEE0277@apple.com> On Mar 1, 2012, at 8:22 AM, Scott Kovatch wrote: > On Mar 1, 2012, at 6:44 AM, Anthony Petrov wrote: > >> Hi Mike, >> >> The dock menu for a Java app displays a list of Java top-level windows when run with Apple JDK. However, with 7u4 the list won't show. >> >> According to the documentation, app's "open documents" are listed in the menu. Does this mean we have to associate an NSDocument with each instance of AWTWindow class? Or is there any other way to make the list visible in the menu? > > All you need to do is have a menu named 'Window' in the nib file, and Cocoa will take care of updating it with all of the open windows, and adding it to the dock icon. The window has to have a title, I believe. That's how it used to work, anyway. > > Aren't we using the shared DefaultApp.nib? That isn't the problem (well, it's a problem, but not related to the Dock window menu). The default NIB has never had a Window menu because developers often add one themselves, and then there is two. We've lived without that from Java 1.3 to 1.6, and have only gotten a few bugs along the lines of "I can't create the dashes and diamonds in the real Window menu"...so people clearly want to be HIG compliant, but it hasn't seemed to occur to them that we should be doing it for them. I'd love to see a "use the platform Window menu" in the menu bar. As to the issue at hand: I think the problem is that JDK7's top level windows are actually NSPanels, not NSWindows. This is so custom style bits can be applied to them (like titlebar-less, utility or HUD). Further work would need to be done to create an NSWindow subclass and an NSPanel subclass that could be dynamically changed at runtime to support "elevating" a window to a new style (and subsequently loosing it's name in the default Window menu - as it should) - but from Java's perspective, that should amount to a re-parenting operation. You can switch the superclass to NSWindow, but I think that will have unexpected consequences for untitled windows. If it doesn't, that only means you lose the extended styles like utility and HUD, which may be a reasonable tradeoff for getting the window title names in the Dock (but not in the main menu bar). ~Mike From swingler at apple.com Thu Mar 1 09:09:13 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 01 Mar 2012 09:09:13 -0800 Subject: Request for review 7147066: [macosx] FileDialog.getDirectory() returns incorrect directory In-Reply-To: <4F4EB975.4010809@oracle.com> References: <4F4C0771.1030206@oracle.com> <1FBBDD81-A062-4438-BAD8-32516D0EB873@apple.com> <4F4D4EBD.6090506@oracle.com> <2926A5BC-E6C6-46E0-986D-19DE9D0326A1@apple.com> <4F4EB975.4010809@oracle.com> Message-ID: On Feb 29, 2012, at 3:49 PM, Dmitry Cherepanov wrote: > Mike Swingler wrote: >> On Feb 28, 2012, at 2:01 PM, Dmitry Cherepanov wrote: >> >>> Mike Swingler wrote: >>> Here's new webrev - http://cr.openjdk.java.net/~dcherepanov/7147066/webrev.1/ >> >> Looks great. I probably should have also mentioned that you can use NSArray iteration syntax too: >> for (id item in array) { } > > We use the array index within the loop and the loop would look like: > > for (id item in array){ > i = [array indexOfObject:item]; > (*env)->SetObjectArrayElement(env, returnValue, i, filename); > } > > This way (with the indexOfObject:) might seem to be more costly rather than incrementing a variable, isn't it? Of course, I didn't see that. Obviously the "i" is required to inject into the JNI array. You could use the block-based enumeration, but that's probably just more verbose: [array enumerateObjectsUsingBlock:^(id obj, NSUInteger index, BOOL *stop){ ... } Regards, Mike Swingler Apple Inc. From Alexander.Potochkin at oracle.com Thu Mar 1 09:25:53 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 01 Mar 2012 21:25:53 +0400 Subject: [7u4] Request for approval: 7146131: [macosx] When click the show optionpane button,it display partly of dialog and hung until timeout Message-ID: <4F4FB121.8020901@oracle.com> Requesting approval to commit fix for CR 7146131. http://cr.openjdk.java.net/~alexp/7146131/webrev.00/ Reviewed by Anthony Petrov http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003403.html the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146131 This fixes a regression from a previous 7u4 fix Thanks alexp From swingler at apple.com Thu Mar 1 09:31:07 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 01 Mar 2012 09:31:07 -0800 Subject: [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode In-Reply-To: <4F4E3D18.3010109@oracle.com> References: <4F4E3D18.3010109@oracle.com> Message-ID: <2AD6CB77-6932-4715-A21A-E7B786C5D6C6@apple.com> On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7145818 at: > > http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.0/ > > Thanks Mike for the suggestion to use the [NSWindow toggleFullScreen] API. I've tested the fix on both 10.7 and 10.6.8, and it works consistently on both systems. Although the new API is claimed to be supported starting with 10.7 only, it works fine on my 10.6.8 box as well (but prints out a warning about sending an unrecognized selector to an AWTWindow instance.) > > I've also verified that the native resize events contain correct window size, so I removed the machinery that sent synthetic events in the full screen mode. A few points to consider: * To protect against the unrecognized selector problem, you should test if the AWTWindow object -respondsToSelector:@selector(toggleFullScreen) before just calling it. * Also, there is already API that calls -toggleFullScreen in the eAWT classes that you might not be aware of. You should probably test for interactions with that, since apps can opt their window into having a full screen widget icon and independently toggle fullscreen. * In some cases, seeing the menubar is actually desirable, where as in the "exclusive" mode, it's probably not. Perhaps you could consult a client property on the window to determine if the menu bar should be hidden? I like this overall solution, because it uses the native platform concept of full screen which doesn't trap the user from switching spaces like the Java SE 6 implementation did. Regards, Mike Swingler Apple Inc. From scott.kovatch at oracle.com Thu Mar 1 10:12:32 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 1 Mar 2012 10:12:32 -0800 Subject: A list of windows in the dock menu? In-Reply-To: <485B3A7B-596A-43F9-B71B-8A513DEE0277@apple.com> References: <4F4F8B60.9090808@oracle.com> <485B3A7B-596A-43F9-B71B-8A513DEE0277@apple.com> Message-ID: <79687509-8332-43A9-87F2-400FC706C238@oracle.com> On Mar 1, 2012, at 9:05 AM, Mike Swingler wrote: > On Mar 1, 2012, at 8:22 AM, Scott Kovatch wrote: > >> On Mar 1, 2012, at 6:44 AM, Anthony Petrov wrote: >> >>> Hi Mike, >>> >>> The dock menu for a Java app displays a list of Java top-level windows when run with Apple JDK. However, with 7u4 the list won't show. >>> >>> According to the documentation, app's "open documents" are listed in the menu. Does this mean we have to associate an NSDocument with each instance of AWTWindow class? Or is there any other way to make the list visible in the menu? >> >> All you need to do is have a menu named 'Window' in the nib file, and Cocoa will take care of updating it with all of the open windows, and adding it to the dock icon. The window has to have a title, I believe. That's how it used to work, anyway. >> >> Aren't we using the shared DefaultApp.nib? > > That isn't the problem (well, it's a problem, but not related to the Dock window menu). The default NIB has never had a Window menu because developers often add one themselves, and then there is two. We've lived without that from Java 1.3 to 1.6, and have only gotten a few bugs along the lines of "I can't create the dashes and diamonds in the real Window menu"...so people clearly want to be HIG compliant, but it hasn't seemed to occur to them that we should be doing it for them. I'd love to see a "use the platform Window menu" in the menu bar. Double-check DefaultApp.nib. There should be a free-floating NSMenu instance in there with a title of Window (or maybe a name of 'Window', I don't recall.) It's not added to the default menu bar. It's been there since 1.4.2 or so, unless someone took it out after I added it. :-) This isn't about adding a Window menu to the menu bar -- there's no way the AWT can handle that in an HIG-compliant way. > As to the issue at hand: > I think the problem is that JDK7's top level windows are actually NSPanels, not NSWindows. This is so custom style bits can be applied to them (like titlebar-less, utility or HUD). Further work would need to be done to create an NSWindow subclass and an NSPanel subclass that could be dynamically changed at runtime to support "elevating" a window to a new style (and subsequently loosing it's name in the default Window menu - as it should) - but from Java's perspective, that should amount to a re-parenting operation. > You can switch the superclass to NSWindow, but I think that will have unexpected consequences for untitled windows. If it doesn't, that only means you lose the extended styles like utility and HUD, which may be a reasonable tradeoff for getting the window title names in the Dock (but not in the main menu bar). That makes sense. I didn't know we were using NSPanel for all windows, though. I remember this now from when I implemented palette/utility window support in the SWT. I don't think that the SWT supported changing a window's style after it was created, so I could look at the style bits at creation time and make an NSPanel or NSWindow as appropriate. I guess there's a use case for being able to change the window style whenever you want, but I can't imagine when it would be useful to do so. -- Scott K. From artem.ananiev at oracle.com Thu Mar 1 10:32:31 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 01 Mar 2012 10:32:31 -0800 Subject: Review request for 7147078: [macosx] Echo char set in TextField doesn't prevent word jumping In-Reply-To: <4F4FA902.6010904@oracle.com> References: <4F4FA902.6010904@oracle.com> Message-ID: <4F4FC0BF.5040103@oracle.com> Hi, Alex, will regular (without any modifiers) UP/DOWN keys work after the fix? Thanks, Artem On 3/1/2012 8:51 AM, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7147078/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147078 > > Thanks > alexp From anthony.petrov at oracle.com Thu Mar 1 13:10:40 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 02 Mar 2012 01:10:40 +0400 Subject: [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode In-Reply-To: <2AD6CB77-6932-4715-A21A-E7B786C5D6C6@apple.com> References: <4F4E3D18.3010109@oracle.com> <2AD6CB77-6932-4715-A21A-E7B786C5D6C6@apple.com> Message-ID: <4F4FE5D0.8010700@oracle.com> Hi Mike, Thanks for the review! Please see my comments inline. On 3/1/2012 9:31 PM, Mike Swingler wrote: > On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote: >> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.0/ > > A few points to consider: > > * To protect against the unrecognized selector problem, you should test if the AWTWindow object -respondsToSelector:@selector(toggleFullScreen) before just calling it. I'm aware of -respondsToSelector. But I suppose that in that case this simply won't work on 10.6.8 at all. Since a) presently it does work on 10.6.8 for reasons unknown, and b) we officially support 10.7+ only, hence the check makes little sense in theory, and c) from ObjC perspective sending an unknown selector isn't an error, but just a warning, it seems to me that having this warning printed out to the console (which isn't seen by 99% of users anyway) is OK when running on 10.6.8. Plus we get the full screen working there. Isn't it awesome? > * Also, there is already API that calls -toggleFullScreen in the eAWT classes that you might not be aware of. You should probably test for interactions with that, since apps can opt their window into having a full screen widget icon and independently toggle fullscreen. Thanks for pointing this out. I'll rework this code to make sure calls from EAWT update the boolean flag. > * In some cases, seeing the menubar is actually desirable, where as in the "exclusive" mode, it's probably not. Perhaps you could consult a client property on the window to determine if the menu bar should be hidden? Excellent idea! I think that by default the menu should be hidden (for Java spec's sake). But if a client property is set, then the menu would be visible. > I like this overall solution, because it uses the native platform concept of full screen which doesn't trap the user from switching spaces like the Java SE 6 implementation did. We've noticed an interesting detail with -toggleFullScreen when it's used in a multi-screen environment. In that case the window will go full screen on the biggest monitor (actually we have a MacBook with an external monitor connected.) The OS seems to ignore the screen where the window were before entering the FS mode (the main notebook display). Is this OK? Can we force it to use the same screen where the window is originally located for the FS mode? -- best regards, Anthony From swingler at apple.com Thu Mar 1 15:14:33 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 01 Mar 2012 15:14:33 -0800 Subject: [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode In-Reply-To: <4F4FE5D0.8010700@oracle.com> References: <4F4E3D18.3010109@oracle.com> <2AD6CB77-6932-4715-A21A-E7B786C5D6C6@apple.com> <4F4FE5D0.8010700@oracle.com> Message-ID: <69A334C5-89AB-49F4-A2BC-1C2E1C318EEE@apple.com> On Mar 1, 2012, at 1:10 PM, Anthony Petrov wrote: > Hi Mike, > > Thanks for the review! Please see my comments inline. > > On 3/1/2012 9:31 PM, Mike Swingler wrote: >> On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote: >>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.0/ >> A few points to consider: >> * To protect against the unrecognized selector problem, you should test if the AWTWindow object -respondsToSelector:@selector(toggleFullScreen) before just calling it. > > I'm aware of -respondsToSelector. But I suppose that in that case this simply won't work on 10.6.8 at all. Since > > a) presently it does work on 10.6.8 for reasons unknown, and If OpenJDK is built on Snow Leopard, it works fine. I believe the problem is the X11/FreeType versions in Lion are newer, and DYLD won't load libraries linked against older versions. But that is going to start me on my rant about how OpenJDK should bundle it's own FreeType... > b) we officially support 10.7+ only, hence the check makes little sense in theory, and Please think of OpenJDK, not just Oracle's proprietary binaries. There are other users who currently compile on Snow Leopard and this is not an inconvenience, since 10.7-only API is very rare in the JDK. > c) from ObjC perspective sending an unknown selector isn't an error, but just a warning, It is extremely poor form. The -respondsToSelector: check is very cheap, and is very obvious what it is guarding against. > it seems to me that having this warning printed out to the console (which isn't seen by 99% of users anyway) is OK when running on 10.6.8. Plus we get the full screen working there. Isn't it awesome? We know there are developers and users who will be running OpenJDK on Mac OS X 10.6.8, so it is perfectly reasonable to add this as an OS guard. We should not actively damage our ability to run on 10.6 if it's trivially avoidable. >> * Also, there is already API that calls -toggleFullScreen in the eAWT classes that you might not be aware of. You should probably test for interactions with that, since apps can opt their window into having a full screen widget icon and independently toggle fullscreen. > > Thanks for pointing this out. I'll rework this code to make sure calls from EAWT update the boolean flag. Great. >> * In some cases, seeing the menubar is actually desirable, where as in the "exclusive" mode, it's probably not. Perhaps you could consult a client property on the window to determine if the menu bar should be hidden? > > Excellent idea! I think that by default the menu should be hidden (for Java spec's sake). But if a client property is set, then the menu would be visible. Cool. There are several client property readers already on the root AWT window that should be easily extendable. >> I like this overall solution, because it uses the native platform concept of full screen which doesn't trap the user from switching spaces like the Java SE 6 implementation did. > > We've noticed an interesting detail with -toggleFullScreen when it's used in a multi-screen environment. In that case the window will go full screen on the biggest monitor (actually we have a MacBook with an external monitor connected.) The OS seems to ignore the screen where the window were before entering the FS mode (the main notebook display). Is this OK? Can we force it to use the same screen where the window is originally located for the FS mode? It's actually the monitor with the menu bar (the primary, as designated in the Monitor's preference pane). This is an issue with the OS, and should be filed at (it's known, but if you have a specific API suggestion to target a screen, or some sort of automatic behavior in mind, it would be good to provide specific suggestions in the bug). Thanks, Mike Swingler Apple Inc. From alexander.zuev at oracle.com Thu Mar 1 15:23:29 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 2 Mar 2012 03:23:29 +0400 Subject: [7u4] Review request for 7148281: [macosx] JTabbedPane tabs with HTML text do not render correctly In-Reply-To: <4F4B8149.8000307@oracle.com> References: <4F4B8149.8000307@oracle.com> Message-ID: <029B44A5-A8BA-491F-BD21-4F83FB2B30D6@oracle.com> Alexander, In the comments above the condition you've changed noted that this code is for non-scrolling tabs only. Could you please check that when tab scrolling is set to on there's no problem with HTML labels and custom component painter? With best regards, Alexander Zuev 27.02.2012, ? 17:12, Alexander Scherbatiy ???????(?): > > Hello, > > Please review the fix for bug 7148281: [macosx] JTabbedPane tabs with HTML text do not render correctly > > Bug description is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7148281 > > Webrev can be found at: http://cr.openjdk.java.net/~alexsch/7148281/webrev.00/ > > In case if a component is set for a tab title there is no need to paint the tab title one more time. > > Thanks, > Alexandr. > From john.r.rose at oracle.com Thu Mar 1 18:42:10 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 1 Mar 2012 18:42:10 -0800 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F4FF0A7.2090505@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> Message-ID: <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> On Mar 1, 2012, at 1:56 PM, Stuart Marks wrote: > cd bsd_amd64_compiler2/product && ./test_gamma > Error occurred during initialization of VM > java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:432) > at java.lang.System.initProperties(Native Method) > at java.lang.System.initializeSystemClass(System.java:1115) A couple of data points: The NPE is because libjava.dylib is handing a null value to Hashtable, for the key "user.language", in System.c. This happens also for me, using a Java 7 libjava.dylib. The bug is oddly sensitive to the setting of DYLD_LIBRARY_PATH, and something about the test_gamma script makes it worse. See demo below. The bug seems to be in the test_gamma script, but I haven't figured out how it works. ? John -------- cd build/macosx-amd64/hotspot/outputdir/bsd_amd64_compiler2/product -------- DYLD_PRINT_LIBRARIES=1 DYLD_LIBRARY_PATH=.:/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib: ./gamma -Xbootclasspath/p:$METH_BUILD/classes -Xbatch -showversion Queens 2>&1 | egrep 'jre/lib|92' dyld: loaded: /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libverify.dylib dyld: loaded: /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libjava.dylib dyld: loaded: /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libzip.dylib dyld: loaded: /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libJPEG.dylib -------- DYLD_PRINT_LIBRARIES=1 DYLD_LIBRARY_PATH=.: ./gamma -Xbootclasspath/p:$METH_BUILD/classes -Xbatch -showversion Queens 2>&1 | egrep 'jre/lib|92' dyld: loaded: /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libverify.dylib dyld: loaded: /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libjava.dylib dyld: loaded: /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libzip.dylib 92. A8 B4 C1 D3 E6 F2 G7 H5 -------- From michael.x.mcmahon at oracle.com Fri Mar 2 01:28:44 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 02 Mar 2012 09:28:44 +0000 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> Message-ID: <4F5092CC.1070805@oracle.com> I can't reproduce it. It must be something related to the boot JDK you are using. Is it a complete jdk7 image? I do get a (different) error if I set DYLD_LIBRARY_PATH in the environment Are you actually setting this in your environment? I notice the sanity check isn't looking for this, which it should on Mac. - Michael On 02/03/12 02:42, John Rose wrote: > On Mar 1, 2012, at 1:56 PM, Stuart Marks wrote: > >> cd bsd_amd64_compiler2/product && ./test_gamma >> Error occurred during initialization of VM >> java.lang.NullPointerException >> at java.util.Hashtable.put(Hashtable.java:432) >> at java.lang.System.initProperties(Native Method) >> at java.lang.System.initializeSystemClass(System.java:1115) > > A couple of data points: > > The NPE is because libjava.dylib is handing a null value to Hashtable, > for the key "user.language", in System.c. > > This happens also for me, using a Java 7 libjava.dylib. The bug is > oddly sensitive to the setting of DYLD_LIBRARY_PATH, and something > about the test_gamma script makes it worse. See demo below. The bug > seems to be in the test_gamma script, but I haven't figured out how it > works. > > ? John > > -------- > cd build/macosx-amd64/hotspot/outputdir/bsd_amd64_compiler2/product > -------- > DYLD_PRINT_LIBRARIES=1 > DYLD_LIBRARY_PATH=.:/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib: > ./gamma -Xbootclasspath/p:$METH_BUILD/classes -Xbatch -showversion > Queens 2>&1 | egrep 'jre/lib|92' > dyld: loaded: > /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libverify.dylib > dyld: loaded: > /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libjava.dylib > dyld: loaded: > /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libzip.dylib > dyld: loaded: > /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libJPEG.dylib > -------- > DYLD_PRINT_LIBRARIES=1 DYLD_LIBRARY_PATH=.: ./gamma > -Xbootclasspath/p:$METH_BUILD/classes -Xbatch -showversion Queens 2>&1 > | egrep 'jre/lib|92' > dyld: loaded: > /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libverify.dylib > dyld: loaded: > /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libjava.dylib > dyld: loaded: > /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/jre/lib/libzip.dylib > 92. A8 B4 C1 D3 E6 F2 G7 H5 > -------- > From dmitry.cherepanov at oracle.com Thu Mar 1 14:54:35 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 02 Mar 2012 02:54:35 +0400 Subject: Request for review 7147066: [macosx] FileDialog.getDirectory() returns incorrect directory In-Reply-To: References: <4F4C0771.1030206@oracle.com> <1FBBDD81-A062-4438-BAD8-32516D0EB873@apple.com> <4F4D4EBD.6090506@oracle.com> <2926A5BC-E6C6-46E0-986D-19DE9D0326A1@apple.com> <4F4EB975.4010809@oracle.com> Message-ID: <4F4FFE2B.6090407@oracle.com> Mike Swingler wrote: > On Feb 29, 2012, at 3:49 PM, Dmitry Cherepanov wrote: > > >> Mike Swingler wrote: >> >>> On Feb 28, 2012, at 2:01 PM, Dmitry Cherepanov wrote: >>> >>> >>>> Mike Swingler wrote: >>>> Here's new webrev - http://cr.openjdk.java.net/~dcherepanov/7147066/webrev.1/ >>>> >>> Looks great. I probably should have also mentioned that you can use NSArray iteration syntax too: >>> for (id item in array) { } >>> >> We use the array index within the loop and the loop would look like: >> >> for (id item in array){ >> i = [array indexOfObject:item]; >> (*env)->SetObjectArrayElement(env, returnValue, i, filename); >> } >> >> This way (with the indexOfObject:) might seem to be more costly rather than incrementing a variable, isn't it? >> > > Of course, I didn't see that. Obviously the "i" is required to inject into the JNI array. > > You could use the block-based enumeration, but that's probably just more verbose: > [array enumerateObjectsUsingBlock:^(id obj, NSUInteger index, BOOL *stop){ ... } > Thanks for the suggestion. Here's the next version - http://cr.openjdk.java.net/~dcherepanov/7147066/webrev.2/ Thanks, Dmitry From alexandr.scherbatiy at oracle.com Fri Mar 2 03:14:58 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 02 Mar 2012 15:14:58 +0400 Subject: [7u4] Review request for 7148281: [macosx] JTabbedPane tabs with HTML text do not render correctly In-Reply-To: <029B44A5-A8BA-491F-BD21-4F83FB2B30D6@oracle.com> References: <4F4B8149.8000307@oracle.com> <029B44A5-A8BA-491F-BD21-4F83FB2B30D6@oracle.com> Message-ID: <4F50ABB2.3000005@oracle.com> On 3/2/2012 3:23 AM, Alexander Zuev wrote: > Alexander, > > In the comments above the condition you've changed noted that this code is for non-scrolling tabs only. Could you please check that when tab scrolling is set to on there's no problem with HTML labels and custom component painter? The WRAP_TAB_LAYOUT policy is not applicable on Aqua L&F so only SCROLL_TAB_LAYOUT is used. I tried the sample where a custom component is set with the plain and html titles. This works in both cases when all tabs are shown on the frame and when a frame size is small so right and left scroll arrows are shown. Thanks, Alexandr. > With best regards, > Alexander Zuev > > 27.02.2012, ? 17:12, Alexander Scherbatiy ???????(?): > >> Hello, >> >> Please review the fix for bug 7148281: [macosx] JTabbedPane tabs with HTML text do not render correctly >> >> Bug description is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7148281 >> >> Webrev can be found at: http://cr.openjdk.java.net/~alexsch/7148281/webrev.00/ >> >> In case if a component is set for a tab title there is no need to paint the tab title one more time. >> >> Thanks, >> Alexandr. >> From Alexander.Potochkin at oracle.com Fri Mar 2 03:36:30 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Fri, 02 Mar 2012 15:36:30 +0400 Subject: Review request for 7147078: [macosx] Echo char set in TextField doesn't prevent word jumping In-Reply-To: <4F4FC0BF.5040103@oracle.com> References: <4F4FA902.6010904@oracle.com> <4F4FC0BF.5040103@oracle.com> Message-ID: <4F50B0BE.903@oracle.com> Hello Artem > Hi, Alex, > > will regular (without any modifiers) UP/DOWN keys work after the fix? Yes The rest of the key bindings are not disabled, see the whole list in com.apple.laf.AquaKeyBindings.commonTextEditorBingings By the way, I sent the fixed build to Yura, he is going to test it today. Thanks alexp > > Thanks, > > Artem > > On 3/1/2012 8:51 AM, Alexander Potochkin wrote: >> Hello >> >> Please review the following fix: >> http://cr.openjdk.java.net/~alexp/7147078/webrev.00/ >> >> the bug's description is here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147078 >> >> Thanks >> alexp From alexander.zuev at oracle.com Fri Mar 2 05:54:10 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 02 Mar 2012 16:54:10 +0300 Subject: [7u4] Review request for 7148281: [macosx] JTabbedPane tabs with HTML text do not render correctly In-Reply-To: <4F50ABB2.3000005@oracle.com> References: <4F4B8149.8000307@oracle.com> <029B44A5-A8BA-491F-BD21-4F83FB2B30D6@oracle.com> <4F50ABB2.3000005@oracle.com> Message-ID: <4F50D102.5000101@oracle.com> Ok then. Fix looks fine to me. On 3/2/12 14:14, Alexander Scherbatiy wrote: > On 3/2/2012 3:23 AM, Alexander Zuev wrote: >> Alexander, >> >> In the comments above the condition you've changed noted that this >> code is for non-scrolling tabs only. Could you please check that when >> tab scrolling is set to on there's no problem with HTML labels and >> custom component painter? > The WRAP_TAB_LAYOUT policy is not applicable on Aqua L&F so only > SCROLL_TAB_LAYOUT is used. > > I tried the sample where a custom component is set with the plain > and html titles. This works in both cases when all tabs are shown on > the frame and when a frame size is small so right and left scroll > arrows are shown. > > Thanks, > Alexandr. > >> With best regards, >> Alexander Zuev >> >> 27.02.2012, ? 17:12, Alexander >> Scherbatiy ???????(?): >> >>> Hello, >>> >>> Please review the fix for bug 7148281: [macosx] JTabbedPane tabs >>> with HTML text do not render correctly >>> >>> Bug description is >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7148281 >>> >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~alexsch/7148281/webrev.00/ >>> >>> In case if a component is set for a tab title there is no need to >>> paint the tab title one more time. >>> >>> Thanks, >>> Alexandr. >>> > From anthony.petrov at oracle.com Fri Mar 2 06:10:30 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 02 Mar 2012 18:10:30 +0400 Subject: [7u4] Review request for 7150516: [macosx] appletviewer shouldn't link against libX11 on the Mac Message-ID: <4F50D4D6.6010008@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7150516 at: http://cr.openjdk.java.net/~anthony/x-22-appletviewerLibX11-7150516.0/ -- best regards, Anthony From anthony.petrov at oracle.com Fri Mar 2 06:20:39 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 02 Mar 2012 18:20:39 +0400 Subject: [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode In-Reply-To: <69A334C5-89AB-49F4-A2BC-1C2E1C318EEE@apple.com> References: <4F4E3D18.3010109@oracle.com> <2AD6CB77-6932-4715-A21A-E7B786C5D6C6@apple.com> <4F4FE5D0.8010700@oracle.com> <69A334C5-89AB-49F4-A2BC-1C2E1C318EEE@apple.com> Message-ID: <4F50D737.40405@oracle.com> Thanks for your suggestions Mike. Here's the latest version of the fix: http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.1/ -- best regards, Anthony On 3/2/2012 3:14 AM, Mike Swingler wrote: > On Mar 1, 2012, at 1:10 PM, Anthony Petrov wrote: > >> Hi Mike, >> >> Thanks for the review! Please see my comments inline. >> >> On 3/1/2012 9:31 PM, Mike Swingler wrote: >>> On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote: >>>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.0/ >>> A few points to consider: >>> * To protect against the unrecognized selector problem, you should test if the AWTWindow object -respondsToSelector:@selector(toggleFullScreen) before just calling it. >> I'm aware of -respondsToSelector. But I suppose that in that case this simply won't work on 10.6.8 at all. Since >> >> a) presently it does work on 10.6.8 for reasons unknown, and > > If OpenJDK is built on Snow Leopard, it works fine. I believe the problem is the X11/FreeType versions in Lion are newer, and DYLD won't load libraries linked against older versions. But that is going to start me on my rant about how OpenJDK should bundle it's own FreeType... > >> b) we officially support 10.7+ only, hence the check makes little sense in theory, and > > Please think of OpenJDK, not just Oracle's proprietary binaries. There are other users who currently compile on Snow Leopard and this is not an inconvenience, since 10.7-only API is very rare in the JDK. > >> c) from ObjC perspective sending an unknown selector isn't an error, but just a warning, > > It is extremely poor form. The -respondsToSelector: check is very cheap, and is very obvious what it is guarding against. > >> it seems to me that having this warning printed out to the console (which isn't seen by 99% of users anyway) is OK when running on 10.6.8. Plus we get the full screen working there. Isn't it awesome? > > We know there are developers and users who will be running OpenJDK on Mac OS X 10.6.8, so it is perfectly reasonable to add this as an OS guard. We should not actively damage our ability to run on 10.6 if it's trivially avoidable. > >>> * Also, there is already API that calls -toggleFullScreen in the eAWT classes that you might not be aware of. You should probably test for interactions with that, since apps can opt their window into having a full screen widget icon and independently toggle fullscreen. >> Thanks for pointing this out. I'll rework this code to make sure calls from EAWT update the boolean flag. > > Great. > >>> * In some cases, seeing the menubar is actually desirable, where as in the "exclusive" mode, it's probably not. Perhaps you could consult a client property on the window to determine if the menu bar should be hidden? >> Excellent idea! I think that by default the menu should be hidden (for Java spec's sake). But if a client property is set, then the menu would be visible. > > Cool. There are several client property readers already on the root AWT window that should be easily extendable. > >>> I like this overall solution, because it uses the native platform concept of full screen which doesn't trap the user from switching spaces like the Java SE 6 implementation did. >> We've noticed an interesting detail with -toggleFullScreen when it's used in a multi-screen environment. In that case the window will go full screen on the biggest monitor (actually we have a MacBook with an external monitor connected.) The OS seems to ignore the screen where the window were before entering the FS mode (the main notebook display). Is this OK? Can we force it to use the same screen where the window is originally located for the FS mode? > > It's actually the monitor with the menu bar (the primary, as designated in the Monitor's preference pane). > > This is an issue with the OS, and should be filed at (it's known, but if you have a specific API suggestion to target a screen, or some sort of automatic behavior in mind, it would be good to provide specific suggestions in the bug). > > Thanks, > Mike Swingler > Apple Inc. > From anthony.petrov at oracle.com Fri Mar 2 06:42:04 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 02 Mar 2012 18:42:04 +0400 Subject: [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode In-Reply-To: <4F50D737.40405@oracle.com> References: <4F4E3D18.3010109@oracle.com> <2AD6CB77-6932-4715-A21A-E7B786C5D6C6@apple.com> <4F4FE5D0.8010700@oracle.com> <69A334C5-89AB-49F4-A2BC-1C2E1C318EEE@apple.com> <4F50D737.40405@oracle.com> Message-ID: <4F50DC3C.7050803@oracle.com> A tiny typo has been fixed, a new webrev is at: http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.2/ -- best regards, Anthony On 3/2/2012 6:20 PM, Anthony Petrov wrote: > Thanks for your suggestions Mike. Here's the latest version of the fix: > > http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.1/ > > -- > best regards, > Anthony > > On 3/2/2012 3:14 AM, Mike Swingler wrote: >> On Mar 1, 2012, at 1:10 PM, Anthony Petrov wrote: >> >>> Hi Mike, >>> >>> Thanks for the review! Please see my comments inline. >>> >>> On 3/1/2012 9:31 PM, Mike Swingler wrote: >>>> On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote: >>>>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.0/ >>>> A few points to consider: >>>> * To protect against the unrecognized selector problem, you should >>>> test if the AWTWindow object >>>> -respondsToSelector:@selector(toggleFullScreen) before just calling it. >>> I'm aware of -respondsToSelector. But I suppose that in that case >>> this simply won't work on 10.6.8 at all. Since >>> >>> a) presently it does work on 10.6.8 for reasons unknown, and >> >> If OpenJDK is built on Snow Leopard, it works fine. I believe the >> problem is the X11/FreeType versions in Lion are newer, and DYLD won't >> load libraries linked against older versions. But that is going to >> start me on my rant about how OpenJDK should bundle it's own FreeType... >> >>> b) we officially support 10.7+ only, hence the check makes little >>> sense in theory, and >> >> Please think of OpenJDK, not just Oracle's proprietary binaries. There >> are other users who currently compile on Snow Leopard and this is not >> an inconvenience, since 10.7-only API is very rare in the JDK. >> >>> c) from ObjC perspective sending an unknown selector isn't an error, >>> but just a warning, >> >> It is extremely poor form. The -respondsToSelector: check is very >> cheap, and is very obvious what it is guarding against. >> >>> it seems to me that having this warning printed out to the console >>> (which isn't seen by 99% of users anyway) is OK when running on >>> 10.6.8. Plus we get the full screen working there. Isn't it awesome? >> >> We know there are developers and users who will be running OpenJDK on >> Mac OS X 10.6.8, so it is perfectly reasonable to add this as an OS >> guard. We should not actively damage our ability to run on 10.6 if >> it's trivially avoidable. >> >>>> * Also, there is already API that calls -toggleFullScreen in the >>>> eAWT classes that you might not be aware of. You should probably >>>> test for interactions with that, since apps can opt their window >>>> into having a full screen widget icon and independently toggle >>>> fullscreen. >>> Thanks for pointing this out. I'll rework this code to make sure >>> calls from EAWT update the boolean flag. >> >> Great. >> >>>> * In some cases, seeing the menubar is actually desirable, where as >>>> in the "exclusive" mode, it's probably not. Perhaps you could >>>> consult a client property on the window to determine if the menu bar >>>> should be hidden? >>> Excellent idea! I think that by default the menu should be hidden >>> (for Java spec's sake). But if a client property is set, then the >>> menu would be visible. >> >> Cool. There are several client property readers already on the root >> AWT window that should be easily extendable. >> >>>> I like this overall solution, because it uses the native platform >>>> concept of full screen which doesn't trap the user from switching >>>> spaces like the Java SE 6 implementation did. >>> We've noticed an interesting detail with -toggleFullScreen when it's >>> used in a multi-screen environment. In that case the window will go >>> full screen on the biggest monitor (actually we have a MacBook with >>> an external monitor connected.) The OS seems to ignore the screen >>> where the window were before entering the FS mode (the main notebook >>> display). Is this OK? Can we force it to use the same screen where >>> the window is originally located for the FS mode? >> >> It's actually the monitor with the menu bar (the primary, as >> designated in the Monitor's preference pane). >> >> This is an issue with the OS, and should be filed at >> (it's known, but if you have a specific >> API suggestion to target a screen, or some sort of automatic behavior >> in mind, it would be good to provide specific suggestions in the bug). >> >> Thanks, >> Mike Swingler >> Apple Inc. >> From anthony.petrov at oracle.com Fri Mar 2 07:30:57 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 02 Mar 2012 19:30:57 +0400 Subject: A list of windows in the dock menu? In-Reply-To: <79687509-8332-43A9-87F2-400FC706C238@oracle.com> References: <4F4F8B60.9090808@oracle.com> <485B3A7B-596A-43F9-B71B-8A513DEE0277@apple.com> <79687509-8332-43A9-87F2-400FC706C238@oracle.com> Message-ID: <4F50E7B1.6050603@oracle.com> Mike, Scott, thanks for your input! I'll see what we can do to support this feature. -- best regards, Anthony On 3/1/2012 10:12 PM, Scott Kovatch wrote: > On Mar 1, 2012, at 9:05 AM, Mike Swingler wrote: > >> On Mar 1, 2012, at 8:22 AM, Scott Kovatch wrote: >> >>> On Mar 1, 2012, at 6:44 AM, Anthony Petrov wrote: >>> >>>> Hi Mike, >>>> >>>> The dock menu for a Java app displays a list of Java top-level windows when run with Apple JDK. However, with 7u4 the list won't show. >>>> >>>> According to the documentation, app's "open documents" are listed in the menu. Does this mean we have to associate an NSDocument with each instance of AWTWindow class? Or is there any other way to make the list visible in the menu? >>> All you need to do is have a menu named 'Window' in the nib file, and Cocoa will take care of updating it with all of the open windows, and adding it to the dock icon. The window has to have a title, I believe. That's how it used to work, anyway. >>> >>> Aren't we using the shared DefaultApp.nib? >> That isn't the problem (well, it's a problem, but not related to the Dock window menu). The default NIB has never had a Window menu because developers often add one themselves, and then there is two. We've lived without that from Java 1.3 to 1.6, and have only gotten a few bugs along the lines of "I can't create the dashes and diamonds in the real Window menu"...so people clearly want to be HIG compliant, but it hasn't seemed to occur to them that we should be doing it for them. I'd love to see a "use the platform Window menu" in the menu bar. > > Double-check DefaultApp.nib. There should be a free-floating NSMenu instance in there with a title of Window (or maybe a name of 'Window', I don't recall.) It's not added to the default menu bar. It's been there since 1.4.2 or so, unless someone took it out after I added it. :-) > > This isn't about adding a Window menu to the menu bar -- there's no way the AWT can handle that in an HIG-compliant way. > >> As to the issue at hand: >> I think the problem is that JDK7's top level windows are actually NSPanels, not NSWindows. This is so custom style bits can be applied to them (like titlebar-less, utility or HUD). Further work would need to be done to create an NSWindow subclass and an NSPanel subclass that could be dynamically changed at runtime to support "elevating" a window to a new style (and subsequently loosing it's name in the default Window menu - as it should) - but from Java's perspective, that should amount to a re-parenting operation. > >> You can switch the superclass to NSWindow, but I think that will have unexpected consequences for untitled windows. If it doesn't, that only means you lose the extended styles like utility and HUD, which may be a reasonable tradeoff for getting the window title names in the Dock (but not in the main menu bar). > > That makes sense. I didn't know we were using NSPanel for all windows, though. > > I remember this now from when I implemented palette/utility window support in the SWT. I don't think that the SWT supported changing a window's style after it was created, so I could look at the style bits at creation time and make an NSPanel or NSWindow as appropriate. I guess there's a use case for being able to change the window style whenever you want, but I can't imagine when it would be useful to do so. > > -- Scott K. > From swingler at apple.com Fri Mar 2 07:37:32 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 02 Mar 2012 07:37:32 -0800 Subject: [7u4] Review request for 7150516: [macosx] appletviewer shouldn't link against libX11 on the Mac In-Reply-To: <4F50D4D6.6010008@oracle.com> References: <4F50D4D6.6010008@oracle.com> Message-ID: <01A7D38A-1C99-4626-ABA4-358F5A9A25BA@apple.com> On Mar 2, 2012, at 6:10 AM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7150516 at: > > http://cr.openjdk.java.net/~anthony/x-22-appletviewerLibX11-7150516.0/ I can't see the bug, but the change looks logical to me. Regards, Mike Swingler Apple Inc. From swingler at apple.com Fri Mar 2 07:40:20 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 02 Mar 2012 07:40:20 -0800 Subject: Request for review 7147066: [macosx] FileDialog.getDirectory() returns incorrect directory In-Reply-To: <4F4FFE2B.6090407@oracle.com> References: <4F4C0771.1030206@oracle.com> <1FBBDD81-A062-4438-BAD8-32516D0EB873@apple.com> <4F4D4EBD.6090506@oracle.com> <2926A5BC-E6C6-46E0-986D-19DE9D0326A1@apple.com> <4F4EB975.4010809@oracle.com> <4F4FFE2B.6090407@oracle.com> Message-ID: <92F61932-9B27-4F37-AAAA-27ED6BA5EFBC@apple.com> On Mar 1, 2012, at 2:54 PM, Dmitry Cherepanov wrote: > Mike Swingler wrote: > >> On Feb 29, 2012, at 3:49 PM, Dmitry Cherepanov wrote: >> >>> Mike Swingler wrote: >>> >>>> On Feb 28, 2012, at 2:01 PM, Dmitry Cherepanov wrote: >>>> >>>>> Mike Swingler wrote: >>>>> Here's new webrev - http://cr.openjdk.java.net/~dcherepanov/7147066/webrev.1/ >>>>> >>>> Looks great. I probably should have also mentioned that you can use NSArray iteration syntax too: >>>> for (id item in array) { } >>>> >>> We use the array index within the loop and the loop would look like: >>> >>> for (id item in array){ >>> i = [array indexOfObject:item]; >>> (*env)->SetObjectArrayElement(env, returnValue, i, filename); >>> } >>> >>> This way (with the indexOfObject:) might seem to be more costly rather than incrementing a variable, isn't it? >> >> Of course, I didn't see that. Obviously the "i" is required to inject into the JNI array. >> >> You could use the block-based enumeration, but that's probably just more verbose: >> [array enumerateObjectsUsingBlock:^(id obj, NSUInteger index, BOOL *stop){ ... } > > Thanks for the suggestion. > Here's the next version - http://cr.openjdk.java.net/~dcherepanov/7147066/webrev.2/ Looks great. :-) Mike Swingler Apple Inc. From anthony.petrov at oracle.com Fri Mar 2 07:42:06 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 02 Mar 2012 19:42:06 +0400 Subject: [7u4] Review request for 7150516: [macosx] appletviewer shouldn't link against libX11 on the Mac In-Reply-To: <01A7D38A-1C99-4626-ABA4-358F5A9A25BA@apple.com> References: <4F50D4D6.6010008@oracle.com> <01A7D38A-1C99-4626-ABA4-358F5A9A25BA@apple.com> Message-ID: <4F50EA4E.4050300@oracle.com> On 3/2/2012 7:37 PM, Mike Swingler wrote: >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7150516 at: >> >> http://cr.openjdk.java.net/~anthony/x-22-appletviewerLibX11-7150516.0/ > > I can't see the bug, but the change looks logical to me. It usually takes a day for a new bug to show up on the web-site. I'm copying its Description below. Thanks for the review! The description: > I noticed a problem with the jdk 7u4 build for OS X - bin/appletviewer > doesn't run. When I try to launch it, I get: > > dyld: Library not loaded: /usr/X11/lib/libX11.6.dylib > Referenced from: > /Library/Java/JavaVirtualMachines/jdk1.7.0_04/demo/jfx/Java2D/../../../bin/appletviewer > > Reason: Incompatible library version: appletviewer requires version > 10.0.0 or later, but libX11.6.dylib provides version 9.0.0 > Trace/BPT trap > > bin/appletviewer worked fine in 7u4b228. > > Running the appletviewer class directly ('java sun.applet.appletviewer') > does seem to work. > > I saw it mentioned in MACOSX_PORT-524 that the X11 toolkit is not the > default in JDK7 on Mac. Perhaps the appletviewer executable is > requesting the X11 toolkit? -- best regards, Anthony From anthony.petrov at oracle.com Fri Mar 2 07:48:29 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 02 Mar 2012 19:48:29 +0400 Subject: [7u4] Request for phase 2 approval for CR 7150516 - [macosx] appletviewer shouldn't link against libX11 on the Mac Message-ID: <4F50EBCD.4050608@oracle.com> Bug: http://bugs.sun.com/view_bug.do?bug_id=7150516 Webrev: http://cr.openjdk.java.net/~anthony/x-22-appletviewerLibX11-7150516.0/ Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003457.html Reviewer: Mike Swingler (swingler) Rationale for inclusion in 7u4: X11 is an optional package on Mac OS X. Since OpenJDK on the Mac uses Cocoa for GUI, the tools shouldn't link against an unused GUI library. With this fix we eliminate the dependency on the libX11 library. -- best regards, Anthony From swingler at apple.com Fri Mar 2 09:13:50 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 02 Mar 2012 09:13:50 -0800 Subject: [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode In-Reply-To: <4F50DC3C.7050803@oracle.com> References: <4F4E3D18.3010109@oracle.com> <2AD6CB77-6932-4715-A21A-E7B786C5D6C6@apple.com> <4F4FE5D0.8010700@oracle.com> <69A334C5-89AB-49F4-A2BC-1C2E1C318EEE@apple.com> <4F50D737.40405@oracle.com> <4F50DC3C.7050803@oracle.com> Message-ID: There are a few points here: * If the user marks the window as "fullscreenable" using the eAWT API, that puts a widget in the upper right corner of the window which allows the user to toggle it into full screen themselves. * When in full screen (using AWT or eAWT API), the user should be able to click the blue exit fullscreen button in the menu bar at any time (if they entered into full screen themselves) * Generally, it is undesirable for the user to be stuck in a state where they cannot return to the desktop. With the current diff, the isFullScreenMode boolean in Java will definitely be out of sync if the user initiates either of these actions. Instead of trying to keep the knowledge of the full screen state in Java behind a lock, I think you probably need query native to see if the window is in the fullscreen state. I've used the following testcase to test the existing eAWT fullscreen API, and I think you'll find it's easy to get into a state where the user is stuck in windowed mode without a menu bar, and that sometimes the user is locked out from returning to windowed mode when they clicked on the window widget. After trying out your diff, I actually found it quite frustrating that the menubar was suppressed and I *had* to use the four-finger swipe gesture to get back to my desktop. How would you feel about just dropping the whole menubar hiding stuff? Since the menu bar is auto-hidden by default, users don't get to it unless they push up to the top of the screen anyway. Try out this test case, and be sure to use the window widget, as well as the button that programmatically fires the eAWT API. import java.awt.*; import java.awt.event.ActionEvent; import javax.swing.*; import com.apple.eawt.AppEvent.FullScreenEvent; import com.apple.eawt.*; public class FullScreenTest { public static void main(String args[]) { SwingUtilities.invokeLater(new Runnable() { public void run() { createFrame(); } }); } static void createFrame() { JFrame frame = new JFrame(); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setTitle(System.getProperty("java.version")); Container contentPane = frame.getContentPane(); contentPane.setLayout(new BorderLayout()); contentPane.add(createPanel(), BorderLayout.CENTER); // turns on the fullscreen window titlebar widget in the upper right corner FullScreenUtilities.setWindowCanFullScreen(frame, true); // useful for re-adjusting content or hiding/showing palette windows FullScreenUtilities.addFullScreenListenerTo(frame, new FullScreenAdapter() { public void windowExitingFullScreen(FullScreenEvent e) { System.out.println("exiting"); } public void windowExitedFullScreen(FullScreenEvent e) { System.out.println("exited"); } public void windowEnteringFullScreen(FullScreenEvent e) { System.out.println("entering"); } public void windowEnteredFullScreen(FullScreenEvent e) { System.out.println("entered"); } }); frame.pack(); frame.setVisible(true); } static Component createPanel() { final JPanel panel = new JPanel(new FlowLayout()); // toggle FullScreen from a toolbar button panel.add(new JButton(new AbstractAction("Full Screen Me!") { public void actionPerformed(ActionEvent e) { Application.getApplication().requestToggleFullScreen( (Window)panel.getTopLevelAncestor()); } })); return panel; } } Regards, Mike Swingler Apple Inc. On Mar 2, 2012, at 6:42 AM, Anthony Petrov wrote: > A tiny typo has been fixed, a new webrev is at: > > http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.2/ > > -- > best regards, > Anthony > > On 3/2/2012 6:20 PM, Anthony Petrov wrote: >> Thanks for your suggestions Mike. Here's the latest version of the fix: >> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.1/ >> -- >> best regards, >> Anthony >> On 3/2/2012 3:14 AM, Mike Swingler wrote: >>> On Mar 1, 2012, at 1:10 PM, Anthony Petrov wrote: >>> >>>> Hi Mike, >>>> >>>> Thanks for the review! Please see my comments inline. >>>> >>>> On 3/1/2012 9:31 PM, Mike Swingler wrote: >>>>> On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote: >>>>>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.0/ >>>>> A few points to consider: >>>>> * To protect against the unrecognized selector problem, you should test if the AWTWindow object -respondsToSelector:@selector(toggleFullScreen) before just calling it. >>>> I'm aware of -respondsToSelector. But I suppose that in that case this simply won't work on 10.6.8 at all. Since >>>> >>>> a) presently it does work on 10.6.8 for reasons unknown, and >>> >>> If OpenJDK is built on Snow Leopard, it works fine. I believe the problem is the X11/FreeType versions in Lion are newer, and DYLD won't load libraries linked against older versions. But that is going to start me on my rant about how OpenJDK should bundle it's own FreeType... >>> >>>> b) we officially support 10.7+ only, hence the check makes little sense in theory, and >>> >>> Please think of OpenJDK, not just Oracle's proprietary binaries. There are other users who currently compile on Snow Leopard and this is not an inconvenience, since 10.7-only API is very rare in the JDK. >>> >>>> c) from ObjC perspective sending an unknown selector isn't an error, but just a warning, >>> >>> It is extremely poor form. The -respondsToSelector: check is very cheap, and is very obvious what it is guarding against. >>> >>>> it seems to me that having this warning printed out to the console (which isn't seen by 99% of users anyway) is OK when running on 10.6.8. Plus we get the full screen working there. Isn't it awesome? >>> >>> We know there are developers and users who will be running OpenJDK on Mac OS X 10.6.8, so it is perfectly reasonable to add this as an OS guard. We should not actively damage our ability to run on 10.6 if it's trivially avoidable. >>> >>>>> * Also, there is already API that calls -toggleFullScreen in the eAWT classes that you might not be aware of. You should probably test for interactions with that, since apps can opt their window into having a full screen widget icon and independently toggle fullscreen. >>>> Thanks for pointing this out. I'll rework this code to make sure calls from EAWT update the boolean flag. >>> >>> Great. >>> >>>>> * In some cases, seeing the menubar is actually desirable, where as in the "exclusive" mode, it's probably not. Perhaps you could consult a client property on the window to determine if the menu bar should be hidden? >>>> Excellent idea! I think that by default the menu should be hidden (for Java spec's sake). But if a client property is set, then the menu would be visible. >>> >>> Cool. There are several client property readers already on the root AWT window that should be easily extendable. >>> >>>>> I like this overall solution, because it uses the native platform concept of full screen which doesn't trap the user from switching spaces like the Java SE 6 implementation did. >>>> We've noticed an interesting detail with -toggleFullScreen when it's used in a multi-screen environment. In that case the window will go full screen on the biggest monitor (actually we have a MacBook with an external monitor connected.) The OS seems to ignore the screen where the window were before entering the FS mode (the main notebook display). Is this OK? Can we force it to use the same screen where the window is originally located for the FS mode? >>> >>> It's actually the monitor with the menu bar (the primary, as designated in the Monitor's preference pane). >>> >>> This is an issue with the OS, and should be filed at (it's known, but if you have a specific API suggestion to target a screen, or some sort of automatic behavior in mind, it would be good to provide specific suggestions in the bug). From artem.ananiev at oracle.com Fri Mar 2 09:51:53 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 02 Mar 2012 09:51:53 -0800 Subject: Review request for 7147078: [macosx] Echo char set in TextField doesn't prevent word jumping In-Reply-To: <4F50B0BE.903@oracle.com> References: <4F4FA902.6010904@oracle.com> <4F4FC0BF.5040103@oracle.com> <4F50B0BE.903@oracle.com> Message-ID: <4F5108B9.805@oracle.com> On 3/2/2012 3:36 AM, Alexander Potochkin wrote: > Hello Artem >> Hi, Alex, >> >> will regular (without any modifiers) UP/DOWN keys work after the fix? > > Yes > > The rest of the key bindings are not disabled, > see the whole list in > com.apple.laf.AquaKeyBindings.commonTextEditorBingings OK, the fix looks fine then. Thanks, Artem > By the way, I sent the fixed build to Yura, he is going to test it today. > > Thanks > alexp > >> >> Thanks, >> >> Artem >> >> On 3/1/2012 8:51 AM, Alexander Potochkin wrote: >>> Hello >>> >>> Please review the following fix: >>> http://cr.openjdk.java.net/~alexp/7147078/webrev.00/ >>> >>> the bug's description is here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147078 >>> >>> Thanks >>> alexp > From edvard.wendelin at oracle.com Fri Mar 2 12:28:04 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 2 Mar 2012 21:28:04 +0100 Subject: [7u4] Request for approval: 7132793: [macosx] setWheelScrollEnabled action reversed In-Reply-To: <4F4B8C4A.6030608@oracle.com> References: <4F4B8C4A.6030608@oracle.com> Message-ID: Approved! On Feb 27, 2012, at 2:59 PM, Alexander Potochkin wrote: > Requesting approval to commit fix for CR 7132793. > > http://cr.openjdk.java.net/~alexp/7132793/webrev.01/ > > Reviewed by Sergey Bylokhov and Artem Ananiev > > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003295.html > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132793 > > The method's implementation contradicts its specification, > the regression test fails and there is a potential JCK problem. > > The final version of the fix is safe and simple. > > Thanks > alexp > > From edvard.wendelin at oracle.com Fri Mar 2 12:28:53 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 2 Mar 2012 21:28:53 +0100 Subject: [7u4] Request for approval: 7146131: [macosx] When click the show optionpane button, it display partly of dialog and hung until timeout In-Reply-To: <4F4FB121.8020901@oracle.com> References: <4F4FB121.8020901@oracle.com> Message-ID: Approved. On Mar 1, 2012, at 6:25 PM, Alexander Potochkin wrote: > Requesting approval to commit fix for CR 7146131. > > http://cr.openjdk.java.net/~alexp/7146131/webrev.00/ > > Reviewed by Anthony Petrov > > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003403.html > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146131 > > This fixes a regression from a previous 7u4 fix > > Thanks > alexp From edvard.wendelin at oracle.com Fri Mar 2 12:30:47 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 2 Mar 2012 21:30:47 +0100 Subject: [7u4] Request for phase 2 approval for CR 7150516 - [macosx] appletviewer shouldn't link against libX11 on the Mac In-Reply-To: <4F50EBCD.4050608@oracle.com> References: <4F50EBCD.4050608@oracle.com> Message-ID: <928908A6-553C-4B07-A23B-CCB7645DD717@oracle.com> Approved. On Mar 2, 2012, at 4:48 PM, Anthony Petrov wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7150516 > Webrev: http://cr.openjdk.java.net/~anthony/x-22-appletviewerLibX11-7150516.0/ > Review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003457.html > Reviewer: Mike Swingler (swingler) > > Rationale for inclusion in 7u4: X11 is an optional package on Mac OS X. Since OpenJDK on the Mac uses Cocoa for GUI, the tools shouldn't link against an unused GUI library. With this fix we eliminate the dependency on the libX11 library. > > -- > best regards, > Anthony > From john.r.rose at oracle.com Fri Mar 2 14:46:08 2012 From: john.r.rose at oracle.com (John Rose) Date: Fri, 2 Mar 2012 14:46:08 -0800 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F5092CC.1070805@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> Message-ID: <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> On Mar 2, 2012, at 1:28 AM, Michael McMahon wrote: > I can't reproduce it. It must be something related to the boot JDK you are using. > Is it a complete jdk7 image? The JDK files I got via the DYLD_LIBRARY_PATH are in a download from this file: http://download.java.net/jdk7u4/archive/b12/binaries/jdk-7u4-ea-bin-b12-macosx-amd64-16_feb_2012.dmg I got it from here: http://jdk7.java.net/macportpreview/ -------- /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/bin/java -fullversion java full version "1.7.0_04-ea-b12" -------- /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/bin/java -Xinternalversion Java HotSpot(TM) 64-Bit Server VM (23.0-b15) for bsd-amd64 JRE (1.7.0_04-ea-b12), built on Feb 16 2012 11:12:32 by "java_re" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) -------- This is also the ALT_BOOTDIR I use for builds. When I built my own copy of hotspot (including gamma) I used a jdk8 repo (hsx/hotspot-comp/{hotspot,jdk,langtools}), plus your patches for 7113349. I wouldn't be surprised if there were random problems running a JDK8 gamma on top of a libjava.dylib from 1.7.0_04. > I do get a (different) error if I set DYLD_LIBRARY_PATH in the environment > Are you actually setting this in your environment? > I notice the sanity check isn't looking for this, which it should on Mac. No, I don't set that, but the example commands I sent have settings for it. What's confusing (but maybe unimportant) is that the bug Stuart and I saw manifests only when libjava is put on the DLLP, but it does not manifest when the same libjava is loaded by some other unknown means. (The loading can be traced with DYLD_PRINT_LIBRARIES, as shown in my message.) HTH ? John From henri.gomez at gmail.com Sat Mar 3 06:14:37 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sat, 3 Mar 2012 15:14:37 +0100 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> Message-ID: <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> Guys could you detail JDK8 build process on OSX ? I'd like to add this to my openjdk-osx-build project. Thanks Le 2 mars 2012 ? 23:46, John Rose a ?crit : > On Mar 2, 2012, at 1:28 AM, Michael McMahon wrote: > >> I can't reproduce it. It must be something related to the boot JDK you are using. >> Is it a complete jdk7 image? > > The JDK files I got via the DYLD_LIBRARY_PATH are in a download from this file: > http://download.java.net/jdk7u4/archive/b12/binaries/jdk-7u4-ea-bin-b12-macosx-amd64-16_feb_2012.dmg > > I got it from here: > http://jdk7.java.net/macportpreview/ > > -------- > /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/bin/java -fullversion > java full version "1.7.0_04-ea-b12" > -------- > /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/bin/java -Xinternalversion > Java HotSpot(TM) 64-Bit Server VM (23.0-b15) for bsd-amd64 JRE (1.7.0_04-ea-b12), built on Feb 16 2012 11:12:32 by "java_re" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) > -------- > > This is also the ALT_BOOTDIR I use for builds. > > When I built my own copy of hotspot (including gamma) I used a jdk8 repo (hsx/hotspot-comp/{hotspot,jdk,langtools}), plus your patches for 7113349. > > I wouldn't be surprised if there were random problems running a JDK8 gamma on top of a libjava.dylib from 1.7.0_04. > >> I do get a (different) error if I set DYLD_LIBRARY_PATH in the environment >> Are you actually setting this in your environment? >> I notice the sanity check isn't looking for this, which it should on Mac. > > No, I don't set that, but the example commands I sent have settings for it. > > What's confusing (but maybe unimportant) is that the bug Stuart and I saw manifests only when libjava is put on the DLLP, but it does not manifest when the same libjava is loaded by some other unknown means. (The loading can be traced with DYLD_PRINT_LIBRARIES, as shown in my message.) > > HTH > > ? John From Alan.Bateman at oracle.com Sat Mar 3 06:31:48 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 03 Mar 2012 14:31:48 +0000 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> Message-ID: <4F522B54.3010800@oracle.com> On 03/03/2012 14:14, Henri Gomez wrote: > Guys could you detail JDK8 build process on OSX ? > > I'd like to add this to my openjdk-osx-build project. > > Thanks > The Mac port isn't in jdk8 yet but should be very soon. The webrev that Michael sent a link to is just part of the process to get the changes agreed before he pushes it to the jdk8/tl forest, something that I hope will happen within a few days. All going well it should mean the Mac port should get to the jdk8 master in a few weeks (exactly when it's clearly but I assume it will bake in jdk8/tl for a bit). So in the mean time you have to take a clone of jdk8/tl and then import the patch files from the webrev (you'll see a link named "Patch of changes" in each of the 4 webrevs). Once you do that then the build is the same as jdk7u except that you need a jdk7 build as the bootstrap JDK. Like Stuart and John, I grabbed the patches and attempted to get jdk8/tl to build. It worked for me and I didn't run into the issues with the gamma launcher. In my case, I used a local build of jdk7/jdk7u-dev as the bootstrap JDK. It will be interesting to hear how you get on. -Alan From henri.gomez at gmail.com Sat Mar 3 10:16:12 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sat, 3 Mar 2012 19:16:12 +0100 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F522B54.3010800@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> Message-ID: I'll wait to get OSX code in master :-) Thanks Alan for the explanation Le 3 mars 2012 ? 15:31, Alan Bateman a ?crit : > On 03/03/2012 14:14, Henri Gomez wrote: >> Guys could you detail JDK8 build process on OSX ? >> >> I'd like to add this to my openjdk-osx-build project. >> >> Thanks >> > The Mac port isn't in jdk8 yet but should be very soon. The webrev that Michael sent a link to is just part of the process to get the changes agreed before he pushes it to the jdk8/tl forest, something that I hope will happen within a few days. All going well it should mean the Mac port should get to the jdk8 master in a few weeks (exactly when it's clearly but I assume it will bake in jdk8/tl for a bit). > > So in the mean time you have to take a clone of jdk8/tl and then import the patch files from the webrev (you'll see a link named "Patch of changes" in each of the 4 webrevs). Once you do that then the build is the same as jdk7u except that you need a jdk7 build as the bootstrap JDK. Like Stuart and John, I grabbed the patches and attempted to get jdk8/tl to build. It worked for me and I didn't run into the issues with the gamma launcher. In my case, I used a local build of jdk7/jdk7u-dev as the bootstrap JDK. It will be interesting to hear how you get on. > > -Alan From john.r.rose at oracle.com Sat Mar 3 12:19:35 2012 From: john.r.rose at oracle.com (John Rose) Date: Sat, 3 Mar 2012 12:19:35 -0800 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> Message-ID: <9B8F7795-FB2B-4ABF-89E9-0A9595C40C57@oracle.com> On Mar 3, 2012, at 6:14 AM, Henri Gomez wrote: > Guys could you detail JDK8 build process on OSX ? > > I'd like to add this to my openjdk-osx-build project. I'm rediscovering it myself. The switch to macosx in jdk8 was phased: hotspot first, then jdk. Before jdk was updated for macosx, builds were basically broken. For the moment, you can follow the mlvm instructions, which will cause you to get snapshots of Michael's work (as macosx-7113349.patch), and these will make a jdk8 repo able to build macosx. When Michael's work promotes, I'll remove those patches from mlvm, and things will get a lot (a lot!) more stable on macosx. Adding a new platform to OpenJDK is not trivial. I'm glad the teething pains have been as light as they have been. (But the adventure's not over yet, is it?) Like everybody, I have a messy hairy build script (derived from those which have been posted). The changes I have had to make recently include: 1. Upgrade to Lion; download Xcode; install the command line tools. 2. Set LP64=1. (Avoid 32-bit builds, at least for now.) 3. Add Michael's patches to jdk. (Crucial!) 4. Set ALT_BOOTDIR to a download of OpenJDK 7 preview on macosx: http://jdk7.java.net/macportpreview/ 5. Remove ALT_FREETYPE_* settings from the build script. 6. Find the compilers using xcrun: CC=$( xcrun -find gcc ); CXX=$( xcrun -find g++ ) 7. Set OPENJDK=true for luck. (Not sure if this is necessary.) To do this, I chose to upgrade to Lion and ditch 32-bit, rather than experiment with alternatives. Yes, I wimped out, and that doesn't help customers who want to run 32-bit systems or Snowleopard. N.B. The Lion upgrade was pretty scary, because I got the notorious "install hangs forever" failure mode. Time Machine saved my bacon, by allowing me to regress back to my Snowleopard image, run disk repair, and try again. My advice: Do not upgrade to Lion without a full backup, and without running the Disk Utility's repair function. Another bit of hard-won advice: If you are relying on Time Machine as I did, go to preferences and remove exclusions form the backup list. I had excluded my Downloads directory for obvious reasons. I found it anxiety provoking when I did an emergency reversion to Snowleopard and found all my Downloads were gone. Also, I had a folder called /Backup in which I manually stashed backups. This also was gone after the full restore; not sure why. (It didn't matter; the extra backup copies were totally redundant, again for obvious reasons.) Time Machine will restore your system to usability, and will faithfully restore stuff under /Users, but it seems to be buggy with random stuff under the file system root. ? John From stephen.bannasch at deanbrook.org Sat Mar 3 12:34:38 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sat, 3 Mar 2012 15:34:38 -0500 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <9B8F7795-FB2B-4ABF-89E9-0A9595C40C57@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <9B8F7795-FB2B-4ABF-89E9-0A9595C40C57@oracle.com> Message-ID: At 12:19 PM -0800 3/3/12, John Rose wrote: >Another bit of hard-won advice: If you are relying on Time Machine as I did, go to preferences and remove exclusions formthe backup list. I had excluded my Downloads directory for obvious reasons. I found it anxiety provoking when I did an emergency reversion to Snowleopard and found all my Downloads were gone. Also, I had a folder called /Backupin which I manually stashed backups. This also was gone after the full restore; not sure why. (It didn't matter; the extra backup copies were totally redundant, again for obvious reasons.) Time Machine will restore your system to usability, and will faithfully restore stuff under /Users, but it seems to be buggy with random stuff under the file system root. I use the shareware Mac app SuperDuper for backup. It's slower than TimeMachine but it works quite reliably. I used it to make a backup, upgraded to Lion, found some essential programs I use not working and restored from the backup. My upgrade to Lion will have to wait until I can find ways to migrate the data to new apps which work in Lion. From mik3hall at gmail.com Sat Mar 3 15:38:28 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 3 Mar 2012 17:38:28 -0600 Subject: trustAnchors parameter must be non-empty Message-ID: <0CA55830-4615-4DA4-8EE1-60643620E16E@gmail.com> Running into this... Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty trying to use some Google data stuff. Appears to be the same error as... http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145128 but that is closed as a duplicate to 7114062 which for some reason I can't look at? This bug is not available. From mark at talios.com Sat Mar 3 16:50:40 2012 From: mark at talios.com (Mark Derricutt) Date: Sun, 4 Mar 2012 13:50:40 +1300 Subject: trustAnchors parameter must be non-empty In-Reply-To: <0CA55830-4615-4DA4-8EE1-60643620E16E@gmail.com> References: <0CA55830-4615-4DA4-8EE1-60643620E16E@gmail.com> Message-ID: I've see this same issue when using the maven-changes-plugin to generate a change log, the source of the problem I was seeing was when using JavaMail, however it occurred both on OpenJDK/OSX on my machine, and on a coworkers Ubuntu machine ( I'm not sure if he was using OpenJDK or the official Oracle Java7 tho ). Unable to see that issue you link as well... -- "Great artists are extremely selfish and arrogant things" ? Steven Wilson, Porcupine Tree On Sun, Mar 4, 2012 at 12:38 PM, Michael Hall wrote: > Running into this... > Caused by: java.security.InvalidAlgorithmParameterException: the > trustAnchors parameter must be non-empty > > trying to use some Google data stuff. > Appears to be the same error as... > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145128 > but that is closed as a duplicate to 7114062 which for some reason I can't > look at? > This bug is not available. > > From mik3hall at gmail.com Sat Mar 3 16:57:31 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 3 Mar 2012 18:57:31 -0600 Subject: trustAnchors parameter must be non-empty In-Reply-To: References: <0CA55830-4615-4DA4-8EE1-60643620E16E@gmail.com> Message-ID: <4DAF5E56-DC56-4170-8A3E-F5C418B84183@gmail.com> On Mar 3, 2012, at 6:50 PM, Mark Derricutt wrote: > the source of the problem I was seeing was when using JavaMail, I include mail.jar. Not sure why, not my code. But open source so I built it to see the authentication exception getting tossed, the original just messages an error without showing the stack trace. From schlosna at gmail.com Sat Mar 3 17:38:27 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Sat, 3 Mar 2012 20:38:27 -0500 Subject: trustAnchors parameter must be non-empty In-Reply-To: <4DAF5E56-DC56-4170-8A3E-F5C418B84183@gmail.com> References: <0CA55830-4615-4DA4-8EE1-60643620E16E@gmail.com> <4DAF5E56-DC56-4170-8A3E-F5C418B84183@gmail.com> Message-ID: On Sat, Mar 3, 2012 at 6:38 PM, Michael Hall wrote: > Running into this... > Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty > > trying to use some Google data stuff. > Appears to be the same error as... > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145128 > but that is closed as a duplicate to 7114062 which for some reason I can't look at? > This bug is not available. By default, the OpenJDK build creates an empty trusted certificate authority keystore ($JAVA_HOME/jre/lib/security/cacerts), so if you attempt to do anything that would use those trusted certificates (e.g. SSL, for certificate chain validations), it will fail with the "java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty" exception. I've run into this issue before during the build when using OpenJDK as a bootstrap for another OpenJDK build [1]. I'd suggest you look at importing the appropriate certificates into your cacerts via keytool, or use the javax.net.ssl.trustStore system property to point at an existing valid keystore. APPLE_JAVA_6_HOME=`/usr/libexec/java_home -v 1.6` CACERTS_FILE=${APPLE_JAVA_6_HOME}/lib/security/cacerts -Djavax.net.ssl.trustStore=${CACERTS_FILE} [1] http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-July/000585.html For example, I see this from my OpenJDK 7 build from earlier this month: $ keytool -list -keystore /Users/david/dev/jdk7u-dev/build/macosx-amd64/j2sdk-image/1.7.0.jdk/Contents/Home/jre/lib/security/cacerts -storepass changeit Keystore type: JKS Keystore provider: SUN Your keystore contains 0 entries Meanwhile, the Apple provided JDK (): $ keytool -list -keystore /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security/cacerts -storepass changeit Keystore type: JKS Keystore provider: SUN Your keystore contains 183 entries keychainrootca-99, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): AA:08:8F:F6:F9:7B:B7:F2:B1:A7:1E:9B:EA:EA:BD:79 keychainrootca-98, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): B0:01:EE:14:D9:AF:29:18:94:76:8E:F1:69:33:2A:84 keychainrootca-97, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 39:16:AA:B9:6A:41:E1:14:69:DF:9E:6C:3B:72:DC:B6 keychainrootca-96, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C5:E6:7B:BF:06:D0:4F:43:ED:C4:7A:65:8A:FB:6B:19 keychainrootca-95, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 20:0B:4A:7A:88:A7:A9:42:86:8A:5F:74:56:7B:88:05 keychainrootca-94, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 77:0D:19:B1:21:FD:00:42:9C:3E:0C:A5:DD:0B:02:8E keychainrootca-93, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): FC:11:B8:D8:08:93:30:00:6D:23:F9:7E:EB:52:1E:02 keychainrootca-92, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): F1:BC:63:6A:54:E0:B5:27:F5:CD:E7:1A:E3:4D:6E:4A keychainrootca-91, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 22:2D:A6:01:EA:7C:0A:F7:F0:6C:56:43:3F:77:76:D3 keychainrootca-90, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 6C:39:7D:A4:0E:55:59:B2:3F:D6:41:B1:12:50:DE:43 keychainrootca-89, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 32:4A:4B:BB:C8:63:69:9B:BE:74:9A:C6:DD:1D:46:24 keychainrootca-88, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 33:B7:84:F5:5F:27:D7:68:27:DE:14:DE:12:2A:ED:6F keychainrootca-87, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): A3:EC:75:0F:2E:88:DF:FA:48:01:4E:0B:5C:48:6F:FB keychainrootca-86, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): D6:39:81:C6:52:7E:96:69:FC:FC:CA:66:ED:05:F2:96 keychainrootca-85, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 17:35:74:AF:7B:61:1C:EB:F4:F9:3C:E2:EE:40:F9:A2 keychainrootca-84, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 24:77:D9:A8:91:D1:3B:FA:88:2D:C2:FF:F8:CD:33:93 keychainrootca-83, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C9:98:27:77:28:1E:3D:0E:15:3C:84:00:B8:85:03:E6 keychainrootca-82, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): E0:06:A1:C9:7D:CF:C9:FC:0D:C0:56:75:96:D8:62:13 keychainrootca-81, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 93:7F:90:1C:ED:84:67:17:A4:65:5F:9B:CB:30:02:97 keychainrootca-80, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 91:F4:03:55:20:A1:F8:63:2C:62:DE:AC:FB:61:1C:8E keychainrootca-79, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 8D:5D:22:EA:28:72:30:F2:95:BE:3C:0B:1B:0D:7D:34 keychainrootca-78, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 53:4B:1D:17:58:58:1A:30:A1:90:F8:6E:5C:F2:CF:65 keychainrootca-77, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 6E:70:8E:4E:3E:5A:46:F2:AF:AE:52:27:4A:8C:26:C2 keychainrootca-76, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): A6:6B:60:90:23:9B:3F:2D:BB:98:6F:D6:A7:19:0D:46 keychainrootca-75, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): EE:FE:61:69:65:6E:F8:9C:C6:2A:F4:D7:2B:63:EF:A2 keychainrootca-74, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): F2:89:95:6E:4D:05:F0:F1:A7:21:55:7D:46:11:BA:47 keychainrootca-73, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 30:C9:E7:1E:6B:E6:14:EB:65:B2:16:69:20:31:67:4D keychainrootca-72, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): CF:F4:27:0D:D4:ED:DC:65:16:49:6D:3D:DA:BF:6E:DE keychainrootca-71, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): DC:32:C3:A7:6D:25:57:C7:68:09:9D:EA:2D:A9:A2:D1 keychainrootca-70, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 1D:35:54:04:85:78:B0:3F:42:42:4D:BF:20:73:0A:3F keychainrootca-69, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C1:62:3E:23:C5:82:73:9C:03:59:4B:2B:E9:77:49:7F keychainrootca-68, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 27:EC:39:47:CD:DA:5A:AF:E2:9A:01:65:21:A9:4C:BB keychainrootca-67, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 64:B0:09:55:CF:B1:D5:99:E2:BE:13:AB:A6:5D:EA:4D keychainrootca-66, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): ED:41:F5:8C:50:C5:2B:9C:73:E6:EE:6C:EB:C2:A8:26 keychainrootca-65, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C4:5D:0E:48:B6:AC:28:30:4E:0A:BC:F9:38:16:87:57 keychainrootca-64, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C1:D9:51:C0:84:B8:6A:75:E8:2F:D7:D6:5F:7E:AC:46 keychainrootca-63, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 42:65:CA:BE:01:9A:9A:4C:A9:8C:41:49:CD:C0:D5:7F keychainrootca-62, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 8F:91:E7:EE:E3:FC:DA:86:CA:FC:DC:70:ED:B7:B7:0C keychainrootca-61, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 82:92:BA:5B:EF:CD:8A:6F:A6:3D:55:F9:84:F6:D6:B7 keychainrootca-60, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): D7:34:3D:EF:1D:27:09:28:E1:31:02:5B:13:2B:DD:F7 keychainrootca-183, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): D3:D9:BD:AE:9F:AC:67:24:B3:C8:1B:52:E1:B9:A9:BD keychainrootca-182, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 91:1B:3F:6E:CD:9E:AB:EE:07:FE:1F:71:D2:B3:61:27 keychainrootca-181, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): CE:4A:CB:6A:D9:52:ED:1B:FF:9F:B6:17:AE:07:76:6B keychainrootca-59, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 14:F1:08:AD:9D:FA:64:E2:89:E7:1C:CF:A8:AD:7D:5E keychainrootca-180, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 4F:EB:F1:F0:70:C2:80:63:5D:58:9F:DA:12:3C:A9:C4 keychainrootca-58, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 4C:56:41:E5:0D:BB:2B:E8:CA:A3:ED:18:08:AD:43:39 keychainrootca-57, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): D6:ED:3C:CA:E2:66:0F:AF:10:43:0D:77:9B:04:09:BF keychainrootca-56, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): BF:60:59:A3:5B:BA:F6:A7:76:42:DA:6F:1A:7B:50:CF keychainrootca-55, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): F3:D7:52:A8:75:FD:18:EC:E1:7D:35:B1:70:6E:A5:9C keychainrootca-54, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): A7:F2:E4:16:06:41:11:50:30:6B:9C:E3:B4:9C:B0:C9 keychainrootca-53, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): B3:A5:3E:77:21:6D:AC:4A:C0:C9:FB:D5:41:3D:CA:06 keychainrootca-52, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 2C:8F:9F:66:1D:18:90:B1:47:26:9D:8E:86:82:8C:A9 keychainrootca-51, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): FD:49:BE:5B:18:5A:25:EC:F9:C3:54:85:10:40:E8:D4 keychainrootca-50, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 28:ED:E6:FC:07:62:B6:1E:F6:1C:3E:70:07:9A:0F:D1 keychainrootca-179, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 74:01:4A:91:B1:08:C4:58:CE:47:CD:F0:DD:11:53:08 keychainrootca-178, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 25:9D:CF:5E:B3:25:9D:95:B9:3F:00:86:5F:47:94:3D keychainrootca-177, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 87:CE:0B:7B:2A:0E:49:00:E1:58:71:9B:37:A8:93:72 keychainrootca-176, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 02:26:C3:01:5E:08:30:37:43:A9:D0:7D:CF:37:E6:BF keychainrootca-175, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 79:E4:A9:84:0D:7D:3A:96:D7:C0:4F:E2:43:4C:89:2E keychainrootca-174, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): D4:74:DE:57:5C:39:B2:D3:9C:85:83:C5:C0:65:49:8A keychainrootca-173, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): AB:BF:EA:E3:6B:29:A6:CC:A6:78:35:99:EF:AD:2B:80 keychainrootca-172, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 8C:48:08:65:BB:DA:FF:9F:FD:8C:E2:95:E0:96:B9:9D keychainrootca-171, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): BF:29:0A:28:ED:65:83:06:9E:FC:E3:16:9F:67:5C:83 keychainrootca-49, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): BA:21:EA:20:D6:DD:DB:8F:C1:57:8B:40:AD:A1:FC:FC keychainrootca-170, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 47:78:92:DB:8A:EC:1B:53:68:F0:1D:00:9C:34:77:5E keychainrootca-48, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): A7:71:FD:26:FC:3C:E5:40:F1:99:06:EB:C1:93:6D:E9 keychainrootca-47, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): EE:7A:41:E0:CF:75:7D:88:92:80:A2:1A:9A:7B:A1:57 keychainrootca-46, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C9:19:62:D0:DA:7E:10:20:FC:A4:CD:03:80:87:2D:F5 keychainrootca-45, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 49:63:AE:27:F4:D5:95:3D:D8:DB:24:86:B8:9C:07:53 keychainrootca-44, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): E7:7A:DC:B1:1F:6E:06:1F:74:6C:59:16:27:C3:4B:C0 keychainrootca-43, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 01:5A:99:C3:D6:4F:A9:4B:3C:3B:B1:A3:AB:27:4C:BF keychainrootca-42, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 7E:23:4E:5B:A7:A5:B4:25:E9:00:07:74:11:62:AE:D6 keychainrootca-41, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 1E:42:95:02:33:92:6B:B9:5F:C0:7F:DA:D6:B2:4B:FC keychainrootca-40, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 7E:61:1E:0F:7B:A3:1B:51:98:6F:41:3B:41:38:3E:F0 keychainrootca-169, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): B2:B6:08:F0:05:3C:37:D6:97:3D:03:B8:69:31:5B:14 keychainrootca-168, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 2C:20:26:9D:CB:1A:4A:00:85:B5:B7:5A:AE:C2:01:37 keychainrootca-167, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C1:33:D5:B0:D7:A6:65:F3:95:E7:8E:F4:A7:A8:32:F9 keychainrootca-166, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 96:94:FC:61:C6:5C:15:3D:93:FC:0F:C4:0F:18:7A:63 keychainrootca-165, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): EB:B9:71:E1:19:A4:98:32:65:21:C4:10:C6:C0:6A:2F keychainrootca-164, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 83:1C:8A:61:C1:6F:B8:4B:7C:8D:B7:58:45:EF:77:73 keychainrootca-163, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 96:F1:CB:9C:06:AB:B4:80:DA:42:DA:03:57:01:2D:9E keychainrootca-162, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): A9:81:C0:B7:3A:92:50:BC:91:A5:21:FF:3D:47:87:9F keychainrootca-161, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): D6:A5:C3:ED:5D:DD:3E:00:C1:3D:87:92:1F:1D:3F:E4 keychainrootca-39, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): FA:40:29:17:72:53:4C:48:EC:9E:8E:1D:5A:75:A3:D1 keychainrootca-160, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): DF:F2:80:73:CC:F1:E6:61:73:FC:F5:42:E9:C5:7C:EE keychainrootca-38, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): F3:7E:3A:13:DC:74:63:06:74:1A:3C:38:32:8C:FB:A9 keychainrootca-37, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 5B:9E:FD:3B:60:35:EA:68:8E:52:FE:13:19:14:4A:A3 keychainrootca-36, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 65:58:AB:15:AD:57:6C:1E:A8:A7:B5:69:AC:BF:FF:EB keychainrootca-35, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): AC:B6:94:A5:9C:17:E0:D7:91:52:9B:B1:97:06:A6:E4 keychainrootca-34, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): A9:23:75:9B:BA:49:36:6E:31:C2:DB:F2:E7:66:BA:87 keychainrootca-33, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): B8:08:9A:F0:03:CC:1B:0D:C8:6C:0B:76:A1:75:64:23 keychainrootca-32, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): A2:6F:53:B7:EE:40:DB:4A:68:E7:FA:18:D9:10:4B:72 keychainrootca-31, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): DF:3C:73:59:81:E7:39:50:81:04:4C:34:A2:CB:B3:7B keychainrootca-30, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): CB:17:E4:31:67:3E:E2:09:FE:45:57:93:F3:0A:FA:1C keychainrootca-159, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 68:9B:17:C6:54:E0:E0:E0:99:55:16:42:F7:5A:86:D8 keychainrootca-158, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 67:CB:9D:C0:13:24:8A:82:9B:B2:17:1E:D1:1B:EC:D4 keychainrootca-157, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 93:EB:36:13:0B:C1:54:F1:3E:75:05:E5:E0:1C:D4:37 keychainrootca-156, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 8F:5D:77:06:27:C4:98:3C:5B:93:78:E7:D7:7D:9B:CC keychainrootca-155, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 86:38:6D:5E:49:63:6C:85:5C:DB:6D:DC:94:B7:D0:F7 keychainrootca-154, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 64:9C:EF:2E:44:FC:C6:8F:52:07:D0:51:73:8F:CB:3D keychainrootca-153, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): D4:80:65:68:24:F9:89:22:28:DB:F5:A4:9A:17:8F:14 keychainrootca-152, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): AA:BF:BF:64:97:DA:98:1D:6F:C6:08:3A:95:70:33:CA keychainrootca-151, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): E6:0B:D2:C9:CA:2D:88:DB:1A:71:0E:4B:78:EB:02:41 keychainrootca-150, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): AA:8E:5D:D9:F8:DB:0A:58:B7:8D:26:87:6C:82:35:55 keychainrootca-29, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): B1:47:BC:18:57:D1:18:A0:78:2D:EC:71:E8:2A:95:73 keychainrootca-28, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 86:AC:DE:2B:C5:6D:C3:D9:8C:28:88:D3:8D:16:13:1E keychainrootca-27, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): F8:BE:C4:63:22:C9:A8:46:74:8B:B8:1D:1E:4A:2B:F6 keychainrootca-26, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): AB:A6:FB:0D:38:B5:E8:E9:F5:00:C4:8F:45:74:DB:98 keychainrootca-25, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): CD:68:B6:A7:C7:C4:CE:75:E0:1D:4F:57:44:61:92:09 keychainrootca-24, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): EF:5A:F1:33:EF:F1:CD:BB:51:02:EE:12:14:4B:96:C4 keychainrootca-23, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): BC:6C:51:33:A7:E9:D3:66:63:54:15:72:1B:21:92:93 keychainrootca-22, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 15:AC:A5:C2:92:2D:79:BC:E8:7F:CB:67:ED:02:CF:36 keychainrootca-21, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): A1:0B:44:B3:CA:10:D8:00:6E:9D:0F:D8:0F:92:0A:D1 keychainrootca-20, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): DB:C8:F2:27:2E:B1:EA:6A:29:23:5D:FE:56:3E:33:DF keychainrootca-149, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 1E:74:C3:86:3C:0C:35:C5:3E:C2:7F:EF:3C:AA:3C:D9 keychainrootca-148, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): F0:58:C5:03:82:67:17:AB:8F:DA:03:10:27:8E:19:C2 keychainrootca-147, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 3A:B2:DE:22:9A:20:93:49:F9:ED:C8:D2:8A:E7:68:0D keychainrootca-146, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): F7:B6:61:AB:03:C2:5C:46:3E:2D:2C:F4:A1:24:D8:54 keychainrootca-145, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 27:DE:36:FE:72:B7:00:03:00:9D:F4:F0:1E:6C:04:24 keychainrootca-144, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 5E:39:7B:DD:F8:BA:EC:82:E9:AC:62:BA:0C:54:00:2B keychainrootca-143, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 8C:42:B6:36:0D:D0:24:CE:4C:B1:BA:06:D2:6A:6B:C9 keychainrootca-142, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 73:3A:74:7A:EC:BB:A3:96:A6:C2:E4:E2:C8:9B:C0:C3 keychainrootca-141, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 91:DE:06:25:AB:DA:FD:32:17:0C:BB:25:17:2A:84:67 keychainrootca-140, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): CA:3D:D3:68:F1:03:5C:D0:32:FA:B8:2B:59:E8:5A:DB keychainrootca-19, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 55:5D:63:00:97:BD:6A:97:F5:67:AB:4B:FB:6E:63:15 keychainrootca-18, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 5C:48:DC:F7:42:72:EC:56:94:6D:1C:CC:71:35:80:75 keychainrootca-17, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): AB:57:A6:5B:7D:42:82:19:B5:D8:58:26:28:5E:FD:FF keychainrootca-16, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): B4:4A:DB:E8:59:16:46:1E:5A:D8:6E:DA:06:43:52:62 keychainrootca-15, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 1B:2E:00:CA:26:06:90:3D:AD:FE:6F:15:68:D3:6B:B3 keychainrootca-14, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 98:EB:0B:35:77:1A:0C:9E:B0:FC:83:27:10:B0:62:F2 keychainrootca-13, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): DB:23:3D:F9:69:FA:4B:B9:95:80:44:73:5E:7D:41:83 keychainrootca-12, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 93:2A:3E:F6:FD:23:69:0D:71:20:D4:2B:47:99:2B:A6 keychainrootca-11, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 2D:BB:E5:25:D3:D1:65:82:3A:B7:0E:FA:E6:EB:E2:E1 keychainrootca-10, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): D7:7C:8B:A4:42:C9:F7:93:9D:65:61:4C:0D:97:E7:E0 keychainrootca-139, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 31:85:3C:62:94:97:63:B9:AA:FD:89:4E:AF:6F:E0:CF keychainrootca-138, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): F7:75:AB:29:FB:51:4E:B7:77:5E:FF:05:3C:99:8E:F5 keychainrootca-137, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C5:70:C4:A2:ED:53:78:0C:C8:10:53:81:64:CB:D0:1D keychainrootca-136, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C5:DF:B8:49:CA:05:13:55:EE:2D:BA:1A:C3:3E:B0:28 keychainrootca-135, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 06:9F:69:79:16:66:90:02:1B:8C:8C:A2:C3:07:6F:3A keychainrootca-134, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 3E:45:52:15:09:51:92:E1:B7:5D:37:9F:B1:87:29:8A keychainrootca-133, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 7C:A5:0F:F8:5B:9A:7D:6D:30:AE:54:5A:E3:42:A2:8A keychainrootca-132, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 94:14:77:7E:3E:5E:FD:8F:30:BD:41:B0:CF:E7:D0:30 keychainrootca-131, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 60:84:7C:5A:CE:DB:0C:D4:CB:A7:E9:FE:02:C6:A9:C0 keychainrootca-130, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 80:3A:BC:22:C1:E6:FB:8D:9B:3B:27:4A:32:1B:9A:01 keychainrootca-129, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 22:4D:8F:8A:FC:F7:35:C2:BB:57:34:90:7B:8B:22:16 keychainrootca-128, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): A8:0D:6F:39:78:B9:43:6D:77:42:6D:98:5A:CC:23:CA keychainrootca-127, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C9:3B:0D:84:41:FC:A4:76:79:23:08:57:DE:10:19:16 keychainrootca-126, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): F8:38:7C:77:88:DF:2C:16:68:2E:C2:E2:52:4B:B8:F9 keychainrootca-125, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): D6:60:E4:56:2A:FA:E5:F7:10:D3:F7:1E:7E:B8:2A:46 keychainrootca-124, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 45:E1:A5:72:C5:A9:36:64:40:9E:F5:E4:58:84:67:8C keychainrootca-123, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 41:03:52:DC:0F:F7:50:1B:16:F0:02:8E:BA:6F:45:C5 keychainrootca-122, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 21:D8:4C:82:2B:99:09:33:A2:EB:14:24:8D:8E:5F:E8 keychainrootca-121, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 87:14:AB:83:C4:04:1B:F1:93:C7:50:E2:D7:21:EB:EF keychainrootca-120, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C8:6E:97:F3:35:A7:29:14:47:82:89:23:91:A6:BE:C8 keychainrootca-119, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): A2:08:E4:B3:3E:EF:DE:08:4B:60:D0:BF:79:52:49:8D keychainrootca-118, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): B7:52:74:E2:92:B4:80:93:F2:75:E4:CC:D7:F2:EA:26 keychainrootca-117, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): CE:78:33:5C:59:78:01:6E:18:EA:B9:36:A0:B9:2E:23 keychainrootca-116, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): FA:3F:91:DA:78:C7:B9:C4:C8:AB:E5:64:A3:72:66:0C keychainrootca-115, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 56:5F:AA:80:61:12:17:F6:67:21:E6:2B:6D:61:56:8E keychainrootca-114, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C2:5B:89:F9:DC:51:FE:0D:95:B3:F3:E5:50:BE:D3:9E keychainrootca-113, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 9D:FB:F9:AC:ED:89:33:22:F4:28:48:83:25:23:5B:E0 keychainrootca-112, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 22:D5:44:B2:CB:A3:FF:8E:EB:97:0E:14:31:5E:3E:EF keychainrootca-111, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 8C:CA:DC:0B:22:CE:F5:BE:72:AC:41:1A:11:A8:D8:12 keychainrootca-110, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): C5:A1:B7:FF:73:DD:D6:D7:34:32:18:DF:FC:3C:AD:88 keychainrootca-9, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): A2:33:9B:4C:74:78:73:D4:6C:E7:C1:F3:8D:CB:5C:E9 keychainrootca-8, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): E9:AC:47:CC:78:B6:CF:02:50:5E:E2:48:1B:EC:95:DC keychainrootca-7, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 26:6D:2C:19:98:B6:70:68:38:50:54:19:EC:90:34:60 keychainrootca-6, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 88:2C:8C:52:B8:A2:3C:F3:F7:BB:03:EA:AE:AC:42:0B keychainrootca-5, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 49:79:04:B0:EB:87:19:AC:47:B0:BC:11:51:9B:74:D0 keychainrootca-4, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): BE:39:5A:BE:07:8A:B1:12:17:25:CC:1D:46:34:3C:B2 keychainrootca-3, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 21:BC:82:AB:49:C4:13:3B:4B:B2:2B:5C:6B:90:9C:19 keychainrootca-2, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 3F:45:96:39:E2:50:87:F7:BB:FE:98:0C:3C:20:98:E6 keychainrootca-1, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): EE:29:31:BC:32:7E:9A:E6:E8:B5:F7:51:B4:34:71:90 keychainrootca-109, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 74:9D:EA:60:24:C4:FD:22:53:3E:CC:3A:72:D9:29:4F keychainrootca-108, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): D3:F3:A6:16:C0:FA:6B:1D:59:B1:2D:96:4D:0E:11:2E keychainrootca-107, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 9F:DD:DB:AB:FF:8E:FF:45:21:5F:F0:6C:9D:8F:FE:2B keychainrootca-106, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): F1:6A:22:18:C9:CD:DF:CE:82:1D:1D:B7:78:5C:A9:A5 keychainrootca-105, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 37:A5:6E:D4:B1:25:84:97:B7:FD:56:15:7A:F9:A2:00 keychainrootca-104, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 2B:70:20:56:86:82:A0:18:C8:07:53:12:28:70:21:72 keychainrootca-103, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 97:60:E8:57:5F:D3:50:47:E5:43:0C:94:36:8A:B0:62 keychainrootca-102, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): B3:9C:25:B1:C3:2E:32:53:80:15:30:9D:4D:02:77:3E keychainrootca-101, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): 10:FC:63:5D:F6:26:3E:0D:F3:25:BE:5F:79:CD:67:67 keychainrootca-100, Oct 17, 2011, trustedCertEntry, Certificate fingerprint (MD5): D5:E9:81:40:C5:18:69:FC:46:2C:89:75:62:0F:AA:78 Hope that helps, - Dave From mik3hall at gmail.com Sat Mar 3 17:43:18 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 3 Mar 2012 19:43:18 -0600 Subject: trustAnchors parameter must be non-empty In-Reply-To: References: <0CA55830-4615-4DA4-8EE1-60643620E16E@gmail.com> <4DAF5E56-DC56-4170-8A3E-F5C418B84183@gmail.com> Message-ID: On Mar 3, 2012, at 7:38 PM, David Schlosnagle wrote: > On Sat, Mar 3, 2012 at 6:38 PM, Michael Hall wrote: >> Running into this... >> Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty >> >> trying to use some Google data stuff. >> Appears to be the same error as... >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145128 >> but that is closed as a duplicate to 7114062 which for some reason I can't look at? >> This bug is not available. > > By default, the OpenJDK build creates an empty trusted certificate > authority keystore ($JAVA_HOME/jre/lib/security/cacerts), so if you > attempt to do anything that would use those trusted certificates (e.g. > SSL, for certificate chain validations), it will fail with the > "java.security.InvalidAlgorithmParameterException: the trustAnchors > parameter must be non-empty" exception. I've run into this issue > before during the build when using OpenJDK as a bootstrap for another > OpenJDK build [1]. I'd suggest you look at importing the appropriate > certificates into your cacerts via keytool, or use the > javax.net.ssl.trustStore system property to point at an existing valid > keystore. Thanks for the detailed response. I will consider the workarounds when I try this again. For the time being I had gone back to Apple's 1.6. From swingler at apple.com Sat Mar 3 22:29:09 2012 From: swingler at apple.com (Mike Swingler) Date: Sat, 03 Mar 2012 22:29:09 -0800 Subject: trustAnchors parameter must be non-empty In-Reply-To: References: <0CA55830-4615-4DA4-8EE1-60643620E16E@gmail.com> Message-ID: <53F68927-F232-45F7-AD90-12B9C68880E0@apple.com> As a workaround, you can just copy the cacerts files from Java SE 6 into your OpenJDK bundle, but that is not a permanent solution. Long term, this is an issue that needs to be authoritatively addressed by Oracle - either by providing a cacerts file, or providing steps to generate one from the native platform. For Java SE 6, we derive the list from the list of root CAs in the Keychain...perhaps this process could be automated when building OpenJDK on the Mac. Regards, Mike Swingler Apple Inc. On Mar 3, 2012, at 4:50 PM, Mark Derricutt wrote: > I've see this same issue when using the maven-changes-plugin to generate a > change log, the source of the problem I was seeing was when using JavaMail, > however it occurred both on OpenJDK/OSX on my machine, and on a coworkers > Ubuntu machine ( I'm not sure if he was using OpenJDK or the official > Oracle Java7 tho ). > > Unable to see that issue you link as well... > > > -- > "Great artists are extremely selfish and arrogant things" ? Steven Wilson, > Porcupine Tree > > > On Sun, Mar 4, 2012 at 12:38 PM, Michael Hall wrote: > >> Running into this... >> Caused by: java.security.InvalidAlgorithmParameterException: the >> trustAnchors parameter must be non-empty >> >> trying to use some Google data stuff. >> Appears to be the same error as... >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145128 >> but that is closed as a duplicate to 7114062 which for some reason I can't >> look at? >> This bug is not available. >> >> From stephen.bannasch at deanbrook.org Sat Mar 3 22:49:36 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sun, 4 Mar 2012 01:49:36 -0500 Subject: building mlvm on Mac OS X 10.6.8 using xcode 3.2.6 Message-ID: I've updated https://gist.github.com/243072 with the latest changes in my MLVM build scripts. This applies the MLVM patches on to of the hsx/hotspot-com forest. John Rose is maintaining a copy of Michael McMahon patches integrating the macosx-port changes into jdk8 as an MLVM patch until they land. The build works well on Mac OS X 10.6.8 using xcode 3.2.6. I'd be curious if it works on 10.7 and with newer version of xcode. The java/lang/invoke tests all pass as well as the coroutine tests. The only failure I've seen so far is trying to run Swing but that probably doesn't have anything to do with the MLVM patches. *** testing Swing: running SwingSet2.jar: ./build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java -jar /Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar Exception in thread "main" java.awt.HeadlessException at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) at SwingSet2.main(SwingSet2.java:251) Running SwingSet2.jar works fine on my 10.6.8 system using a build of jdk7u-dev from a couple of days ago. From scott.kovatch at oracle.com Sun Mar 4 09:40:10 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Sun, 4 Mar 2012 09:40:10 -0800 Subject: trustAnchors parameter must be non-empty In-Reply-To: <53F68927-F232-45F7-AD90-12B9C68880E0@apple.com> References: <0CA55830-4615-4DA4-8EE1-60643620E16E@gmail.com> <53F68927-F232-45F7-AD90-12B9C68880E0@apple.com> Message-ID: As Mike correctly points out, copying the cacerts file is a short-term solution. Each licensee is responsible for obtaining their own set of root certificates for distribution. This was true when Apple was a licensee of Java, which is why we exported the root certificates from the keychain and put them in the cacerts file that gets distributed with Apple's JDK. OpenJDK, in that sense, is just another licensee. Oracle distributions of JDK 7 will have a full set of root certificates, the same ones distributed on all other platforms. If someone wanted to contribute the code and scripts for extracting the root CAs from the current OS's 'System Roots' keychain I should be able to integrate it post-7u4. -- Scott K. On Mar 3, 2012, at 10:29 PM, Mike Swingler wrote: > As a workaround, you can just copy the cacerts files from Java SE 6 into your OpenJDK bundle, but that is not a permanent solution. > > Long term, this is an issue that needs to be authoritatively addressed by Oracle - either by providing a cacerts file, or providing steps to generate one from the native platform. For Java SE 6, we derive the list from the list of root CAs in the Keychain...perhaps this process could be automated when building OpenJDK on the Mac. > > Regards, > Mike Swingler > Apple Inc. > > On Mar 3, 2012, at 4:50 PM, Mark Derricutt wrote: > >> I've see this same issue when using the maven-changes-plugin to generate a >> change log, the source of the problem I was seeing was when using JavaMail, >> however it occurred both on OpenJDK/OSX on my machine, and on a coworkers >> Ubuntu machine ( I'm not sure if he was using OpenJDK or the official >> Oracle Java7 tho ). >> >> Unable to see that issue you link as well... >> >> >> -- >> "Great artists are extremely selfish and arrogant things" ? Steven Wilson, >> Porcupine Tree >> >> >> On Sun, Mar 4, 2012 at 12:38 PM, Michael Hall wrote: >> >>> Running into this... >>> Caused by: java.security.InvalidAlgorithmParameterException: the >>> trustAnchors parameter must be non-empty >>> >>> trying to use some Google data stuff. >>> Appears to be the same error as... >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145128 >>> but that is closed as a duplicate to 7114062 which for some reason I can't >>> look at? >>> This bug is not available. >>> >>> > From swingler at apple.com Sun Mar 4 11:00:02 2012 From: swingler at apple.com (Mike Swingler) Date: Sun, 04 Mar 2012 11:00:02 -0800 Subject: trustAnchors parameter must be non-empty In-Reply-To: References: <0CA55830-4615-4DA4-8EE1-60643620E16E@gmail.com> <53F68927-F232-45F7-AD90-12B9C68880E0@apple.com> Message-ID: <40380BCE-A778-413E-A970-1487F237E0AE@apple.com> Scott, the RootCertExtractor.java you originally wrote is in Apple's private drop of Deploy under src/make/macosx/tools. I'm not sure why it does a native System.load() of libdeploy.jnilib, but perhaps it's not longer required. If this code could make it's way into jdk/make/tools, and get run from the JDK makefiles that would totally rock. ;-) Cheers, Mike Swingler Apple Inc. On Mar 4, 2012, at 9:40 AM, Scott Kovatch wrote: > As Mike correctly points out, copying the cacerts file is a short-term solution. > > Each licensee is responsible for obtaining their own set of root certificates for distribution. This was true when Apple was a licensee of Java, which is why we exported the root certificates from the keychain and put them in the cacerts file that gets distributed with Apple's JDK. OpenJDK, in that sense, is just another licensee. > > Oracle distributions of JDK 7 will have a full set of root certificates, the same ones distributed on all other platforms. > > If someone wanted to contribute the code and scripts for extracting the root CAs from the current OS's 'System Roots' keychain I should be able to integrate it post-7u4. > > -- Scott K. > > On Mar 3, 2012, at 10:29 PM, Mike Swingler wrote: > >> As a workaround, you can just copy the cacerts files from Java SE 6 into your OpenJDK bundle, but that is not a permanent solution. >> >> Long term, this is an issue that needs to be authoritatively addressed by Oracle - either by providing a cacerts file, or providing steps to generate one from the native platform. For Java SE 6, we derive the list from the list of root CAs in the Keychain...perhaps this process could be automated when building OpenJDK on the Mac. >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Mar 3, 2012, at 4:50 PM, Mark Derricutt wrote: >> >>> I've see this same issue when using the maven-changes-plugin to generate a >>> change log, the source of the problem I was seeing was when using JavaMail, >>> however it occurred both on OpenJDK/OSX on my machine, and on a coworkers >>> Ubuntu machine ( I'm not sure if he was using OpenJDK or the official >>> Oracle Java7 tho ). >>> >>> Unable to see that issue you link as well... >>> >>> >>> -- >>> "Great artists are extremely selfish and arrogant things" ? Steven Wilson, >>> Porcupine Tree >>> >>> >>> On Sun, Mar 4, 2012 at 12:38 PM, Michael Hall wrote: >>> >>>> Running into this... >>>> Caused by: java.security.InvalidAlgorithmParameterException: the >>>> trustAnchors parameter must be non-empty >>>> >>>> trying to use some Google data stuff. >>>> Appears to be the same error as... >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145128 >>>> but that is closed as a duplicate to 7114062 which for some reason I can't >>>> look at? >>>> This bug is not available. >>>> >>>> >> > From scott.kovatch at oracle.com Sun Mar 4 11:20:23 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Sun, 4 Mar 2012 11:20:23 -0800 Subject: trustAnchors parameter must be non-empty In-Reply-To: <40380BCE-A778-413E-A970-1487F237E0AE@apple.com> References: <0CA55830-4615-4DA4-8EE1-60643620E16E@gmail.com> <53F68927-F232-45F7-AD90-12B9C68880E0@apple.com> <40380BCE-A778-413E-A970-1487F237E0AE@apple.com> Message-ID: <04D7AA73-D23E-4E3C-B93F-563DC895FE13@oracle.com> Okay, I'll have a look at it. I thought it might be there, but I wasn't replying from my work laptop so I couldn't check. It probably looks at libdeploy because that was the easiest place I could think of to put the native code, and that already linked against the Security framework. -- Scott On Mar 4, 2012, at 11:00 AM, Mike Swingler wrote: > Scott, the RootCertExtractor.java you originally wrote is in Apple's private drop of Deploy under src/make/macosx/tools. I'm not sure why it does a native System.load() of libdeploy.jnilib, but perhaps it's not longer required. > > If this code could make it's way into jdk/make/tools, and get run from the JDK makefiles that would totally rock. ;-) > > Cheers, > Mike Swingler > Apple Inc. > > On Mar 4, 2012, at 9:40 AM, Scott Kovatch wrote: > >> As Mike correctly points out, copying the cacerts file is a short-term solution. >> >> Each licensee is responsible for obtaining their own set of root certificates for distribution. This was true when Apple was a licensee of Java, which is why we exported the root certificates from the keychain and put them in the cacerts file that gets distributed with Apple's JDK. OpenJDK, in that sense, is just another licensee. >> >> Oracle distributions of JDK 7 will have a full set of root certificates, the same ones distributed on all other platforms. >> >> If someone wanted to contribute the code and scripts for extracting the root CAs from the current OS's 'System Roots' keychain I should be able to integrate it post-7u4. >> >> -- Scott K. >> >> On Mar 3, 2012, at 10:29 PM, Mike Swingler wrote: >> >>> As a workaround, you can just copy the cacerts files from Java SE 6 into your OpenJDK bundle, but that is not a permanent solution. >>> >>> Long term, this is an issue that needs to be authoritatively addressed by Oracle - either by providing a cacerts file, or providing steps to generate one from the native platform. For Java SE 6, we derive the list from the list of root CAs in the Keychain...perhaps this process could be automated when building OpenJDK on the Mac. >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> >>> On Mar 3, 2012, at 4:50 PM, Mark Derricutt wrote: >>> >>>> I've see this same issue when using the maven-changes-plugin to generate a >>>> change log, the source of the problem I was seeing was when using JavaMail, >>>> however it occurred both on OpenJDK/OSX on my machine, and on a coworkers >>>> Ubuntu machine ( I'm not sure if he was using OpenJDK or the official >>>> Oracle Java7 tho ). >>>> >>>> Unable to see that issue you link as well... >>>> >>>> >>>> -- >>>> "Great artists are extremely selfish and arrogant things" ? Steven Wilson, >>>> Porcupine Tree >>>> >>>> >>>> On Sun, Mar 4, 2012 at 12:38 PM, Michael Hall wrote: >>>> >>>>> Running into this... >>>>> Caused by: java.security.InvalidAlgorithmParameterException: the >>>>> trustAnchors parameter must be non-empty >>>>> >>>>> trying to use some Google data stuff. >>>>> Appears to be the same error as... >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145128 >>>>> but that is closed as a duplicate to 7114062 which for some reason I can't >>>>> look at? >>>>> This bug is not available. >>>>> >>>>> >>> >> > From dmitry.cherepanov at oracle.com Sun Mar 4 10:40:22 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Sun, 04 Mar 2012 22:40:22 +0400 Subject: [7u4] Request for phase 2 approval for CR 7147066 - [macosx] FileDialog.getDirectory() returns incorrect directory Message-ID: <4F53B716.4040700@oracle.com> CR: http://bugs.sun.com/view_bug.do?bug_id=7147066 Webrev: http://cr.openjdk.java.net/~dcherepanov/7147066/webrev.2/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003384.html Reviewers: Anthony Petrov, Mike Swingler Rationale for inclusion in 7u4: This is a regression introduced in a recent build. Thanks, Dmitry From dmitry.cherepanov at oracle.com Sun Mar 4 11:55:41 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Sun, 04 Mar 2012 23:55:41 +0400 Subject: Request for review 7150345: [macosx] Can't type into applets Message-ID: <4F53C8BD.4090401@oracle.com> Hello, Here's a fix for a regression introduced by recent focus changes [1] (7129825). With the fix for 7129825 applied, we started rejecting cross-application focus requests and the proposed change partially reverts the focus changes to fix the embedded frame bug. Webrev - http://cr.openjdk.java.net/~dcherepanov/7150345/webrev.0/ Thanks, Dmitry [1] http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/bdf67b76a4f0 From edvard.wendelin at oracle.com Mon Mar 5 02:41:19 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 5 Mar 2012 11:41:19 +0100 Subject: [7u4] Request for phase 2 approval for CR 7147066 - [macosx] FileDialog.getDirectory() returns incorrect directory In-Reply-To: <4F53B716.4040700@oracle.com> References: <4F53B716.4040700@oracle.com> Message-ID: <37F71ED6-E909-4A90-BCE7-9C1B42F04E57@oracle.com> approved. On Mar 4, 2012, at 7:40 PM, Dmitry Cherepanov wrote: > CR: http://bugs.sun.com/view_bug.do?bug_id=7147066 > Webrev: http://cr.openjdk.java.net/~dcherepanov/7147066/webrev.2/ > Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003384.html > > Reviewers: Anthony Petrov, Mike Swingler > Rationale for inclusion in 7u4: This is a regression introduced in a recent build. > > Thanks, > Dmitry From anton.tarasov at oracle.com Mon Mar 5 03:48:56 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 05 Mar 2012 14:48:56 +0300 Subject: Request for review 7150345: [macosx] Can't type into applets In-Reply-To: <4F53C8BD.4090401@oracle.com> References: <4F53C8BD.4090401@oracle.com> Message-ID: <4F54A828.3040302@oracle.com> Hi Dmitry, With your changes you allow cross-app focus requests to an applet. This means that an applet may receive focus on java level, while native system will reject it. I see that the problem is that LWCToolkit.isApplicationActive() returns false for EmbeddedFrame. May be we should change the implementation of this method so that it look at the embedder? Thanks, Anton. On 3/4/12 10:55 PM, Dmitry Cherepanov wrote: > Hello, > > Here's a fix for a regression introduced by recent focus changes [1] > (7129825). With the fix for 7129825 applied, we started rejecting > cross-application focus requests and the proposed change partially > reverts the focus changes to fix the embedded frame bug. > > Webrev - http://cr.openjdk.java.net/~dcherepanov/7150345/webrev.0/ > > Thanks, > Dmitry > > [1] http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/bdf67b76a4f0 > From weijun.wang at oracle.com Mon Mar 5 04:48:13 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 05 Mar 2012 20:48:13 +0800 Subject: Who can fix this? 7151062: [macosx] SCDynamicStore prints error messages to stderr Message-ID: <4F54B60D.8020908@oracle.com> Hi All This is a native code issue in the security area. Anyone familiar with OS X programming can deal with it? Thanks Max -------- Original Message -------- *Change Request ID*: 7151062 *Synopsis*: [macosx] SCDynamicStore prints error messages to stderr === *Description* ============================================================ Simply running the following line sun.security.krb5.Config.getInstance(); on a Mac shows 2012-03-05 17:19:07.474 java[58479:1f03] Unable to load realm info from SCDynamicStore into the stderr. The words are printed by NSLog calls inside src/macosx/native/java/util/SCDynamicStoreConfig.m They should be removed or only shows when system property "sun.security.krb5.debug" is set to true, or when some other kind of logging option is turned on. *** (#1 of 1): 2012-03-05 09:36:48 GMT+00:00 weijun.wang at oracle.com From anthony.petrov at oracle.com Mon Mar 5 05:13:53 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 05 Mar 2012 17:13:53 +0400 Subject: building mlvm on Mac OS X 10.6.8 using xcode 3.2.6 In-Reply-To: References: Message-ID: <4F54BC11.4070005@oracle.com> Hi Stephen, On 03/04/12 10:49, Stephen Bannasch wrote: > The only failure I've seen so far is trying to run Swing but that > probably doesn't have anything to do with the MLVM patches. > > *** testing Swing: running SwingSet2.jar: > > ./build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java -jar > /Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar > > > Exception in thread "main" java.awt.HeadlessException > at > sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) > > at SwingSet2.main(SwingSet2.java:251) > > Running SwingSet2.jar works fine on my 10.6.8 system using a build of > jdk7u-dev from a couple of days ago. Are you running it on a local console or over an ssh connection? If you roll back your patch, build a vanilla OpenJDK 8, and run SwingSet the same way on the same machine with it, will it throw the exception? -- best regards, Anthony From stephen.bannasch at deanbrook.org Mon Mar 5 05:43:14 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Mon, 5 Mar 2012 08:43:14 -0500 Subject: building mlvm on Mac OS X 10.6.8 using xcode 3.2.6 In-Reply-To: <4F54BC11.4070005@oracle.com> References: <4F54BC11.4070005@oracle.com> Message-ID: At 5:13 PM +0400 3/5/12, Anthony Petrov wrote: >Hi Stephen, > >On 03/04/12 10:49, Stephen Bannasch wrote: >>The only failure I've seen so far is trying to run Swing but that >>probably doesn't have anything to do with the MLVM patches. >> >>*** testing Swing: running SwingSet2.jar: >> >>./build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java -jar >>/Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar >> >> >>Exception in thread "main" java.awt.HeadlessException >>at >>sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) >> >>at SwingSet2.main(SwingSet2.java:251) >> >>Running SwingSet2.jar works fine on my 10.6.8 system using a build of >>jdk7u-dev from a couple of days ago. > >Are you running it on a local console or over an ssh connection? In a local console >If you roll back your patch, build a vanilla OpenJDK 8, and run SwingSet the same way on the same machine with it, will it throw the exception? John Rose integrated Michael's webrev for integrating macosx-port intoi jdk8 into a patch that applies to hsx/hotspot-comp (along with the other MLVM patches). When I looked into how to apply Michael's webrev to jdk8/tl I couldn't see any easy way to download and apply the webrev.I can't scp the webrev. I couldn't find any instructions for how to download and apply a webrev for an "anonymous"user. FYI: I do have a working account on http://java.net -- I thought this used to be integrated into the openjdk ecosystem but apparently it isn't. From anthony.petrov at oracle.com Mon Mar 5 05:54:27 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 05 Mar 2012 17:54:27 +0400 Subject: building mlvm on Mac OS X 10.6.8 using xcode 3.2.6 In-Reply-To: References: <4F54BC11.4070005@oracle.com> Message-ID: <4F54C593.8080004@oracle.com> On 03/05/12 17:43, Stephen Bannasch wrote: > At 5:13 PM +0400 3/5/12, Anthony Petrov wrote: >> Hi Stephen, >> >> On 03/04/12 10:49, Stephen Bannasch wrote: >>> The only failure I've seen so far is trying to run Swing but that >>> probably doesn't have anything to do with the MLVM patches. >>> >>> *** testing Swing: running SwingSet2.jar: >>> >>> ./build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java -jar >>> /Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar >>> >>> >>> Exception in thread "main" java.awt.HeadlessException >>> at >>> sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) >>> >>> at SwingSet2.main(SwingSet2.java:251) >>> >>> Running SwingSet2.jar works fine on my 10.6.8 system using a build of >>> jdk7u-dev from a couple of days ago. >> >> Are you running it on a local console or over an ssh connection? > > In a local console Normally this shouldn't be happening then. >> If you roll back your patch, build a vanilla OpenJDK 8, and run SwingSet the same way on the same machine with it, will it throw the exception? > > John Rose integrated Michael's webrev for integrating macosx-port intoi jdk8 into a patch that applies to hsx/hotspot-comp (along with the other MLVM patches). > > When I looked into how to apply Michael's webrev to jdk8/tl I couldn't see any easy way to download and apply the webrev.I can't scp the webrev. I couldn't find any instructions for how to download and apply a webrev for an "anonymous"user. I don't seem to be seeing the Mac Port changes in a jdk8 repository (I checked jdk8/tl/jdk). Have Michael's fix been pushed already? I saw someone mentioning that... If not, then I suggest to wait till this is done, and then try again. -- best regards, Anthony From stephen.bannasch at deanbrook.org Mon Mar 5 07:32:27 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Mon, 5 Mar 2012 10:32:27 -0500 Subject: building mlvm on Mac OS X 10.6.8 using xcode 3.2.6 In-Reply-To: <4F54C593.8080004@oracle.com> References: <4F54BC11.4070005@oracle.com> <4F54C593.8080004@oracle.com> Message-ID: At 5:54 PM +0400 3/5/12, Anthony Petrov wrote: >On 03/05/12 17:43, Stephen Bannasch wrote: >>At 5:13 PM +0400 3/5/12, Anthony Petrov wrote: >>>Hi Stephen, >>> >>>On 03/04/12 10:49, Stephen Bannasch wrote: >>>>The only failure I've seen so far is trying to run Swing but that >>>>probably doesn't have anything to do with the MLVM patches. >>> >>>Are you running it on a local console or over an ssh connection? >> >>In a local console > >Normally this shouldn't be happening then. > >>>If you roll back your patch, build a vanilla OpenJDK 8, and run SwingSet the same way on the same machine with it, will it throw the exception? >> >>John Rose integrated Michael's webrev for integrating macosx-port intoi jdk8 into a patch that applies to hsx/hotspot-comp (along with the other MLVM patches). >> >>When I looked into how to apply Michael's webrev to jdk8/tl I couldn't see any easy way to download and apply the webrev.Ican't scp the webrev. I couldn't find any instructions for how to download and apply a webrev for an "anonymous"user. > >I don't seem to be seeing the Mac Port changes in a jdk8 repository (I checked jdk8/tl/jdk). Have Michael's fix been pushed already? I saw someone mentioning that... If not, then I suggest to wait till this is done, and then try again. As I understand it Michael McMahon changes here: http://cr.openjdk.java.net/~michaelm/7113349/jdk8/webrev.4/ Apply to jdk8/tl I just don't know any simple way for me to download and apply the webrev as a patch. So I was planning to wait until his webrev got integrated and try the test again. From anthony.petrov at oracle.com Mon Mar 5 07:39:47 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 05 Mar 2012 19:39:47 +0400 Subject: building mlvm on Mac OS X 10.6.8 using xcode 3.2.6 In-Reply-To: References: <4F54BC11.4070005@oracle.com> <4F54C593.8080004@oracle.com> Message-ID: <4F54DE43.7030104@oracle.com> On 03/05/12 19:32, Stephen Bannasch wrote: >> I don't seem to be seeing the Mac Port changes in a jdk8 repository (I checked jdk8/tl/jdk). Have Michael's fix been pushed already? I saw someone mentioning that... If not, then I suggest to wait till this is done, and then try again. > > As I understand it Michael McMahon changes here: > > http://cr.openjdk.java.net/~michaelm/7113349/jdk8/webrev.4/ > > Apply to jdk8/tl > > I just don't know any simple way for me to download and apply the webrev as a patch. You can find a link labeled "Patch of changes:" at the top of every webrev main page. > So I was planning to wait until his webrev got integrated and try the test again. Yes, I think this will be the best option. Please try this out once the changes are in the OpenJDK repo. -- best regards, Anthony From anthony.petrov at oracle.com Mon Mar 5 08:03:38 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 05 Mar 2012 20:03:38 +0400 Subject: [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode In-Reply-To: References: <4F4E3D18.3010109@oracle.com> <2AD6CB77-6932-4715-A21A-E7B786C5D6C6@apple.com> <4F4FE5D0.8010700@oracle.com> <69A334C5-89AB-49F4-A2BC-1C2E1C318EEE@apple.com> <4F50D737.40405@oracle.com> <4F50DC3C.7050803@oracle.com> Message-ID: <4F54E3DA.6070908@oracle.com> Hi Mike, A few points: * When a user enters the full screen using the OS widget, the full screen state isn't sync'd with Java's GraphicsDevice.getFullScreenWindow(). * Rather than calling native, I'd actually update the flag upon receiving native notifications about entering/leaving the FS mode. * If you call -toggleFullScreen: for a window w/o the NSWindowCollectionBehaviorFullScreenPrimary collection behavior, then the menus and the dock stay visible. Apart from that, there's no the default 10.7-specific animation for such windows when entering the FS mode. * If I mark an undecorated window as fullscreenable, its original size won't be restored when exiting the FS mode. So we can't simply enable the behavior automatically for all windows. An app must opt in. * Apple JDK 1.6 won't let a user exit a FS Java application, too. So at least we don't introduce a regression here. Also, the full screen is a restricted functionality that's unavailable to unsigned code by default. Thus we generally trust code that's able to enter the mode (in that it should let user out when needed). * The fix we're currently reviewing is supposed to fix a bug with popup windows not showing up for a Java app that doesn't use EAWT at all. As far as I've tested it, it does resolve the issue. And the behavior seems to be quite consistent with what Apple JDK 1.6 does. * The only thing the fix worsens is for EAWT-aware app: it hides the menu bar unconditionally when entering the FS mode. I've just fixed that by avoiding hiding the menu bar if a window is marked as FULLSCREENABLE. I believe that a new fix at http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.3/ is what we need in 7u4. We may file a new change request to address EAWT-specific issues in a future release. Please review. -- best regards, Anthony On 03/02/12 21:13, Mike Swingler wrote: > There are a few points here: > * If the user marks the window as "fullscreenable" using the eAWT API, > that puts a widget in the upper right corner of the window which allows > the user to toggle it into full screen themselves. > * When in full screen (using AWT or eAWT API), the user should be able > to click the blue exit fullscreen button in the menu bar at any time (if > they entered into full screen themselves) > * Generally, it is undesirable for the user to be stuck in a state where > they cannot return to the desktop. > > With the current diff, the isFullScreenMode boolean in Java will > definitely be out of sync if the user initiates either of these actions. > > Instead of trying to keep the knowledge of the full screen state in Java > behind a lock, I think you probably need query native to see if the > window is in the fullscreen state. I've used the following testcase to > test the existing eAWT fullscreen API, and I think you'll find it's easy > to get into a state where the user is stuck in windowed mode without a > menu bar, and that sometimes the user is locked out from returning to > windowed mode when they clicked on the window widget. > > After trying out your diff, I actually found it quite frustrating that > the menubar was suppressed and I *had* to use the four-finger swipe > gesture to get back to my desktop. How would you feel about just > dropping the whole menubar hiding stuff? Since the menu bar is > auto-hidden by default, users don't get to it unless they push up to the > top of the screen anyway. > > Try out this test case, and be sure to use the window widget, as well as > the button that programmatically fires the eAWT API. > > import java.awt.*; > import java.awt.event.ActionEvent; > import javax.swing.*; > > import com.apple.eawt.AppEvent.FullScreenEvent; > import com.apple.eawt.*; > > public class FullScreenTest { > public static void main(String args[]) { > SwingUtilities.invokeLater(new Runnable() { > public void run() { createFrame(); } > }); > } > > > static void createFrame() { > JFrame frame = new JFrame(); > frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > frame.setTitle(System.getProperty("java.version")); > > > Container contentPane = frame.getContentPane(); > contentPane.setLayout(new BorderLayout()); > contentPane.add(createPanel(), BorderLayout.CENTER); > > > // turns on the fullscreen window titlebar widget in the upper right corner > FullScreenUtilities.setWindowCanFullScreen(frame, true); > > > // useful for re-adjusting content or hiding/showing palette windows > FullScreenUtilities.addFullScreenListenerTo(frame, new FullScreenAdapter() { > public void windowExitingFullScreen(FullScreenEvent e) { > System.out.println("exiting"); > } > public void windowExitedFullScreen(FullScreenEvent e) { > System.out.println("exited"); > } > public void windowEnteringFullScreen(FullScreenEvent e) { > System.out.println("entering"); > } > public void windowEnteredFullScreen(FullScreenEvent e) { > System.out.println("entered"); > } > }); > > > frame.pack(); > frame.setVisible(true); > } > > static Component createPanel() { > final JPanel panel = new JPanel(new FlowLayout()); > > > // toggle FullScreen from a toolbar button > panel.add(new JButton(new AbstractAction("Full Screen Me!") { > public void actionPerformed(ActionEvent e) { > Application.getApplication().requestToggleFullScreen( > (Window)panel.getTopLevelAncestor()); > } > })); > > > return panel; > } > } > > Regards, > Mike Swingler > Apple Inc. > > On Mar 2, 2012, at 6:42 AM, Anthony Petrov wrote: > >> A tiny typo has been fixed, a new webrev is at: >> >> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.2/ >> >> -- >> best regards, >> Anthony >> >> On 3/2/2012 6:20 PM, Anthony Petrov wrote: >>> Thanks for your suggestions Mike. Here's the latest version of the fix: >>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.1/ >>> -- >>> best regards, >>> Anthony >>> On 3/2/2012 3:14 AM, Mike Swingler wrote: >>>> On Mar 1, 2012, at 1:10 PM, Anthony Petrov wrote: >>>> >>>>> Hi Mike, >>>>> >>>>> Thanks for the review! Please see my comments inline. >>>>> >>>>> On 3/1/2012 9:31 PM, Mike Swingler wrote: >>>>>> On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote: >>>>>>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.0/ >>>>>> A few points to consider: >>>>>> * To protect against the unrecognized selector problem, you should >>>>>> test if the AWTWindow object >>>>>> -respondsToSelector:@selector(toggleFullScreen) before just >>>>>> calling it. >>>>> I'm aware of -respondsToSelector. But I suppose that in that case >>>>> this simply won't work on 10.6.8 at all. Since >>>>> >>>>> a) presently it does work on 10.6.8 for reasons unknown, and >>>> >>>> If OpenJDK is built on Snow Leopard, it works fine. I believe the >>>> problem is the X11/FreeType versions in Lion are newer, and DYLD >>>> won't load libraries linked against older versions. But that is >>>> going to start me on my rant about how OpenJDK should bundle it's >>>> own FreeType... >>>> >>>>> b) we officially support 10.7+ only, hence the check makes little >>>>> sense in theory, and >>>> >>>> Please think of OpenJDK, not just Oracle's proprietary binaries. >>>> There are other users who currently compile on Snow Leopard and this >>>> is not an inconvenience, since 10.7-only API is very rare in the JDK. >>>> >>>>> c) from ObjC perspective sending an unknown selector isn't an >>>>> error, but just a warning, >>>> >>>> It is extremely poor form. The -respondsToSelector: check is very >>>> cheap, and is very obvious what it is guarding against. >>>> >>>>> it seems to me that having this warning printed out to the console >>>>> (which isn't seen by 99% of users anyway) is OK when running on >>>>> 10.6.8. Plus we get the full screen working there. Isn't it awesome? >>>> >>>> We know there are developers and users who will be running OpenJDK >>>> on Mac OS X 10.6.8, so it is perfectly reasonable to add this as an >>>> OS guard. We should not actively damage our ability to run on 10.6 >>>> if it's trivially avoidable. >>>> >>>>>> * Also, there is already API that calls -toggleFullScreen in the >>>>>> eAWT classes that you might not be aware of. You should probably >>>>>> test for interactions with that, since apps can opt their window >>>>>> into having a full screen widget icon and independently toggle >>>>>> fullscreen. >>>>> Thanks for pointing this out. I'll rework this code to make sure >>>>> calls from EAWT update the boolean flag. >>>> >>>> Great. >>>> >>>>>> * In some cases, seeing the menubar is actually desirable, where >>>>>> as in the "exclusive" mode, it's probably not. Perhaps you could >>>>>> consult a client property on the window to determine if the menu >>>>>> bar should be hidden? >>>>> Excellent idea! I think that by default the menu should be hidden >>>>> (for Java spec's sake). But if a client property is set, then the >>>>> menu would be visible. >>>> >>>> Cool. There are several client property readers already on the root >>>> AWT window that should be easily extendable. >>>> >>>>>> I like this overall solution, because it uses the native platform >>>>>> concept of full screen which doesn't trap the user from switching >>>>>> spaces like the Java SE 6 implementation did. >>>>> We've noticed an interesting detail with -toggleFullScreen when >>>>> it's used in a multi-screen environment. In that case the window >>>>> will go full screen on the biggest monitor (actually we have a >>>>> MacBook with an external monitor connected.) The OS seems to ignore >>>>> the screen where the window were before entering the FS mode (the >>>>> main notebook display). Is this OK? Can we force it to use the same >>>>> screen where the window is originally located for the FS mode? >>>> >>>> It's actually the monitor with the menu bar (the primary, as >>>> designated in the Monitor's preference pane). >>>> >>>> This is an issue with the OS, and should be filed at >>>> (it's known, but if you have a >>>> specific API suggestion to target a screen, or some sort of >>>> automatic behavior in mind, it would be good to provide specific >>>> suggestions in the bug). > From michael.x.mcmahon at oracle.com Mon Mar 5 08:05:26 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 05 Mar 2012 16:05:26 +0000 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> Message-ID: <4F54E446.6010205@oracle.com> I'm still having problems reproducing this, even with the same boot JDK you are using. I remember the original macosx-port hotspot had a build option called ALWAYS_PASS_TEST_GAMMA. So, presumably there has been an issue with this before. Based on what you say below about possible issues running an 8 gamma with a libjava from 7 is this some kind of boot strapping problem, which may need an option like the above until we get promoted macos builds where the right libjava can be pulled in? I don't know enough about gamma to know if this makes sense.. - Michael On 02/03/12 22:46, John Rose wrote: > On Mar 2, 2012, at 1:28 AM, Michael McMahon wrote: > >> I can't reproduce it. It must be something related to the boot JDK you are using. >> Is it a complete jdk7 image? > The JDK files I got via the DYLD_LIBRARY_PATH are in a download from this file: > http://download.java.net/jdk7u4/archive/b12/binaries/jdk-7u4-ea-bin-b12-macosx-amd64-16_feb_2012.dmg > > I got it from here: > http://jdk7.java.net/macportpreview/ > > -------- > /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/bin/java -fullversion > java full version "1.7.0_04-ea-b12" > -------- > /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/bin/java -Xinternalversion > Java HotSpot(TM) 64-Bit Server VM (23.0-b15) for bsd-amd64 JRE (1.7.0_04-ea-b12), built on Feb 16 2012 11:12:32 by "java_re" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) > -------- > > This is also the ALT_BOOTDIR I use for builds. > > When I built my own copy of hotspot (including gamma) I used a jdk8 repo (hsx/hotspot-comp/{hotspot,jdk,langtools}), plus your patches for 7113349. > > I wouldn't be surprised if there were random problems running a JDK8 gamma on top of a libjava.dylib from 1.7.0_04. > >> I do get a (different) error if I set DYLD_LIBRARY_PATH in the environment >> Are you actually setting this in your environment? >> I notice the sanity check isn't looking for this, which it should on Mac. > No, I don't set that, but the example commands I sent have settings for it. > > What's confusing (but maybe unimportant) is that the bug Stuart and I saw manifests only when libjava is put on the DLLP, but it does not manifest when the same libjava is loaded by some other unknown means. (The loading can be traced with DYLD_PRINT_LIBRARIES, as shown in my message.) > > HTH > > ? John From stephen.bannasch at deanbrook.org Mon Mar 5 12:52:55 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Mon, 5 Mar 2012 15:52:55 -0500 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F54E446.6010205@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> Message-ID: At 4:05 PM +0000 3/5/12, Michael McMahon wrote: >I'm still having problems reproducing this, even with the same boot JDK you are using. > >I remember the original macosx-port hotspot had a build option called ALWAYS_PASS_TEST_GAMMA. >So, presumably there has been an issue with this before. > >Based on what you say below about possible issues running an 8 gamma with a libjava from 7 >is this some kind of boot strapping problem, which may need an option like the above >until we get promoted macos builds where the right libjava can be pulled in? >I don't know enough about gamma to know if this makes sense.. I've reproduced John's error on 10.6.8 applying webrev.4 on top of jdk8/tl. Am setting ALT_BOOTDIR to 1.7.0_04 as built from jdk7u-dev on Mar 4. Here's what -Xinternalversion reports from that build: OpenJDK 64-Bit Server VM (23.0-b16) for bsd-amd64 JRE (1.7.0_04-internal-stephen_2012_03_04_02_12-b00), built on Mar 4 2012 02:23:33 by "stephen" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6) This is how I setup the repo, applied patches and initiated the build: https://gist.github.com/1980690 The error occurs running ./test_gamma: ... echo "Doing vm.make build:" Doing vm.make build: All done. cd bsd_amd64_compiler2/product && ./test_gamma Using java runtime at: /Users/stephen/Library/Java/JavaVirtualMachines/1.7.0_04-2012_03_04.jdk/Contents/Home/jre Error occurred during initialization of VM java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:432) at java.lang.System.initProperties(Native Method) at java.lang.System.initializeSystemClass(System.java:1115) From stuart.marks at oracle.com Mon Mar 5 15:29:31 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 05 Mar 2012 15:29:31 -0800 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> Message-ID: <4F554C5B.6030309@oracle.com> On 3/5/12 12:52 PM, Stephen Bannasch wrote: > At 4:05 PM +0000 3/5/12, Michael McMahon wrote: >> I'm still having problems reproducing this, even with the same boot JDK you are using. > > I've reproduced John's error on 10.6.8 applying webrev.4 on top of jdk8/tl. > > The error occurs running ./test_gamma: > ... > echo "Doing vm.make build:" > Doing vm.make build: > All done. > cd bsd_amd64_compiler2/product&& ./test_gamma > Using java runtime at: /Users/stephen/Library/Java/JavaVirtualMachines/1.7.0_04-2012_03_04.jdk/Contents/Home/jre > Error occurred during initialization of VM > java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:432) > at java.lang.System.initProperties(Native Method) > at java.lang.System.initializeSystemClass(System.java:1115) OK, I think I figured it out. It's our old friend LANG. Earlier in this thread, John had observed > The NPE is because libjava.dylib is handing a null value to Hashtable, for the key "user.language", in System.c. The user.language property comes from (or at least is related to) the LANG environment variable. If LANG is unset, I get this crash in test_gamma. If LANG is set to en_US.UTF-8 the build succeeds. Curiously, with LANG=en_US.UTF-8, the build log says WARNING: LANG has been set to en_US.UTF-8, this can cause build failures. Try setting LANG to 'C'. but the build succeeds. There is no corresponding warning if LANG is unset. :-( Also curiously, the jdk7u build on Mac doesn't have the same sensitivity to the absence of LANG. I'll try this out on other platforms. I'm not sure, but it could be that this problem is unrelated to Michael's changes. If so, then sorry for the noise. But at least we might have gotten a lead on some other build mysteries. s'marks From stephen.bannasch at deanbrook.org Mon Mar 5 17:40:55 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Mon, 5 Mar 2012 20:40:55 -0500 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F554C5B.6030309@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> <4F554C5B.6030309@oracle.com> Message-ID: At 3:29 PM -0800 3/5/12, Stuart Marks wrote: >On 3/5/12 12:52 PM, Stephen Bannasch wrote: >>At 4:05 PM +0000 3/5/12, Michael McMahon wrote: >>>I'm still having problems reproducing this, even with the same boot JDK you are using. >> >>I've reproduced John's error on 10.6.8 applying webrev.4 on top of jdk8/tl. >> >>The error occurs running ./test_gamma: >> ... >> echo "Doing vm.make build:" >> Doing vm.make build: >> All done. >> cd bsd_amd64_compiler2/product&& ./test_gamma >> Using java runtime at: /Users/stephen/Library/Java/JavaVirtualMachines/1.7.0_04-2012_03_04.jdk/Contents/Home/jre >> Error occurred during initialization of VM >> java.lang.NullPointerException >> at java.util.Hashtable.put(Hashtable.java:432) >> at java.lang.System.initProperties(Native Method) >> at java.lang.System.initializeSystemClass(System.java:1115) > >OK, I think I figured it out. It's our old friend LANG. > >Earlier in this thread, John had observed > >>The NPE is because libjava.dylib is handing a null value to Hashtable, for the key "user.language", in System.c. > >The user.language property comes from (or at least is related to) the LANG environment variable. IfLANG is unset, I get this crash in test_gamma. If LANG is set to en_US.UTF-8 the build succeeds. After adding LANG=C my build on Mac OS X 10.6.8 completed. However I still have the error running SwingSet2.jar (also present on MLVM) ./build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java -jar /Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar Exception in thread "main" java.awt.HeadlessException at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) at SwingSet2.main(SwingSet2.java:251) FYI: updated build scripts: https://gist.github.com/1980690 From dmitry.cherepanov at oracle.com Mon Mar 5 14:53:14 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Tue, 06 Mar 2012 02:53:14 +0400 Subject: Request for review 7150345: [macosx] Can't type into applets In-Reply-To: <4F54A828.3040302@oracle.com> References: <4F53C8BD.4090401@oracle.com> <4F54A828.3040302@oracle.com> Message-ID: <4F5543DA.7070005@oracle.com> Hi Anton, Anton V. Tarasov wrote: > With your changes you allow cross-app focus requests to an applet. > This means that an applet may receive focus on java level, while > native system will reject it. > > I see that the problem is that LWCToolkit.isApplicationActive() > returns false for EmbeddedFrame. > May be we should change the implementation of this method so that it > look at the embedder? Thanks for the review. Here's an update webrev: http://cr.openjdk.java.net/~dcherepanov/7150345/webrev.1 The fix introduces focus handlers for NPAPI focus events to start tracking the "active" state of the embedder and now it rejects focus requests if the embedder isn't active. Thanks, Dmitry From michael.x.mcmahon at oracle.com Tue Mar 6 03:02:36 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 06 Mar 2012 11:02:36 +0000 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F554C5B.6030309@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> <4F554C5B.6030309@oracle.com> Message-ID: <4F55EECC.4040206@oracle.com> On 05/03/12 23:29, Stuart Marks wrote: > On 3/5/12 12:52 PM, Stephen Bannasch wrote: >> At 4:05 PM +0000 3/5/12, Michael McMahon wrote: >>> I'm still having problems reproducing this, even with the same boot >>> JDK you are using. >> >> I've reproduced John's error on 10.6.8 applying webrev.4 on top of >> jdk8/tl. >> >> The error occurs running ./test_gamma: >> ... >> echo "Doing vm.make build:" >> Doing vm.make build: >> All done. >> cd bsd_amd64_compiler2/product&& ./test_gamma >> Using java runtime at: >> /Users/stephen/Library/Java/JavaVirtualMachines/1.7.0_04-2012_03_04.jdk/Contents/Home/jre >> Error occurred during initialization of VM >> java.lang.NullPointerException >> at java.util.Hashtable.put(Hashtable.java:432) >> at java.lang.System.initProperties(Native Method) >> at java.lang.System.initializeSystemClass(System.java:1115) > > OK, I think I figured it out. It's our old friend LANG. > > Earlier in this thread, John had observed > >> The NPE is because libjava.dylib is handing a null value to >> Hashtable, for the key "user.language", in System.c. > > The user.language property comes from (or at least is related to) the > LANG environment variable. If LANG is unset, I get this crash in > test_gamma. If LANG is set to en_US.UTF-8 the build succeeds. > > Curiously, with LANG=en_US.UTF-8, the build log says > > WARNING: LANG has been set to en_US.UTF-8, this can cause build > failures. > Try setting LANG to 'C'. > > but the build succeeds. There is no corresponding warning if LANG is > unset. :-( > > Also curiously, the jdk7u build on Mac doesn't have the same > sensitivity to the absence of LANG. I'll try this out on other platforms. > > I'm not sure, but it could be that this problem is unrelated to > Michael's changes. If so, then sorry for the noise. But at least we > might have gotten a lead on some other build mysteries. > > s'marks Great. That's good to know. From what I can see, the reason why 7u does not show the same symptom is because test_gamma bails out in the 7u build because it doesn't know the file/directory structure of the Apple (boot) JDK. So, it doesn't actually run the test. Since 8 is using an openjdk 7 bootstrap, it does know where to find the files and it runs the test. The main Java launcher is able to deal with LANG not being set. It sets user.language to a reasonable default. But, it appears like gamma doesn't do that (and hence the null key for Hashtable.put()). So, for the moment, I think we just have to ensure that LANG is set. I know the recommended value is "C", but it does work for the en_XX.UTF-8 locales. As was pointed out recently, there are other locales where it definitely doesn't work (due to dependencies in the build on the output of the date command iirc). - Michael. From anton.tarasov at oracle.com Tue Mar 6 04:05:36 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 06 Mar 2012 16:05:36 +0400 Subject: Request for review 7150345: [macosx] Can't type into applets In-Reply-To: <4F5543DA.7070005@oracle.com> References: <4F53C8BD.4090401@oracle.com> <4F54A828.3040302@oracle.com> <4F5543DA.7070005@oracle.com> Message-ID: <4F55FD90.5020409@oracle.com> I approve. Thanks, Anton. On 06.03.2012 2:53, Dmitry Cherepanov wrote: > Hi Anton, > > Anton V. Tarasov wrote: >> With your changes you allow cross-app focus requests to an applet. >> This means that an applet may receive focus on java level, while native system will reject it. >> >> I see that the problem is that LWCToolkit.isApplicationActive() returns false for EmbeddedFrame. >> May be we should change the implementation of this method so that it look at the embedder? > > Thanks for the review. Here's an update webrev: > > http://cr.openjdk.java.net/~dcherepanov/7150345/webrev.1 > > The fix introduces focus handlers for NPAPI focus events to start tracking the "active" state of > the embedder and now it rejects focus requests if the embedder isn't active. > > Thanks, > Dmitry From andrew.brygin at oracle.com Tue Mar 6 04:11:52 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Tue, 06 Mar 2012 16:11:52 +0400 Subject: [7u4] request for review: 7124219: [macosx] Unable to draw images to fullscreen Message-ID: <4F55FF08.2000401@oracle.com> Hello, Failed tests use buffer strategy to render the test content. However, this approach does not work, because method flip() is not implemented in window component peer. We can implement corresponding method in LWWindowPeer where required buffers are already present. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124219 Webrev: http://cr.openjdk.java.net/~bae/7124219/webrev/ Thanks, Andrew From sergey.bylokhov at oracle.com Tue Mar 6 04:39:43 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 06 Mar 2012 16:39:43 +0400 Subject: [7u4] Request for review: 7124523 [macosx] b216: Mising part of applet functionality In-Reply-To: <4F4E16C7.7040705@oracle.com> References: <4F4E16C7.7040705@oracle.com> Message-ID: <4F56058F.1010403@oracle.com> Does anybody has a chance to review it? Thanks. 29.02.2012 16:15, Sergey Bylokhov wrote: > Hi Everyone, > The size of components is a bit bigger and one of the buttons simply > doesn't fit into the window. Default size of the demo window should be > increased. Two demos affected. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124523 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124523/webrev.00/ > -- Best regards, Sergey. From sergey.bylokhov at oracle.com Tue Mar 6 04:40:09 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 06 Mar 2012 16:40:09 +0400 Subject: [7u4] Request for review: 7124548 [macosx] Memory leak in JOptionPane.createDialog In-Reply-To: <4F4E1ED4.3090506@oracle.com> References: <4F4E1ED4.3090506@oracle.com> Message-ID: <4F5605A9.4070509@oracle.com> Does anybody has a chance to review it? Thanks. 29.02.2012 16:49, Sergey Bylokhov wrote: > Hi Everyone, > It would be good to break connection to window peer when we dispose > CGLayer. Because CGlayer can be used in the CGLSurfaceData which can > be cached in BufferedContext.validatedSrcData. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124548 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124548/webrev.00/ > -- Best regards, Sergey. From sergey.bylokhov at oracle.com Tue Mar 6 05:03:22 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 06 Mar 2012 17:03:22 +0400 Subject: [7u4] request for review: 7124219: [macosx] Unable to draw images to fullscreen In-Reply-To: <4F55FF08.2000401@oracle.com> References: <4F55FF08.2000401@oracle.com> Message-ID: <4F560B1A.7070207@oracle.com> Hi, Andrew. Looks good. 06.03.2012 16:11, Andrew Brygin wrote: > Hello, > > Failed tests use buffer strategy to render the test content. However, > this approach does not work, because method flip() is not implemented > in window component peer. > We can implement corresponding method in LWWindowPeer where required > buffers are already present. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124219 > Webrev: http://cr.openjdk.java.net/~bae/7124219/webrev/ > > Thanks, > Andrew -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Mar 6 06:17:25 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 06 Mar 2012 18:17:25 +0400 Subject: [7u4] Request for review: 7124523 [macosx] b216: Mising part of applet functionality In-Reply-To: <4F4E16C7.7040705@oracle.com> References: <4F4E16C7.7040705@oracle.com> Message-ID: <4F561C75.2090001@oracle.com> Hi Sergey, The fix looks fine to me. -- best regards, Anthony On 2/29/2012 4:15 PM, Sergey Bylokhov wrote: > Hi Everyone, > The size of components is a bit bigger and one of the buttons simply > doesn't fit into the window. Default size of the demo window should be > increased. Two demos affected. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124523 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124523/webrev.00/ > From scott.kovatch at oracle.com Tue Mar 6 08:28:36 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 6 Mar 2012 08:28:36 -0800 Subject: [7u4] Request for review: 7124548 [macosx] Memory leak in JOptionPane.createDialog In-Reply-To: <4F5605A9.4070509@oracle.com> References: <4F4E1ED4.3090506@oracle.com> <4F5605A9.4070509@oracle.com> Message-ID: <5C6D526F-9781-4D49-9B48-9EC332A1C9A5@oracle.com> The change itself looks fine. Do you need to guard against someone using the object after dispose() is called or will the NPEs just indicate a programmer error of some kind? -- Scott On Mar 6, 2012, at 4:40 AM, Sergey Bylokhov wrote: > Does anybody has a chance to review it? > Thanks. > > 29.02.2012 16:49, Sergey Bylokhov wrote: >> Hi Everyone, >> It would be good to break connection to window peer when we dispose CGLayer. Because CGlayer can be used in the CGLSurfaceData which can be cached in BufferedContext.validatedSrcData. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124548 >> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124548/webrev.00/ >> > > > -- > Best regards, Sergey. > From anthony.petrov at oracle.com Tue Mar 6 08:43:51 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 06 Mar 2012 20:43:51 +0400 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> <4F554C5B.6030309@oracle.com> Message-ID: <4F563EC7.8080901@oracle.com> Hi Michael, Could you please confirm if SwingSet2 works for you when you're using a JDK8 build with your Mac Port changes in place? -- best regards, Anthony On 3/6/2012 5:40 AM, Stephen Bannasch wrote: > At 3:29 PM -0800 3/5/12, Stuart Marks wrote: >> On 3/5/12 12:52 PM, Stephen Bannasch wrote: >>> At 4:05 PM +0000 3/5/12, Michael McMahon wrote: >>>> I'm still having problems reproducing this, even with the same boot JDK you are using. >>> I've reproduced John's error on 10.6.8 applying webrev.4 on top of jdk8/tl. >>> >>> The error occurs running ./test_gamma: >>> ... >>> echo "Doing vm.make build:" >>> Doing vm.make build: >>> All done. >>> cd bsd_amd64_compiler2/product&& ./test_gamma >>> Using java runtime at: /Users/stephen/Library/Java/JavaVirtualMachines/1.7.0_04-2012_03_04.jdk/Contents/Home/jre >>> Error occurred during initialization of VM >>> java.lang.NullPointerException >>> at java.util.Hashtable.put(Hashtable.java:432) >>> at java.lang.System.initProperties(Native Method) >>> at java.lang.System.initializeSystemClass(System.java:1115) >> OK, I think I figured it out. It's our old friend LANG. >> >> Earlier in this thread, John had observed >> >>> The NPE is because libjava.dylib is handing a null value to Hashtable, for the key "user.language", in System.c. >> The user.language property comes from (or at least is related to) the LANG environment variable. IfLANG is unset, I get this crash in test_gamma. If LANG is set to en_US.UTF-8 the build succeeds. > > After adding LANG=C my build on Mac OS X 10.6.8 completed. > > However I still have the error running SwingSet2.jar (also present on MLVM) > > ./build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java -jar /Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar > > Exception in thread "main" java.awt.HeadlessException > at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) > at SwingSet2.main(SwingSet2.java:251) > > FYI: updated build scripts: https://gist.github.com/1980690 > From michael.x.mcmahon at oracle.com Tue Mar 6 08:58:30 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 06 Mar 2012 16:58:30 +0000 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F563EC7.8080901@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> <4F554C5B.6030309@oracle.com> <4F563EC7.8080901@oracle.com> Message-ID: <4F564236.3040802@oracle.com> Yes, it does. It's probably worth waiting until I push the changes to the jdk8/tl forest (which I plan to do later today). Then Stephen can be sure he is building a consistent source base. - Michael. On 06/03/12 16:43, Anthony Petrov wrote: > Hi Michael, > > Could you please confirm if SwingSet2 works for you when you're using > a JDK8 build with your Mac Port changes in place? > > -- > best regards, > Anthony > > On 3/6/2012 5:40 AM, Stephen Bannasch wrote: >> At 3:29 PM -0800 3/5/12, Stuart Marks wrote: >>> On 3/5/12 12:52 PM, Stephen Bannasch wrote: >>>> At 4:05 PM +0000 3/5/12, Michael McMahon wrote: >>>>> I'm still having problems reproducing this, even with the same >>>>> boot JDK you are using. >>>> I've reproduced John's error on 10.6.8 applying webrev.4 on top of >>>> jdk8/tl. >>>> >>>> The error occurs running ./test_gamma: >>>> ... >>>> echo "Doing vm.make build:" >>>> Doing vm.make build: >>>> All done. >>>> cd bsd_amd64_compiler2/product&& ./test_gamma >>>> Using java runtime at: >>>> /Users/stephen/Library/Java/JavaVirtualMachines/1.7.0_04-2012_03_04.jdk/Contents/Home/jre >>>> Error occurred during initialization of VM >>>> java.lang.NullPointerException >>>> at java.util.Hashtable.put(Hashtable.java:432) >>>> at java.lang.System.initProperties(Native Method) >>>> at java.lang.System.initializeSystemClass(System.java:1115) >>> OK, I think I figured it out. It's our old friend LANG. >>> >>> Earlier in this thread, John had observed >>> >>>> The NPE is because libjava.dylib is handing a null value to >>>> Hashtable, for the key "user.language", in System.c. >>> The user.language property comes from (or at least is related to) >>> the LANG environment variable. IfLANG is unset, I get this crash in >>> test_gamma. If LANG is set to en_US.UTF-8 the build succeeds. >> >> After adding LANG=C my build on Mac OS X 10.6.8 completed. >> >> However I still have the error running SwingSet2.jar (also present on >> MLVM) >> >> ./build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java >> -jar /Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar >> >> Exception in thread "main" java.awt.HeadlessException >> at >> sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) >> at SwingSet2.main(SwingSet2.java:251) >> >> FYI: updated build scripts: https://gist.github.com/1980690 >> From sergey.bylokhov at oracle.com Tue Mar 6 16:53:35 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 07 Mar 2012 04:53:35 +0400 Subject: [7u4] Request for review: 7124548 [macosx] Memory leak in JOptionPane.createDialog In-Reply-To: <5C6D526F-9781-4D49-9B48-9EC332A1C9A5@oracle.com> References: <4F4E1ED4.3090506@oracle.com> <4F5605A9.4070509@oracle.com> <5C6D526F-9781-4D49-9B48-9EC332A1C9A5@oracle.com> Message-ID: <4F56B18F.2080600@oracle.com> Hi, Scott. From my point of view it should not be used after disposing. But it should be well tested before push. 06.03.2012 20:28, Scott Kovatch wrote: > The change itself looks fine. Do you need to guard against someone using the object after dispose() is called or will the NPEs just indicate a programmer error of some kind? > > -- Scott > > On Mar 6, 2012, at 4:40 AM, Sergey Bylokhov wrote: > >> Does anybody has a chance to review it? >> Thanks. >> >> 29.02.2012 16:49, Sergey Bylokhov wrote: >>> Hi Everyone, >>> It would be good to break connection to window peer when we dispose CGLayer. Because CGlayer can be used in the CGLSurfaceData which can be cached in BufferedContext.validatedSrcData. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124548 >>> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124548/webrev.00/ >>> >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From stuart.marks at oracle.com Tue Mar 6 22:50:32 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 06 Mar 2012 22:50:32 -0800 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F55EECC.4040206@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> <4F554C5B.6030309@oracle.com> <4F55EECC.4040206@oracle.com> Message-ID: <4F570538.1070104@oracle.com> On 3/6/12 3:02 AM, Michael McMahon wrote: > On 05/03/12 23:29, Stuart Marks wrote: >> If LANG is unset, I get this crash in test_gamma. > Since 8 is using an openjdk 7 bootstrap, it does know where to find the files > and it runs > the test. The main Java launcher is able to deal with LANG not being set. It sets > user.language to a reasonable default. But, it appears like gamma doesn't do that > (and hence the null key for Hashtable.put()). > > So, for the moment, I think we just have to ensure that LANG is set. I know > the recommended value is "C", but it does work for the en_XX.UTF-8 locales. > As was pointed out recently, there are other locales where it definitely > doesn't work > (due to dependencies in the build on the output of the date command iirc). So, is it a bug (low priority) that the Mac build fails in this obscure fashion if LANG is unset? It succeeds with LANG unset, on Linux at least. Or perhaps the build instructions should be modified to *require* that LANG be set. Right now README-builds.html implies that LANG should be set, by setting it in examples, but it's not an explicit requirement. s'marks From alexandr.scherbatiy at oracle.com Wed Mar 7 00:52:51 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 07 Mar 2012 12:52:51 +0400 Subject: [7u4] Request for phase 2 approval for CR 7148281 - [macosx] JTabbedPane tabs with HTML text do not render correctly Message-ID: <4F5721E3.9060104@oracle.com> Bug: http://bugs.sun.com/view_bug.do?bug_id=7148281 Webrev: http://cr.openjdk.java.net/~alexsch/7148281/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003456.html Reviewers: Alexander Zuev (kizune) Rationale for inclusion into 7u4: Required to NetBeans highly visible issue. NetBeans IDE uses HTML in titles of tabs in the output to highlight the outputs which are important to the user. On 7u4 on Mac the HTML breaks tabs appearance. Thanks, Alexandr. From edvard.wendelin at oracle.com Wed Mar 7 01:07:29 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 07 Mar 2012 10:07:29 +0100 Subject: [7u4] Request for phase 2 approval for CR 7148281 - [macosx] JTabbedPane tabs with HTML text do not render correctly In-Reply-To: <4F5721E3.9060104@oracle.com> References: <4F5721E3.9060104@oracle.com> Message-ID: <4F572551.8030205@oracle.com> Approved. On 03/07/2012 09:52 AM, Alexander Scherbatiy wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7148281 > Webrev: http://cr.openjdk.java.net/~alexsch/7148281/webrev.00/ > Review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003456.html > Reviewers: Alexander Zuev (kizune) > > Rationale for inclusion into 7u4: Required to NetBeans highly visible > issue. > NetBeans IDE uses HTML in titles of tabs in the output to highlight > the outputs which are important to the user. > On 7u4 on Mac the HTML breaks tabs appearance. > > > Thanks, > Alexandr. > From edvard.wendelin at oracle.com Wed Mar 7 01:51:21 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 07 Mar 2012 10:51:21 +0100 Subject: [7u4] Request for phase 2 approval for CR 7150516 - [macosx] appletviewer shouldn't link against libX11 on the Mac In-Reply-To: <4F50EBCD.4050608@oracle.com> References: <4F50EBCD.4050608@oracle.com> Message-ID: <4F572F99.7020006@oracle.com> I thought I had approved this already, but can't find the email so I'm giving it a second attempt :) On 03/02/2012 04:48 PM, Anthony Petrov wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7150516 > Webrev: > http://cr.openjdk.java.net/~anthony/x-22-appletviewerLibX11-7150516.0/ > Review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003457.html > > Reviewer: Mike Swingler (swingler) > > Rationale for inclusion in 7u4: X11 is an optional package on Mac OS > X. Since OpenJDK on the Mac uses Cocoa for GUI, the tools shouldn't > link against an unused GUI library. With this fix we eliminate the > dependency on the libX11 library. > > -- > best regards, > Anthony > From andrew.brygin at oracle.com Wed Mar 7 05:27:19 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 07 Mar 2012 17:27:19 +0400 Subject: [7u4] Request for phase 2 approval for CR 7124219 - [macosx] Unable to draw images to fullscreen Message-ID: <4F576237.4080603@oracle.com> CR: http://bugs.sun.com/view_bug.do?bug_id=7124219 Webrev: http://cr.openjdk.java.net/~bae/7124219/webrev Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003504.html Reviewers: Sergey Bylokhov Rationale for inclusion in 7u4: this problem prevents execution of a test suite for full screen rendering. Thanks, Andrew From edvard.wendelin at oracle.com Wed Mar 7 05:41:38 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 07 Mar 2012 14:41:38 +0100 Subject: [7u4] Request for phase 2 approval for CR 7124219 - [macosx] Unable to draw images to fullscreen In-Reply-To: <4F576237.4080603@oracle.com> References: <4F576237.4080603@oracle.com> Message-ID: <4F576592.4020503@oracle.com> Pre-approved pending release team approval. Once critical approved, please feel free to push. Cheers, Edvard On 03/07/2012 02:27 PM, Andrew Brygin wrote: > CR: http://bugs.sun.com/view_bug.do?bug_id=7124219 > Webrev: http://cr.openjdk.java.net/~bae/7124219/webrev > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003504.html > > Reviewers: Sergey Bylokhov > Rationale for inclusion in 7u4: this problem prevents execution of a > test suite for full screen rendering. > > Thanks, > Andrew From Alexander.Potochkin at oracle.com Wed Mar 7 06:56:07 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Wed, 07 Mar 2012 18:56:07 +0400 Subject: [7u4] Request for review: 7124548 [macosx] Memory leak in JOptionPane.createDialog In-Reply-To: <4F4E1ED4.3090506@oracle.com> References: <4F4E1ED4.3090506@oracle.com> Message-ID: <4F577707.7@oracle.com> Hello Sergey Looks good Thanks alexp > Hi Everyone, > It would be good to break connection to window peer when we dispose > CGLayer. Because CGlayer can be used in the CGLSurfaceData which can > be cached in BufferedContext.validatedSrcData. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124548 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124548/webrev.00/ > From leonid.romanov at oracle.com Wed Mar 7 07:55:51 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 7 Mar 2012 19:55:51 +0400 Subject: [7u4] Review request for CR 7124321: [macosx] TrayIcon MouseListener is never triggered Message-ID: Hi, Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124321 webrev: http://cr.openjdk.java.net/~leonidr/7124321/ Thanks, Leonid. From michael.x.mcmahon at oracle.com Wed Mar 7 08:15:23 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 07 Mar 2012 16:15:23 +0000 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F570538.1070104@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> <4F554C5B.6030309@oracle.com> <4F55EECC.4040206@oracle.com> <4F570538.1070104@oracle.com> Message-ID: <4F57899B.7050305@oracle.com> On 07/03/12 06:50, Stuart Marks wrote: > On 3/6/12 3:02 AM, Michael McMahon wrote: >> On 05/03/12 23:29, Stuart Marks wrote: >>> If LANG is unset, I get this crash in test_gamma. >> Since 8 is using an openjdk 7 bootstrap, it does know where to find >> the files >> and it runs >> the test. The main Java launcher is able to deal with LANG not being >> set. It sets >> user.language to a reasonable default. But, it appears like gamma >> doesn't do that >> (and hence the null key for Hashtable.put()). >> >> So, for the moment, I think we just have to ensure that LANG is set. >> I know >> the recommended value is "C", but it does work for the en_XX.UTF-8 >> locales. >> As was pointed out recently, there are other locales where it definitely >> doesn't work >> (due to dependencies in the build on the output of the date command >> iirc). > > So, is it a bug (low priority) that the Mac build fails in this > obscure fashion if LANG is unset? It succeeds with LANG unset, on > Linux at least. > > Or perhaps the build instructions should be modified to *require* that > LANG be set. Right now README-builds.html implies that LANG should be > set, by setting it in examples, but it's not an explicit requirement. > > s'marks Stuart, I will submit two bugs - 1) on the gamma issue in jdk7u and 8 and 2) to check for LANG in the Mac OS X sanity check as a temporary workaround until 1) is fixed. I have a fix for 2) ready for review. Also, just to let folks know that the initial jdk8 changeset for Mac OS has been pushed to the jdk8/tl forest. All going well, it should appear in the jdk8 master next Tuesday. In the meantime, it is available in jdk8/tl. - Michael. From anthony.petrov at oracle.com Wed Mar 7 08:24:58 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 07 Mar 2012 20:24:58 +0400 Subject: [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode In-Reply-To: <4F54E3DA.6070908@oracle.com> References: <4F4E3D18.3010109@oracle.com> <2AD6CB77-6932-4715-A21A-E7B786C5D6C6@apple.com> <4F4FE5D0.8010700@oracle.com> <69A334C5-89AB-49F4-A2BC-1C2E1C318EEE@apple.com> <4F50D737.40405@oracle.com> <4F50DC3C.7050803@oracle.com> <4F54E3DA.6070908@oracle.com> Message-ID: <4F578BDA.6000001@oracle.com> Could I get a review for the latest version of the fix please? Here's the link for your convenience: http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.3/ -- best regards, Anthony On 3/5/2012 8:03 PM, Anthony Petrov wrote: > Hi Mike, > > A few points: > > * When a user enters the full screen using the OS widget, the full > screen state isn't sync'd with Java's GraphicsDevice.getFullScreenWindow(). > > * Rather than calling native, I'd actually update the flag upon > receiving native notifications about entering/leaving the FS mode. > > * If you call -toggleFullScreen: for a window w/o the > NSWindowCollectionBehaviorFullScreenPrimary collection behavior, then > the menus and the dock stay visible. Apart from that, there's no the > default 10.7-specific animation for such windows when entering the FS mode. > > * If I mark an undecorated window as fullscreenable, its original size > won't be restored when exiting the FS mode. So we can't simply enable > the behavior automatically for all windows. An app must opt in. > > * Apple JDK 1.6 won't let a user exit a FS Java application, too. So at > least we don't introduce a regression here. Also, the full screen is a > restricted functionality that's unavailable to unsigned code by default. > Thus we generally trust code that's able to enter the mode (in that it > should let user out when needed). > > * The fix we're currently reviewing is supposed to fix a bug with popup > windows not showing up for a Java app that doesn't use EAWT at all. As > far as I've tested it, it does resolve the issue. And the behavior seems > to be quite consistent with what Apple JDK 1.6 does. > > * The only thing the fix worsens is for EAWT-aware app: it hides the > menu bar unconditionally when entering the FS mode. I've just fixed that > by avoiding hiding the menu bar if a window is marked as FULLSCREENABLE. > I believe that a new fix at > > http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.3/ > > is what we need in 7u4. We may file a new change request to address > EAWT-specific issues in a future release. > > Please review. > > -- > best regards, > Anthony > > On 03/02/12 21:13, Mike Swingler wrote: >> There are a few points here: >> * If the user marks the window as "fullscreenable" using the eAWT API, >> that puts a widget in the upper right corner of the window which allows >> the user to toggle it into full screen themselves. >> * When in full screen (using AWT or eAWT API), the user should be able >> to click the blue exit fullscreen button in the menu bar at any time (if >> they entered into full screen themselves) >> * Generally, it is undesirable for the user to be stuck in a state where >> they cannot return to the desktop. >> >> With the current diff, the isFullScreenMode boolean in Java will >> definitely be out of sync if the user initiates either of these actions. >> >> Instead of trying to keep the knowledge of the full screen state in Java >> behind a lock, I think you probably need query native to see if the >> window is in the fullscreen state. I've used the following testcase to >> test the existing eAWT fullscreen API, and I think you'll find it's easy >> to get into a state where the user is stuck in windowed mode without a >> menu bar, and that sometimes the user is locked out from returning to >> windowed mode when they clicked on the window widget. >> >> After trying out your diff, I actually found it quite frustrating that >> the menubar was suppressed and I *had* to use the four-finger swipe >> gesture to get back to my desktop. How would you feel about just >> dropping the whole menubar hiding stuff? Since the menu bar is >> auto-hidden by default, users don't get to it unless they push up to the >> top of the screen anyway. >> >> Try out this test case, and be sure to use the window widget, as well as >> the button that programmatically fires the eAWT API. >> >> import java.awt.*; >> import java.awt.event.ActionEvent; >> import javax.swing.*; >> >> import com.apple.eawt.AppEvent.FullScreenEvent; >> import com.apple.eawt.*; >> >> public class FullScreenTest { >> public static void main(String args[]) { >> SwingUtilities.invokeLater(new Runnable() { >> public void run() { createFrame(); } >> }); >> } >> >> >> static void createFrame() { >> JFrame frame = new JFrame(); >> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> frame.setTitle(System.getProperty("java.version")); >> >> >> Container contentPane = frame.getContentPane(); >> contentPane.setLayout(new BorderLayout()); >> contentPane.add(createPanel(), BorderLayout.CENTER); >> >> >> // turns on the fullscreen window titlebar widget in the upper right >> corner >> FullScreenUtilities.setWindowCanFullScreen(frame, true); >> >> >> // useful for re-adjusting content or hiding/showing palette windows >> FullScreenUtilities.addFullScreenListenerTo(frame, new >> FullScreenAdapter() { >> public void windowExitingFullScreen(FullScreenEvent e) { >> System.out.println("exiting"); >> } >> public void windowExitedFullScreen(FullScreenEvent e) { >> System.out.println("exited"); >> } >> public void windowEnteringFullScreen(FullScreenEvent e) { >> System.out.println("entering"); >> } >> public void windowEnteredFullScreen(FullScreenEvent e) { >> System.out.println("entered"); >> } >> }); >> >> >> frame.pack(); >> frame.setVisible(true); >> } >> >> static Component createPanel() { >> final JPanel panel = new JPanel(new FlowLayout()); >> >> >> // toggle FullScreen from a toolbar button >> panel.add(new JButton(new AbstractAction("Full Screen Me!") { >> public void actionPerformed(ActionEvent e) { >> Application.getApplication().requestToggleFullScreen( >> (Window)panel.getTopLevelAncestor()); >> } >> })); >> >> >> return panel; >> } >> } >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Mar 2, 2012, at 6:42 AM, Anthony Petrov wrote: >> >>> A tiny typo has been fixed, a new webrev is at: >>> >>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.2/ >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 3/2/2012 6:20 PM, Anthony Petrov wrote: >>>> Thanks for your suggestions Mike. Here's the latest version of the fix: >>>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.1/ >>>> -- >>>> best regards, >>>> Anthony >>>> On 3/2/2012 3:14 AM, Mike Swingler wrote: >>>>> On Mar 1, 2012, at 1:10 PM, Anthony Petrov wrote: >>>>> >>>>>> Hi Mike, >>>>>> >>>>>> Thanks for the review! Please see my comments inline. >>>>>> >>>>>> On 3/1/2012 9:31 PM, Mike Swingler wrote: >>>>>>> On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote: >>>>>>>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.0/ >>>>>>>> >>>>>>> A few points to consider: >>>>>>> * To protect against the unrecognized selector problem, you should >>>>>>> test if the AWTWindow object >>>>>>> -respondsToSelector:@selector(toggleFullScreen) before just >>>>>>> calling it. >>>>>> I'm aware of -respondsToSelector. But I suppose that in that case >>>>>> this simply won't work on 10.6.8 at all. Since >>>>>> >>>>>> a) presently it does work on 10.6.8 for reasons unknown, and >>>>> >>>>> If OpenJDK is built on Snow Leopard, it works fine. I believe the >>>>> problem is the X11/FreeType versions in Lion are newer, and DYLD >>>>> won't load libraries linked against older versions. But that is >>>>> going to start me on my rant about how OpenJDK should bundle it's >>>>> own FreeType... >>>>> >>>>>> b) we officially support 10.7+ only, hence the check makes little >>>>>> sense in theory, and >>>>> >>>>> Please think of OpenJDK, not just Oracle's proprietary binaries. >>>>> There are other users who currently compile on Snow Leopard and this >>>>> is not an inconvenience, since 10.7-only API is very rare in the JDK. >>>>> >>>>>> c) from ObjC perspective sending an unknown selector isn't an >>>>>> error, but just a warning, >>>>> >>>>> It is extremely poor form. The -respondsToSelector: check is very >>>>> cheap, and is very obvious what it is guarding against. >>>>> >>>>>> it seems to me that having this warning printed out to the console >>>>>> (which isn't seen by 99% of users anyway) is OK when running on >>>>>> 10.6.8. Plus we get the full screen working there. Isn't it awesome? >>>>> >>>>> We know there are developers and users who will be running OpenJDK >>>>> on Mac OS X 10.6.8, so it is perfectly reasonable to add this as an >>>>> OS guard. We should not actively damage our ability to run on 10.6 >>>>> if it's trivially avoidable. >>>>> >>>>>>> * Also, there is already API that calls -toggleFullScreen in the >>>>>>> eAWT classes that you might not be aware of. You should probably >>>>>>> test for interactions with that, since apps can opt their window >>>>>>> into having a full screen widget icon and independently toggle >>>>>>> fullscreen. >>>>>> Thanks for pointing this out. I'll rework this code to make sure >>>>>> calls from EAWT update the boolean flag. >>>>> >>>>> Great. >>>>> >>>>>>> * In some cases, seeing the menubar is actually desirable, where >>>>>>> as in the "exclusive" mode, it's probably not. Perhaps you could >>>>>>> consult a client property on the window to determine if the menu >>>>>>> bar should be hidden? >>>>>> Excellent idea! I think that by default the menu should be hidden >>>>>> (for Java spec's sake). But if a client property is set, then the >>>>>> menu would be visible. >>>>> >>>>> Cool. There are several client property readers already on the root >>>>> AWT window that should be easily extendable. >>>>> >>>>>>> I like this overall solution, because it uses the native platform >>>>>>> concept of full screen which doesn't trap the user from switching >>>>>>> spaces like the Java SE 6 implementation did. >>>>>> We've noticed an interesting detail with -toggleFullScreen when >>>>>> it's used in a multi-screen environment. In that case the window >>>>>> will go full screen on the biggest monitor (actually we have a >>>>>> MacBook with an external monitor connected.) The OS seems to ignore >>>>>> the screen where the window were before entering the FS mode (the >>>>>> main notebook display). Is this OK? Can we force it to use the same >>>>>> screen where the window is originally located for the FS mode? >>>>> >>>>> It's actually the monitor with the menu bar (the primary, as >>>>> designated in the Monitor's preference pane). >>>>> >>>>> This is an issue with the OS, and should be filed at >>>>> (it's known, but if you have a >>>>> specific API suggestion to target a screen, or some sort of >>>>> automatic behavior in mind, it would be good to provide specific >>>>> suggestions in the bug). >> From stephen.bannasch at deanbrook.org Wed Mar 7 09:43:12 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 7 Mar 2012 12:43:12 -0500 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F57899B.7050305@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> <4F554C5B.6030309@oracle.com> <4F55EECC.4040206@oracle.com> <4F570538.1070104@oracle.com> <4F57899B.7050305@oracle.com> Message-ID: At 4:15 PM +0000 3/7/12, Michael McMahon wrote: >On 07/03/12 06:50, Stuart Marks wrote: >>On 3/6/12 3:02 AM, Michael McMahon wrote: >>>On 05/03/12 23:29, Stuart Marks wrote: >>>>If LANG is unset, I get this crash in test_gamma. >>>Since 8 is using an openjdk 7 bootstrap, it does know where to find the files >>>and it runs >>>the test. The main Java launcher is able to deal with LANG not being set. It sets >>>user.language to a reasonable default. But, it appears like gamma doesn't do that >>>(and hence the null key for Hashtable.put()). >>> >>>So, for the moment, I think we just have to ensure that LANG is set. I know >>>the recommended value is "C", but it does work for the en_XX.UTF-8 locales. >>>As was pointed out recently, there are other locales where it definitely >>>doesn't work >>>(due to dependencies in the build on the output of the date command iirc). >> >>So, is it a bug (low priority) that the Mac build fails in this obscure fashion if LANG is unset? It succeeds with LANG unset, on Linux at least. >> >>Or perhaps the build instructions should be modified to *require* that LANG be set. Right now README-builds.html implies that LANG should be set, by setting it in examples, but it's not an explicit requirement. >> >>s'marks >Stuart, > >I will submit two bugs - 1) on the gamma issue in jdk7u and 8 >and 2) to check for LANG in the Mac OS X sanity check as a temporary workaround until 1) is fixed. >I have a fix for 2) ready for review. > >Also, just to let folks know that the initial jdk8 changeset for Mac OS has been pushed to >the jdk8/tl forest. All going well, it should appear in the jdk8 master next Tuesday. >In the meantime, it is available in jdk8/tl. Just built jdk8/tl (without any patching) on my 10.6.8 system. Build completes fine. jtreg testing of jdk/test/java/lang/invoke/ passes. Testing with SwingSet2.jar fails: /build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java -jar /Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar Exception in thread "main" java.awt.HeadlessException at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) at SwingSet2.main(SwingSet2.java:251) My build settings: unset LC_ALL LANG CLASSPATH JAVA_HOME LD_LIBRARY_PATH; make LANG=C LP64=1 OPENJDK=true ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=$TEST_GAMMA ALT_BOOTDIR=$SYSTEM_JAVA_1_7 HOTSPOT_BUILD_JOBS=$BUILD_JOBS Which expands into: make LANG=C LP64=1 OPENJDK=true ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=/Users/stephen/Library/Java/JavaVirtualMachines/1.7.0_04-2012_03_04.jdk/Contents/Home HOTSPOT_BUILD_JOBS=4 From Alexander.Potochkin at oracle.com Wed Mar 7 10:35:05 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Wed, 07 Mar 2012 22:35:05 +0400 Subject: [7u4] request for review: 7144065: [macosx] Orphaned Choice popup window Message-ID: <4F57AA59.30804@oracle.com> Hello Please review the following fix: http://cr.openjdk.java.net/~alexp/7144065/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144065 Showing the popup with the awt.Choice as the target allow us to reuse the standard Swing mouse grab functionality Thanks alexp From michael.x.mcmahon at oracle.com Wed Mar 7 14:20:27 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 07 Mar 2012 22:20:27 +0000 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> <4F554C5B.6030309@oracle.com> <4F55EECC.4040206@oracle.com> <4F570538.1070104@oracle.com> <4F57899B.7050305@oracle.com> Message-ID: <4F57DF2B.7060804@oracle.com> On 07/03/12 17:43, Stephen Bannasch wrote: > At 4:15 PM +0000 3/7/12, Michael McMahon wrote: >> On 07/03/12 06:50, Stuart Marks wrote: >>> On 3/6/12 3:02 AM, Michael McMahon wrote: >>>> On 05/03/12 23:29, Stuart Marks wrote: >>>>> If LANG is unset, I get this crash in test_gamma. >>>> Since 8 is using an openjdk 7 bootstrap, it does know where to find the files >>>> and it runs >>>> the test. The main Java launcher is able to deal with LANG not being set. It sets >>>> user.language to a reasonable default. But, it appears like gamma doesn't do that >>>> (and hence the null key for Hashtable.put()). >>>> >>>> So, for the moment, I think we just have to ensure that LANG is set. I know >>>> the recommended value is "C", but it does work for the en_XX.UTF-8 locales. >>>> As was pointed out recently, there are other locales where it definitely >>>> doesn't work >>>> (due to dependencies in the build on the output of the date command iirc). >>> So, is it a bug (low priority) that the Mac build fails in this obscure fashion if LANG is unset? It succeeds with LANG unset, on Linux at least. >>> >>> Or perhaps the build instructions should be modified to *require* that LANG be set. Right now README-builds.html implies that LANG should be set, by setting it in examples, but it's not an explicit requirement. >>> >>> s'marks >> Stuart, >> >> I will submit two bugs - 1) on the gamma issue in jdk7u and 8 >> and 2) to check for LANG in the Mac OS X sanity check as a temporary workaround until 1) is fixed. >> I have a fix for 2) ready for review. >> >> Also, just to let folks know that the initial jdk8 changeset for Mac OS has been pushed to >> the jdk8/tl forest. All going well, it should appear in the jdk8 master next Tuesday. >> In the meantime, it is available in jdk8/tl. > Just built jdk8/tl (without any patching) on my 10.6.8 system. > > Build completes fine. > > jtreg testing of jdk/test/java/lang/invoke/ passes. > > Testing with SwingSet2.jar fails: > > /build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java -jar /Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar > > Exception in thread "main" java.awt.HeadlessException > at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) > at SwingSet2.main(SwingSet2.java:251) > > My build settings: > > unset LC_ALL LANG CLASSPATH JAVA_HOME LD_LIBRARY_PATH; > make LANG=C LP64=1 OPENJDK=true ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=$TEST_GAMMA ALT_BOOTDIR=$SYSTEM_JAVA_1_7 HOTSPOT_BUILD_JOBS=$BUILD_JOBS > > Which expands into: > > make LANG=C LP64=1 OPENJDK=true ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=/Users/stephen/Library/Java/JavaVirtualMachines/1.7.0_04-2012_03_04.jdk/Contents/Home HOTSPOT_BUILD_JOBS=4 > > > I've just realised there was a hotspot change in my local forest that I had forgotten about. Hotspot changes are pushed through a different route. So, I'm not sure when exactly this will get fixed. I will file a bug on it right now. But, here is the relevant patch, which you can apply yourself. - Michael, diff -r 0ed0960af27d src/os/bsd/vm/os_bsd.cpp --- a/src/os/bsd/vm/os_bsd.cpp Thu Feb 23 12:03:08 2012 -0800 +++ b/src/os/bsd/vm/os_bsd.cpp Wed Mar 07 22:14:09 2012 +0000 @@ -5811,7 +5811,7 @@ char buf[MAXPATHLEN]; char libmawtpath[MAXPATHLEN]; const char *xawtstr = "/xawt/libmawt" JNI_LIB_SUFFIX; - const char *new_xawtstr = "/libawt_xawt" JNI_LIB_SUFFIX; + const char *new_xawtstr = "/xawt/libawt_xawt" JNI_LIB_SUFFIX; char *p; // Get path to libjvm.so From stephen.bannasch at deanbrook.org Wed Mar 7 15:31:18 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 7 Mar 2012 18:31:18 -0500 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F57DF2B.7060804@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> <4F554C5B.6030309@oracle.com> <4F55EECC.4040206@oracle.com> <4F570538.1070104@oracle.com> <4F57899B.7050305@oracle.com> <4F57DF2B.7060804@oracle.com> Message-ID: At 10:20 PM +0000 3/7/12, Michael McMahon wrote: >I've just realised there was a hotspot change in my local forest that I had forgotten about. >Hotspot changes are pushed through a different route. So, I'm not sure when exactly this >will get fixed. I will file a bug on it right now. But, here is the relevant patch, which you >can apply yourself. > >- Michael, > >diff -r 0ed0960af27d src/os/bsd/vm/os_bsd.cpp >--- a/src/os/bsd/vm/os_bsd.cpp Thu Feb 23 12:03:08 2012 -0800 >+++ b/src/os/bsd/vm/os_bsd.cpp Wed Mar 07 22:14:09 2012 +0000 >@@ -5811,7 +5811,7 @@ > char buf[MAXPATHLEN]; > char libmawtpath[MAXPATHLEN]; > const char *xawtstr = "/xawt/libmawt" JNI_LIB_SUFFIX; >- const char *new_xawtstr = "/libawt_xawt" JNI_LIB_SUFFIX; >+ const char *new_xawtstr = "/xawt/libawt_xawt" JNI_LIB_SUFFIX; > char *p; > > // Get path to libjvm.so Thanks, That fixed the problem running SwingSet2.jar From michael.x.mcmahon at oracle.com Thu Mar 8 04:15:36 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 08 Mar 2012 12:15:36 +0000 Subject: RFR: 7152186: java.awt.HeadlessException when running AWT apps [macosx] Message-ID: <4F58A2E8.3090900@oracle.com> Can I get the following webrev reviewed for JDK8 please? http://cr.openjdk.java.net/~michaelm/7152186/webrev.1/ It is for the issue reported a few days ago where a HeadlessException is being thrown in AWT. So, we'd like to fix this issue in JDK rather than Hotspot. This change makes the Mac AWT toolkits compatible (in terms of location) with other platforms (eg was jre/lib/xawt/libawt_xawt.dylib --> jre/lib/libawt_xawt.dylib) - same for the lwawt and headless toolkits. The libraries will now be named: jre/lib/libawt_headless.dylib jre/lib/libawt_lwawt.dylib jre/lib/libawt_xawt.dylib I'd like to push this change today. After it has been pushed, then the patch I sent yesterday (to hotspot) should be removed, if anyone has applied it. Thanks, Michael. From anthony.petrov at oracle.com Thu Mar 8 04:21:54 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 08 Mar 2012 16:21:54 +0400 Subject: [7u4] Review request for CR 7124321: [macosx] TrayIcon MouseListener is never triggered In-Reply-To: References: Message-ID: <4F58A462.9010701@oracle.com> Hi Leonid, The fix looks fine. BTW, the dummyFrame field might be declared as 'final' in the CTrayIcon class. -- best regards, Anthony On 3/7/2012 7:55 PM, Leonid Romanov wrote: > Hi, > Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124321 > webrev: http://cr.openjdk.java.net/~leonidr/7124321/ > > Thanks, > Leonid. > > From anthony.petrov at oracle.com Thu Mar 8 04:44:17 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 08 Mar 2012 16:44:17 +0400 Subject: RFR: 7152186: java.awt.HeadlessException when running AWT apps [macosx] In-Reply-To: <4F58A2E8.3090900@oracle.com> References: <4F58A2E8.3090900@oracle.com> Message-ID: <4F58A9A1.9050904@oracle.com> Hi Michael, The fix looks fine to me. -- best regards, Anthony On 3/8/2012 4:15 PM, Michael McMahon wrote: > Can I get the following webrev reviewed for JDK8 please? > > http://cr.openjdk.java.net/~michaelm/7152186/webrev.1/ > > It is for the issue reported a few days ago where a HeadlessException > is being thrown in AWT. So, we'd like to fix this issue in JDK rather > than Hotspot. > This change makes the Mac AWT toolkits compatible (in terms of location) > with > other platforms (eg was jre/lib/xawt/libawt_xawt.dylib --> > jre/lib/libawt_xawt.dylib) > - same for the lwawt and headless toolkits. > > The libraries will now be named: > > jre/lib/libawt_headless.dylib > jre/lib/libawt_lwawt.dylib > jre/lib/libawt_xawt.dylib > > I'd like to push this change today. After it has been pushed, then the > patch > I sent yesterday (to hotspot) should be removed, if anyone has applied it. > > Thanks, > Michael. From chris.hegarty at oracle.com Thu Mar 8 05:30:50 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 08 Mar 2012 13:30:50 +0000 Subject: RFR: 7152186: java.awt.HeadlessException when running AWT apps [macosx] In-Reply-To: <4F58A9A1.9050904@oracle.com> References: <4F58A2E8.3090900@oracle.com> <4F58A9A1.9050904@oracle.com> Message-ID: <4F58B48A.7050608@oracle.com> On 08/03/2012 12:44, Anthony Petrov wrote: > Hi Michael, > > The fix looks fine to me. +1, thanks for resolving this. -Chris. > > -- > best regards, > Anthony > > On 3/8/2012 4:15 PM, Michael McMahon wrote: >> Can I get the following webrev reviewed for JDK8 please? >> >> http://cr.openjdk.java.net/~michaelm/7152186/webrev.1/ >> >> It is for the issue reported a few days ago where a HeadlessException >> is being thrown in AWT. So, we'd like to fix this issue in JDK rather >> than Hotspot. >> This change makes the Mac AWT toolkits compatible (in terms of >> location) with >> other platforms (eg was jre/lib/xawt/libawt_xawt.dylib --> >> jre/lib/libawt_xawt.dylib) >> - same for the lwawt and headless toolkits. >> >> The libraries will now be named: >> >> jre/lib/libawt_headless.dylib >> jre/lib/libawt_lwawt.dylib >> jre/lib/libawt_xawt.dylib >> >> I'd like to push this change today. After it has been pushed, then the >> patch >> I sent yesterday (to hotspot) should be removed, if anyone has applied >> it. >> >> Thanks, >> Michael. From anthony.petrov at oracle.com Thu Mar 8 08:17:53 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 08 Mar 2012 20:17:53 +0400 Subject: [7u4] Review request for 7148275: [macosx] setIconImages() not working correctly (distorted icon when minimized) Message-ID: <4F58DBB1.7070007@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7148275 at: http://cr.openjdk.java.net/~anthony/x-23-lowResIcon.0/ -- best regards, Anthony From weijun.wang at oracle.com Fri Mar 9 02:25:34 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 09 Mar 2012 18:25:34 +0800 Subject: What is ARCH on Mac Message-ID: <4F59DA9E.6020009@oracle.com> Hi All I'm quite confused on this. I'm able to build openjdk-8 on my Mac and the build is inside build/macosx-amd64 direcory. The "make sanity" command also shows ARCH=amd64. However, if I go into the test directory and run "make" there, it's trying to test against build/macosx-i586. Then I find out it's because on my system "uname -m" returns i386. Is there any problem with my system? Thanks Max From kirk at kodewerk.com Fri Mar 9 02:31:18 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 9 Mar 2012 11:31:18 +0100 Subject: What is ARCH on Mac In-Reply-To: <4F59DA9E.6020009@oracle.com> References: <4F59DA9E.6020009@oracle.com> Message-ID: Weijun, File a bug 'cos Mac's are Intel, not AMD. It's been a while but I've seen some questionable code in the JDK w.r.t. testing for OSX. Maybe with the merge this is coming back to bite??? Kirk On 2012-03-09, at 11:25 AM, Weijun Wang wrote: > Hi All > > I'm quite confused on this. I'm able to build openjdk-8 on my Mac and the build is inside build/macosx-amd64 direcory. The "make sanity" command also shows ARCH=amd64. However, if I go into the test directory and run "make" there, it's trying to test against build/macosx-i586. Then I find out it's because on my system "uname -m" returns i386. > > Is there any problem with my system? > > Thanks > Max From michael.x.mcmahon at oracle.com Fri Mar 9 02:52:46 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 09 Mar 2012 10:52:46 +0000 Subject: What is ARCH on Mac In-Reply-To: <4F59DA9E.6020009@oracle.com> References: <4F59DA9E.6020009@oracle.com> Message-ID: <4F59E0FE.8060005@oracle.com> On 09/03/12 10:25, Weijun Wang wrote: > Hi All > > I'm quite confused on this. I'm able to build openjdk-8 on my Mac and > the build is inside build/macosx-amd64 direcory. The "make sanity" > command also shows ARCH=amd64. However, if I go into the test > directory and run "make" there, it's trying to test against > build/macosx-i586. Then I find out it's because on my system "uname > -m" returns i386. > > Is there any problem with my system? > > Thanks > Max I've never gotten to the bottom of that. On my 10.7.3 box, here is the output from some relevant commands: uname -m => x86_64 arch => i386 machine => i486 It's configurable somehow. The man page for arch(1) says system settings for this are in /System/Library/archSettings. But, that file doesn't exist on my system. BTW. The Open jdk ARCH will be changing from amd64 to x86_64. - Michael From edvard.wendelin at oracle.com Fri Mar 9 06:17:24 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 09 Mar 2012 15:17:24 +0100 Subject: Request for phase 2 approval for CR 7124262 - [macosx] Drag events go to a wrong child. In-Reply-To: <4F4BA54F.8090107@oracle.com> References: <4F4BA54F.8090107@oracle.com> Message-ID: <4F5A10F4.9090506@oracle.com> I see that you've pushed this already :) Approved. On 02/27/2012 04:46 PM, Alexander Zuev wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7124262 > Webrev: http://cr.openjdk.java.net/~kizune/7124262/webrev.02/ > Review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003293.html > Reviewers: Alexander Potochkin (alexp), Sergey Bylokhov (serb) > > Rationale for inclusion into 7u4: The major functionality without this > fix is not working, > it is currently not possible to use Drag and Drop functionality in any > application that has at least one AWT element > in the active window. The fix is considered low-risk since only > MacOS-specific files were modified and no > cross-platform functionality is affected. > > With best regards, > Alexander Zuev From dalibor.topic at oracle.com Fri Mar 9 07:22:24 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 09 Mar 2012 16:22:24 +0100 Subject: Approval request for CR 7147456 In-Reply-To: <4F46C2C8.70706@oracle.com> References: <0D5D0D12-CBFD-4448-B153-206FAFB2D30A@oracle.com> <4F46C2C8.70706@oracle.com> Message-ID: <4F5A2030.7060808@oracle.com> This one doesn't seem to have been pushed yet into any 7u forest. cheers, dalibor topic On 2/23/12 11:50 PM, Paul Hohensee wrote: > Approved. > > Paul > > On 2/23/12 2:39 PM, Greg Brown wrote: >> Requesting approval to commit fix for CR 7147456. Reviewed by Mike Swingler and Scott Kovatch: >> >> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-February/001987.html >> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-February/002007.html >> >> On Feb 21, 2012, at 11:57 AM, Greg Brown wrote: >> >>> Based on feedback on macosx-port-dev, this change flattens the key structure used in the plist for JavaAppLauncher. It also renames the generated "JavaVM" to "Java" to clarify the folder's intent (the folder does not contain a Java VM but rather resources related to execution of the Java part of the launcher app): >>> >>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003239.html >>> >>> Webrev: >>> http://cr.openjdk.java.net/~gkbrown/7147456/webrev.00/ >>> -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 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 swingler at apple.com Fri Mar 9 07:45:51 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 09 Mar 2012 07:45:51 -0800 Subject: [7u4] Review request for 7148275: [macosx] setIconImages() not working correctly (distorted icon when minimized) In-Reply-To: <4F58DBB1.7070007@oracle.com> References: <4F58DBB1.7070007@oracle.com> Message-ID: On Mar 8, 2012, at 8:17 AM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7148275 at: > > http://cr.openjdk.java.net/~anthony/x-23-lowResIcon.0/ Looks good to me. Regards, Mike Swingler Apple Inc. From astrange at apple.com Fri Mar 9 11:40:45 2012 From: astrange at apple.com (Alexander Strange) Date: Fri, 09 Mar 2012 14:40:45 -0500 Subject: What is ARCH on Mac In-Reply-To: <4F59E0FE.8060005@oracle.com> References: <4F59DA9E.6020009@oracle.com> <4F59E0FE.8060005@oracle.com> Message-ID: <3385E17B-642F-4A94-AA85-A116A872B78D@apple.com> On Mar 9, 2012, at 5:52 AM, Michael McMahon wrote: > On 09/03/12 10:25, Weijun Wang wrote: >> Hi All >> >> I'm quite confused on this. I'm able to build openjdk-8 on my Mac and the build is inside build/macosx-amd64 direcory. The "make sanity" command also shows ARCH=amd64. However, if I go into the test directory and run "make" there, it's trying to test against build/macosx-i586. Then I find out it's because on my system "uname -m" returns i386. >> >> Is there any problem with my system? >> >> Thanks >> Max > I've never gotten to the bottom of that. On my 10.7.3 box, here is the output > from some relevant commands: > > uname -m => x86_64 > arch => i386 > machine => i486 uname -m displays the architecture of the kernel, which is not necessarily the same as the userland architecture. That is, both the 32-bit and 64-bit x86 kernels support 32-bit and 64-bit programs. If you want to check if the system supports x86-64 userland, use 'sysctl hw.cpu64bit_capable'. From kelly.ohair at oracle.com Fri Mar 9 12:54:40 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 9 Mar 2012 12:54:40 -0800 Subject: What is ARCH on Mac In-Reply-To: <4F59DA9E.6020009@oracle.com> References: <4F59DA9E.6020009@oracle.com> Message-ID: <861ED3B4-135F-428E-8B43-D6707A2E7F2F@oracle.com> The test/Makefiles do not share the Defs-*.gmk files that the build makefile do. They are pretty independent and could easily have this wrong. Granted the makefiles, product, properties, bundle names, and directory names all suffer from a little ARCH craziness. :^( -kto On Mar 9, 2012, at 2:25 AM, Weijun Wang wrote: > Hi All > > I'm quite confused on this. I'm able to build openjdk-8 on my Mac and the build is inside build/macosx-amd64 direcory. The "make sanity" command also shows ARCH=amd64. However, if I go into the test directory and run "make" there, it's trying to test against build/macosx-i586. Then I find out it's because on my system "uname -m" returns i386. > > Is there any problem with my system? > > Thanks > Max From anton.tarasov at oracle.com Sun Mar 11 04:34:27 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Sun, 11 Mar 2012 15:34:27 +0400 Subject: [7u4] request for review: 7144065: [macosx] Orphaned Choice popup window In-Reply-To: <4F57AA59.30804@oracle.com> References: <4F57AA59.30804@oracle.com> Message-ID: <4F5C8DC3.5030302@oracle.com> Hi Alex, I like the solution! Approved. Thanks, Anton. On 07.03.2012 22:35, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7144065/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144065 > > Showing the popup with the awt.Choice as the target > allow us to reuse the standard Swing mouse grab functionality > > Thanks > alexp From sergey.bylokhov at oracle.com Sun Mar 11 06:30:43 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 11 Mar 2012 17:30:43 +0400 Subject: [7u4] Request for review: 7149913 [macosx] Deadlock in LWTextComponentPeer Message-ID: <4F5CA903.8050603@oracle.com> Hi Everyone, Deadlock happens when 2 threads lock delegateLock and DefaultCaret object in different order. Removed code initially was added to stop recursion between paintPeer and addDirtyRegion( repaintPeer()->paintPeer()->print()->addDirtyRegion()->repaintPeer()-> etc), but it is impossible now because repaintPeer() asynchronous. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 Webrev can be found at: http://cr.openjdk.java.net/~serb/7149913/webrev.00/ -- Best regards, Sergey. From Alexander.Potochkin at oracle.com Sun Mar 11 10:04:00 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Sun, 11 Mar 2012 21:04:00 +0400 Subject: [7u4] Request for review: 7149913 [macosx] Deadlock in LWTextComponentPeer In-Reply-To: <4F5CA903.8050603@oracle.com> References: <4F5CA903.8050603@oracle.com> Message-ID: <4F5CDB00.4080304@oracle.com> Hello Sergey Looks good! alexp > Hi Everyone, > Deadlock happens when 2 threads lock delegateLock and DefaultCaret > object in different order. Removed code initially was added to stop > recursion between paintPeer and addDirtyRegion( > repaintPeer()->paintPeer()->print()->addDirtyRegion()->repaintPeer()-> > etc), but it is impossible now because repaintPeer() asynchronous. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7149913/webrev.00/ > From Alexander.Potochkin at oracle.com Sun Mar 11 10:31:11 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Sun, 11 Mar 2012 21:31:11 +0400 Subject: [7u4] Request for approval: 7144065: [macosx] Orphaned Choice popup window Message-ID: <4F5CE15F.4050706@oracle.com> Requesting approval to commit fix for CR 7144065. http://cr.openjdk.java.net/~alexp/7144065/webrev.00/ Reviewed by Anton Tarasov http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003540.html the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144065 Thanks alexp From edvard.wendelin at oracle.com Mon Mar 12 04:59:40 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 12 Mar 2012 12:59:40 +0100 Subject: [7u4] Request for approval: 7144065: [macosx] Orphaned Choice popup window In-Reply-To: <4F5CE15F.4050706@oracle.com> References: <4F5CE15F.4050706@oracle.com> Message-ID: <4F5DE52C.4050003@oracle.com> Pre-approved pending release team approval. Once you see OK in CR, please push. Cheers, Edvard On 03/11/2012 06:31 PM, Alexander Potochkin wrote: > Requesting approval to commit fix for CR 7144065. > > http://cr.openjdk.java.net/~alexp/7144065/webrev.00/ > > Reviewed by Anton Tarasov > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003540.html > > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144065 > > Thanks > alexp > From anthony.petrov at oracle.com Mon Mar 12 06:01:20 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 12 Mar 2012 17:01:20 +0400 Subject: [7u4] Request for phase 2 approval for CR 7148275 - [macosx] setIconImages() not working correctly (distorted icon when minimized) Message-ID: <4F5DF3A0.70606@oracle.com> Bug: http://bugs.sun.com/view_bug.do?bug_id=7148275 Webrev: http://cr.openjdk.java.net/~anthony/x-23-lowResIcon.0/ Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003531.html Reviewer: Mike Swingler (swingler) Rationale for inclusion in 7u4: the fix resolves a noticeable visual artifact that manifests itself when minimizing top-level windows to the dock. The fix is rather trivial, and thus considered as LOW-risk. The fix has been verified with NetBeans and some manual JDK regression tests. -- best regards, Anthony From edvard.wendelin at oracle.com Mon Mar 12 06:04:03 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 12 Mar 2012 14:04:03 +0100 Subject: [7u4] Request for phase 2 approval for CR 7148275 - [macosx] setIconImages() not working correctly (distorted icon when minimized) In-Reply-To: <4F5DF3A0.70606@oracle.com> References: <4F5DF3A0.70606@oracle.com> Message-ID: <4F5DF443.7050607@oracle.com> Pre-approved pending release team approval. Once you see OK in CR, please push. Cheers, Edvard On 03/12/2012 02:01 PM, Anthony Petrov wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7148275 > Webrev: http://cr.openjdk.java.net/~anthony/x-23-lowResIcon.0/ > Review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003531.html > Reviewer: Mike Swingler (swingler) > > Rationale for inclusion in 7u4: the fix resolves a noticeable visual > artifact that manifests itself when minimizing top-level windows to > the dock. The fix is rather trivial, and thus considered as LOW-risk. > The fix has been verified with NetBeans and some manual JDK regression > tests. > > -- > best regards, > Anthony From sergey.bylokhov at oracle.com Mon Mar 12 06:35:20 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 12 Mar 2012 17:35:20 +0400 Subject: [7u4] Request for approval: 7124523 [macosx] b216: Mising part of applet UI Message-ID: <4F5DFB98.5040500@oracle.com> Hello, This is a request to push the following changes to jdk7u4-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=7124523 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124523/webrev.00/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003508.html -- Best regards, Sergey. From sergey.bylokhov at oracle.com Mon Mar 12 06:35:29 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 12 Mar 2012 17:35:29 +0400 Subject: [7u4] Request for approval: 7124537 [macosx] Menu shortcuts for all menu items should be disabled if a menu itself is disabled Message-ID: <4F5DFBA1.9070801@oracle.com> Hello, This is a request to push the following changes to jdk7u4-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=7124537 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124537/webrev.00/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003429.html -- Best regards, Sergey. From sergey.bylokhov at oracle.com Mon Mar 12 06:35:38 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 12 Mar 2012 17:35:38 +0400 Subject: [7u4] Request for approval: 7149913 [macosx] Deadlock in LWTextComponentPeer Message-ID: <4F5DFBAA.4010509@oracle.com> Hello, This is a request to push the following changes to jdk7u4-dev. The fix has been reviewed on macosx-port-dev mailing list by Alexander Potochkin. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 Webrev can be found at: http://cr.openjdk.java.net/~serb/7149913/webrev.00/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003542.html -- Best regards, Sergey. From edvard.wendelin at oracle.com Mon Mar 12 06:40:46 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 12 Mar 2012 14:40:46 +0100 Subject: [7u4] Request for approval: 7124537 [macosx] Menu shortcuts for all menu items should be disabled if a menu itself is disabled In-Reply-To: <4F5DFBA1.9070801@oracle.com> References: <4F5DFBA1.9070801@oracle.com> Message-ID: <4F5DFCDE.3030702@oracle.com> Pre-approved pending release team approval. Once you see OK in CR, please push. Cheers, Edvard On 03/12/2012 02:35 PM, Sergey Bylokhov wrote: > Hello, > This is a request to push the following changes to jdk7u4-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=7124537 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124537/webrev.00/ > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003429.html > > From edvard.wendelin at oracle.com Mon Mar 12 06:40:50 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 12 Mar 2012 14:40:50 +0100 Subject: [7u4] Request for approval: 7149913 [macosx] Deadlock in LWTextComponentPeer In-Reply-To: <4F5DFBAA.4010509@oracle.com> References: <4F5DFBAA.4010509@oracle.com> Message-ID: <4F5DFCE2.6070406@oracle.com> Pre-approved pending release team approval. Once you see OK in CR, please push. Cheers, Edvard On 03/12/2012 02:35 PM, Sergey Bylokhov wrote: > Hello, > This is a request to push the following changes to jdk7u4-dev. > The fix has been reviewed on macosx-port-dev mailing list by Alexander > Potochkin. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7149913/webrev.00/ > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003542.html > > From edvard.wendelin at oracle.com Mon Mar 12 06:57:39 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 12 Mar 2012 14:57:39 +0100 Subject: [7u4] Request for approval: 7124523 [macosx] b216: Mising part of applet UI In-Reply-To: <4F5DFB98.5040500@oracle.com> References: <4F5DFB98.5040500@oracle.com> Message-ID: <4F5E00D3.6030103@oracle.com> Pre-approved pending release team approval. Once you see OK in CR, please push. Cheers, Edvard On 03/12/2012 02:35 PM, Sergey Bylokhov wrote: > Hello, > This is a request to push the following changes to jdk7u4-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=7124523 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124523/webrev.00/ > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003508.html > > From anton.tarasov at oracle.com Mon Mar 12 07:04:32 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 12 Mar 2012 18:04:32 +0400 Subject: [7u4] Review request for 7145768 - [macosx] Regression: failure in b11 of ModalDialogInFocusEventTest Message-ID: <4F5E0270.4080906@oracle.com> Hello, Please review a fix for 7145768. webrev: http://cr.openjdk.java.net/~ant/7145768/webrev.0/webrev The fix addresses two focus issues: 1. A window's native focus state should be inspected when requestFocusInWindow() call chain is evaluated. This is to avoid requesting focus to a window when it's not allowed for an unfocused window. 2. Requesting focus to a window being shown should go through the requestWindowFocus() method, which manages all necessary native focus requests (requests focus to an owner when a simple window is shown). The changeFocusedWindow() method is called after native focused window is already set and it just processes this fact on java level. Thanks, Anton. From greg.x.brown at oracle.com Mon Mar 12 11:29:00 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Mon, 12 Mar 2012 14:29:00 -0400 Subject: javah Message-ID: Hi all, Has the behavior of javah changed in Java 7? I'm using the task in Ant to generate some JNI headers. When I run my Ant script under Java 6, I only get headers for classes I explicitly specify. Under Java 7, I get headers for all of my specified classes as well as any nested classes defined by those classes, even though the nested classes themselves don't specify any native methods. I'm not sure if Ant or javah is responsible for the change, but if it is javah - is this intentional, or is it a bug? Thanks, Greg From artem.ananiev at oracle.com Mon Mar 12 11:43:04 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 12 Mar 2012 11:43:04 -0700 Subject: [7u4] Review request for 7145827 - [macosx] JCK failure in b11: FocusableWindow3 In-Reply-To: <4F4E2587.3060507@oracle.com> References: <4F4E2587.3060507@oracle.com> Message-ID: <4F5E43B8.10608@oracle.com> Looks fine. Thanks, Artem On 2/29/2012 5:17 AM, Anton V. Tarasov wrote: > Hello, > > Please review a fix for 7145827. > > webrev: http://cr.openjdk.java.net/~ant/7145827/webrev.0/ > > The problem was that an owned window didn't take into account > focusability of its decorated owner. > Now it does. Also, the fix removes some cache variable as its benefit is > doubtful. > > Thanks, > Anton. > > From jonathan.gibbons at oracle.com Mon Mar 12 11:48:35 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 12 Mar 2012 11:48:35 -0700 Subject: javah In-Reply-To: References: Message-ID: <4F5E4503.10508@oracle.com> On 03/12/2012 11:29 AM, Greg Brown wrote: > Hi all, > > Has the behavior of javah changed in Java 7? I'm using the task in Ant to generate some JNI headers. When I run my Ant script under Java 6, I only get headers for classes I explicitly specify. Under Java 7, I get headers for all of my specified classes as well as any nested classes defined by those classes, even though the nested classes themselves don't specify any native methods. > > I'm not sure if Ant or javah is responsible for the change, but if it is javah - is this intentional, or is it a bug? > > Thanks, > Greg > javah was rewritten in JDK 7, but the intent was the headers generated should be the same as for earlier versions of javah. -- Jon From greg.x.brown at oracle.com Mon Mar 12 12:30:34 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Mon, 12 Mar 2012 15:30:34 -0400 Subject: javah In-Reply-To: <4F5E4503.10508@oracle.com> References: <4F5E4503.10508@oracle.com> Message-ID: >> Has the behavior of javah changed in Java 7? I'm using the task in Ant to generate some JNI headers. When I run my Ant script under Java 6, I only get headers for classes I explicitly specify. Under Java 7, I get headers for all of my specified classes as well as any nested classes defined by those classes, even though the nested classes themselves don't specify any native methods. >> >> I'm not sure if Ant or javah is responsible for the change, but if it is javah - is this intentional, or is it a bug? >> >> Thanks, >> Greg >> > > javah was rewritten in JDK 7, but the intent was the headers generated should be the same as for earlier versions of javah. So, to confirm - the fact that these headers were are generated in Java 6 but are generated in Java 7 is likely a bug? From swingler at apple.com Mon Mar 12 14:00:04 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 12 Mar 2012 14:00:04 -0700 Subject: [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode In-Reply-To: <4F578BDA.6000001@oracle.com> References: <4F4E3D18.3010109@oracle.com> <2AD6CB77-6932-4715-A21A-E7B786C5D6C6@apple.com> <4F4FE5D0.8010700@oracle.com> <69A334C5-89AB-49F4-A2BC-1C2E1C318EEE@apple.com> <4F50D737.40405@oracle.com> <4F50DC3C.7050803@oracle.com> <4F54E3DA.6070908@oracle.com> <4F578BDA.6000001@oracle.com> Message-ID: I don't see where you are getting the notifications from native when the user enters full screen by pressing the window widget. This change looks fine to address the immediate problem, but testing it's interaction with the eAWT full screen experience needs a followup bug. Regards, Mike Swingler Apple Inc. On Mar 7, 2012, at 8:24 AM, Anthony Petrov wrote: > Could I get a review for the latest version of the fix please? Here's the link for your convenience: > > http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.3/ > > -- > best regards, > Anthony > > On 3/5/2012 8:03 PM, Anthony Petrov wrote: >> Hi Mike, >> A few points: >> * When a user enters the full screen using the OS widget, the full screen state isn't sync'd with Java's GraphicsDevice.getFullScreenWindow(). >> * Rather than calling native, I'd actually update the flag upon receiving native notifications about entering/leaving the FS mode. >> * If you call -toggleFullScreen: for a window w/o the NSWindowCollectionBehaviorFullScreenPrimary collection behavior, then the menus and the dock stay visible. Apart from that, there's no the default 10.7-specific animation for such windows when entering the FS mode. >> * If I mark an undecorated window as fullscreenable, its original size won't be restored when exiting the FS mode. So we can't simply enable the behavior automatically for all windows. An app must opt in. >> * Apple JDK 1.6 won't let a user exit a FS Java application, too. So at least we don't introduce a regression here. Also, the full screen is a restricted functionality that's unavailable to unsigned code by default. Thus we generally trust code that's able to enter the mode (in that it should let user out when needed). >> * The fix we're currently reviewing is supposed to fix a bug with popup windows not showing up for a Java app that doesn't use EAWT at all. As far as I've tested it, it does resolve the issue. And the behavior seems to be quite consistent with what Apple JDK 1.6 does. >> * The only thing the fix worsens is for EAWT-aware app: it hides the menu bar unconditionally when entering the FS mode. I've just fixed that by avoiding hiding the menu bar if a window is marked as FULLSCREENABLE. I believe that a new fix at >> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.3/ >> is what we need in 7u4. We may file a new change request to address EAWT-specific issues in a future release. >> Please review. >> -- >> best regards, >> Anthony >> On 03/02/12 21:13, Mike Swingler wrote: >>> There are a few points here: >>> * If the user marks the window as "fullscreenable" using the eAWT API, >>> that puts a widget in the upper right corner of the window which allows >>> the user to toggle it into full screen themselves. >>> * When in full screen (using AWT or eAWT API), the user should be able >>> to click the blue exit fullscreen button in the menu bar at any time (if >>> they entered into full screen themselves) >>> * Generally, it is undesirable for the user to be stuck in a state where >>> they cannot return to the desktop. >>> >>> With the current diff, the isFullScreenMode boolean in Java will >>> definitely be out of sync if the user initiates either of these actions. >>> >>> Instead of trying to keep the knowledge of the full screen state in Java >>> behind a lock, I think you probably need query native to see if the >>> window is in the fullscreen state. I've used the following testcase to >>> test the existing eAWT fullscreen API, and I think you'll find it's easy >>> to get into a state where the user is stuck in windowed mode without a >>> menu bar, and that sometimes the user is locked out from returning to >>> windowed mode when they clicked on the window widget. >>> >>> After trying out your diff, I actually found it quite frustrating that >>> the menubar was suppressed and I *had* to use the four-finger swipe >>> gesture to get back to my desktop. How would you feel about just >>> dropping the whole menubar hiding stuff? Since the menu bar is >>> auto-hidden by default, users don't get to it unless they push up to the >>> top of the screen anyway. >>> >>> Try out this test case, and be sure to use the window widget, as well as >>> the button that programmatically fires the eAWT API. >>> >>> import java.awt.*; >>> import java.awt.event.ActionEvent; >>> import javax.swing.*; >>> >>> import com.apple.eawt.AppEvent.FullScreenEvent; >>> import com.apple.eawt.*; >>> >>> public class FullScreenTest { >>> public static void main(String args[]) { >>> SwingUtilities.invokeLater(new Runnable() { >>> public void run() { createFrame(); } >>> }); >>> } >>> >>> >>> static void createFrame() { >>> JFrame frame = new JFrame(); >>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>> frame.setTitle(System.getProperty("java.version")); >>> >>> >>> Container contentPane = frame.getContentPane(); >>> contentPane.setLayout(new BorderLayout()); >>> contentPane.add(createPanel(), BorderLayout.CENTER); >>> >>> >>> // turns on the fullscreen window titlebar widget in the upper right corner >>> FullScreenUtilities.setWindowCanFullScreen(frame, true); >>> >>> >>> // useful for re-adjusting content or hiding/showing palette windows >>> FullScreenUtilities.addFullScreenListenerTo(frame, new FullScreenAdapter() { >>> public void windowExitingFullScreen(FullScreenEvent e) { >>> System.out.println("exiting"); >>> } >>> public void windowExitedFullScreen(FullScreenEvent e) { >>> System.out.println("exited"); >>> } >>> public void windowEnteringFullScreen(FullScreenEvent e) { >>> System.out.println("entering"); >>> } >>> public void windowEnteredFullScreen(FullScreenEvent e) { >>> System.out.println("entered"); >>> } >>> }); >>> >>> >>> frame.pack(); >>> frame.setVisible(true); >>> } >>> >>> static Component createPanel() { >>> final JPanel panel = new JPanel(new FlowLayout()); >>> >>> >>> // toggle FullScreen from a toolbar button >>> panel.add(new JButton(new AbstractAction("Full Screen Me!") { >>> public void actionPerformed(ActionEvent e) { >>> Application.getApplication().requestToggleFullScreen( >>> (Window)panel.getTopLevelAncestor()); >>> } >>> })); >>> >>> >>> return panel; >>> } >>> } >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> >>> On Mar 2, 2012, at 6:42 AM, Anthony Petrov wrote: >>> >>>> A tiny typo has been fixed, a new webrev is at: >>>> >>>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.2/ >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 3/2/2012 6:20 PM, Anthony Petrov wrote: >>>>> Thanks for your suggestions Mike. Here's the latest version of the fix: >>>>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.1/ >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> On 3/2/2012 3:14 AM, Mike Swingler wrote: >>>>>> On Mar 1, 2012, at 1:10 PM, Anthony Petrov wrote: >>>>>> >>>>>>> Hi Mike, >>>>>>> >>>>>>> Thanks for the review! Please see my comments inline. >>>>>>> >>>>>>> On 3/1/2012 9:31 PM, Mike Swingler wrote: >>>>>>>> On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote: >>>>>>>>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.0/ >>>>>>>> A few points to consider: >>>>>>>> * To protect against the unrecognized selector problem, you should >>>>>>>> test if the AWTWindow object >>>>>>>> -respondsToSelector:@selector(toggleFullScreen) before just >>>>>>>> calling it. >>>>>>> I'm aware of -respondsToSelector. But I suppose that in that case >>>>>>> this simply won't work on 10.6.8 at all. Since >>>>>>> >>>>>>> a) presently it does work on 10.6.8 for reasons unknown, and >>>>>> >>>>>> If OpenJDK is built on Snow Leopard, it works fine. I believe the >>>>>> problem is the X11/FreeType versions in Lion are newer, and DYLD >>>>>> won't load libraries linked against older versions. But that is >>>>>> going to start me on my rant about how OpenJDK should bundle it's >>>>>> own FreeType... >>>>>> >>>>>>> b) we officially support 10.7+ only, hence the check makes little >>>>>>> sense in theory, and >>>>>> >>>>>> Please think of OpenJDK, not just Oracle's proprietary binaries. >>>>>> There are other users who currently compile on Snow Leopard and this >>>>>> is not an inconvenience, since 10.7-only API is very rare in the JDK. >>>>>> >>>>>>> c) from ObjC perspective sending an unknown selector isn't an >>>>>>> error, but just a warning, >>>>>> >>>>>> It is extremely poor form. The -respondsToSelector: check is very >>>>>> cheap, and is very obvious what it is guarding against. >>>>>> >>>>>>> it seems to me that having this warning printed out to the console >>>>>>> (which isn't seen by 99% of users anyway) is OK when running on >>>>>>> 10.6.8. Plus we get the full screen working there. Isn't it awesome? >>>>>> >>>>>> We know there are developers and users who will be running OpenJDK >>>>>> on Mac OS X 10.6.8, so it is perfectly reasonable to add this as an >>>>>> OS guard. We should not actively damage our ability to run on 10.6 >>>>>> if it's trivially avoidable. >>>>>> >>>>>>>> * Also, there is already API that calls -toggleFullScreen in the >>>>>>>> eAWT classes that you might not be aware of. You should probably >>>>>>>> test for interactions with that, since apps can opt their window >>>>>>>> into having a full screen widget icon and independently toggle >>>>>>>> fullscreen. >>>>>>> Thanks for pointing this out. I'll rework this code to make sure >>>>>>> calls from EAWT update the boolean flag. >>>>>> >>>>>> Great. >>>>>> >>>>>>>> * In some cases, seeing the menubar is actually desirable, where >>>>>>>> as in the "exclusive" mode, it's probably not. Perhaps you could >>>>>>>> consult a client property on the window to determine if the menu >>>>>>>> bar should be hidden? >>>>>>> Excellent idea! I think that by default the menu should be hidden >>>>>>> (for Java spec's sake). But if a client property is set, then the >>>>>>> menu would be visible. >>>>>> >>>>>> Cool. There are several client property readers already on the root >>>>>> AWT window that should be easily extendable. >>>>>> >>>>>>>> I like this overall solution, because it uses the native platform >>>>>>>> concept of full screen which doesn't trap the user from switching >>>>>>>> spaces like the Java SE 6 implementation did. >>>>>>> We've noticed an interesting detail with -toggleFullScreen when >>>>>>> it's used in a multi-screen environment. In that case the window >>>>>>> will go full screen on the biggest monitor (actually we have a >>>>>>> MacBook with an external monitor connected.) The OS seems to ignore >>>>>>> the screen where the window were before entering the FS mode (the >>>>>>> main notebook display). Is this OK? Can we force it to use the same >>>>>>> screen where the window is originally located for the FS mode? >>>>>> >>>>>> It's actually the monitor with the menu bar (the primary, as >>>>>> designated in the Monitor's preference pane). >>>>>> >>>>>> This is an issue with the OS, and should be filed at >>>>>> (it's known, but if you have a >>>>>> specific API suggestion to target a screen, or some sort of >>>>>> automatic behavior in mind, it would be good to provide specific >>>>>> suggestions in the bug). >>> From jonathan.gibbons at oracle.com Mon Mar 12 16:30:48 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 12 Mar 2012 16:30:48 -0700 Subject: javah In-Reply-To: References: <4F5E4503.10508@oracle.com> Message-ID: <4F5E8728.3090905@oracle.com> On 03/12/2012 12:30 PM, Greg Brown wrote: >>> Has the behavior of javah changed in Java 7? I'm using the task in Ant to generate some JNI headers. When I run my Ant script under Java 6, I only get headers for classes I explicitly specify. Under Java 7, I get headers for all of my specified classes as well as any nested classes defined by those classes, even though the nested classes themselves don't specify any native methods. >>> >>> I'm not sure if Ant or javah is responsible for the change, but if it is javah - is this intentional, or is it a bug? >>> >>> Thanks, >>> Greg >>> >> javah was rewritten in JDK 7, but the intent was the headers generated should be the same as for earlier versions of javah. > So, to confirm - the fact that these headers were are generated in Java 6 but are generated in Java 7 is likely a bug? > > > Greg, I see the same behavior on JDK 5, 6, 7, 8. Here's my test program: > package p; > > class C { > native void m(); > > class Inner { > void m2() { } > } > } Here's my test script: > #!/bin/sh > > rm -rf play/classes play/jdk* > > mkdir play/classes > /opt/jdk/1.5.0/bin/javac -d play/classes $(find play/src -name \*.java) > > for i in 5 6 7 8 ; do > mkdir play/jdk$i > /opt/jdk/1.$i.0/bin/javah -classpath play/classes -d play/jdk$i p.C > done > > find play/jdk* And here's the output: > $ sh -x play/test.sh > + rm -rf play/classes play/jdk5 play/jdk6 play/jdk7 play/jdk8 > + mkdir play/classes > + find play/src -name *.java > + /opt/jdk/1.5.0/bin/javac -d play/classes play/src/p/C.java > + mkdir play/jdk5 > + /opt/jdk/1.5.0/bin/javah -classpath play/classes -d play/jdk5 p.C > + mkdir play/jdk6 > + /opt/jdk/1.6.0/bin/javah -classpath play/classes -d play/jdk6 p.C > + mkdir play/jdk7 > + /opt/jdk/1.7.0/bin/javah -classpath play/classes -d play/jdk7 p.C > + mkdir play/jdk8 > + /opt/jdk/1.8.0/bin/javah -classpath play/classes -d play/jdk8 p.C > + find play/jdk5 play/jdk6 play/jdk7 play/jdk8 > play/jdk5 > play/jdk5/p_C_Inner.h > play/jdk5/p_C.h > play/jdk6 > play/jdk6/p_C_Inner.h > play/jdk6/p_C.h > play/jdk7 > play/jdk7/p_C_Inner.h > play/jdk7/p_C.h > play/jdk8 > play/jdk8/p_C_Inner.h > play/jdk8/p_C.h -- Jon From niagarasoft20-macosxportdev at yahoo.com Mon Mar 12 17:30:45 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Mon, 12 Mar 2012 17:30:45 -0700 (PDT) Subject: [7u4] Request for phase 2 approval for CR 7132692 - [macosx] Class com.apple.eawt not functioning References: <4F437DD7.8040505@oracle.com> <7088A00E-0405-4A53-A5E8-24495DCD7102@oracle.com> Message-ID: <1331598645.19244.YahooMailNeo@web126006.mail.ne1.yahoo.com> Has this been pushed to source? I've just compiled this and attempted to use it but still not working using the provided JavaAppLauncher? Still not getting the apple menus. I DO get them however when invoking the executable jar from the command line. Using that method they work fine. Perhaps I'm missing something in the info.plist config file. I'm doing exactly what I described in the steps here: https://wikis.oracle.com/display/OpenJDK/How+to+embed+a+.jre+bundle+in+your+Mac+app This is the version I'm attempting to bundle: openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-mnigrin_2012_03_06_20_25-b00) OpenJDK 64-Bit Server VM (build 23.0-b16, mixed mode) >________________________________ > From: Edvard Wendelin >To: Anthony Petrov >Cc: "jdk7u-dev at openjdk.java.net" ; macosx-port-dev >Sent: Friday, February 24, 2012 9:25 AM >Subject: Re: [7u4] Request for phase 2 approval for CR 7132692 - [macosx] Class com.apple.eawt not functioning > >Approved. > >On Feb 21, 2012, at 12:19 PM, Anthony Petrov wrote: > >> Bug: http://bugs.sun.com/view_bug.do?bug_id=7132692 >> Webrev: http://cr.openjdk.java.net/~anthony/x-16-eawt-7132692.0/ >> Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002992.html >> Reviewer: Artem Ananiev (art) >> >> Rationale for inclusion in 7u4: NetBeans requires this feature. Also, many Java applications deployed on the Mac expect the Apple menu items (About, Preferences, and Quit) to function correctly. W/o this fix the menus don't work as expected. The fix is considered as low-risk since it doesn't affect any functionality other than the Apple menu handling code. >> >> -- >> best regards, >> Anthony > > > > From greg.x.brown at oracle.com Mon Mar 12 18:13:27 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Mon, 12 Mar 2012 21:13:27 -0400 Subject: javah In-Reply-To: <4F5E8728.3090905@oracle.com> References: <4F5E4503.10508@oracle.com> <4F5E8728.3090905@oracle.com> Message-ID: Hi Jon, Thanks for looking into this. Could you possibly try running your test with Inner as a nested (static) class rather than an inner class? I wonder if that might have something to do with the difference in behavior. Greg On Mar 12, 2012, at 7:30 PM, Jonathan Gibbons wrote: > On 03/12/2012 12:30 PM, Greg Brown wrote: >>>> Has the behavior of javah changed in Java 7? I'm using the task in Ant to generate some JNI headers. When I run my Ant script under Java 6, I only get headers for classes I explicitly specify. Under Java 7, I get headers for all of my specified classes as well as any nested classes defined by those classes, even though the nested classes themselves don't specify any native methods. >>>> >>>> I'm not sure if Ant or javah is responsible for the change, but if it is javah - is this intentional, or is it a bug? >>>> >>>> Thanks, >>>> Greg >>>> >>> javah was rewritten in JDK 7, but the intent was the headers generated should be the same as for earlier versions of javah. >> So, to confirm - the fact that these headers were are generated in Java 6 but are generated in Java 7 is likely a bug? >> >> >> > > Greg, > > I see the same behavior on JDK 5, 6, 7, 8. > > Here's my test program: >> package p; >> >> class C { >> native void m(); >> >> class Inner { >> void m2() { } >> } >> } > > Here's my test script: >> #!/bin/sh >> >> rm -rf play/classes play/jdk* >> >> mkdir play/classes >> /opt/jdk/1.5.0/bin/javac -d play/classes $(find play/src -name \*.java) >> >> for i in 5 6 7 8 ; do >> mkdir play/jdk$i >> /opt/jdk/1.$i.0/bin/javah -classpath play/classes -d play/jdk$i p.C >> done >> >> find play/jdk* > > And here's the output: >> $ sh -x play/test.sh >> + rm -rf play/classes play/jdk5 play/jdk6 play/jdk7 play/jdk8 >> + mkdir play/classes >> + find play/src -name *.java >> + /opt/jdk/1.5.0/bin/javac -d play/classes play/src/p/C.java >> + mkdir play/jdk5 >> + /opt/jdk/1.5.0/bin/javah -classpath play/classes -d play/jdk5 p.C >> + mkdir play/jdk6 >> + /opt/jdk/1.6.0/bin/javah -classpath play/classes -d play/jdk6 p.C >> + mkdir play/jdk7 >> + /opt/jdk/1.7.0/bin/javah -classpath play/classes -d play/jdk7 p.C >> + mkdir play/jdk8 >> + /opt/jdk/1.8.0/bin/javah -classpath play/classes -d play/jdk8 p.C >> + find play/jdk5 play/jdk6 play/jdk7 play/jdk8 >> play/jdk5 >> play/jdk5/p_C_Inner.h >> play/jdk5/p_C.h >> play/jdk6 >> play/jdk6/p_C_Inner.h >> play/jdk6/p_C.h >> play/jdk7 >> play/jdk7/p_C_Inner.h >> play/jdk7/p_C.h >> play/jdk8 >> play/jdk8/p_C_Inner.h >> play/jdk8/p_C.h > > -- Jon > From jonathan.gibbons at oracle.com Mon Mar 12 18:17:05 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 12 Mar 2012 18:17:05 -0700 Subject: javah In-Reply-To: References: <4F5E4503.10508@oracle.com> <4F5E8728.3090905@oracle.com> Message-ID: <4F5EA011.1090501@oracle.com> Greg, Same results. -- Jon On 03/12/2012 06:13 PM, Greg Brown wrote: > Hi Jon, > Thanks for looking into this. Could you possibly try running your test with Inner as a nested (static) class rather than an inner class? I wonder if that might have something to do with the difference in behavior. > Greg > > On Mar 12, 2012, at 7:30 PM, Jonathan Gibbons wrote: > >> On 03/12/2012 12:30 PM, Greg Brown wrote: >>>>> Has the behavior of javah changed in Java 7? I'm using the task in Ant to generate some JNI headers. When I run my Ant script under Java 6, I only get headers for classes I explicitly specify. Under Java 7, I get headers for all of my specified classes as well as any nested classes defined by those classes, even though the nested classes themselves don't specify any native methods. >>>>> >>>>> I'm not sure if Ant or javah is responsible for the change, but if it is javah - is this intentional, or is it a bug? >>>>> >>>>> Thanks, >>>>> Greg >>>>> >>>> javah was rewritten in JDK 7, but the intent was the headers generated should be the same as for earlier versions of javah. >>> So, to confirm - the fact that these headers were are generated in Java 6 but are generated in Java 7 is likely a bug? >>> >>> >>> >> Greg, >> >> I see the same behavior on JDK 5, 6, 7, 8. >> >> Here's my test program: >>> package p; >>> >>> class C { >>> native void m(); >>> >>> class Inner { >>> void m2() { } >>> } >>> } >> Here's my test script: >>> #!/bin/sh >>> >>> rm -rf play/classes play/jdk* >>> >>> mkdir play/classes >>> /opt/jdk/1.5.0/bin/javac -d play/classes $(find play/src -name \*.java) >>> >>> for i in 5 6 7 8 ; do >>> mkdir play/jdk$i >>> /opt/jdk/1.$i.0/bin/javah -classpath play/classes -d play/jdk$i p.C >>> done >>> >>> find play/jdk* >> And here's the output: >>> $ sh -x play/test.sh >>> + rm -rf play/classes play/jdk5 play/jdk6 play/jdk7 play/jdk8 >>> + mkdir play/classes >>> + find play/src -name *.java >>> + /opt/jdk/1.5.0/bin/javac -d play/classes play/src/p/C.java >>> + mkdir play/jdk5 >>> + /opt/jdk/1.5.0/bin/javah -classpath play/classes -d play/jdk5 p.C >>> + mkdir play/jdk6 >>> + /opt/jdk/1.6.0/bin/javah -classpath play/classes -d play/jdk6 p.C >>> + mkdir play/jdk7 >>> + /opt/jdk/1.7.0/bin/javah -classpath play/classes -d play/jdk7 p.C >>> + mkdir play/jdk8 >>> + /opt/jdk/1.8.0/bin/javah -classpath play/classes -d play/jdk8 p.C >>> + find play/jdk5 play/jdk6 play/jdk7 play/jdk8 >>> play/jdk5 >>> play/jdk5/p_C_Inner.h >>> play/jdk5/p_C.h >>> play/jdk6 >>> play/jdk6/p_C_Inner.h >>> play/jdk6/p_C.h >>> play/jdk7 >>> play/jdk7/p_C_Inner.h >>> play/jdk7/p_C.h >>> play/jdk8 >>> play/jdk8/p_C_Inner.h >>> play/jdk8/p_C.h >> -- Jon >> From greg.x.brown at oracle.com Mon Mar 12 18:27:08 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Mon, 12 Mar 2012 21:27:08 -0400 Subject: javah In-Reply-To: <4F5EA011.1090501@oracle.com> References: <4F5E4503.10508@oracle.com> <4F5E8728.3090905@oracle.com> <4F5EA011.1090501@oracle.com> Message-ID: <550E9AB3-7AF1-4431-95DA-E3DA1F211518@oracle.com> > Same results. That's weird. I'll try to run your tests on my machine with Java 6 and 7 and see what happens. Thanks! G From scott.kovatch at oracle.com Mon Mar 12 19:46:31 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 12 Mar 2012 19:46:31 -0700 Subject: [7u4] Request for phase 2 approval for CR 7132692 - [macosx] Class com.apple.eawt not functioning In-Reply-To: <1331598645.19244.YahooMailNeo@web126006.mail.ne1.yahoo.com> References: <4F437DD7.8040505@oracle.com> <7088A00E-0405-4A53-A5E8-24495DCD7102@oracle.com> <1331598645.19244.YahooMailNeo@web126006.mail.ne1.yahoo.com> Message-ID: <02F03B77-A005-4365-85FB-28F7D72B4260@oracle.com> Looks like it was just pushed to jdk7u4 today at 3:15 p.m. or so Pacific time. It's tagged for the b16 build. I'm not sure when it will make its way back to the main jdk7u forest. -- Scott K. On Mar 12, 2012, at 5:30 PM, niagarasoft20-macosxportdev at yahoo.com wrote: > Has this been pushed to source? I've just compiled this and attempted to use it but still not working using the provided JavaAppLauncher? Still not getting the apple menus. I DO get them however when invoking the executable jar from the command line. Using that method they work fine. Perhaps I'm missing something in the info.plist config file. I'm doing exactly what I described in the steps here: > > https://wikis.oracle.com/display/OpenJDK/How+to+embed+a+.jre+bundle+in+your+Mac+app > > This is the version I'm attempting to bundle: > > openjdk version "1.7.0-internal" > OpenJDK Runtime Environment (build 1.7.0-internal-mnigrin_2012_03_06_20_25-b00) > OpenJDK 64-Bit Server VM (build 23.0-b16, mixed mode) > > > > >> ________________________________ >> From: Edvard Wendelin >> To: Anthony Petrov >> Cc: "jdk7u-dev at openjdk.java.net" ; macosx-port-dev >> Sent: Friday, February 24, 2012 9:25 AM >> Subject: Re: [7u4] Request for phase 2 approval for CR 7132692 - [macosx] Class com.apple.eawt not functioning >> >> Approved. >> >> On Feb 21, 2012, at 12:19 PM, Anthony Petrov wrote: >> >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=7132692 >>> Webrev: http://cr.openjdk.java.net/~anthony/x-16-eawt-7132692.0/ >>> Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002992.html >>> Reviewer: Artem Ananiev (art) >>> >>> Rationale for inclusion in 7u4: NetBeans requires this feature. Also, many Java applications deployed on the Mac expect the Apple menu items (About, Preferences, and Quit) to function correctly. W/o this fix the menus don't work as expected. The fix is considered as low-risk since it doesn't affect any functionality other than the Apple menu handling code. >>> >>> -- >>> best regards, >>> Anthony >> >> >> >> From anton.tarasov at oracle.com Tue Mar 13 06:07:31 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 13 Mar 2012 17:07:31 +0400 Subject: [7u4] Request for phase 2 approval for CR 7125044 - [macosx] Test failure because Component.transferFocus() works differently in applet and application Message-ID: <4F5F4693.4070006@oracle.com> Bug: http://bugs.sun.com/view_bug.do?bug_id=7125044 Webrev: http://cr.openjdk.java.net/~ant/7125044/webrev.3 Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003433.html Reviewer: Artem Ananiev (art) Rationale for inclusion in 7u4: The broken functionality is essential for correct kbd focus work. Without the fix, AWT apps on OSX will have *Swing* focus traversal policy that may lead to unexpected or even erroneous results during focus traversal operations. Thanks, Anton. From alexandr.scherbatiy at oracle.com Tue Mar 13 06:13:30 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 13 Mar 2012 17:13:30 +0400 Subject: Request for review 7151821: [macosx] Mnemonic doesn't work in JTabbedPane Message-ID: <4F5F47FA.5000503@oracle.com> Please review a fix for 7151821. webrev: http://cr.openjdk.java.net/~alexsch/7151821/webrev.00/ This is a fix for regression after switching using [event charactersIgnoringModifiers] string to [event characters] during the MACOSX_PORT-568 issue fixing: http://java.net/jira/browse/MACOSX_PORT-568 http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5780795f381e The characters string is null during Ctrl+Alt+Char mnemonic pressing. According to the NSEvent charactersIgnoringModifiers doc: This method returns the non-modifier key character pressed for dead keys, such as Option-e. For example, Option-e (no shift key) returns an ?e" for this method, whereas the characters method returns an empty string. The fix uses the charactersIgnoringModifiers string for the keychar when the Ctrl+Alt mnemonic key combination is pressed. Thanks, Alexandr. From anthony.petrov at oracle.com Tue Mar 13 08:01:39 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 13 Mar 2012 19:01:39 +0400 Subject: Request for review 7151821: [macosx] Mnemonic doesn't work in JTabbedPane In-Reply-To: <4F5F47FA.5000503@oracle.com> References: <4F5F47FA.5000503@oracle.com> Message-ID: <4F5F6153.4030201@oracle.com> Hi Alexander, How about doing something more generic, like the following: chars = [ev chars]; if (chars is empty) { chars = [ev charsIgnoreMods]; } ? What might go wrong with such approach? In this case we'll also see chars=='e' for Option+e. Would that be a bug, or would it be actually something that we'd like to see? -- best regards, Anthony On 3/13/2012 5:13 PM, Alexander Scherbatiy wrote: > Please review a fix for 7151821. > > webrev: http://cr.openjdk.java.net/~alexsch/7151821/webrev.00/ > > > This is a fix for regression after switching using [event > charactersIgnoringModifiers] string to [event characters] during the > MACOSX_PORT-568 issue fixing: > http://java.net/jira/browse/MACOSX_PORT-568 > http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5780795f381e > > The characters string is null during Ctrl+Alt+Char mnemonic pressing. > > According to the NSEvent charactersIgnoringModifiers doc: > This method returns the non-modifier key character pressed for dead > keys, such as Option-e. > For example, Option-e (no shift key) returns an ?e" for this method, > whereas the characters method returns an empty string. > > The fix uses the charactersIgnoringModifiers string for the keychar when > the Ctrl+Alt mnemonic key combination is pressed. > > Thanks, > Alexandr. > From leonid.romanov at oracle.com Tue Mar 13 08:24:41 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 13 Mar 2012 19:24:41 +0400 Subject: Request for review 7151821: [macosx] Mnemonic doesn't work in JTabbedPane In-Reply-To: <4F5F47FA.5000503@oracle.com> References: <4F5F47FA.5000503@oracle.com> Message-ID: <7AA70445-6588-4473-8F35-A3A3A6A0A53E@oracle.com> Hi, What is the test case for this issue? What Control+alt+char is supposed to do? On 13.03.2012, at 17:13, Alexander Scherbatiy wrote: > Please review a fix for 7151821. > > webrev: http://cr.openjdk.java.net/~alexsch/7151821/webrev.00/ > > > This is a fix for regression after switching using [event charactersIgnoringModifiers] string to [event characters] during the MACOSX_PORT-568 issue fixing: > http://java.net/jira/browse/MACOSX_PORT-568 > http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5780795f381e > > The characters string is null during Ctrl+Alt+Char mnemonic pressing. > > According to the NSEvent charactersIgnoringModifiers doc: > This method returns the non-modifier key character pressed for dead keys, such as Option-e. > For example, Option-e (no shift key) returns an ?e" for this method, whereas the characters method returns an empty string. > > The fix uses the charactersIgnoringModifiers string for the keychar when the Ctrl+Alt mnemonic key combination is pressed. > > Thanks, > Alexandr. > From leonid.romanov at oracle.com Tue Mar 13 08:28:43 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 13 Mar 2012 19:28:43 +0400 Subject: [7u4] Request for phase 2 approval for CR 7124321: [macosx] TrayIcon MouseListener is never triggered Message-ID: <13AFE963-4527-4322-AEF4-30CE02A343DE@oracle.com> Bug: http://bugs.sun.com/view_bug.do?bug_id=7124321 Webrev: http://cr.openjdk.java.net/~leonidr/7124321/webrev.01/ Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003520.html Reviewer: Anthony Petrov (anthony) Rationale for inclusion in 7u4: it's a regression from JDK 6. The fix modifies TrayIcon related code only in a rather simple way, so it's a low risk fix. Thanks, Leonid. From leonid.romanov at oracle.com Tue Mar 13 08:35:08 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 13 Mar 2012 19:35:08 +0400 Subject: Request for review 7151821: [macosx] Mnemonic doesn't work in JTabbedPane In-Reply-To: <7AA70445-6588-4473-8F35-A3A3A6A0A53E@oracle.com> References: <4F5F47FA.5000503@oracle.com> <7AA70445-6588-4473-8F35-A3A3A6A0A53E@oracle.com> Message-ID: Hit "Send" too early. Basically, what you are describing in 7151821 is exactly the way JDK 6 works. So, what is wrong with it? Does it break anything? On 13.03.2012, at 19:24, Leonid Romanov wrote: > Hi, > What is the test case for this issue? What Control+alt+char is supposed to do? > > On 13.03.2012, at 17:13, Alexander Scherbatiy wrote: > >> Please review a fix for 7151821. >> >> webrev: http://cr.openjdk.java.net/~alexsch/7151821/webrev.00/ >> >> >> This is a fix for regression after switching using [event charactersIgnoringModifiers] string to [event characters] during the MACOSX_PORT-568 issue fixing: >> http://java.net/jira/browse/MACOSX_PORT-568 >> http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5780795f381e >> >> The characters string is null during Ctrl+Alt+Char mnemonic pressing. >> >> According to the NSEvent charactersIgnoringModifiers doc: >> This method returns the non-modifier key character pressed for dead keys, such as Option-e. >> For example, Option-e (no shift key) returns an ?e" for this method, whereas the characters method returns an empty string. >> >> The fix uses the charactersIgnoringModifiers string for the keychar when the Ctrl+Alt mnemonic key combination is pressed. >> >> Thanks, >> Alexandr. >> > From edvard.wendelin at oracle.com Tue Mar 13 08:31:44 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 13 Mar 2012 16:31:44 +0100 Subject: [7u4] Request for phase 2 approval for CR 7125044 - [macosx] Test failure because Component.transferFocus() works differently in applet and application In-Reply-To: <4F5F4693.4070006@oracle.com> References: <4F5F4693.4070006@oracle.com> Message-ID: <4F5F6860.4070309@oracle.com> Pre-approved pending release team approval. Cheers, Edvard On 03/13/2012 02:07 PM, Anton V. Tarasov wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7125044 > Webrev: http://cr.openjdk.java.net/~ant/7125044/webrev.3 > Review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003433.html > Reviewer: Artem Ananiev (art) > > Rationale for inclusion in 7u4: The broken functionality is essential > for correct kbd focus > work. Without the fix, AWT apps on OSX will have *Swing* focus > traversal policy that may lead > to unexpected or even erroneous results during focus traversal > operations. > > Thanks, > Anton. From edvard.wendelin at oracle.com Tue Mar 13 08:32:21 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 13 Mar 2012 16:32:21 +0100 Subject: [7u4] Request for phase 2 approval for CR 7124321: [macosx] TrayIcon MouseListener is never triggered In-Reply-To: <13AFE963-4527-4322-AEF4-30CE02A343DE@oracle.com> References: <13AFE963-4527-4322-AEF4-30CE02A343DE@oracle.com> Message-ID: <4F5F6885.70701@oracle.com> Pre-approved pending release team approval. Once you see OK in CR, please push. On 03/13/2012 04:28 PM, Leonid Romanov wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7124321 > Webrev: http://cr.openjdk.java.net/~leonidr/7124321/webrev.01/ > Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003520.html > Reviewer: Anthony Petrov (anthony) > > Rationale for inclusion in 7u4: it's a regression from JDK 6. The fix modifies TrayIcon related code only in a rather simple way, so it's a low risk fix. > > Thanks, > Leonid. > > From alexandr.scherbatiy at oracle.com Tue Mar 13 09:05:31 2012 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Tue, 13 Mar 2012 19:05:31 +0300 Subject: Request for review 7151821: [macosx] Mnemonic doesn't work in JTabbedPane In-Reply-To: References: <4F5F47FA.5000503@oracle.com> <7AA70445-6588-4473-8F35-A3A3A6A0A53E@oracle.com> Message-ID: <4F5F704B.5070607@oracle.com> 13.03.2012 18:35, Leonid Romanov ?????: > Hit "Send" too early. Basically, what you are describing in 7151821 is exactly the way JDK 6 works. So, what is wrong with it? Does it break anything? It is definitely a regression from the b225. The key listener got a KeyEvent with the key char 'a' after pressing for example the Ctrl+Alt+a. And it is expected that the key char should be 'a' in this case. In the latest build the key char is not 'a' for a KeyEvent. The test case with the KeyListener installed to the JPanel is described in the issue 7151821: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7151821 The Alt+Key combination is a system combination on Mac and can't be used for mnemonics. It seems that the Mac OS X is not friendly to the Java mnemonics. Here is some comments from the document: https://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/07-NativePlatformIntegration/NativePlatformIntegration.html ----------------------------------------- Using mnemonics is discouraged in Mac OS X, because mnemonics violate the principles of Mac OS X Human Interface Guidelines. If you are developing a Java application for multiple platforms and some of those platforms recommend the use of mnemonics, just include a single setMnemonics() method that is conditionally called (based on the platform) when constructing your interface. Note: Since the ALT_MASK modifier is the Option key in Mac OS X, Control-Alt masks set for Windows become Command-Option masks if you use getMenuShortcutKeyMask() in conjunction with ALT_MASK. ----------------------------------------- So the Ctrl+Alt+char used for the mnemonics on all tests instead of the Alt+char. Thanks, Alexandr. > > On 13.03.2012, at 19:24, Leonid Romanov wrote: > >> Hi, >> What is the test case for this issue? What Control+alt+char is supposed to do? >> >> On 13.03.2012, at 17:13, Alexander Scherbatiy wrote: >> >>> Please review a fix for 7151821. >>> >>> webrev: http://cr.openjdk.java.net/~alexsch/7151821/webrev.00/ >>> >>> >>> This is a fix for regression after switching using [event charactersIgnoringModifiers] string to [event characters] during the MACOSX_PORT-568 issue fixing: >>> http://java.net/jira/browse/MACOSX_PORT-568 >>> http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5780795f381e >>> >>> The characters string is null during Ctrl+Alt+Char mnemonic pressing. >>> >>> According to the NSEvent charactersIgnoringModifiers doc: >>> This method returns the non-modifier key character pressed for dead keys, such as Option-e. >>> For example, Option-e (no shift key) returns an ?e" for this method, whereas the characters method returns an empty string. >>> >>> The fix uses the charactersIgnoringModifiers string for the keychar when the Ctrl+Alt mnemonic key combination is pressed. >>> >>> Thanks, >>> Alexandr. >>> From leonid.romanov at oracle.com Tue Mar 13 09:26:19 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 13 Mar 2012 20:26:19 +0400 Subject: Request for review 7151821: [macosx] Mnemonic doesn't work in JTabbedPane In-Reply-To: <4F5F704B.5070607@oracle.com> References: <4F5F47FA.5000503@oracle.com> <7AA70445-6588-4473-8F35-A3A3A6A0A53E@oracle.com> <4F5F704B.5070607@oracle.com> Message-ID: Thanks! I've played with javax/swing/JTabbedPane/4624207/bug4624207.java and there is an interesting thing about it: although mnemonics for switching between tabs don't work, setting focus to the "Name" text field via ctrl+alt+m works just fine. So, could it be that there is something broken about the way how JTabbedPane mnemonics are handled? I'm not an expert when it comes to mnemonics, but it seems to me that mnemonics use key codes, so they shouldn't be affected by key char value, right? On 13.03.2012, at 20:05, Alexandr Scherbatiy wrote: > 13.03.2012 18:35, Leonid Romanov ?????: >> Hit "Send" too early. Basically, what you are describing in 7151821 is exactly the way JDK 6 works. So, what is wrong with it? Does it break anything? > It is definitely a regression from the b225. > > The key listener got a KeyEvent with the key char 'a' after pressing for example the Ctrl+Alt+a. > And it is expected that the key char should be 'a' in this case. > > In the latest build the key char is not 'a' for a KeyEvent. > The test case with the KeyListener installed to the JPanel is described in the issue 7151821: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7151821 > > The Alt+Key combination is a system combination on Mac and can't be used for mnemonics. > > It seems that the Mac OS X is not friendly to the Java mnemonics. > Here is some comments from the document: > https://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/07-NativePlatformIntegration/NativePlatformIntegration.html > ----------------------------------------- > Using mnemonics is discouraged in Mac OS X, because mnemonics violate the principles of Mac OS X Human Interface Guidelines. If you are developing a Java application for multiple platforms and some of those platforms recommend the use of mnemonics, just include a single setMnemonics() method that is conditionally called (based on the platform) when constructing your interface. > > Note: Since the ALT_MASK modifier is the Option key in Mac OS X, Control-Alt masks set for Windows become Command-Option masks if you use getMenuShortcutKeyMask() in conjunction with ALT_MASK. > ----------------------------------------- > > So the Ctrl+Alt+char used for the mnemonics on all tests instead of the Alt+char. > > Thanks, > Alexandr. > > >> >> On 13.03.2012, at 19:24, Leonid Romanov wrote: >> >>> Hi, >>> What is the test case for this issue? What Control+alt+char is supposed to do? >>> >>> On 13.03.2012, at 17:13, Alexander Scherbatiy wrote: >>> >>>> Please review a fix for 7151821. >>>> >>>> webrev: http://cr.openjdk.java.net/~alexsch/7151821/webrev.00/ >>>> >>>> >>>> This is a fix for regression after switching using [event charactersIgnoringModifiers] string to [event characters] during the MACOSX_PORT-568 issue fixing: >>>> http://java.net/jira/browse/MACOSX_PORT-568 >>>> http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5780795f381e >>>> >>>> The characters string is null during Ctrl+Alt+Char mnemonic pressing. >>>> >>>> According to the NSEvent charactersIgnoringModifiers doc: >>>> This method returns the non-modifier key character pressed for dead keys, such as Option-e. >>>> For example, Option-e (no shift key) returns an ?e" for this method, whereas the characters method returns an empty string. >>>> >>>> The fix uses the charactersIgnoringModifiers string for the keychar when the Ctrl+Alt mnemonic key combination is pressed. >>>> >>>> Thanks, >>>> Alexandr. >>>> > From niagarasoft20-macosxportdev at yahoo.com Tue Mar 13 10:56:26 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Tue, 13 Mar 2012 10:56:26 -0700 (PDT) Subject: [7u4] Request for phase 2 approval for CR 7132692 - [macosx] Class com.apple.eawt not functioning In-Reply-To: <02F03B77-A005-4365-85FB-28F7D72B4260@oracle.com> References: <4F437DD7.8040505@oracle.com> <7088A00E-0405-4A53-A5E8-24495DCD7102@oracle.com> <1331598645.19244.YahooMailNeo@web126006.mail.ne1.yahoo.com> <02F03B77-A005-4365-85FB-28F7D72B4260@oracle.com> Message-ID: <1331661386.90854.YahooMailNeo@web126006.mail.ne1.yahoo.com> It DOES work from the command line. Perhaps this is an issue with the Launcher? Mike >________________________________ > From: Scott Kovatch >To: "niagarasoft20-macosxportdev at yahoo.com" >Cc: Edvard Wendelin ; Anthony Petrov ; Mike Swingler ; "jdk7u-dev at openjdk.java.net" ; macosx-port-dev >Sent: Monday, March 12, 2012 10:46 PM >Subject: Re: [7u4] Request for phase 2 approval for CR 7132692 - [macosx] Class com.apple.eawt not functioning > >Looks like it was just pushed to jdk7u4 today at 3:15 p.m. or so Pacific time. It's tagged for the b16 build. I'm not sure when it will make its way back to the main jdk7u forest. > >-- Scott K. > >On Mar 12, 2012, at 5:30 PM, niagarasoft20-macosxportdev at yahoo.com wrote: > >> Has this been pushed to source? I've just compiled this and attempted to use it but still not working using the provided JavaAppLauncher? Still not getting the apple menus. I DO get them however when invoking the executable jar from the command line. Using that method they work fine. Perhaps I'm missing something in the info.plist config file. I'm doing exactly what I described in the steps here: >> >> https://wikis.oracle.com/display/OpenJDK/How+to+embed+a+.jre+bundle+in+your+Mac+app >> >> This is the version I'm attempting to bundle: >> >> openjdk version "1.7.0-internal" >> OpenJDK Runtime Environment (build 1.7.0-internal-mnigrin_2012_03_06_20_25-b00) >> OpenJDK 64-Bit Server VM (build 23.0-b16, mixed mode) >> >> >> >> >>> ________________________________ >>> From: Edvard Wendelin >>> To: Anthony Petrov >>> Cc: "jdk7u-dev at openjdk.java.net" ; macosx-port-dev >>> Sent: Friday, February 24, 2012 9:25 AM >>> Subject: Re: [7u4] Request for phase 2 approval for CR 7132692 - [macosx] Class com.apple.eawt not functioning >>> >>> Approved. >>> >>> On Feb 21, 2012, at 12:19 PM, Anthony Petrov wrote: >>> >>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=7132692 >>>> Webrev: http://cr.openjdk.java.net/~anthony/x-16-eawt-7132692.0/ >>>> Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/002992.html >>>> Reviewer: Artem Ananiev (art) >>>> >>>> Rationale for inclusion in 7u4: NetBeans requires this feature. Also, many Java applications deployed on the Mac expect the Apple menu items (About, Preferences, and Quit) to function correctly. W/o this fix the menus don't work as expected. The fix is considered as low-risk since it doesn't affect any functionality other than the Apple menu handling code. >>>> >>>> -- >>>> best regards, >>>> Anthony >>> >>> >>> >>> > > > > From Alan.Bateman at oracle.com Wed Mar 14 02:29:14 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Mar 2012 09:29:14 +0000 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F522B54.3010800@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> Message-ID: <4F6064EA.9060600@oracle.com> On 03/03/2012 14:31, Alan Bateman wrote: > On 03/03/2012 14:14, Henri Gomez wrote: >> Guys could you detail JDK8 build process on OSX ? >> >> I'd like to add this to my openjdk-osx-build project. >> >> Thanks >> > The Mac port isn't in jdk8 yet but should be very soon. The webrev > that Michael sent a link to is just part of the process to get the > changes agreed before he pushes it to the jdk8/tl forest, something > that I hope will happen within a few days. All going well it should > mean the Mac port should get to the jdk8 master in a few weeks > (exactly when it's clearly but I assume it will bake in jdk8/tl for a > bit). Just to follow up on this thread. Lana pushed the Mac port to the jdk8 master yesterday so you should be able to clone jdk8/jdk8 and do your stuff (with a jdk7 build as the bootstrap JDK and working around the gamma launcher issue). -Alan From anton.tarasov at oracle.com Wed Mar 14 02:38:35 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 14 Mar 2012 13:38:35 +0400 Subject: Request for review 7151821: [macosx] Mnemonic doesn't work in JTabbedPane In-Reply-To: References: <4F5F47FA.5000503@oracle.com> <7AA70445-6588-4473-8F35-A3A3A6A0A53E@oracle.com> <4F5F704B.5070607@oracle.com> Message-ID: <4F60671B.5000009@oracle.com> Hi All, On 13.03.2012 20:26, Leonid Romanov wrote: > Thanks! I've played with javax/swing/JTabbedPane/4624207/bug4624207.java and there is an interesting thing about it: although mnemonics for switching between tabs don't work, setting focus to the "Name" text field via ctrl+alt+m works just fine. So, could it be that there is something broken about the way how JTabbedPane mnemonics are handled? I'm not an expert when it comes to mnemonics, but it seems to me that mnemonics use key codes, so they shouldn't be affected by key char value, right? This is a good question. A valid keyChar value is supposed to be delivered by KEY_TYPED event [1]: <> So, we shouldn't actually rely on keyChar in non KEY_TYPED events. I also experimented with the test and found out that, for instance, ctrl+alt+Number mnemonic did work for JTabbedPane. The reason is that such a key stroke produces a valid keyChar (Number). So here's another question: what is the difference b/w ctrl+alt+Number and ctrl+alt+Letter in terms of a keyChar? May the fix for 7134826 be the right place to look at (CPlatformResponder.handleKeyEvent(..))? Thanks, Anton. [1] http://docs.oracle.com/javase/7/docs/api/java/awt/event/KeyEvent.html > > > On 13.03.2012, at 20:05, Alexandr Scherbatiy wrote: > >> 13.03.2012 18:35, Leonid Romanov ?????: >>> Hit "Send" too early. Basically, what you are describing in 7151821 is exactly the way JDK 6 works. So, what is wrong with it? Does it break anything? >> It is definitely a regression from the b225. >> >> The key listener got a KeyEvent with the key char 'a' after pressing for example the Ctrl+Alt+a. >> And it is expected that the key char should be 'a' in this case. >> >> In the latest build the key char is not 'a' for a KeyEvent. >> The test case with the KeyListener installed to the JPanel is described in the issue 7151821: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7151821 >> >> The Alt+Key combination is a system combination on Mac and can't be used for mnemonics. >> >> It seems that the Mac OS X is not friendly to the Java mnemonics. >> Here is some comments from the document: >> https://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/07-NativePlatformIntegration/NativePlatformIntegration.html >> ----------------------------------------- >> Using mnemonics is discouraged in Mac OS X, because mnemonics violate the principles of Mac OS X Human Interface Guidelines. If you are developing a Java application for multiple platforms and some of those platforms recommend the use of mnemonics, just include a single setMnemonics() method that is conditionally called (based on the platform) when constructing your interface. >> >> Note: Since the ALT_MASK modifier is the Option key in Mac OS X, Control-Alt masks set for Windows become Command-Option masks if you use getMenuShortcutKeyMask() in conjunction with ALT_MASK. >> ----------------------------------------- >> >> So the Ctrl+Alt+char used for the mnemonics on all tests instead of the Alt+char. >> >> Thanks, >> Alexandr. >> >> >>> On 13.03.2012, at 19:24, Leonid Romanov wrote: >>> >>>> Hi, >>>> What is the test case for this issue? What Control+alt+char is supposed to do? >>>> >>>> On 13.03.2012, at 17:13, Alexander Scherbatiy wrote: >>>> >>>>> Please review a fix for 7151821. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~alexsch/7151821/webrev.00/ >>>>> >>>>> >>>>> This is a fix for regression after switching using [event charactersIgnoringModifiers] string to [event characters] during the MACOSX_PORT-568 issue fixing: >>>>> http://java.net/jira/browse/MACOSX_PORT-568 >>>>> http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5780795f381e >>>>> >>>>> The characters string is null during Ctrl+Alt+Char mnemonic pressing. >>>>> >>>>> According to the NSEvent charactersIgnoringModifiers doc: >>>>> This method returns the non-modifier key character pressed for dead keys, such as Option-e. >>>>> For example, Option-e (no shift key) returns an ?e" for this method, whereas the characters method returns an empty string. >>>>> >>>>> The fix uses the charactersIgnoringModifiers string for the keychar when the Ctrl+Alt mnemonic key combination is pressed. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> From anton.tarasov at oracle.com Wed Mar 14 02:46:28 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 14 Mar 2012 13:46:28 +0400 Subject: Request for review 7151821: [macosx] Mnemonic doesn't work in JTabbedPane In-Reply-To: <4F5F6153.4030201@oracle.com> References: <4F5F47FA.5000503@oracle.com> <4F5F6153.4030201@oracle.com> Message-ID: <4F6068F4.8070301@oracle.com> Hi Anthony, option+char produces a special unicode symbol and actually may not generate KEY_TYPED at all (it won't with the fix for 7144063). Instead, it synthesizes InputMethodEvent. So, your suggestion is applicable to KEY_PRESSED/KEY_RELEASED for which a valid keyChar is not mandatory (but perhaps, we may provide it if we get it). Thanks, Anton. On 13.03.2012 19:01, Anthony Petrov wrote: > Hi Alexander, > > How about doing something more generic, like the following: > > chars = [ev chars]; > if (chars is empty) { > chars = [ev charsIgnoreMods]; > } > > ? What might go wrong with such approach? In this case we'll also see chars=='e' for Option+e. > Would that be a bug, or would it be actually something that we'd like to see? > > -- > best regards, > Anthony > > On 3/13/2012 5:13 PM, Alexander Scherbatiy wrote: >> Please review a fix for 7151821. >> >> webrev: http://cr.openjdk.java.net/~alexsch/7151821/webrev.00/ >> >> >> This is a fix for regression after switching using [event charactersIgnoringModifiers] string to >> [event characters] during the MACOSX_PORT-568 issue fixing: >> http://java.net/jira/browse/MACOSX_PORT-568 >> http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5780795f381e >> >> The characters string is null during Ctrl+Alt+Char mnemonic pressing. >> >> According to the NSEvent charactersIgnoringModifiers doc: >> This method returns the non-modifier key character pressed for dead keys, such as Option-e. >> For example, Option-e (no shift key) returns an ?e" for this method, whereas the characters >> method returns an empty string. >> >> The fix uses the charactersIgnoringModifiers string for the keychar when the Ctrl+Alt mnemonic >> key combination is pressed. >> >> Thanks, >> Alexandr. >> From leonid.romanov at oracle.com Wed Mar 14 03:42:26 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 14 Mar 2012 14:42:26 +0400 Subject: Request for review 7151821: [macosx] Mnemonic doesn't work in JTabbedPane In-Reply-To: <4F60671B.5000009@oracle.com> References: <4F5F47FA.5000503@oracle.com> <7AA70445-6588-4473-8F35-A3A3A6A0A53E@oracle.com> <4F5F704B.5070607@oracle.com> <4F60671B.5000009@oracle.com> Message-ID: Ok, I've done some digging through Swing code and found that mnemonics implementation does rely on key char value. See SwingUtilities.notifyAction method, which delivers Action event when one of the registered key strokes has been triggered by user. Here is the relevant code snippet: // Convert it to a string. String command; if (commandO != null) { command = commandO.toString(); } else if (!stayNull && event.getKeyChar() != KeyEvent.CHAR_UNDEFINED) { command = String.valueOf(event.getKeyChar()); } else { // Do null for undefined chars, or if registerKeyboardAction // was called with a null. command = null; } action.actionPerformed(new ActionEvent(sender, ActionEvent.ACTION_PERFORMED, command, event.getWhen(), modifiers)); Also, see BasicTabbedPaneUI's actionPerformed() method which uses that key char like this: else if (key == SET_SELECTED) { String command = e.getActionCommand(); if (command != null && command.length() > 0) { int mnemonic = (int)e.getActionCommand().charAt(0); if (mnemonic >= 'a' && mnemonic <='z') { mnemonic -= ('a' - 'A'); } Integer index = ui.mnemonicToIndexMap.get(Integer.valueOf(mnemonic)); if (index != null && pane.isEnabledAt(index.intValue())) { pane.setSelectedIndex(index.intValue()); } } } I can't say I completely understand what the code above is trying to achieve (and why), but it seems like Alexandr's fix is actually correct. The problem is the following: on Cocoa level, there is no difference between pressing ctrl+c and ctrl+alt+c, in both cases NSEvent's -characters method returns 0x03 as the character typed. While this is exactly what we want in case of ctrl+c, in order for the ctrl+alt+c mnemonic to work, we have to return 'c' instead, even if it contradicts the way OS X works. On 14.03.2012, at 13:38, Anton V. Tarasov wrote: > Hi All, > > On 13.03.2012 20:26, Leonid Romanov wrote: >> Thanks! I've played with javax/swing/JTabbedPane/4624207/bug4624207.java and there is an interesting thing about it: although mnemonics for switching between tabs don't work, setting focus to the "Name" text field via ctrl+alt+m works just fine. So, could it be that there is something broken about the way how JTabbedPane mnemonics are handled? I'm not an expert when it comes to mnemonics, but it seems to me that mnemonics use key codes, so they shouldn't be affected by key char value, right? > > This is a good question. > > A valid keyChar value is supposed to be delivered by KEY_TYPED event [1]: > > <> > > So, we shouldn't actually rely on keyChar in non KEY_TYPED events. > > I also experimented with the test and found out that, for instance, ctrl+alt+Number mnemonic did work for JTabbedPane. The reason is that such a key stroke produces a valid keyChar (Number). So here's another question: what is the difference b/w ctrl+alt+Number and ctrl+alt+Letter in terms of a keyChar? May the fix for 7134826 be the right place to look at (CPlatformResponder.handleKeyEvent(..))? > > Thanks, > Anton. > > [1] http://docs.oracle.com/javase/7/docs/api/java/awt/event/KeyEvent.html > >> >> >> On 13.03.2012, at 20:05, Alexandr Scherbatiy wrote: >> >>> 13.03.2012 18:35, Leonid Romanov ?????: >>>> Hit "Send" too early. Basically, what you are describing in 7151821 is exactly the way JDK 6 works. So, what is wrong with it? Does it break anything? >>> It is definitely a regression from the b225. >>> >>> The key listener got a KeyEvent with the key char 'a' after pressing for example the Ctrl+Alt+a. >>> And it is expected that the key char should be 'a' in this case. >>> >>> In the latest build the key char is not 'a' for a KeyEvent. >>> The test case with the KeyListener installed to the JPanel is described in the issue 7151821: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7151821 >>> >>> The Alt+Key combination is a system combination on Mac and can't be used for mnemonics. >>> >>> It seems that the Mac OS X is not friendly to the Java mnemonics. >>> Here is some comments from the document: >>> https://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/07-NativePlatformIntegration/NativePlatformIntegration.html >>> ----------------------------------------- >>> Using mnemonics is discouraged in Mac OS X, because mnemonics violate the principles of Mac OS X Human Interface Guidelines. If you are developing a Java application for multiple platforms and some of those platforms recommend the use of mnemonics, just include a single setMnemonics() method that is conditionally called (based on the platform) when constructing your interface. >>> >>> Note: Since the ALT_MASK modifier is the Option key in Mac OS X, Control-Alt masks set for Windows become Command-Option masks if you use getMenuShortcutKeyMask() in conjunction with ALT_MASK. >>> ----------------------------------------- >>> >>> So the Ctrl+Alt+char used for the mnemonics on all tests instead of the Alt+char. >>> >>> Thanks, >>> Alexandr. >>> >>> >>>> On 13.03.2012, at 19:24, Leonid Romanov wrote: >>>> >>>>> Hi, >>>>> What is the test case for this issue? What Control+alt+char is supposed to do? >>>>> >>>>> On 13.03.2012, at 17:13, Alexander Scherbatiy wrote: >>>>> >>>>>> Please review a fix for 7151821. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7151821/webrev.00/ >>>>>> >>>>>> >>>>>> This is a fix for regression after switching using [event charactersIgnoringModifiers] string to [event characters] during the MACOSX_PORT-568 issue fixing: >>>>>> http://java.net/jira/browse/MACOSX_PORT-568 >>>>>> http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5780795f381e >>>>>> >>>>>> The characters string is null during Ctrl+Alt+Char mnemonic pressing. >>>>>> >>>>>> According to the NSEvent charactersIgnoringModifiers doc: >>>>>> This method returns the non-modifier key character pressed for dead keys, such as Option-e. >>>>>> For example, Option-e (no shift key) returns an ?e" for this method, whereas the characters method returns an empty string. >>>>>> >>>>>> The fix uses the charactersIgnoringModifiers string for the keychar when the Ctrl+Alt mnemonic key combination is pressed. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> > From andrew.brygin at oracle.com Wed Mar 14 04:58:37 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 14 Mar 2012 15:58:37 +0400 Subject: [7u4] request for review: 7152608: [macosx] Crash in liblwawt.dylib in AccelGlyphCache_RemoveCellInfo Message-ID: <4F6087ED.2080709@oracle.com> Hello, this problem is an example of 'use-after-free' crash: the crash itself happens when AccelGlyphCache meets invalid pointer to a cache cell info in cached glyph info structure. This pointer can have arbitrary value, because corresponding glyph info structure is already destroyed by CStrike cache machinery. The root of the problem is that this destruction is made without any notification to AccelGlyphCache, which keeps and uses invalid pointer to glyph info object. Suggested solution is to remove a glyph info instance from the accelerated cache before destruction. Please take a look to suggested fix. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152608 Webrev: http://cr.openjdk.java.net/~bae/7152608/webrev/ Thanks, Andrew From anton.tarasov at oracle.com Wed Mar 14 05:04:18 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 14 Mar 2012 16:04:18 +0400 Subject: Request for review 7151821: [macosx] Mnemonic doesn't work in JTabbedPane In-Reply-To: References: <4F5F47FA.5000503@oracle.com> <7AA70445-6588-4473-8F35-A3A3A6A0A53E@oracle.com> <4F5F704B.5070607@oracle.com> <4F60671B.5000009@oracle.com> Message-ID: <4F608942.1070303@oracle.com> On 14.03.2012 14:42, Leonid Romanov wrote: > Ok, I've done some digging through Swing code and found that mnemonics implementation does rely on key char value. See SwingUtilities.notifyAction method, which delivers Action event when one of the registered key strokes has been triggered by user. Here is the relevant code snippet: > > // Convert it to a string. > String command; > > if (commandO != null) { > command = commandO.toString(); > } > else if (!stayNull&& event.getKeyChar() != KeyEvent.CHAR_UNDEFINED) { > command = String.valueOf(event.getKeyChar()); > } > else { > // Do null for undefined chars, or if registerKeyboardAction > // was called with a null. > command = null; > } > action.actionPerformed(new ActionEvent(sender, > ActionEvent.ACTION_PERFORMED, command, event.getWhen(), > modifiers)); > > Also, see BasicTabbedPaneUI's actionPerformed() method which uses that key char like this: > > else if (key == SET_SELECTED) { > String command = e.getActionCommand(); > > if (command != null&& command.length()> 0) { > int mnemonic = (int)e.getActionCommand().charAt(0); > if (mnemonic>= 'a'&& mnemonic<='z') { > mnemonic -= ('a' - 'A'); > } > Integer index = ui.mnemonicToIndexMap.get(Integer.valueOf(mnemonic)); > if (index != null&& pane.isEnabledAt(index.intValue())) { > pane.setSelectedIndex(index.intValue()); > } > } > } > > I can't say I completely understand what the code above is trying to achieve (and why), but it seems like Alexandr's fix is actually correct. The problem is the following: on Cocoa level, there is no difference between pressing ctrl+c and ctrl+alt+c, in both cases NSEvent's -characters method returns 0x03 as the character typed. While this is exactly what we want in case of ctrl+c, in order for the ctrl+alt+c mnemonic to work, we have to return 'c' instead, even if it contradicts the way OS X works. Well, I see. Thanks for the analysis. I asked Alexander P. (cc'ed) about the mnemonics. He said that using a keyChar is a "historical reason". And indeed, there's an obsolete setMnemonic(char) method: http://docs.oracle.com/javase/7/docs/api/javax/swing/AbstractButton.html#setMnemonic%28char%29 Thanks, Anton. > > > On 14.03.2012, at 13:38, Anton V. Tarasov wrote: > >> Hi All, >> >> On 13.03.2012 20:26, Leonid Romanov wrote: >>> Thanks! I've played with javax/swing/JTabbedPane/4624207/bug4624207.java and there is an interesting thing about it: although mnemonics for switching between tabs don't work, setting focus to the "Name" text field via ctrl+alt+m works just fine. So, could it be that there is something broken about the way how JTabbedPane mnemonics are handled? I'm not an expert when it comes to mnemonics, but it seems to me that mnemonics use key codes, so they shouldn't be affected by key char value, right? >> This is a good question. >> >> A valid keyChar value is supposed to be delivered by KEY_TYPED event [1]: >> >> <> >> >> So, we shouldn't actually rely on keyChar in non KEY_TYPED events. >> >> I also experimented with the test and found out that, for instance, ctrl+alt+Number mnemonic did work for JTabbedPane. The reason is that such a key stroke produces a valid keyChar (Number). So here's another question: what is the difference b/w ctrl+alt+Number and ctrl+alt+Letter in terms of a keyChar? May the fix for 7134826 be the right place to look at (CPlatformResponder.handleKeyEvent(..))? >> >> Thanks, >> Anton. >> >> [1] http://docs.oracle.com/javase/7/docs/api/java/awt/event/KeyEvent.html >> >>> >>> On 13.03.2012, at 20:05, Alexandr Scherbatiy wrote: >>> >>>> 13.03.2012 18:35, Leonid Romanov ?????: >>>>> Hit "Send" too early. Basically, what you are describing in 7151821 is exactly the way JDK 6 works. So, what is wrong with it? Does it break anything? >>>> It is definitely a regression from the b225. >>>> >>>> The key listener got a KeyEvent with the key char 'a' after pressing for example the Ctrl+Alt+a. >>>> And it is expected that the key char should be 'a' in this case. >>>> >>>> In the latest build the key char is not 'a' for a KeyEvent. >>>> The test case with the KeyListener installed to the JPanel is described in the issue 7151821: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7151821 >>>> >>>> The Alt+Key combination is a system combination on Mac and can't be used for mnemonics. >>>> >>>> It seems that the Mac OS X is not friendly to the Java mnemonics. >>>> Here is some comments from the document: >>>> https://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/07-NativePlatformIntegration/NativePlatformIntegration.html >>>> ----------------------------------------- >>>> Using mnemonics is discouraged in Mac OS X, because mnemonics violate the principles of Mac OS X Human Interface Guidelines. If you are developing a Java application for multiple platforms and some of those platforms recommend the use of mnemonics, just include a single setMnemonics() method that is conditionally called (based on the platform) when constructing your interface. >>>> >>>> Note: Since the ALT_MASK modifier is the Option key in Mac OS X, Control-Alt masks set for Windows become Command-Option masks if you use getMenuShortcutKeyMask() in conjunction with ALT_MASK. >>>> ----------------------------------------- >>>> >>>> So the Ctrl+Alt+char used for the mnemonics on all tests instead of the Alt+char. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>>> On 13.03.2012, at 19:24, Leonid Romanov wrote: >>>>> >>>>>> Hi, >>>>>> What is the test case for this issue? What Control+alt+char is supposed to do? >>>>>> >>>>>> On 13.03.2012, at 17:13, Alexander Scherbatiy wrote: >>>>>> >>>>>>> Please review a fix for 7151821. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7151821/webrev.00/ >>>>>>> >>>>>>> >>>>>>> This is a fix for regression after switching using [event charactersIgnoringModifiers] string to [event characters] during the MACOSX_PORT-568 issue fixing: >>>>>>> http://java.net/jira/browse/MACOSX_PORT-568 >>>>>>> http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5780795f381e >>>>>>> >>>>>>> The characters string is null during Ctrl+Alt+Char mnemonic pressing. >>>>>>> >>>>>>> According to the NSEvent charactersIgnoringModifiers doc: >>>>>>> This method returns the non-modifier key character pressed for dead keys, such as Option-e. >>>>>>> For example, Option-e (no shift key) returns an ?e" for this method, whereas the characters method returns an empty string. >>>>>>> >>>>>>> The fix uses the charactersIgnoringModifiers string for the keychar when the Ctrl+Alt mnemonic key combination is pressed. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> From henri.gomez at gmail.com Wed Mar 14 05:59:38 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 14 Mar 2012 14:59:38 +0200 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F6064EA.9060600@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> <4F6064EA.9060600@oracle.com> Message-ID: Good news. Could you recall us the recommended/official build command lines ? 2012/3/14 Alan Bateman : > On 03/03/2012 14:31, Alan Bateman wrote: >> >> On 03/03/2012 14:14, Henri Gomez wrote: >>> >>> Guys could you detail JDK8 build process on OSX ? >>> >>> I'd like to add this to my openjdk-osx-build project. >>> >>> Thanks >>> >> The Mac port isn't in jdk8 yet but should be very soon. The webrev that >> Michael sent a link to is just part of the process to get the changes agreed >> before he pushes it to the jdk8/tl forest, something that I hope will happen >> within a few days. All going well it should mean the Mac port should get to >> the jdk8 master in a few weeks (exactly when it's clearly but I assume it >> will bake in jdk8/tl for a bit). > > Just to follow up on this thread. Lana pushed the Mac port to the jdk8 > master yesterday so you should be able to clone jdk8/jdk8 and do your stuff > (with a jdk7 build as the bootstrap JDK and working around the gamma > launcher issue). > > -Alan From leonid.romanov at oracle.com Wed Mar 14 06:39:41 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 14 Mar 2012 17:39:41 +0400 Subject: [7u4] Review request for CR 7124286: [macosx] Option modifier should work like AltGr as in Apple jdk 6 Message-ID: <36E2C8D7-CD2F-4CFC-A402-54A477F51EE5@oracle.com> Hi, Please review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124286 webrev: http://cr.openjdk.java.net/~leonidr/7124286/webrev.00/ Since this fix modifies shared code, I tried to keep as much of original code as possible. Also, isPrintableCharacterModifiersMask() might be not the best name possible: the reason I used it is because I couldn't come with better name. Thanks, Leonid. From anton.tarasov at oracle.com Wed Mar 14 07:25:32 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 14 Mar 2012 18:25:32 +0400 Subject: [7u4] Request for phase 2 approval for CR 7145827: [macosx] JCK failure in b11: FocusableWindow3 Message-ID: <4F60AA5C.70904@oracle.com> Bug: http://bugs.sun.com/view_bug.do?bug_id=7145827 Webrev: http://cr.openjdk.java.net/~ant/7145827/webrev.0/ Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003555.html Reviewer: Artem Ananiev (art) Rationale for inclusion in 7u4: JCK failure. Thanks, Anton. From swingler at apple.com Wed Mar 14 08:32:10 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 14 Mar 2012 08:32:10 -0700 Subject: [7u4] Review request for CR 7124286: [macosx] Option modifier should work like AltGr as in Apple jdk 6 In-Reply-To: <36E2C8D7-CD2F-4CFC-A402-54A477F51EE5@oracle.com> References: <36E2C8D7-CD2F-4CFC-A402-54A477F51EE5@oracle.com> Message-ID: <554DAF43-DACD-4C93-B419-02AB47B7C5C9@apple.com> On Mar 14, 2012, at 6:39 AM, Leonid Romanov wrote: > Hi, > Please review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124286 > webrev: http://cr.openjdk.java.net/~leonidr/7124286/webrev.00/ > > Since this fix modifies shared code, I tried to keep as much of original code as possible. Also, isPrintableCharacterModifiersMask() might be not the best name possible: the reason I used it is because I couldn't come with better name. Really the only alternative would be opposite: isCommandInvocationModifiersMask(), which may be more accurate as to what you are testing...seems like a tossup to me though. The general idea seems fine, and I like how the Mac behavior difference can be handled by a simple override, but others may have more specific critiques. Regards, Mike Swingler Apple Inc. From swingler at apple.com Wed Mar 14 08:33:49 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 14 Mar 2012 08:33:49 -0700 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> <4F6064EA.9060600@oracle.com> Message-ID: They should be the same ones as what is on the wiki page...it's just a different repo. I haven't tried it yet, but if you have any issues, here is the place to discuss them. Regards, Mike Swingler Apple Inc. On Mar 14, 2012, at 5:59 AM, Henri Gomez wrote: > Good news. > > Could you recall us the recommended/official build command lines ? > > 2012/3/14 Alan Bateman : >> On 03/03/2012 14:31, Alan Bateman wrote: >>> >>> On 03/03/2012 14:14, Henri Gomez wrote: >>>> >>>> Guys could you detail JDK8 build process on OSX ? >>>> >>>> I'd like to add this to my openjdk-osx-build project. >>>> >>>> Thanks >>>> >>> The Mac port isn't in jdk8 yet but should be very soon. The webrev that >>> Michael sent a link to is just part of the process to get the changes agreed >>> before he pushes it to the jdk8/tl forest, something that I hope will happen >>> within a few days. All going well it should mean the Mac port should get to >>> the jdk8 master in a few weeks (exactly when it's clearly but I assume it >>> will bake in jdk8/tl for a bit). >> >> Just to follow up on this thread. Lana pushed the Mac port to the jdk8 >> master yesterday so you should be able to clone jdk8/jdk8 and do your stuff >> (with a jdk7 build as the bootstrap JDK and working around the gamma >> launcher issue). >> >> -Alan From michael.x.mcmahon at oracle.com Wed Mar 14 08:39:46 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 14 Mar 2012 15:39:46 +0000 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> <4F6064EA.9060600@oracle.com> Message-ID: <4F60BBC2.5060409@oracle.com> Right, except for using 7u4 as the boot JDK, everything else should be the same. - Michael On 14/03/12 15:33, Mike Swingler wrote: > They should be the same ones as what is on the wiki page...it's just a different repo. I haven't tried it yet, but if you have any issues, here is the place to discuss them. > > Regards, > Mike Swingler > Apple Inc. > > On Mar 14, 2012, at 5:59 AM, Henri Gomez wrote: > >> Good news. >> >> Could you recall us the recommended/official build command lines ? >> >> 2012/3/14 Alan Bateman: >>> On 03/03/2012 14:31, Alan Bateman wrote: >>>> On 03/03/2012 14:14, Henri Gomez wrote: >>>>> Guys could you detail JDK8 build process on OSX ? >>>>> >>>>> I'd like to add this to my openjdk-osx-build project. >>>>> >>>>> Thanks >>>>> >>>> The Mac port isn't in jdk8 yet but should be very soon. The webrev that >>>> Michael sent a link to is just part of the process to get the changes agreed >>>> before he pushes it to the jdk8/tl forest, something that I hope will happen >>>> within a few days. All going well it should mean the Mac port should get to >>>> the jdk8 master in a few weeks (exactly when it's clearly but I assume it >>>> will bake in jdk8/tl for a bit). >>> Just to follow up on this thread. Lana pushed the Mac port to the jdk8 >>> master yesterday so you should be able to clone jdk8/jdk8 and do your stuff >>> (with a jdk7 build as the bootstrap JDK and working around the gamma >>> launcher issue). >>> >>> -Alan From henri.gomez at gmail.com Wed Mar 14 09:01:59 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 14 Mar 2012 18:01:59 +0200 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> <4F6064EA.9060600@oracle.com> Message-ID: Well I'm using mainly same stuff except I added : ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7` A fresh OpenJDK 8 for OSX has been released : http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-8-x64-jdk-b29-20120314.dmg Cheers 2012/3/14 Mike Swingler : > They should be the same ones as what is on the wiki page...it's just a different repo. I haven't tried it yet, but if you have any issues, here is the place to discuss them. > > Regards, > Mike Swingler > Apple Inc. > > On Mar 14, 2012, at 5:59 AM, Henri Gomez wrote: > >> Good news. >> >> Could you recall us the recommended/official build command lines ? >> >> 2012/3/14 Alan Bateman : >>> On 03/03/2012 14:31, Alan Bateman wrote: >>>> >>>> On 03/03/2012 14:14, Henri Gomez wrote: >>>>> >>>>> Guys could you detail JDK8 build process on OSX ? >>>>> >>>>> I'd like to add this to my openjdk-osx-build project. >>>>> >>>>> Thanks >>>>> >>>> The Mac port isn't in jdk8 yet but should be very soon. The webrev that >>>> Michael sent a link to is just part of the process to get the changes agreed >>>> before he pushes it to the jdk8/tl forest, something that I hope will happen >>>> within a few days. All going well it should mean the Mac port should get to >>>> the jdk8 master in a few weeks (exactly when it's clearly but I assume it >>>> will bake in jdk8/tl for a bit). >>> >>> Just to follow up on this thread. Lana pushed the Mac port to the jdk8 >>> master yesterday so you should be able to clone jdk8/jdk8 and do your stuff >>> (with a jdk7 build as the bootstrap JDK and working around the gamma >>> launcher issue). >>> >>> -Alan > From swingler at apple.com Wed Mar 14 09:02:57 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 14 Mar 2012 09:02:57 -0700 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> <4F6064EA.9060600@oracle.com> Message-ID: Awesome, thanks much Henri! Cheers, Mike Swingler Apple Inc. On Mar 14, 2012, at 9:01 AM, Henri Gomez wrote: > Well I'm using mainly same stuff except I added : > > ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7` > > A fresh OpenJDK 8 for OSX has been released : > > http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-8-x64-jdk-b29-20120314.dmg > > Cheers > > 2012/3/14 Mike Swingler : >> They should be the same ones as what is on the wiki page...it's just a different repo. I haven't tried it yet, but if you have any issues, here is the place to discuss them. >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Mar 14, 2012, at 5:59 AM, Henri Gomez wrote: >> >>> Good news. >>> >>> Could you recall us the recommended/official build command lines ? >>> >>> 2012/3/14 Alan Bateman : >>>> On 03/03/2012 14:31, Alan Bateman wrote: >>>>> >>>>> On 03/03/2012 14:14, Henri Gomez wrote: >>>>>> >>>>>> Guys could you detail JDK8 build process on OSX ? >>>>>> >>>>>> I'd like to add this to my openjdk-osx-build project. >>>>>> >>>>>> Thanks >>>>>> >>>>> The Mac port isn't in jdk8 yet but should be very soon. The webrev that >>>>> Michael sent a link to is just part of the process to get the changes agreed >>>>> before he pushes it to the jdk8/tl forest, something that I hope will happen >>>>> within a few days. All going well it should mean the Mac port should get to >>>>> the jdk8 master in a few weeks (exactly when it's clearly but I assume it >>>>> will bake in jdk8/tl for a bit). >>>> >>>> Just to follow up on this thread. Lana pushed the Mac port to the jdk8 >>>> master yesterday so you should be able to clone jdk8/jdk8 and do your stuff >>>> (with a jdk7 build as the bootstrap JDK and working around the gamma >>>> launcher issue). >>>> >>>> -Alan >> From scott.kovatch at oracle.com Wed Mar 14 09:27:53 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 14 Mar 2012 09:27:53 -0700 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> <4F6064EA.9060600@oracle.com> Message-ID: <6827EFB6-FD55-4851-98B1-68617D8205DA@oracle.com> This is great to see! Thanks for doing that! ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA On Mar 14, 2012, at 9:01 AM, Henri Gomez wrote: > Well I'm using mainly same stuff except I added : > > ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7` > > A fresh OpenJDK 8 for OSX has been released : > > http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-8-x64-jdk-b29-20120314.dmg > > Cheers > > 2012/3/14 Mike Swingler : >> They should be the same ones as what is on the wiki page...it's just a different repo. I haven't tried it yet, but if you have any issues, here is the place to discuss them. >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Mar 14, 2012, at 5:59 AM, Henri Gomez wrote: >> >>> Good news. >>> >>> Could you recall us the recommended/official build command lines ? >>> >>> 2012/3/14 Alan Bateman : >>>> On 03/03/2012 14:31, Alan Bateman wrote: >>>>> >>>>> On 03/03/2012 14:14, Henri Gomez wrote: >>>>>> >>>>>> Guys could you detail JDK8 build process on OSX ? >>>>>> >>>>>> I'd like to add this to my openjdk-osx-build project. >>>>>> >>>>>> Thanks >>>>>> >>>>> The Mac port isn't in jdk8 yet but should be very soon. The webrev that >>>>> Michael sent a link to is just part of the process to get the changes agreed >>>>> before he pushes it to the jdk8/tl forest, something that I hope will happen >>>>> within a few days. All going well it should mean the Mac port should get to >>>>> the jdk8 master in a few weeks (exactly when it's clearly but I assume it >>>>> will bake in jdk8/tl for a bit). >>>> >>>> Just to follow up on this thread. Lana pushed the Mac port to the jdk8 >>>> master yesterday so you should be able to clone jdk8/jdk8 and do your stuff >>>> (with a jdk7 build as the bootstrap JDK and working around the gamma >>>> launcher issue). >>>> >>>> -Alan >> From scott.kovatch at oracle.com Wed Mar 14 09:33:36 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 14 Mar 2012 09:33:36 -0700 Subject: OpenJDK prerequisites Message-ID: Henri, On your page for OpenJDK 7/8 builds you have: ============ Prerequisite Mike Swingler from Apple Java Team mention in mailing-list : "As a prerequisite to using OpenJDK, we'd ask that you install the Apple Java Developer Preview" "This preview will ensure that you have a /Library/Java/JavaVirtualMachines directory to land the 1.7.0.jdk into, as well as the new API that OpenJDK is now relying on." Latest Java 1.6 for Snow and Lion should include these requirements : Java for Mac OS X 10.7 Update 1: http://support.apple.com/kb/DL1421 Java for Mac OS X 10.6 Update 6: http://support.apple.com/kb/DL1360 =========== OS X 10.7.3 now takes care of all of these issues. For Snow Leopard you will still need Java for Mac OS X 10.6 Update 6, but on Lion you don't need Java 6 to install JDK 7. (Mike can correct me if I'm wrong.) -- Scott K. From henri.gomez at gmail.com Wed Mar 14 12:56:56 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 14 Mar 2012 21:56:56 +0200 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <6827EFB6-FD55-4851-98B1-68617D8205DA@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> <4F6064EA.9060600@oracle.com> <6827EFB6-FD55-4851-98B1-68617D8205DA@oracle.com> Message-ID: Well, I tried some Java 8 samples like : public class Sample4 { enum Decision { APPROVE, DECLINE, APPROVE_REFER } interface DecisionService { Decision getRiskDecision(Applicant applicant); } class Applicant { private int score; public Applicant(int score) { this.score = score; } public int getScore() { return score; } } public void test() { DecisionService cs = (a) -> { if (a.getScore() > 700) { return Decision.APPROVE; } else if (a.getScore() > 600 && a.getScore() < 650) { return Decision.APPROVE_REFER; } else { return Decision.DECLINE; }}; Decision decision = cs.getRiskDecision(new Applicant(800)); System.out.println(decision.toString()); } public static void main(String... args) { new Sample4().test(); } } But it fail to build ;( Sample4.java:24: error: lambda expressions are not supported in -source 1.8 DecisionService cs = (a) -> { ^ (use -source 8 or higher to enable lambda expressions) Tried to force -source 8, no more luck. Any Lamba guru around ? :) 2012/3/14 Scott Kovatch : > This is great to see! Thanks for doing that! > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > > On Mar 14, 2012, at 9:01 AM, Henri Gomez wrote: > > Well I'm using mainly same stuff except I added : > > ALT_BOOTDIR=`/usr/libexec/java_home -v 1.7` > > A fresh OpenJDK 8 for OSX has been released : > > http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-8-x64-jdk-b29-20120314.dmg > > Cheers > > 2012/3/14 Mike Swingler : > > They should be the same ones as what is on the > wiki page...it's > just a different repo. I haven't tried it yet, but if you have any issues, > here is the place to discuss them. > > > Regards, > > Mike Swingler > > Apple Inc. > > > On Mar 14, 2012, at 5:59 AM, Henri Gomez wrote: > > > Good news. > > > Could you recall us the recommended/official build command lines ? > > > 2012/3/14 Alan Bateman : > > On 03/03/2012 14:31, Alan Bateman wrote: > > > On 03/03/2012 14:14, Henri Gomez wrote: > > > Guys could you detail JDK8 build process on OSX ? > > > I'd like to add this to my openjdk-osx-build project. > > > Thanks > > > The Mac port isn't in jdk8 yet but should be very soon. The webrev that > > Michael sent a link to is just part of the process to get the changes agreed > > before he pushes it to the jdk8/tl forest, something that I hope will happen > > within a few days. All going well it should mean the Mac port should get to > > the jdk8 master in a few weeks (exactly when it's clearly but I assume it > > will bake in jdk8/tl for a bit). > > > Just to follow up on this thread. Lana pushed the Mac port to the jdk8 > > master yesterday so you should be able to clone jdk8/jdk8 and do your stuff > > (with a jdk7 build as the bootstrap JDK and working around the gamma > > launcher issue). > > > -Alan > > > From henri.gomez at gmail.com Wed Mar 14 13:13:42 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 14 Mar 2012 22:13:42 +0200 Subject: OpenJDK prerequisites In-Reply-To: References: Message-ID: > OS X 10.7.3 now takes care of all of these issues. For Snow Leopard you will > still need Java for Mac OS X 10.6 Update 6, but on Lion you don't need Java > 6 to install JDK 7. > > (Mike can correct me if I'm wrong.) > > -- Scott K. > page fixed. Thanks Scott From henri.gomez at gmail.com Wed Mar 14 13:16:41 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 14 Mar 2012 22:16:41 +0200 Subject: OpenJDK prerequisites In-Reply-To: References: Message-ID: Since I've got 2 OSX experts not too far. On Lion, drag and drop operation (install and update time), require to be signed for admin rights And update (ie dragging a new version over a previous one), didn't works anymore. Don't get such behaviour on SnowLeopard. DMG use standard hdiutil stuff, unchanged from Snow. Any idea about update problem ? 2012/3/14 Henri Gomez : >> OS X 10.7.3 now takes care of all of these issues. For Snow Leopard you will >> still need Java for Mac OS X 10.6 Update 6, but on Lion you don't need Java >> 6 to install JDK 7. >> >> (Mike can correct me if I'm wrong.) >> >> -- Scott K. >> > > page fixed. > > Thanks Scott From swingler at apple.com Wed Mar 14 13:48:04 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 14 Mar 2012 13:48:04 -0700 Subject: OpenJDK prerequisites In-Reply-To: References: Message-ID: <55DF2FAE-EDA4-4A83-BD1B-6187B211E01E@apple.com> I don't code-signing has anything to do with this?do you mean that the user has to authenticate? If drag-and-drop replacement doesn't work (with authentication), then that's a bug that needs to be filed against the Finder at . Regards, Mike Swingler Apple Inc. On Mar 14, 2012, at 1:16 PM, Henri Gomez wrote: > Since I've got 2 OSX experts not too far. > > On Lion, drag and drop operation (install and update time), require to > be signed for admin rights > And update (ie dragging a new version over a previous one), didn't > works anymore. > > Don't get such behaviour on SnowLeopard. > > DMG use standard hdiutil stuff, unchanged from Snow. > > Any idea about update problem ? > > 2012/3/14 Henri Gomez : >>> OS X 10.7.3 now takes care of all of these issues. For Snow Leopard you will >>> still need Java for Mac OS X 10.6 Update 6, but on Lion you don't need Java >>> 6 to install JDK 7. >>> >>> (Mike can correct me if I'm wrong.) >>> >>> -- Scott K. >>> >> >> page fixed. >> >> Thanks Scott From henri.gomez at gmail.com Wed Mar 14 13:53:49 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 14 Mar 2012 22:53:49 +0200 Subject: OpenJDK prerequisites In-Reply-To: <55DF2FAE-EDA4-4A83-BD1B-6187B211E01E@apple.com> References: <55DF2FAE-EDA4-4A83-BD1B-6187B211E01E@apple.com> Message-ID: > I don't code-signing has anything to do with this?do you mean that the user has to authenticate? Yes on Lion. Here is /Library/Java/JavaVirtualMachines/ : total 0 0 drwxr-xr-x 3 root wheel 102 29 jui 2011 1.6.0_26-b03-383.jdk 0 drwxr-xr-x 3 root wheel 102 22 sep 23:09 1.6.0_27-b07-395.jdk 0 drwxr-xr-x 3 root wheel 102 15 oct 00:55 1.6.0_29-b11-397.jdk 0 drwxr-xr-x 3 henri staff 102 8 nov 22:11 openjdk-1.8-x86_64 0 drwxr-xr-x 3 root wheel 102 15 d?c 23:45 1.6.0_30-b12-404.jdk 0 drwxr-xr-x@ 4 henri wheel 136 12 jan 23:44 JDK 1.7.0 Developer Preview.jdk 0 drwxr-xr-x 3 root wheel 102 30 jan 20:50 1.6.0_30-b12-409.jdk 0 drwxr-xr-x 3 root wheel 102 14 f?v 22:31 1.6.0_31-b04-411.jdk 0 drwxr-xr-x@ 4 henri wheel 136 13 mar 10:11 1.7.0u4.jdk 0 drwxr-xr-x@ 4 henri wheel 136 14 mar 10:35 1.7.0u.jdk 0 drwxr-xr-x@ 4 henri wheel 136 14 mar 17:13 1.8.0.jdk > If drag-and-drop replacement doesn't work (with authentication), then that's a bug that needs to be filed against the Finder at . Well, if someone else report the problem, I'll open a bug, may be it's only on my machine. From mark at talios.com Wed Mar 14 14:33:45 2012 From: mark at talios.com (Mark Derricutt) Date: Thu, 15 Mar 2012 10:33:45 +1300 Subject: OpenJDK prerequisites In-Reply-To: References: <55DF2FAE-EDA4-4A83-BD1B-6187B211E01E@apple.com> Message-ID: <4F610EB9.5000208@talios.com> On my work iMac (Lion) whenever I update the official JDK7 Preview I have to drop to a shell and rm the old version due to some weird permissions issue that keeps returning, Finder tells me the directory is locked or something from memory. Does this sound like the same thing you're seeing Henri? Strangely, this _doesn't_ happen on my Macbook Pro's Lion install at home.. On Thu Mar 15 09:53:49 2012, Henri Gomez wrote: >> I don't code-signing has anything to do with this?do you mean that the user has to authenticate? > > Yes on Lion. > > Here is /Library/Java/JavaVirtualMachines/ : > > total 0 > 0 drwxr-xr-x 3 root wheel 102 29 jui 2011 1.6.0_26-b03-383.jdk > 0 drwxr-xr-x 3 root wheel 102 22 sep 23:09 1.6.0_27-b07-395.jdk > 0 drwxr-xr-x 3 root wheel 102 15 oct 00:55 1.6.0_29-b11-397.jdk > 0 drwxr-xr-x 3 henri staff 102 8 nov 22:11 openjdk-1.8-x86_64 > 0 drwxr-xr-x 3 root wheel 102 15 d?c 23:45 1.6.0_30-b12-404.jdk > 0 drwxr-xr-x@ 4 henri wheel 136 12 jan 23:44 JDK 1.7.0 Developer Preview.jdk > 0 drwxr-xr-x 3 root wheel 102 30 jan 20:50 1.6.0_30-b12-409.jdk > 0 drwxr-xr-x 3 root wheel 102 14 f?v 22:31 1.6.0_31-b04-411.jdk > 0 drwxr-xr-x@ 4 henri wheel 136 13 mar 10:11 1.7.0u4.jdk > 0 drwxr-xr-x@ 4 henri wheel 136 14 mar 10:35 1.7.0u.jdk > 0 drwxr-xr-x@ 4 henri wheel 136 14 mar 17:13 1.8.0.jdk > >> If drag-and-drop replacement doesn't work (with authentication), then that's a bug that needs to be filed against the Finder at. > > Well, if someone else report the problem, I'll open a bug, may be it's > only on my machine. From Alan.Bateman at oracle.com Wed Mar 14 14:54:42 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Mar 2012 21:54:42 +0000 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> <4F6064EA.9060600@oracle.com> <6827EFB6-FD55-4851-98B1-68617D8205DA@oracle.com> Message-ID: <4F6113A2.9050001@oracle.com> On 14/03/2012 19:56, Henri Gomez wrote: > : > > But it fail to build ;( > > Sample4.java:24: error: lambda expressions are not supported in -source 1.8 > DecisionService cs = (a) -> { > ^ > (use -source 8 or higher to enable lambda expressions) > > Tried to force -source 8, no more luck. > > Any Lamba guru around ? :) > So is it true that you plan to release GA builds next week :-) Lambda isn't in JDK8 yet. One the Mac port gets to lambda/lambda then you should be able make more people happy. -Alan From henri.gomez at gmail.com Wed Mar 14 14:58:41 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 14 Mar 2012 23:58:41 +0200 Subject: OpenJDK prerequisites In-Reply-To: <4F610EB9.5000208@talios.com> References: <55DF2FAE-EDA4-4A83-BD1B-6187B211E01E@apple.com> <4F610EB9.5000208@talios.com> Message-ID: same problem yes ;( 2012/3/14 Mark Derricutt : > On my work iMac (Lion) whenever I update the official JDK7 Preview I have to > drop to a shell and rm the old version due to some weird permissions issue > that keeps returning, Finder tells me the directory is locked or something > from memory. > > Does this sound like the same thing you're seeing Henri? > > Strangely, this _doesn't_ happen on my Macbook Pro's Lion install at home.. > > > On Thu Mar 15 09:53:49 2012, Henri Gomez wrote: >>> >>> I don't code-signing has anything to do with this?do you mean that the >>> user has to authenticate? >> >> >> Yes on Lion. >> >> Here is /Library/Java/JavaVirtualMachines/ : >> >> total 0 >> 0 drwxr-xr-x ?3 root ? wheel ?102 29 jui ?2011 1.6.0_26-b03-383.jdk >> 0 drwxr-xr-x ?3 root ? wheel ?102 22 sep 23:09 1.6.0_27-b07-395.jdk >> 0 drwxr-xr-x ?3 root ? wheel ?102 15 oct 00:55 1.6.0_29-b11-397.jdk >> 0 drwxr-xr-x ?3 henri ?staff ?102 ?8 nov 22:11 openjdk-1.8-x86_64 >> 0 drwxr-xr-x ?3 root ? wheel ?102 15 d?c 23:45 1.6.0_30-b12-404.jdk >> 0 drwxr-xr-x@ 4 henri ?wheel ?136 12 jan 23:44 JDK 1.7.0 Developer >> Preview.jdk >> 0 drwxr-xr-x ?3 root ? wheel ?102 30 jan 20:50 1.6.0_30-b12-409.jdk >> 0 drwxr-xr-x ?3 root ? wheel ?102 14 f?v 22:31 1.6.0_31-b04-411.jdk >> 0 drwxr-xr-x@ 4 henri ?wheel ?136 13 mar 10:11 1.7.0u4.jdk >> 0 drwxr-xr-x@ 4 henri ?wheel ?136 14 mar 10:35 1.7.0u.jdk >> 0 drwxr-xr-x@ 4 henri ?wheel ?136 14 mar 17:13 1.8.0.jdk >> >>> If drag-and-drop replacement doesn't work (with authentication), then >>> that's a bug that needs to be filed against the Finder >>> at. >> >> >> Well, if someone else report the problem, I'll open a bug, may be it's >> only on my machine. > > > From henri.gomez at gmail.com Wed Mar 14 14:59:54 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 14 Mar 2012 23:59:54 +0200 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F6113A2.9050001@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> <4F6064EA.9060600@oracle.com> <6827EFB6-FD55-4851-98B1-68617D8205DA@oracle.com> <4F6113A2.9050001@oracle.com> Message-ID: >> Any Lamba guru around ? :) >> > So is it true that you plan to release GA builds next week :-) Nope, just packaging existing stuff > Lambda isn't in JDK8 yet. One the Mac port gets to lambda/lambda then you > should be able make more people happy. I get many mails from JDK8 enthusiasts. And they all asked ... Lambdas ! From mark at talios.com Wed Mar 14 15:12:40 2012 From: mark at talios.com (Mark Derricutt) Date: Thu, 15 Mar 2012 11:12:40 +1300 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F6113A2.9050001@oracle.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> <4F6064EA.9060600@oracle.com> <6827EFB6-FD55-4851-98B1-68617D8205DA@oracle.com> <4F6113A2.9050001@oracle.com> Message-ID: <4F6117D8.4080605@talios.com> Henri - I see the "official" preview release has a special "with lamda" build: http://jdk8.java.net/lambda/ over the normal preview build.... On Thu Mar 15 10:54:42 2012, Alan Bateman wrote: > On 14/03/2012 19:56, Henri Gomez wrote: >> : >> >> But it fail to build ;( >> >> Sample4.java:24: error: lambda expressions are not supported in >> -source 1.8 >> DecisionService cs = (a) -> { >> ^ >> (use -source 8 or higher to enable lambda expressions) >> >> Tried to force -source 8, no more luck. >> >> Any Lamba guru around ? :) >> > So is it true that you plan to release GA builds next week :-) > > Lambda isn't in JDK8 yet. One the Mac port gets to lambda/lambda then > you should be able make more people happy. > > -Alan From henri.gomez at gmail.com Wed Mar 14 22:48:11 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 15 Mar 2012 07:48:11 +0200 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: <4F6117D8.4080605@talios.com> References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> <4F6064EA.9060600@oracle.com> <6827EFB6-FD55-4851-98B1-68617D8205DA@oracle.com> <4F6113A2.9050001@oracle.com> <4F6117D8.4080605@talios.com> Message-ID: <5AF2DCC9-004D-4395-A951-8F7F49866F42@gmail.com> Mlvm powered ? Le 15 mars 2012 ? 00:12, Mark Derricutt a ?crit : > Henri - I see the "official" preview release has a special "with lamda" build: > > http://jdk8.java.net/lambda/ > > over the normal preview build.... > > On Thu Mar 15 10:54:42 2012, Alan Bateman wrote: >> On 14/03/2012 19:56, Henri Gomez wrote: >>> : >>> >>> But it fail to build ;( >>> >>> Sample4.java:24: error: lambda expressions are not supported in -source 1.8 >>> DecisionService cs = (a) -> { >>> ^ >>> (use -source 8 or higher to enable lambda expressions) >>> >>> Tried to force -source 8, no more luck. >>> >>> Any Lamba guru around ? :) >>> >> So is it true that you plan to release GA builds next week :-) >> >> Lambda isn't in JDK8 yet. One the Mac port gets to lambda/lambda then you should be able make more people happy. >> >> -Alan > > From alexander.zuev at oracle.com Thu Mar 15 07:27:17 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 15 Mar 2012 18:27:17 +0400 Subject: [7u4] request for review: 7152608: [macosx] Crash in liblwawt.dylib in AccelGlyphCache_RemoveCellInfo In-Reply-To: <4F6087ED.2080709@oracle.com> References: <4F6087ED.2080709@oracle.com> Message-ID: <4F61FC45.7070401@oracle.com> Andrew, Fix looks fine to me. WBR, Alex. On 3/14/12 15:58, Andrew Brygin wrote: > Hello, > > this problem is an example of 'use-after-free' crash: the crash itself > happens when AccelGlyphCache meets invalid pointer to a cache cell info > in cached glyph info structure. This pointer can have arbitrary value, > because corresponding glyph info structure is already destroyed by > CStrike cache machinery. > The root of the problem is that this destruction is made without any > notification to AccelGlyphCache, which keeps and uses invalid pointer > to glyph info object. > Suggested solution is to remove a glyph info instance from the > accelerated cache before destruction. Please take a look to suggested > fix. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152608 > Webrev: http://cr.openjdk.java.net/~bae/7152608/webrev/ > > Thanks, > Andrew From alexander.zuev at oracle.com Thu Mar 15 09:02:53 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 15 Mar 2012 20:02:53 +0400 Subject: [7u4] Request for review: 7145406: [macosx] Migrate Apple tests from macosx-port to 7u Message-ID: <4F6212AD.5020705@oracle.com> Hello, please look at the proposed fix for bug 7145406: [macosx] Migrate Apple tests from macosx-port to 7u As a fix i've collected all the missing tests and slightly updated their copyright notices fixing year to 2012 Bug description: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145406 Webrev: http://cr.openjdk.java.net/~kizune/7145406/ With best regards, Alexander Zuev From michael.x.mcmahon at oracle.com Thu Mar 15 09:18:26 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 15 Mar 2012 16:18:26 +0000 Subject: RFR: 7151898: Check for LANG in Mac OS X jdk build sanity check [macosx] Message-ID: <4F621652.6010608@oracle.com> Can I get the following jdk8 change reviewed please? It is a simple sanity check on Mac OS X to ensure that LANG is set in the environment. Currently, the build fails if it's not set, but the failure is quite obscure. http://cr.openjdk.java.net/~michaelm/7151898/webrev.1/ Thanks Michael. From edvard.wendelin at oracle.com Thu Mar 15 09:23:08 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 15 Mar 2012 17:23:08 +0100 Subject: [7u4] Request for phase 2 approval for CR 7145827: [macosx] JCK failure in b11: FocusableWindow3 In-Reply-To: <4F60AA5C.70904@oracle.com> References: <4F60AA5C.70904@oracle.com> Message-ID: <4F62176C.5070501@oracle.com> Approved. On 03/14/2012 03:25 PM, Anton V. Tarasov wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7145827 > Webrev: http://cr.openjdk.java.net/~ant/7145827/webrev.0/ > Review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003555.html > Reviewer: Artem Ananiev (art) > > Rationale for inclusion in 7u4: JCK failure. > > Thanks, > Anton. From kelly.ohair at oracle.com Thu Mar 15 09:30:05 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 15 Mar 2012 09:30:05 -0700 Subject: RFR: 7151898: Check for LANG in Mac OS X jdk build sanity check [macosx] In-Reply-To: <4F621652.6010608@oracle.com> References: <4F621652.6010608@oracle.com> Message-ID: <27FF6016-14B1-42F3-B9D6-002CBC76D4B8@oracle.com> Looks fine to me. -kto On Mar 15, 2012, at 9:18 AM, Michael McMahon wrote: > Can I get the following jdk8 change reviewed please? > > It is a simple sanity check on Mac OS X to ensure that > LANG is set in the environment. Currently, the build fails > if it's not set, but the failure is quite obscure. > > http://cr.openjdk.java.net/~michaelm/7151898/webrev.1/ > > Thanks > Michael. From stuart.marks at oracle.com Thu Mar 15 09:43:59 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 15 Mar 2012 09:43:59 -0700 Subject: RFR: 7151898: Check for LANG in Mac OS X jdk build sanity check [macosx] In-Reply-To: <27FF6016-14B1-42F3-B9D6-002CBC76D4B8@oracle.com> References: <4F621652.6010608@oracle.com> <27FF6016-14B1-42F3-B9D6-002CBC76D4B8@oracle.com> Message-ID: <4F621C4F.9000306@oracle.com> Looks good to me too. I've updated the Mac build instructions on the wiki to state that LANG should be set. s'marks On 3/15/12 9:30 AM, Kelly O'Hair wrote: > Looks fine to me. > > -kto > > On Mar 15, 2012, at 9:18 AM, Michael McMahon wrote: > >> Can I get the following jdk8 change reviewed please? >> >> It is a simple sanity check on Mac OS X to ensure that >> LANG is set in the environment. Currently, the build fails >> if it's not set, but the failure is quite obscure. >> >> http://cr.openjdk.java.net/~michaelm/7151898/webrev.1/ >> >> Thanks >> Michael. > From andrew.brygin at oracle.com Thu Mar 15 09:46:51 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Thu, 15 Mar 2012 20:46:51 +0400 Subject: [7u4] Request for phase 2 approval for CR 7152608 - [macosx] Crash in liblwawt.dylib in AccelGlyphCache_RemoveCellInfo Message-ID: <4F621CFB.4070805@oracle.com> CR: http://bugs.sun.com/view_bug.do?bug_id=7152608 Webrev: http://cr.openjdk.java.net/~bae/7152608/webrev Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003580.html Reviewers: Alexader Zuev Rationale for inclusion in 7u4: this crash may affects any application which renders text intensively. Thanks, Andrew From edvard.wendelin at oracle.com Thu Mar 15 09:51:08 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 15 Mar 2012 17:51:08 +0100 Subject: [7u4] Request for phase 2 approval for CR 7152608 - [macosx] Crash in liblwawt.dylib in AccelGlyphCache_RemoveCellInfo In-Reply-To: <4F621CFB.4070805@oracle.com> References: <4F621CFB.4070805@oracle.com> Message-ID: <4F621DFC.3090203@oracle.com> Approved. On 03/15/2012 05:46 PM, Andrew Brygin wrote: > CR: http://bugs.sun.com/view_bug.do?bug_id=7152608 > Webrev: http://cr.openjdk.java.net/~bae/7152608/webrev > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003580.html > > Reviewers: Alexader Zuev > Rationale for inclusion in 7u4: this crash may affects any application > which renders text intensively. > > Thanks, > Andrew From swingler at apple.com Thu Mar 15 10:59:12 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 15 Mar 2012 10:59:12 -0700 Subject: RFR: 7151898: Check for LANG in Mac OS X jdk build sanity check [macosx] In-Reply-To: <4F621C4F.9000306@oracle.com> References: <4F621652.6010608@oracle.com> <27FF6016-14B1-42F3-B9D6-002CBC76D4B8@oracle.com> <4F621C4F.9000306@oracle.com> Message-ID: <40CFF823-B36A-4B90-B890-61F414D9AF6E@apple.com> What other values are valid? UTF8? Why would a builder ever want to change the lang? I think the build script should define it and use it for it's own private purposes (allowing it to be overridden) if there is no compelling reason for an ordinary user to know/care what lang is. I'd prefer not to clutter up the build instructions unless you _really_ have to pass some value that is machine-specific (like the location of the bootstrap JDK). Even then, on the Mac, I think the build scripts should call /usr/libexec/java_home -v 1.7+ on their own, and only balk if there is not sufficient OpenJDK installed. Regards, Mike Swingler Apple Inc. On Mar 15, 2012, at 9:43 AM, Stuart Marks wrote: > Looks good to me too. I've updated the Mac build instructions on the wiki to state that LANG should be set. > > s'marks > > On 3/15/12 9:30 AM, Kelly O'Hair wrote: >> Looks fine to me. >> >> -kto >> >> On Mar 15, 2012, at 9:18 AM, Michael McMahon wrote: >> >>> Can I get the following jdk8 change reviewed please? >>> >>> It is a simple sanity check on Mac OS X to ensure that >>> LANG is set in the environment. Currently, the build fails >>> if it's not set, but the failure is quite obscure. >>> >>> http://cr.openjdk.java.net/~michaelm/7151898/webrev.1/ >>> >>> Thanks >>> Michael. >> From tobi at ultramixer.com Thu Mar 15 09:35:07 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Thu, 15 Mar 2012 17:35:07 +0100 Subject: Quality difference between Apple JDK6 and OpenJDK7 Message-ID: Hi, I noticed a big quality difference between Apples JDK6 implementation and the OpenJDK7. When I resize a window (JFrame) the content is repainted very ugly in OpenJDK7, in Apple JDK6 the background is painted very smoothly. What's the reason for and how can we change this? Best regards, Tobi From stuart.marks at oracle.com Thu Mar 15 11:57:16 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 15 Mar 2012 11:57:16 -0700 Subject: RFR: 7151898: Check for LANG in Mac OS X jdk build sanity check [macosx] In-Reply-To: <40CFF823-B36A-4B90-B890-61F414D9AF6E@apple.com> References: <4F621652.6010608@oracle.com> <27FF6016-14B1-42F3-B9D6-002CBC76D4B8@oracle.com> <4F621C4F.9000306@oracle.com> <40CFF823-B36A-4B90-B890-61F414D9AF6E@apple.com> Message-ID: <4F623B8C.8080709@oracle.com> I agree, there's a larger question about LANG that needs to be asked here. From a pragmatic point of view, I ran into a build issue that boiled down to the absence of LANG in my environment in certain cases (ssh vs VNC). README-builds.html recommends setting LANG=C for OpenSolaris and all the Linux-flavored build environments. So, it makes sense for LANG=C to go into the Mac build instructions as well. (README-builds.html should get updated too.) Unlike on Linux, the consequences of LANG being unset on Mac are that the build breaks, so Michael has added this check in the Makefile to prevent this obvious error. I believe he was also going to file a bug on the Mac build breaking when LANG is unset. Now, the larger questions are, what are the valid values of LANG, and if all the Unix-flavored build instructions recommend setting LANG=C, why not just have the makefiles or build scripts set this value and be done with it? I don't know, and I don't have the expertise in the build system to know how other LANG settings would affect the build. Perhaps somebody else on build-dev knows. Meanwhile, we're patching things up this way, even though it makes things a bit messier. s'marks On 3/15/12 10:59 AM, Mike Swingler wrote: > What other values are valid? UTF8? Why would a builder ever want to change the lang? > > I think the build script should define it and use it for it's own private purposes (allowing it to be overridden) if there is no compelling reason for an ordinary user to know/care what lang is. I'd prefer not to clutter up the build instructions unless you _really_ have to pass some value that is machine-specific (like the location of the bootstrap JDK). Even then, on the Mac, I think the build scripts should call /usr/libexec/java_home -v 1.7+ on their own, and only balk if there is not sufficient OpenJDK installed. > > Regards, > Mike Swingler > Apple Inc. > > On Mar 15, 2012, at 9:43 AM, Stuart Marks wrote: > >> Looks good to me too. I've updated the Mac build instructions on the wiki to state that LANG should be set. >> >> s'marks >> >> On 3/15/12 9:30 AM, Kelly O'Hair wrote: >>> Looks fine to me. >>> >>> -kto >>> >>> On Mar 15, 2012, at 9:18 AM, Michael McMahon wrote: >>> >>>> Can I get the following jdk8 change reviewed please? >>>> >>>> It is a simple sanity check on Mac OS X to ensure that >>>> LANG is set in the environment. Currently, the build fails >>>> if it's not set, but the failure is quite obscure. >>>> >>>> http://cr.openjdk.java.net/~michaelm/7151898/webrev.1/ >>>> >>>> Thanks >>>> Michael. >>> > From kelly.ohair at oracle.com Thu Mar 15 12:22:59 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 15 Mar 2012 12:22:59 -0700 Subject: RFR: 7151898: Check for LANG in Mac OS X jdk build sanity check [macosx] In-Reply-To: <4F623B8C.8080709@oracle.com> References: <4F621652.6010608@oracle.com> <27FF6016-14B1-42F3-B9D6-002CBC76D4B8@oracle.com> <4F621C4F.9000306@oracle.com> <40CFF823-B36A-4B90-B890-61F414D9AF6E@apple.com> <4F623B8C.8080709@oracle.com> Message-ID: <973968CA-C9C4-4961-9631-266636B39923@oracle.com> On Mar 15, 2012, at 11:57 AM, Stuart Marks wrote: > I agree, there's a larger question about LANG that needs to be asked here. > > From a pragmatic point of view, I ran into a build issue that boiled down to the absence of LANG in my environment in certain cases (ssh vs VNC). README-builds.html recommends setting LANG=C for OpenSolaris and all the Linux-flavored build environments. So, it makes sense for LANG=C to go into the Mac build instructions as well. (README-builds.html should get updated too.) Unlike on Linux, the consequences of LANG being unset on Mac are that the build breaks, so Michael has added this check in the Makefile to prevent this obvious error. I believe he was also going to file a bug on the Mac build breaking when LANG is unset. > > Now, the larger questions are, what are the valid values of LANG, and if all the Unix-flavored build instructions recommend setting LANG=C, why not just have the makefiles or build scripts set this value and be done with it? Not sure why this was ever done, seems ok with me. Granted, LANG isn't the only variable that might cause locale issues, the other LC_* variables could create issues. My I18n/L10n knowledge is quite rusty. :^( But in general, I agree that it must be set, we should just "export LANG=C" in the Makefiles, if that works. -kto > > I don't know, and I don't have the expertise in the build system to know how other LANG settings would affect the build. Perhaps somebody else on build-dev knows. Meanwhile, we're patching things up this way, even though it makes things a bit messier. > > s'marks > > > On 3/15/12 10:59 AM, Mike Swingler wrote: >> What other values are valid? UTF8? Why would a builder ever want to change the lang? >> >> I think the build script should define it and use it for it's own private purposes (allowing it to be overridden) if there is no compelling reason for an ordinary user to know/care what lang is. I'd prefer not to clutter up the build instructions unless you _really_ have to pass some value that is machine-specific (like the location of the bootstrap JDK). Even then, on the Mac, I think the build scripts should call /usr/libexec/java_home -v 1.7+ on their own, and only balk if there is not sufficient OpenJDK installed. >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Mar 15, 2012, at 9:43 AM, Stuart Marks wrote: >> >>> Looks good to me too. I've updated the Mac build instructions on the wiki to state that LANG should be set. >>> >>> s'marks >>> >>> On 3/15/12 9:30 AM, Kelly O'Hair wrote: >>>> Looks fine to me. >>>> >>>> -kto >>>> >>>> On Mar 15, 2012, at 9:18 AM, Michael McMahon wrote: >>>> >>>>> Can I get the following jdk8 change reviewed please? >>>>> >>>>> It is a simple sanity check on Mac OS X to ensure that >>>>> LANG is set in the environment. Currently, the build fails >>>>> if it's not set, but the failure is quite obscure. >>>>> >>>>> http://cr.openjdk.java.net/~michaelm/7151898/webrev.1/ >>>>> >>>>> Thanks >>>>> Michael. >>>> >> From michael.x.mcmahon at oracle.com Thu Mar 15 12:43:32 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 15 Mar 2012 19:43:32 +0000 Subject: RFR: 7151898: Check for LANG in Mac OS X jdk build sanity check [macosx] In-Reply-To: <4F623B8C.8080709@oracle.com> References: <4F621652.6010608@oracle.com> <27FF6016-14B1-42F3-B9D6-002CBC76D4B8@oracle.com> <4F621C4F.9000306@oracle.com> <40CFF823-B36A-4B90-B890-61F414D9AF6E@apple.com> <4F623B8C.8080709@oracle.com> Message-ID: <4F624664.9000304@oracle.com> It definitely works with LANG=en_US.UTF-8 (and other en country variants). It definitely doesn't**work in the zh_CN locale, as was reported recently. The reason evidently is a dependency in the build on the output format of the date command. Which other locales it works in, I don't know. So, I guess it makes sense to standardize on a particular setting. The idea of setting it internally within the build to "C" sounds attractive because forcing people to use such an outdated compatibility mode locale seems wrong. I'm not sure how easy it is to set environment variables in make is (as opposed to reading/using them ). I wonder why this wasn't done before... In any case, this is a general build issue rather than being Mac specific. By the way, I did file a bug on the LANG breakage (7151897) Thanks Michael. On 15/03/12 18:57, Stuart Marks wrote: > I agree, there's a larger question about LANG that needs to be asked > here. > > From a pragmatic point of view, I ran into a build issue that boiled > down to the absence of LANG in my environment in certain cases (ssh vs > VNC). README-builds.html recommends setting LANG=C for OpenSolaris and > all the Linux-flavored build environments. So, it makes sense for > LANG=C to go into the Mac build instructions as well. > (README-builds.html should get updated too.) Unlike on Linux, the > consequences of LANG being unset on Mac are that the build breaks, so > Michael has added this check in the Makefile to prevent this obvious > error. I believe he was also going to file a bug on the Mac build > breaking when LANG is unset. > > Now, the larger questions are, what are the valid values of LANG, and > if all the Unix-flavored build instructions recommend setting LANG=C, > why not just have the makefiles or build scripts set this value and be > done with it? > > I don't know, and I don't have the expertise in the build system to > know how other LANG settings would affect the build. Perhaps somebody > else on build-dev knows. Meanwhile, we're patching things up this way, > even though it makes things a bit messier. > > s'marks > > > On 3/15/12 10:59 AM, Mike Swingler wrote: >> What other values are valid? UTF8? Why would a builder ever want to >> change the lang? >> >> I think the build script should define it and use it for it's own >> private purposes (allowing it to be overridden) if there is no >> compelling reason for an ordinary user to know/care what lang is. I'd >> prefer not to clutter up the build instructions unless you _really_ >> have to pass some value that is machine-specific (like the location >> of the bootstrap JDK). Even then, on the Mac, I think the build >> scripts should call /usr/libexec/java_home -v 1.7+ on their own, and >> only balk if there is not sufficient OpenJDK installed. >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Mar 15, 2012, at 9:43 AM, Stuart Marks wrote: >> >>> Looks good to me too. I've updated the Mac build instructions on the >>> wiki to state that LANG should be set. >>> >>> s'marks >>> >>> On 3/15/12 9:30 AM, Kelly O'Hair wrote: >>>> Looks fine to me. >>>> >>>> -kto >>>> >>>> On Mar 15, 2012, at 9:18 AM, Michael McMahon wrote: >>>> >>>>> Can I get the following jdk8 change reviewed please? >>>>> >>>>> It is a simple sanity check on Mac OS X to ensure that >>>>> LANG is set in the environment. Currently, the build fails >>>>> if it's not set, but the failure is quite obscure. >>>>> >>>>> http://cr.openjdk.java.net/~michaelm/7151898/webrev.1/ >>>>> >>>>> Thanks >>>>> Michael. >>>> >> From jonathan.gibbons at oracle.com Mon Mar 12 19:31:13 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 12 Mar 2012 19:31:13 -0700 Subject: javah In-Reply-To: <550E9AB3-7AF1-4431-95DA-E3DA1F211518@oracle.com> References: <4F5E4503.10508@oracle.com> <4F5E8728.3090905@oracle.com> <4F5EA011.1090501@oracle.com> <550E9AB3-7AF1-4431-95DA-E3DA1F211518@oracle.com> Message-ID: <4F5EB171.8030001@oracle.com> On 03/12/2012 06:27 PM, Greg Brown wrote: >> Same results. > That's weird. I'll try to run your tests on my machine with Java 6 and 7 and see what happens. > > Thanks! > G > Greg, The behavior *does* appear to change with Ant's task. The Ant task does not support the fork attribute, so I had to write the Ant script such that it could be invoked multiple times, with different values for JAVA_HOME. And yes, when running Ant on JDK 5 or JDK 6, you just get the headers for the classes you specify; in JDK 7 or 8 you get the additional headers for the nested classes as well. We are getting off-topic for macosx-port; I suggest you follow up directly to me or compiler-dev. Issues with should be filed against Ant. -- Jon > > > > > > > > srcdir="src" destdir="classes"> > > > > > > > > > > > > > > > $ for i in 5 6 7 8 ; do JAVA_HOME=/opt/jdk/1.$i.0 ant -f > play/build.xml -Djdk=$i default ; done > Buildfile: play/build.xml > > default: > [delete] Deleting directory /w/jjg/work/javah/play/classes > [delete] Deleting directory /w/jjg/work/javah/play/jdk5 > [mkdir] Created dir: /w/jjg/work/javah/play/classes > [javac] Compiling 1 source file to /w/jjg/work/javah/play/classes > [mkdir] Created dir: /w/jjg/work/javah/play/jdk5 > [exec] jdk5 > [exec] jdk5/p_C.h > > BUILD SUCCESSFUL > Total time: 0 seconds > Buildfile: play/build.xml > > default: > [delete] Deleting directory /w/jjg/work/javah/play/classes > [delete] Deleting directory /w/jjg/work/javah/play/jdk6 > [mkdir] Created dir: /w/jjg/work/javah/play/classes > [javac] Compiling 1 source file to /w/jjg/work/javah/play/classes > [mkdir] Created dir: /w/jjg/work/javah/play/jdk6 > [exec] jdk6 > [exec] jdk6/p_C.h > > BUILD SUCCESSFUL > Total time: 0 seconds > Buildfile: play/build.xml > > default: > [delete] Deleting directory /w/jjg/work/javah/play/classes > [delete] Deleting directory /w/jjg/work/javah/play/jdk7 > [mkdir] Created dir: /w/jjg/work/javah/play/classes > [javac] Compiling 1 source file to /w/jjg/work/javah/play/classes > [mkdir] Created dir: /w/jjg/work/javah/play/jdk7 > [exec] jdk7 > [exec] jdk7/p_C_Inner.h > [exec] jdk7/p_C.h > > BUILD SUCCESSFUL > Total time: 1 second > Buildfile: play/build.xml > > default: > [delete] Deleting directory /w/jjg/work/javah/play/classes > [delete] Deleting directory /w/jjg/work/javah/play/jdk8 > [mkdir] Created dir: /w/jjg/work/javah/play/classes > [javac] Compiling 1 source file to /w/jjg/work/javah/play/classes > [mkdir] Created dir: /w/jjg/work/javah/play/jdk8 > [exec] jdk8 > [exec] jdk8/p_C_Inner.h > [exec] jdk8/p_C.h > > BUILD SUCCESSFUL > Total time: 1 second From fredrik.ohrstrom at oracle.com Thu Mar 15 12:57:12 2012 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Thu, 15 Mar 2012 12:57:12 -0700 (PDT) Subject: RFR: 7151898: Check for LANG in Mac OS X jdk build sanity check [macosx] Message-ID: ----- stuart.marks at oracle.com skrev: > I don't know, and I don't have the expertise in the build system to > know how other LANG settings would affect the build. Perhaps somebody else on > build-dev knows. Meanwhile, we're patching things up this way, even though it > makes things a bit messier. If you had built the new build-infra/jdk8 tree, you would have noticed that it does not require you to set LANG=C It should work with any locale, I use my default setting LANG=sv_SE.UTF-8 The reason LANG=C is necessary for the old makefiles is because in very few places in the makefiles, tr,date,sort and some other cli tools, are used in such a way that is dependent on the locale. Also these commands generate Java source or other settings which cause the actual error message to appear much later, and it takes a bit of time to track it back to the original cause, which is in fact trivial to fix. //Fredrik From kelly.ohair at oracle.com Thu Mar 15 13:56:10 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 15 Mar 2012 13:56:10 -0700 Subject: RFR: 7151898: Check for LANG in Mac OS X jdk build sanity check [macosx] In-Reply-To: References: Message-ID: On Mar 15, 2012, at 12:57 PM, Fredrik ?hrstr?m wrote: > > ----- stuart.marks at oracle.com skrev: > >> I don't know, and I don't have the expertise in the build system to >> know how other LANG settings would affect the build. Perhaps somebody else on >> build-dev knows. Meanwhile, we're patching things up this way, even though it >> makes things a bit messier. > > If you had built the new build-infra/jdk8 tree, you would have noticed > that it does not require you to set LANG=C > It should work with any locale, I use my default setting LANG=sv_SE.UTF-8 > > The reason LANG=C is necessary for the old makefiles is because > in very few places in the makefiles, tr,date,sort and some other cli tools, > are used in such a way that is dependent on the locale. Also > these commands generate Java source or other settings which cause the > actual error message to appear much later, and it takes a bit of time > to track it back to the original cause, which is in fact trivial to fix. > With Windows, it's not quite the same as Linux and Solaris. Using LANG=C was originally just a suggestion, mainly because that was the only setting we guaranteed would work. A long time ago, the javac compilations were not supplied the -encoding option, and the default was to assume the current locale defined the source file character encoding. I'm pretty sure we always supply the -encoding option now, or should. I was trying to be lang neutral, and at the time UTF8 was not an option, it was just that encoding the crazy Java guys used. ;^) It is very hard to know the complete impact of building the product in different locales when native code is involved. So as much as I would like to guarantee all selections will work, I would rather we narrow down the options here to avoid having to deal with all the possible combinations. -kto > //Fredrik From dalibor.topic at oracle.com Thu Mar 15 14:18:27 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 15 Mar 2012 14:18:27 -0700 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <532A2A85-2AF6-4218-B72A-1489B5C793E6@gmail.com> <4F522B54.3010800@oracle.com> <4F6064EA.9060600@oracle.com> <6827EFB6-FD55-4851-98B1-68617D8205DA@oracle.com> <4F6113A2.9050001@oracle.com> Message-ID: <4F625CA3.8060001@oracle.com> On 3/14/12 2:59 PM, Henri Gomez wrote: > I get many mails from JDK8 enthusiasts. And they all asked ... Lambdas ! Lamdba support hasn't been integrated into JDK 8 yet. See https://blogs.oracle.com/mcimadamore/entry/lambda_integration_plan for details. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 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 dmitry.cherepanov at oracle.com Thu Mar 15 23:37:26 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 16 Mar 2012 10:37:26 +0400 Subject: [7u6] Request for approval for 7150345: [macosx] Can't type into applets Message-ID: <4F62DFA6.5010907@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=7150345 Webrev: http://cr.openjdk.java.net/~dcherepanov/7150345/webrev.1/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003487.html Thanks, Dmitry From fredrik.ohrstrom at oracle.com Fri Mar 16 00:55:41 2012 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 16 Mar 2012 08:55:41 +0100 Subject: RFR: 7151898: Check for LANG in Mac OS X jdk build sanity check [macosx] In-Reply-To: References: Message-ID: <4F62F1FD.5080209@oracle.com> 2012-03-15 21:56, Kelly O'Hair skrev: > It is very hard to know the complete impact of building the product in different locales when > native code is involved. So as much as I would like to guarantee all selections will work, I would > rather we narrow down the options here to avoid having to deal with all the possible combinations. Which tools did you have in mind that generate native code and are affected by LANG!=C ? One of the simplest ways to fix the problem is to replace for example `date` with `LANG=C date` It should be rather simple to prefix those tools that you are thinking of with a LANG=C prefix. Exporting LANG=C to the shell is very inconvenient because it breaks a lot of shell usability for me. Just globally setting LANG=C inside the makefiles, would also work, but it is much nicer if we know what we are doing and just target those commands who actually matter. //Fredrik From Alexander.Potochkin at oracle.com Fri Mar 16 06:00:00 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Fri, 16 Mar 2012 17:00:00 +0400 Subject: [7u4] Request for phase 2 approval for 7144065: [macosx] Orphaned Choice popup window Message-ID: <4F633950.8090008@oracle.com> CR: http://bugs.sun.com/view_bug.do?bug_id=7144065 Webrev: http://cr.openjdk.java.net/~alexp/7144065/webrev.00/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003540.html Reviewers: Anton Tarasov 7u4-critical-watch: Release Team decided to force the fix in 7u4 Thanks, Andrew From anthony.petrov at oracle.com Fri Mar 16 06:00:34 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 16 Mar 2012 17:00:34 +0400 Subject: [7u4] Request for review: 7145406: [macosx] Migrate Apple tests from macosx-port to 7u In-Reply-To: <4F6212AD.5020705@oracle.com> References: <4F6212AD.5020705@oracle.com> Message-ID: <4F633972.1090202@oracle.com> Looks fine to me. -- best regards, Anthony On 3/15/2012 8:02 PM, Alexander Zuev wrote: > Hello, > > please look at the proposed fix for bug 7145406: [macosx] Migrate > Apple tests from macosx-port to 7u > > As a fix i've collected all the missing tests and slightly updated > their copyright notices fixing year to 2012 > > Bug description: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145406 > Webrev: http://cr.openjdk.java.net/~kizune/7145406/ > > With best regards, > Alexander Zuev From anthony.petrov at oracle.com Fri Mar 16 06:03:06 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 16 Mar 2012 17:03:06 +0400 Subject: [7u4] Request for review: 7145406: [macosx] Migrate Apple tests from macosx-port to 7u In-Reply-To: <4F633972.1090202@oracle.com> References: <4F6212AD.5020705@oracle.com> <4F633972.1090202@oracle.com> Message-ID: <4F633A0A.4040205@oracle.com> Um, I guess I typed too fast. Should some of the tests be excluded on other platforms? E.g. the test/com/apple/eawt/DockIconTest.java imports and uses the eawt package which isn't available on platforms other than the Mac. This test won't even compile on other platforms. -- best regards, Anthony On 3/16/2012 5:00 PM, Anthony Petrov wrote: > Looks fine to me. > > -- > best regards, > Anthony > > On 3/15/2012 8:02 PM, Alexander Zuev wrote: >> Hello, >> >> please look at the proposed fix for bug 7145406: [macosx] Migrate >> Apple tests from macosx-port to 7u >> >> As a fix i've collected all the missing tests and slightly updated >> their copyright notices fixing year to 2012 >> >> Bug description: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145406 >> Webrev: http://cr.openjdk.java.net/~kizune/7145406/ >> >> With best regards, >> Alexander Zuev > From edvard.wendelin at oracle.com Fri Mar 16 06:16:18 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 16 Mar 2012 14:16:18 +0100 Subject: [7u4] Request for phase 2 approval for 7144065: [macosx] Orphaned Choice popup window In-Reply-To: <4F633950.8090008@oracle.com> References: <4F633950.8090008@oracle.com> Message-ID: <1CC34FAD-0A61-451D-946F-5B4E86F6E753@oracle.com> Pre-approved pending Release team approval. Once you see OK in bug, please feel free to push the fix. Cheers, Edvard On Mar 16, 2012, at 2:00 PM, Alexander Potochkin wrote: > CR: http://bugs.sun.com/view_bug.do?bug_id=7144065 > Webrev: http://cr.openjdk.java.net/~alexp/7144065/webrev.00/ > Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003540.html > > Reviewers: Anton Tarasov > 7u4-critical-watch: Release Team decided to force the fix in 7u4 > > Thanks, > Andrew From edvard.wendelin at oracle.com Fri Mar 16 06:17:55 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 16 Mar 2012 14:17:55 +0100 Subject: [7u6] Request for approval for 7150345: [macosx] Can't type into applets In-Reply-To: <4F62DFA6.5010907@oracle.com> References: <4F62DFA6.5010907@oracle.com> Message-ID: <559F4A9F-6DFB-4E5A-9E41-A125B7383D81@oracle.com> Approved. On Mar 16, 2012, at 7:37 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=7150345 > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7150345/webrev.1/ > > Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003487.html > > Thanks, > Dmitry > From anthony.petrov at oracle.com Fri Mar 16 06:24:07 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 16 Mar 2012 17:24:07 +0400 Subject: [7u4] Review request for 7145818: [macosx] dialogs not showing when JFrame is in full screen mode In-Reply-To: References: <4F4E3D18.3010109@oracle.com> <2AD6CB77-6932-4715-A21A-E7B786C5D6C6@apple.com> <4F4FE5D0.8010700@oracle.com> <69A334C5-89AB-49F4-A2BC-1C2E1C318EEE@apple.com> <4F50D737.40405@oracle.com> <4F50DC3C.7050803@oracle.com> <4F54E3DA.6070908@oracle.com> <4F578BDA.6000001@oracle.com> Message-ID: <4F633EF7.4010708@oracle.com> Hi Mike, Thanks for your comments. Actually, given the very tight time period for the 7u4 release, and the risk of the fix (since it changes the machinery for entering the full screen mode), we have decided to postpone this fix till 7u6. By this time we'll be able to resolve all EAWT-related issues as well as test the fix thoroughly. -- best regards, Anthony On 3/13/2012 1:00 AM, Mike Swingler wrote: > I don't see where you are getting the notifications from native when the user enters full screen by pressing the window widget. This change looks fine to address the immediate problem, but testing it's interaction with the eAWT full screen experience needs a followup bug. > > Regards, > Mike Swingler > Apple Inc. > > On Mar 7, 2012, at 8:24 AM, Anthony Petrov wrote: > >> Could I get a review for the latest version of the fix please? Here's the link for your convenience: >> >> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.3/ >> >> -- >> best regards, >> Anthony >> >> On 3/5/2012 8:03 PM, Anthony Petrov wrote: >>> Hi Mike, >>> A few points: >>> * When a user enters the full screen using the OS widget, the full screen state isn't sync'd with Java's GraphicsDevice.getFullScreenWindow(). >>> * Rather than calling native, I'd actually update the flag upon receiving native notifications about entering/leaving the FS mode. >>> * If you call -toggleFullScreen: for a window w/o the NSWindowCollectionBehaviorFullScreenPrimary collection behavior, then the menus and the dock stay visible. Apart from that, there's no the default 10.7-specific animation for such windows when entering the FS mode. >>> * If I mark an undecorated window as fullscreenable, its original size won't be restored when exiting the FS mode. So we can't simply enable the behavior automatically for all windows. An app must opt in. >>> * Apple JDK 1.6 won't let a user exit a FS Java application, too. So at least we don't introduce a regression here. Also, the full screen is a restricted functionality that's unavailable to unsigned code by default. Thus we generally trust code that's able to enter the mode (in that it should let user out when needed). >>> * The fix we're currently reviewing is supposed to fix a bug with popup windows not showing up for a Java app that doesn't use EAWT at all. As far as I've tested it, it does resolve the issue. And the behavior seems to be quite consistent with what Apple JDK 1.6 does. >>> * The only thing the fix worsens is for EAWT-aware app: it hides the menu bar unconditionally when entering the FS mode. I've just fixed that by avoiding hiding the menu bar if a window is marked as FULLSCREENABLE. I believe that a new fix at >>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.3/ >>> is what we need in 7u4. We may file a new change request to address EAWT-specific issues in a future release. >>> Please review. >>> -- >>> best regards, >>> Anthony >>> On 03/02/12 21:13, Mike Swingler wrote: >>>> There are a few points here: >>>> * If the user marks the window as "fullscreenable" using the eAWT API, >>>> that puts a widget in the upper right corner of the window which allows >>>> the user to toggle it into full screen themselves. >>>> * When in full screen (using AWT or eAWT API), the user should be able >>>> to click the blue exit fullscreen button in the menu bar at any time (if >>>> they entered into full screen themselves) >>>> * Generally, it is undesirable for the user to be stuck in a state where >>>> they cannot return to the desktop. >>>> >>>> With the current diff, the isFullScreenMode boolean in Java will >>>> definitely be out of sync if the user initiates either of these actions. >>>> >>>> Instead of trying to keep the knowledge of the full screen state in Java >>>> behind a lock, I think you probably need query native to see if the >>>> window is in the fullscreen state. I've used the following testcase to >>>> test the existing eAWT fullscreen API, and I think you'll find it's easy >>>> to get into a state where the user is stuck in windowed mode without a >>>> menu bar, and that sometimes the user is locked out from returning to >>>> windowed mode when they clicked on the window widget. >>>> >>>> After trying out your diff, I actually found it quite frustrating that >>>> the menubar was suppressed and I *had* to use the four-finger swipe >>>> gesture to get back to my desktop. How would you feel about just >>>> dropping the whole menubar hiding stuff? Since the menu bar is >>>> auto-hidden by default, users don't get to it unless they push up to the >>>> top of the screen anyway. >>>> >>>> Try out this test case, and be sure to use the window widget, as well as >>>> the button that programmatically fires the eAWT API. >>>> >>>> import java.awt.*; >>>> import java.awt.event.ActionEvent; >>>> import javax.swing.*; >>>> >>>> import com.apple.eawt.AppEvent.FullScreenEvent; >>>> import com.apple.eawt.*; >>>> >>>> public class FullScreenTest { >>>> public static void main(String args[]) { >>>> SwingUtilities.invokeLater(new Runnable() { >>>> public void run() { createFrame(); } >>>> }); >>>> } >>>> >>>> >>>> static void createFrame() { >>>> JFrame frame = new JFrame(); >>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>> frame.setTitle(System.getProperty("java.version")); >>>> >>>> >>>> Container contentPane = frame.getContentPane(); >>>> contentPane.setLayout(new BorderLayout()); >>>> contentPane.add(createPanel(), BorderLayout.CENTER); >>>> >>>> >>>> // turns on the fullscreen window titlebar widget in the upper right corner >>>> FullScreenUtilities.setWindowCanFullScreen(frame, true); >>>> >>>> >>>> // useful for re-adjusting content or hiding/showing palette windows >>>> FullScreenUtilities.addFullScreenListenerTo(frame, new FullScreenAdapter() { >>>> public void windowExitingFullScreen(FullScreenEvent e) { >>>> System.out.println("exiting"); >>>> } >>>> public void windowExitedFullScreen(FullScreenEvent e) { >>>> System.out.println("exited"); >>>> } >>>> public void windowEnteringFullScreen(FullScreenEvent e) { >>>> System.out.println("entering"); >>>> } >>>> public void windowEnteredFullScreen(FullScreenEvent e) { >>>> System.out.println("entered"); >>>> } >>>> }); >>>> >>>> >>>> frame.pack(); >>>> frame.setVisible(true); >>>> } >>>> >>>> static Component createPanel() { >>>> final JPanel panel = new JPanel(new FlowLayout()); >>>> >>>> >>>> // toggle FullScreen from a toolbar button >>>> panel.add(new JButton(new AbstractAction("Full Screen Me!") { >>>> public void actionPerformed(ActionEvent e) { >>>> Application.getApplication().requestToggleFullScreen( >>>> (Window)panel.getTopLevelAncestor()); >>>> } >>>> })); >>>> >>>> >>>> return panel; >>>> } >>>> } >>>> >>>> Regards, >>>> Mike Swingler >>>> Apple Inc. >>>> >>>> On Mar 2, 2012, at 6:42 AM, Anthony Petrov wrote: >>>> >>>>> A tiny typo has been fixed, a new webrev is at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.2/ >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 3/2/2012 6:20 PM, Anthony Petrov wrote: >>>>>> Thanks for your suggestions Mike. Here's the latest version of the fix: >>>>>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.1/ >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> On 3/2/2012 3:14 AM, Mike Swingler wrote: >>>>>>> On Mar 1, 2012, at 1:10 PM, Anthony Petrov wrote: >>>>>>> >>>>>>>> Hi Mike, >>>>>>>> >>>>>>>> Thanks for the review! Please see my comments inline. >>>>>>>> >>>>>>>> On 3/1/2012 9:31 PM, Mike Swingler wrote: >>>>>>>>> On Feb 29, 2012, at 6:58 AM, Anthony Petrov wrote: >>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-21-popupInFullscreen-7145818.0/ >>>>>>>>> A few points to consider: >>>>>>>>> * To protect against the unrecognized selector problem, you should >>>>>>>>> test if the AWTWindow object >>>>>>>>> -respondsToSelector:@selector(toggleFullScreen) before just >>>>>>>>> calling it. >>>>>>>> I'm aware of -respondsToSelector. But I suppose that in that case >>>>>>>> this simply won't work on 10.6.8 at all. Since >>>>>>>> >>>>>>>> a) presently it does work on 10.6.8 for reasons unknown, and >>>>>>> If OpenJDK is built on Snow Leopard, it works fine. I believe the >>>>>>> problem is the X11/FreeType versions in Lion are newer, and DYLD >>>>>>> won't load libraries linked against older versions. But that is >>>>>>> going to start me on my rant about how OpenJDK should bundle it's >>>>>>> own FreeType... >>>>>>> >>>>>>>> b) we officially support 10.7+ only, hence the check makes little >>>>>>>> sense in theory, and >>>>>>> Please think of OpenJDK, not just Oracle's proprietary binaries. >>>>>>> There are other users who currently compile on Snow Leopard and this >>>>>>> is not an inconvenience, since 10.7-only API is very rare in the JDK. >>>>>>> >>>>>>>> c) from ObjC perspective sending an unknown selector isn't an >>>>>>>> error, but just a warning, >>>>>>> It is extremely poor form. The -respondsToSelector: check is very >>>>>>> cheap, and is very obvious what it is guarding against. >>>>>>> >>>>>>>> it seems to me that having this warning printed out to the console >>>>>>>> (which isn't seen by 99% of users anyway) is OK when running on >>>>>>>> 10.6.8. Plus we get the full screen working there. Isn't it awesome? >>>>>>> We know there are developers and users who will be running OpenJDK >>>>>>> on Mac OS X 10.6.8, so it is perfectly reasonable to add this as an >>>>>>> OS guard. We should not actively damage our ability to run on 10.6 >>>>>>> if it's trivially avoidable. >>>>>>> >>>>>>>>> * Also, there is already API that calls -toggleFullScreen in the >>>>>>>>> eAWT classes that you might not be aware of. You should probably >>>>>>>>> test for interactions with that, since apps can opt their window >>>>>>>>> into having a full screen widget icon and independently toggle >>>>>>>>> fullscreen. >>>>>>>> Thanks for pointing this out. I'll rework this code to make sure >>>>>>>> calls from EAWT update the boolean flag. >>>>>>> Great. >>>>>>> >>>>>>>>> * In some cases, seeing the menubar is actually desirable, where >>>>>>>>> as in the "exclusive" mode, it's probably not. Perhaps you could >>>>>>>>> consult a client property on the window to determine if the menu >>>>>>>>> bar should be hidden? >>>>>>>> Excellent idea! I think that by default the menu should be hidden >>>>>>>> (for Java spec's sake). But if a client property is set, then the >>>>>>>> menu would be visible. >>>>>>> Cool. There are several client property readers already on the root >>>>>>> AWT window that should be easily extendable. >>>>>>> >>>>>>>>> I like this overall solution, because it uses the native platform >>>>>>>>> concept of full screen which doesn't trap the user from switching >>>>>>>>> spaces like the Java SE 6 implementation did. >>>>>>>> We've noticed an interesting detail with -toggleFullScreen when >>>>>>>> it's used in a multi-screen environment. In that case the window >>>>>>>> will go full screen on the biggest monitor (actually we have a >>>>>>>> MacBook with an external monitor connected.) The OS seems to ignore >>>>>>>> the screen where the window were before entering the FS mode (the >>>>>>>> main notebook display). Is this OK? Can we force it to use the same >>>>>>>> screen where the window is originally located for the FS mode? >>>>>>> It's actually the monitor with the menu bar (the primary, as >>>>>>> designated in the Monitor's preference pane). >>>>>>> >>>>>>> This is an issue with the OS, and should be filed at >>>>>>> (it's known, but if you have a >>>>>>> specific API suggestion to target a screen, or some sort of >>>>>>> automatic behavior in mind, it would be good to provide specific >>>>>>> suggestions in the bug). > From anthony.petrov at oracle.com Fri Mar 16 08:22:59 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 16 Mar 2012 19:22:59 +0400 Subject: [7u4] Review request for 7154177: [macosx] An invisible owner frame becomes visible upon clicking a child window Message-ID: <4F635AD3.6070207@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7154177 at: http://cr.openjdk.java.net/~anthony/7u4-5-invisibleOwner-7154177.0/ Basically, with this fix we make sure we never make an invisible window an owner or a child for another window on the native level. This way the OS won't accidentally show an invisible window on the screen. Note that there's one scenario that isn't handled properly with this fix: > // visible root owner > // invisible owner > // visible dialog In this case the visible dialog will not be tied with the visible root owner by the child-parent relationship. However, this scenario seems to be very unlikely to occur in real life. -- best regards, Anthony From sergey.bylokhov at oracle.com Fri Mar 16 10:10:55 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 16 Mar 2012 21:10:55 +0400 Subject: Quality difference between Apple JDK6 and OpenJDK7 In-Reply-To: References: Message-ID: <4F63741F.8010506@oracle.com> Hi, Tobias. What do you mean to say ugly? Is it drawn slowly or just a garbage appears on the window? If you mean that in time when you resize the window the drawing goes correctly, but with a delay (there is a background at window border), so it is an expected behavior at this moment. In most cases we behave the same way on other platforms. Of course this behavior will be improved in the nearest versions. If there is a garbage and a picture absolutely incorrectly during window size changing, it is necessary to create a new bug on bugs.sun.com. Please provide a steps to reproduce(example http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002219.html) and screenshot. Thanks. 15.03.2012 20:35, Tobias Bley wrote: > Hi, > > I noticed a big quality difference between Apples JDK6 implementation and the OpenJDK7. When I resize a window (JFrame) the content is repainted very ugly in OpenJDK7, in Apple JDK6 the background is painted very smoothly. > > What's the reason for and how can we change this? > > Best regards, > Tobi > > > > > > -- Best regards, Sergey. From anthony.petrov at oracle.com Fri Mar 16 10:18:33 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 16 Mar 2012 21:18:33 +0400 Subject: [7u4] Review request for 7124428: [macosx] Frame.setExtendedState() doesn't work for undecorated windows Message-ID: <4F6375E9.6060001@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124428 at: http://cr.openjdk.java.net/~anthony/7u4-7-setExtendedStateUndecorated-7124428.0/ It looks like OS X handles the -zoom request incorrectly for undecorated windows. Therefore we have to emulate it in our code. -- best regards, Anthony From dmitry.cherepanov at oracle.com Fri Mar 16 13:04:00 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Sat, 17 Mar 2012 00:04:00 +0400 Subject: Request for review 7150349: [macosx] Applets attempting to show popup menus activate the applet process Message-ID: <4F639CB0.6040901@oracle.com> Hello, Here's a fix for broken popup windows in applets. Basically, the fix suppresses the activation of the applet's process when the user opens a popup window. To implement this, it starts using the NSNonactivatingPanelMask mask for popup windows. Also, the fix introduces -orderFrontRegardless to make sure that the popup window goes to the top while the applet is inactive. Webrev - http://cr.openjdk.java.net/~dcherepanov/7150349/webrev.0/ Thanks, Dmitry From swingler at apple.com Fri Mar 16 13:08:03 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 16 Mar 2012 13:08:03 -0700 Subject: [7u4] Review request for 7124428: [macosx] Frame.setExtendedState() doesn't work for undecorated windows In-Reply-To: <4F6375E9.6060001@oracle.com> References: <4F6375E9.6060001@oracle.com> Message-ID: On Mar 16, 2012, at 10:18 AM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124428 at: > > http://cr.openjdk.java.net/~anthony/7u4-7-setExtendedStateUndecorated-7124428.0/ > > It looks like OS X handles the -zoom request incorrectly for undecorated windows. Therefore we have to emulate it in our code. I'd suggest pulling the logic for choosing undecorated into the constructor, making the private boolean undecorated final, and then just relying on the value inside of getInitialStyleBits(). Making the undecorated boolean final serves as a warning to others in the future. Otherwise, this looks great. Cheers, Mike Swingler Apple Inc. From artem.ananiev at oracle.com Sat Mar 17 07:07:07 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Sat, 17 Mar 2012 18:07:07 +0400 Subject: Quality difference between Apple JDK6 and OpenJDK7 In-Reply-To: References: Message-ID: <4F649A8B.50306@oracle.com> Hi, Tobi, as Sergey said, there is definitely a room for improvement here. Apple team has contributed many parts of their JDK6 implementation, but it didn't include much of AWT code, so all the windows, events, painting, etc. code is written from scratch. BTW, we welcome contributions to OpenJDK code, did you know about that? :) Thanks, Artem On 3/15/2012 8:35 PM, Tobias Bley wrote: > Hi, > > I noticed a big quality difference between Apples JDK6 implementation and the OpenJDK7. When I resize a window (JFrame) the content is repainted very ugly in OpenJDK7, in Apple JDK6 the background is painted very smoothly. > > What's the reason for and how can we change this? > > Best regards, > Tobi > > > > > > From sergey.bylokhov at oracle.com Mon Mar 19 05:23:59 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 19 Mar 2012 16:23:59 +0400 Subject: [7u4] Review request for 7154177: [macosx] An invisible owner frame becomes visible upon clicking a child window In-Reply-To: <4F635AD3.6070207@oracle.com> References: <4F635AD3.6070207@oracle.com> Message-ID: <4F67255F.9010307@oracle.com> Hi Anthony. probably it would be good to add 2 regression tests for this issue? 1) For the current issue, which wasn't found by the existing tests. 2) For the issue which was not resolved in the current fix. 16.03.2012 19:22, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7154177 > at: > > http://cr.openjdk.java.net/~anthony/7u4-5-invisibleOwner-7154177.0/ > > Basically, with this fix we make sure we never make an invisible > window an owner or a child for another window on the native level. > This way the OS won't accidentally show an invisible window on the > screen. > > Note that there's one scenario that isn't handled properly with this fix: > >> // visible root owner >> // invisible owner >> // visible dialog > > In this case the visible dialog will not be tied with the visible root > owner by the child-parent relationship. However, this scenario seems > to be very unlikely to occur in real life. > > -- > best regards, > Anthony -- Best regards, Sergey. From artem.ananiev at oracle.com Mon Mar 19 05:47:26 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 19 Mar 2012 16:47:26 +0400 Subject: [7u4] Review request for 7145768 - [macosx] Regression: failure in b11 of ModalDialogInFocusEventTest In-Reply-To: <4F5E0270.4080906@oracle.com> References: <4F5E0270.4080906@oracle.com> Message-ID: <4F672ADE.60406@oracle.com> Hi, Anton, I don't see anything wrong with the fix. Please, bear in mind I'm not an expert in AWT focus code, though :) Thanks, Artem On 3/12/2012 6:04 PM, Anton V. Tarasov wrote: > Hello, > > Please review a fix for 7145768. > > webrev: http://cr.openjdk.java.net/~ant/7145768/webrev.0/webrev > > The fix addresses two focus issues: > > 1. A window's native focus state should be inspected when > requestFocusInWindow() call chain is evaluated. This is to avoid > requesting focus to a window when it's not allowed for an unfocused window. > > 2. Requesting focus to a window being shown should go through the > requestWindowFocus() method, > which manages all necessary native focus requests (requests focus to an > owner when a simple window is shown). The changeFocusedWindow() method > is called after native focused window is already set > and it just processes this fact on java level. > > Thanks, > Anton. > > From Alexander.Potochkin at oracle.com Mon Mar 19 07:06:22 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 19 Mar 2012 18:06:22 +0400 Subject: [7u4] Review request for CR 7124286: [macosx] Option modifier should work like AltGr as in Apple jdk 6 In-Reply-To: <36E2C8D7-CD2F-4CFC-A402-54A477F51EE5@oracle.com> References: <36E2C8D7-CD2F-4CFC-A402-54A477F51EE5@oracle.com> Message-ID: <4F673D5E.2070807@oracle.com> Hello Leonid looks good for me Thanks alexp > Hi, > Please review a fix for for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124286 > webrev: http://cr.openjdk.java.net/~leonidr/7124286/webrev.00/ > > Since this fix modifies shared code, I tried to keep as much of original code as possible. Also, isPrintableCharacterModifiersMask() might be not the best name possible: the reason I used it is because I couldn't come with better name. > > Thanks, > Leonid. > > From leonid.romanov at oracle.com Mon Mar 19 07:24:16 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 19 Mar 2012 18:24:16 +0400 Subject: [7u4] Review request for CR 7150089: [macosx] Default for a custom cursor created from non-existent image is not transparent Message-ID: <329E85DC-9243-451E-986A-24D30D3BCC67@oracle.com> Hi, Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150089 webrev: http://cr.openjdk.java.net/~leonidr/7150089/webrev.00/ Thanks, Leonid. From anthony.petrov at oracle.com Mon Mar 19 08:23:10 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 19 Mar 2012 19:23:10 +0400 Subject: [7u4] Review request for 7124428: [macosx] Frame.setExtendedState() doesn't work for undecorated windows In-Reply-To: References: <4F6375E9.6060001@oracle.com> Message-ID: <4F674F5E.8030900@oracle.com> Hi Mike, On 03/17/12 00:08, Mike Swingler wrote: >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124428 at: >> >> http://cr.openjdk.java.net/~anthony/7u4-7-setExtendedStateUndecorated-7124428.0/ >> >> It looks like OS X handles the -zoom request incorrectly for undecorated windows. Therefore we have to emulate it in our code. > > I'd suggest pulling the logic for choosing undecorated into the constructor, making the private boolean undecorated final, and then just relying on the value inside of getInitialStyleBits(). Making the undecorated boolean final serves as a warning to others in the future. Non-final fields that are meant to be final are evil, I agree. However, in this particular case we can't initialize this field in the constructor because the target for this CPlatformWindow instance is unknown yet. We only get a reference to a Window object when the CPlatformWindow.initialize() is called which is happening after the constructor finishes execution. Thus the field has to be non-final. > Otherwise, this looks great. Thanks for the review. -- best regards, Anthony From Alexander.Potochkin at oracle.com Mon Mar 19 11:02:19 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 19 Mar 2012 22:02:19 +0400 Subject: [7u4] Request for review: 7152952: [macosx] List rows overlap with enlarged font Message-ID: <4F6774AB.1010808@oracle.com> Hello Please review this simple fix http://cr.openjdk.java.net/~alexp/7152952/ for the following bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152952 Thanks alexp From sergey.bylokhov at oracle.com Mon Mar 19 11:19:38 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 19 Mar 2012 22:19:38 +0400 Subject: [7u4] Request for review: 7152952: [macosx] List rows overlap with enlarged font In-Reply-To: <4F6774AB.1010808@oracle.com> References: <4F6774AB.1010808@oracle.com> Message-ID: <4F6778BA.8050007@oracle.com> Hi, Alexander. Probably the same issue exists in LWTextComponentPeer in which revalidate method exists too? Maybe we can add empty revalidate method to LWComponentPeer and call it from LWComponentPeer.setFont()? 19.03.2012 22:02, Alexander Potochkin wrote: > Hello > > Please review this simple fix > http://cr.openjdk.java.net/~alexp/7152952/ > > for the following bug > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152952 > > Thanks > alexp -- Best regards, Sergey. From swingler at apple.com Mon Mar 19 18:58:40 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 19 Mar 2012 18:58:40 -0700 Subject: [7u4] Review request for CR 7150089: [macosx] Default for a custom cursor created from non-existent image is not transparent In-Reply-To: <329E85DC-9243-451E-986A-24D30D3BCC67@oracle.com> References: <329E85DC-9243-451E-986A-24D30D3BCC67@oracle.com> Message-ID: On Mar 19, 2012, at 7:24 AM, Leonid Romanov wrote: > Hi, > Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150089 > webrev: http://cr.openjdk.java.net/~leonidr/7150089/webrev.00/ This looks like a reasonable approach for the issue. Approved, Mike Swingler Apple Inc. From dmitry.cherepanov at oracle.com Mon Mar 19 23:41:59 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Tue, 20 Mar 2012 10:41:59 +0400 Subject: Request for review 7154516: [macosx] Popup menus have no visible borders Message-ID: <4F6826B7.3000003@oracle.com> Hello, Here's a temporary fix for 7154516. The problem with borders caused by known unresolved issue (7124236) and the proposed change temporarily makes popups opaque to enable shadows for popups. http://cr.openjdk.java.net/~dcherepanov/7154516/webrev.0/ Thanks, Dmitry From anton.tarasov at oracle.com Mon Mar 19 23:39:30 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 20 Mar 2012 10:39:30 +0400 Subject: Request for review 7150349: [macosx] Applets attempting to show popup menus activate the applet process In-Reply-To: <4F639CB0.6040901@oracle.com> References: <4F639CB0.6040901@oracle.com> Message-ID: <4F682622.7080902@oracle.com> Hi Dmitry, The fix looks fine for me. Thanks, Anton. On 17.03.2012 0:04, Dmitry Cherepanov wrote: > Hello, > > Here's a fix for broken popup windows in applets. Basically, the fix suppresses the activation of > the applet's process when the user opens a popup window. To implement this, it starts using the > NSNonactivatingPanelMask mask for popup windows. Also, the fix introduces -orderFrontRegardless to > make sure that the popup window goes to the top while the applet is inactive. > > Webrev - http://cr.openjdk.java.net/~dcherepanov/7150349/webrev.0/ > > Thanks, > Dmitry From dmitry.cherepanov at oracle.com Mon Mar 19 23:51:37 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Tue, 20 Mar 2012 10:51:37 +0400 Subject: [7u6] Request for approval for 7150349: [macosx] Applets attempting to show popup menus activate the applet process Message-ID: <4F6828F9.4080208@oracle.com> This is a request to push the following fix to jdk7u-dev: Bug: 7150349 "[macosx] Applets attempting to show popup menus activate the applet process" Webrev: http://cr.openjdk.java.net/~dcherepanov/7150349/webrev.0/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003631.html Thanks, Dmitry From sergey.bylokhov at oracle.com Tue Mar 20 00:24:58 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 20 Mar 2012 11:24:58 +0400 Subject: Request for review 7154516: [macosx] Popup menus have no visible borders In-Reply-To: <4F6826B7.3000003@oracle.com> References: <4F6826B7.3000003@oracle.com> Message-ID: <4F6830CA.3020901@oracle.com> Hi Dmitry, looks good. 20.03.2012 10:41, Dmitry Cherepanov wrote: > Hello, > > Here's a temporary fix for 7154516. The problem with borders caused by > known unresolved issue (7124236) and the proposed change temporarily > makes popups opaque to enable shadows for popups. > > http://cr.openjdk.java.net/~dcherepanov/7154516/webrev.0/ > > Thanks, > Dmitry > -- Best regards, Sergey. From leonid.romanov at oracle.com Tue Mar 20 04:36:10 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 20 Mar 2012 15:36:10 +0400 Subject: [7u4] Request for phase 2 approval for CR 7150089: [macosx] Default for a custom cursor created from non-existent image is not transparent Message-ID: Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150089 Webrev: http://cr.openjdk.java.net/~leonidr/7150089/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003637.html Reviewer: swingler Rationale for inclusion in 7u4: Since 1.3 release, there is an approach adopted for cursors created from non-existent image to make them transparent. It is an additional well-known if not exactly documented feature (see discussion in 4212593). This behavior was implemented in Apple jdk6. Thanks, Leonid. From anthony.petrov at oracle.com Tue Mar 20 05:07:18 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 20 Mar 2012 16:07:18 +0400 Subject: [7u4] Review request for 7154177: [macosx] An invisible owner frame becomes visible upon clicking a child window In-Reply-To: <4F67255F.9010307@oracle.com> References: <4F635AD3.6070207@oracle.com> <4F67255F.9010307@oracle.com> Message-ID: <4F6872F6.9090306@oracle.com> Hi Sergey, Thanks for the review. Indeed, a test case should be fine for this fix, so here's the updated webrev: http://cr.openjdk.java.net/~anthony/7u4-5-invisibleOwner-7154177.1/ As to the 2), I prefer to not add tests for things that should be improved eventually, so instead I've filed a CR 7155164 to address this issue later. -- best regards, Anthony On 3/19/2012 4:23 PM, Sergey Bylokhov wrote: > Hi Anthony. > probably it would be good to add 2 regression tests for this issue? > 1) For the current issue, which wasn't found by the existing tests. > 2) For the issue which was not resolved in the current fix. > > 16.03.2012 19:22, Anthony Petrov wrote: >> Hello, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7154177 >> at: >> >> http://cr.openjdk.java.net/~anthony/7u4-5-invisibleOwner-7154177.0/ >> >> Basically, with this fix we make sure we never make an invisible >> window an owner or a child for another window on the native level. >> This way the OS won't accidentally show an invisible window on the >> screen. >> >> Note that there's one scenario that isn't handled properly with this fix: >> >>> // visible root owner >>> // invisible owner >>> // visible dialog >> >> In this case the visible dialog will not be tied with the visible root >> owner by the child-parent relationship. However, this scenario seems >> to be very unlikely to occur in real life. >> >> -- >> best regards, >> Anthony > > From edvard.wendelin at oracle.com Tue Mar 20 05:31:15 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 20 Mar 2012 13:31:15 +0100 Subject: [7u6] Request for approval for 7150349: [macosx] Applets attempting to show popup menus activate the applet process In-Reply-To: <4F6828F9.4080208@oracle.com> References: <4F6828F9.4080208@oracle.com> Message-ID: <4F687893.3080803@oracle.com> Hi, I assume this is applicable to JDK 8 as well? I haven't seen a push to the JDK 8 forest. I'll approve it, but please make sure to push the fix to the appropriate JDK 8 forest before pushing it to jdk7u-dev. Cheers, Edvard On 03/20/2012 07:51 AM, Dmitry Cherepanov wrote: > This is a request to push the following fix to jdk7u-dev: > > Bug: 7150349 "[macosx] Applets attempting to show popup menus activate > the applet process" > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7150349/webrev.0/ > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003631.html > > Thanks, > Dmitry > From edvard.wendelin at oracle.com Tue Mar 20 05:36:22 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 20 Mar 2012 13:36:22 +0100 Subject: [7u4] Request for phase 2 approval for CR 7150089: [macosx] Default for a custom cursor created from non-existent image is not transparent In-Reply-To: References: Message-ID: <4F6879C6.1030901@oracle.com> Pre-approved pending release team approval. Once you see OK in bug, feel free to push the fix. Cheers, Edvard On 03/20/2012 12:36 PM, Leonid Romanov wrote: > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150089 > Webrev: http://cr.openjdk.java.net/~leonidr/7150089/webrev.00/ > Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003637.html > Reviewer: swingler > > Rationale for inclusion in 7u4: Since 1.3 release, there is an approach adopted for cursors created from non-existent image to make them transparent. It is an additional well-known if not exactly documented feature (see discussion in 4212593). This behavior was implemented in Apple jdk6. > > Thanks, > Leonid. From anthony.petrov at oracle.com Tue Mar 20 05:47:18 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 20 Mar 2012 16:47:18 +0400 Subject: [7u4] Request for phase 2 approval for CR 7124428: [macosx] Frame.setExtendedState() doesn't work for undecorated windows Message-ID: <4F687C56.90501@oracle.com> Bug: http://bugs.sun.com/view_bug.do?bug_id=7124428 Webrev: http://cr.openjdk.java.net/~anthony/7u4-7-setExtendedStateUndecorated-7124428.0/ Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003630.html Reviewer: Mike Swingler (swingler) Rationale for inclusion in 7u4: the fix resolves a couple of SQE tests failures. Its risk is estimated as LOW because it only affects programmatic maximization of frames on the Mac. -- best regards, Anthony From edvard.wendelin at oracle.com Tue Mar 20 05:57:57 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 20 Mar 2012 13:57:57 +0100 Subject: [7u4] Request for phase 2 approval for CR 7124428: [macosx] Frame.setExtendedState() doesn't work for undecorated windows In-Reply-To: <4F687C56.90501@oracle.com> References: <4F687C56.90501@oracle.com> Message-ID: <4F687ED5.5030100@oracle.com> Pre-approved pending release team approval. Feel free to push as soon as you see OK in CR. Cheers, Edvard On 03/20/2012 01:47 PM, Anthony Petrov wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7124428 > Webrev: > http://cr.openjdk.java.net/~anthony/7u4-7-setExtendedStateUndecorated-7124428.0/ > Review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003630.html > Reviewer: Mike Swingler (swingler) > > Rationale for inclusion in 7u4: the fix resolves a couple of SQE tests > failures. Its risk is estimated as LOW because it only affects > programmatic maximization of frames on the Mac. > > -- > best regards, > Anthony From anton.tarasov at oracle.com Tue Mar 20 06:53:12 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 20 Mar 2012 17:53:12 +0400 Subject: [7u4] Review request for 7154072 [macosx] swallowing key events Message-ID: <4F688BC8.1000701@oracle.com> Hello, Please review a fix for 7154072. webrev: http://cr.openjdk.java.net/~ant/7154072/webrev.1 A pointer to NSEvent was used to compare current and previous key events in order to skip repetitive ones. The pointer didn't retain the object and when a new key event object was allocated by the same address the events were considered equal. The latter was erroneously skipped. A new regression test is provided as well. Thanks, Anton. From anthony.petrov at oracle.com Tue Mar 20 06:59:21 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 20 Mar 2012 17:59:21 +0400 Subject: [7u4] Review request for 7154072 [macosx] swallowing key events In-Reply-To: <4F688BC8.1000701@oracle.com> References: <4F688BC8.1000701@oracle.com> Message-ID: <4F688D39.1000205@oracle.com> Hi Anton, The fix looks fine to me. -- best regards, Anthony On 3/20/2012 5:53 PM, Anton V. Tarasov wrote: > Hello, > > Please review a fix for 7154072. > > webrev: http://cr.openjdk.java.net/~ant/7154072/webrev.1 > > A pointer to NSEvent was used to compare current and previous key events > in order to skip repetitive ones. The pointer didn't retain the object > and when a new key event object was allocated by the same address the > events were considered equal. The latter was erroneously skipped. > > A new regression test is provided as well. > > Thanks, > Anton. > > From anthony.petrov at oracle.com Tue Mar 20 07:35:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 20 Mar 2012 18:35:22 +0400 Subject: [7u4] Review request for 7149085: [macosx] Quit with QuitStrategy CLOSE_ALL_WINDOWS does terminate application Message-ID: <4F6895AA.4020708@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7149085 at: http://cr.openjdk.java.net/~anthony/7u4-8-CloseAllWindows-7149085.0/ I have verified that with this fix both JDK 7u4 and Apple JDK behave equivalently for both quit strategies: CLOSE_ALL_WINDOWS and SYSTEM_EXIT_0. -- best regards, Anthony From Alexander.Potochkin at oracle.com Tue Mar 20 07:48:24 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 20 Mar 2012 18:48:24 +0400 Subject: [7u4] Request for review: 7152952: [macosx] List rows overlap with enlarged font In-Reply-To: <4F6778BA.8050007@oracle.com> References: <4F6774AB.1010808@oracle.com> <4F6778BA.8050007@oracle.com> Message-ID: <4F6898B8.1090008@oracle.com> Hello Sergey > Hi, Alexander. > Probably the same issue exists in LWTextComponentPeer in which > revalidate method exists too? Maybe we can add empty revalidate method > to LWComponentPeer and call it from LWComponentPeer.setFont()? This is a good idea, I started refactoring and found that the fix became too risky for the current 7u4 time frame So I'd rather put this fix as is and refactor the code for 7u6 with more time for testing, I filed an RFE for that, see #7155209 Thanks alexp > > 19.03.2012 22:02, Alexander Potochkin wrote: >> Hello >> >> Please review this simple fix >> http://cr.openjdk.java.net/~alexp/7152952/ >> >> for the following bug >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152952 >> >> Thanks >> alexp > > From alexander.zuev at oracle.com Tue Mar 20 08:55:47 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 20 Mar 2012 19:55:47 +0400 Subject: [7u4] Review request for 7149085: [macosx] Quit with QuitStrategy CLOSE_ALL_WINDOWS does terminate application In-Reply-To: <4F6895AA.4020708@oracle.com> References: <4F6895AA.4020708@oracle.com> Message-ID: <4F68A883.2030409@oracle.com> Anthony, looks Ok for me. WBR, Alex On 3/20/12 18:35, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7149085 > at: > > http://cr.openjdk.java.net/~anthony/7u4-8-CloseAllWindows-7149085.0/ > > I have verified that with this fix both JDK 7u4 and Apple JDK behave > equivalently for both quit strategies: CLOSE_ALL_WINDOWS and > SYSTEM_EXIT_0. > > -- > best regards, > Anthony From sergey.bylokhov at oracle.com Tue Mar 20 07:58:42 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 20 Mar 2012 18:58:42 +0400 Subject: [7u4] Request for review: 7152952: [macosx] List rows overlap with enlarged font In-Reply-To: <4F6898B8.1090008@oracle.com> References: <4F6774AB.1010808@oracle.com> <4F6778BA.8050007@oracle.com> <4F6898B8.1090008@oracle.com> Message-ID: <4F689B22.7020602@oracle.com> 20.03.2012 18:48, Alexander Potochkin wrote: > Hello Sergey >> Hi, Alexander. >> Probably the same issue exists in LWTextComponentPeer in which >> revalidate method exists too? Maybe we can add empty revalidate >> method to LWComponentPeer and call it from LWComponentPeer.setFont()? > > This is a good idea, > I started refactoring and found that the fix became too risky for the > current 7u4 time frame > > So I'd rather put this fix as is and refactor the code for 7u6 with > more time for testing, > I filed an RFE for that, see #7155209 ok. i haven't any objections > > Thanks > alexp > >> >> 19.03.2012 22:02, Alexander Potochkin wrote: >>> Hello >>> >>> Please review this simple fix >>> http://cr.openjdk.java.net/~alexp/7152952/ >>> >>> for the following bug >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152952 >>> >>> Thanks >>> alexp >> >> > -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Mar 20 08:57:28 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 20 Mar 2012 19:57:28 +0400 Subject: [7u4] Request for phase 2 approval for CR 7149085: [macosx] Quit with QuitStrategy CLOSE_ALL_WINDOWS does terminate application Message-ID: <4F68A8E8.4060809@oracle.com> Bug: http://bugs.sun.com/view_bug.do?bug_id=7149085 Webrev: http://cr.openjdk.java.net/~anthony/7u4-8-CloseAllWindows-7149085.0/ Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003654.html Reviewer: Alexander Zuev (kizune) Rationale for inclusion in 7u4: deferral of the fix rejected by the Release Team. Impact: Resolves an issue with EAWT (Mac OS X-specific) API. Risk: LOW: a one-liner fix. -- best regards, Anthony From sergey.bylokhov at oracle.com Tue Mar 20 09:05:59 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 20 Mar 2012 20:05:59 +0400 Subject: [7u4] Review request for 7154177: [macosx] An invisible owner frame becomes visible upon clicking a child window In-Reply-To: <4F6872F6.9090306@oracle.com> References: <4F635AD3.6070207@oracle.com> <4F67255F.9010307@oracle.com> <4F6872F6.9090306@oracle.com> Message-ID: <4F68AAE7.4050101@oracle.com> Hi, Anthony. looks good. 20.03.2012 16:07, Anthony Petrov wrote: > Hi Sergey, > > Thanks for the review. Indeed, a test case should be fine for this > fix, so here's the updated webrev: > > http://cr.openjdk.java.net/~anthony/7u4-5-invisibleOwner-7154177.1/ > > As to the 2), I prefer to not add tests for things that should be > improved eventually, so instead I've filed a CR 7155164 to address > this issue later. > > -- > best regards, > Anthony > > On 3/19/2012 4:23 PM, Sergey Bylokhov wrote: >> Hi Anthony. >> probably it would be good to add 2 regression tests for this issue? >> 1) For the current issue, which wasn't found by the existing tests. >> 2) For the issue which was not resolved in the current fix. >> >> 16.03.2012 19:22, Anthony Petrov wrote: >>> Hello, >>> >>> Please review a fix for >>> http://bugs.sun.com/view_bug.do?bug_id=7154177 at: >>> >>> http://cr.openjdk.java.net/~anthony/7u4-5-invisibleOwner-7154177.0/ >>> >>> Basically, with this fix we make sure we never make an invisible >>> window an owner or a child for another window on the native level. >>> This way the OS won't accidentally show an invisible window on the >>> screen. >>> >>> Note that there's one scenario that isn't handled properly with this >>> fix: >>> >>>> // visible root owner >>>> // invisible owner >>>> // visible dialog >>> >>> In this case the visible dialog will not be tied with the visible >>> root owner by the child-parent relationship. However, this scenario >>> seems to be very unlikely to occur in real life. >>> >>> -- >>> best regards, >>> Anthony >> >> -- Best regards, Sergey. From Alexander.Potochkin at oracle.com Tue Mar 20 09:15:36 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 20 Mar 2012 20:15:36 +0400 Subject: [7u4] Request for review: 7152952: [macosx] List rows overlap with enlarged font In-Reply-To: <4F689B22.7020602@oracle.com> References: <4F6774AB.1010808@oracle.com> <4F6778BA.8050007@oracle.com> <4F6898B8.1090008@oracle.com> <4F689B22.7020602@oracle.com> Message-ID: <4F68AD28.1010806@oracle.com> Hello Sergey >> So I'd rather put this fix as is and refactor the code for 7u6 with >> more time for testing, >> I filed an RFE for that, see #7155209 > > ok. i haven't any objections Thanks alexp >> >> Thanks >> alexp >> >>> >>> 19.03.2012 22:02, Alexander Potochkin wrote: >>>> Hello >>>> >>>> Please review this simple fix >>>> http://cr.openjdk.java.net/~alexp/7152952/ >>>> >>>> for the following bug >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152952 >>>> >>>> Thanks >>>> alexp >>> >>> >> > > From anthony.petrov at oracle.com Tue Mar 20 09:22:38 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 20 Mar 2012 20:22:38 +0400 Subject: [7u4] Request for phase 2 approval for CR 7154177: [macosx] An invisible owner frame becomes visible upon clicking a child window Message-ID: <4F68AECE.9040704@oracle.com> Bug: http://bugs.sun.com/view_bug.do?bug_id=7154177 Webrev: http://cr.openjdk.java.net/~anthony/7u4-5-invisibleOwner-7154177.1/ Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003628.html Reviewer: Sergey Bylokhov (serb) Rationale for inclusion in 7u4: Impact: Resolves a noticeable visual artifact that may affect any Swing application using popup-menus, or, say, owned dialogs. Risk: MEDIUM: the fix changes the logic that establishes the parent-child relationship between top-level windows on the native level. -- best regards, Anthony From Alexander.Potochkin at oracle.com Tue Mar 20 09:27:47 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 20 Mar 2012 20:27:47 +0400 Subject: [7u4] Request for phase 2 approval for CR 7152952: [macosx] List rows overlap with enlarged font Message-ID: <4F68B003.5030506@oracle.com> Bug: http://bugs.sun.com/view_bug.do?bug_id=7152952 Webrev: http://cr.openjdk.java.net/~alexp/7152952/webrev.00 Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003657.html Reviewer: Sergey Bylokhov Rationale for inclusion in 7u4: this is a regression from JDK6 From edvard.wendelin at oracle.com Tue Mar 20 09:45:34 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 20 Mar 2012 17:45:34 +0100 Subject: [7u4] Request for phase 2 approval for CR 7149085: [macosx] Quit with QuitStrategy CLOSE_ALL_WINDOWS does terminate application In-Reply-To: <4F68A8E8.4060809@oracle.com> References: <4F68A8E8.4060809@oracle.com> Message-ID: <4F68B42E.4040803@oracle.com> Pre-approved pending release team approval. Feel free to push once it's been approved. Make sure you create a CR for 8 so that we don't forget that we should forward port this! Cheers, Edvard On 03/20/2012 04:57 PM, Anthony Petrov wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7149085 > Webrev: > http://cr.openjdk.java.net/~anthony/7u4-8-CloseAllWindows-7149085.0/ > Review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003654.html > Reviewer: Alexander Zuev (kizune) > > Rationale for inclusion in 7u4: deferral of the fix rejected by the > Release Team. > Impact: > Resolves an issue with EAWT (Mac OS X-specific) API. > Risk: > LOW: a one-liner fix. > > -- > best regards, > Anthony From edvard.wendelin at oracle.com Tue Mar 20 09:49:19 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Tue, 20 Mar 2012 17:49:19 +0100 Subject: [7u4] Request for phase 2 approval for CR 7154177: [macosx] An invisible owner frame becomes visible upon clicking a child window In-Reply-To: <4F68AECE.9040704@oracle.com> References: <4F68AECE.9040704@oracle.com> Message-ID: <4F68B50F.5040408@oracle.com> Pre-approved pending release team approval. Remember to create a sub-CR for this one as well! On 03/20/2012 05:22 PM, Anthony Petrov wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7154177 > Webrev: > http://cr.openjdk.java.net/~anthony/7u4-5-invisibleOwner-7154177.1/ > Review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003628.html > Reviewer: Sergey Bylokhov (serb) > > Rationale for inclusion in 7u4: > Impact: > Resolves a noticeable visual artifact that may affect any Swing > application using popup-menus, or, say, owned dialogs. > Risk: > MEDIUM: the fix changes the logic that establishes the > parent-child relationship between top-level windows on the native level. > > -- > best regards, > Anthony From dmitry.cherepanov at oracle.com Wed Mar 21 01:48:44 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Wed, 21 Mar 2012 12:48:44 +0400 Subject: [7u4] Request for phase 2 approval for CR 7154516: [macosx] Popup menus have no visible borders Message-ID: <4F6995EC.20205@oracle.com> Bug: http://bugs.sun.com/view_bug.do?bug_id=7154516 Webrev: http://cr.openjdk.java.net/~dcherepanov/7154516/webrev.0/ Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003642.html Reviewer: Sergey Bylokhov (serb) Rationale for inclusion in 7u4: This is a very visible problem - shadows don't get drawn for popup windows. Also, it's a regression from Apple's JDK. Low-risk fix (one-liner). Thanks, Dmitry From leonid.romanov at oracle.com Wed Mar 21 02:43:44 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 21 Mar 2012 13:43:44 +0400 Subject: [7u4] Request for phase 2 approval for CR 7124286: [macosx] Option modifier should work like AltGr as in Apple jdk 6 Message-ID: <9920109D-868D-4ACC-9B0D-178A09BA93F4@oracle.com> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124286 Webrev: http://cr.openjdk.java.net/~leonidr/7124286/webrev.00/ Reviewer: swingler, alexp Rationale for inclusion in 7u4: the ability to enter characters from the extended characters set via option+letter combo is a basic functionality, expected by many international users. Thanks, Leonid. From artem.ananiev at oracle.com Wed Mar 21 05:19:10 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 21 Mar 2012 16:19:10 +0400 Subject: [7u4] Review request for 7149085: [macosx] Quit with QuitStrategy CLOSE_ALL_WINDOWS does terminate application In-Reply-To: <4F6895AA.4020708@oracle.com> References: <4F6895AA.4020708@oracle.com> Message-ID: <4F69C73E.1040909@oracle.com> Hi, Anthony, the fix looks fine. Note that the bug is not critical enough to be fixed in 7u4, so please retarget it to 7u6. Thanks, Artem On 3/20/2012 6:35 PM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7149085 at: > > http://cr.openjdk.java.net/~anthony/7u4-8-CloseAllWindows-7149085.0/ > > I have verified that with this fix both JDK 7u4 and Apple JDK behave > equivalently for both quit strategies: CLOSE_ALL_WINDOWS and SYSTEM_EXIT_0. > > -- > best regards, > Anthony From anthony.petrov at oracle.com Wed Mar 21 05:18:01 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 21 Mar 2012 16:18:01 +0400 Subject: [7u4] Review request for 7149085: [macosx] Quit with QuitStrategy CLOSE_ALL_WINDOWS does terminate application In-Reply-To: <4F69C73E.1040909@oracle.com> References: <4F6895AA.4020708@oracle.com> <4F69C73E.1040909@oracle.com> Message-ID: <4F69C6F9.7000609@oracle.com> Hi Artem, Thanks for the review. Please see the Comments section in the bug report to see why I'm proposing the fix for 7u4. -- best regards, Anthony On 3/21/2012 4:19 PM, Artem Ananiev wrote: > Hi, Anthony, > > the fix looks fine. Note that the bug is not critical enough to be fixed > in 7u4, so please retarget it to 7u6. > > Thanks, > > Artem > > On 3/20/2012 6:35 PM, Anthony Petrov wrote: >> Hello, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7149085 >> at: >> >> http://cr.openjdk.java.net/~anthony/7u4-8-CloseAllWindows-7149085.0/ >> >> I have verified that with this fix both JDK 7u4 and Apple JDK behave >> equivalently for both quit strategies: CLOSE_ALL_WINDOWS and >> SYSTEM_EXIT_0. >> >> -- >> best regards, >> Anthony From Alexander.Potochkin at oracle.com Wed Mar 21 05:48:30 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Wed, 21 Mar 2012 16:48:30 +0400 Subject: [7u4] Request for review: 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. Message-ID: <4F69CE1E.7070202@oracle.com> Hello Please review this fix http://cr.openjdk.java.net/~alexp/7149005 The bug is not publicly visible, so I'll describe it here: Java Control Panel's UI controls are painted incorrectly with various painting artifacts It happens because AquaLaF changes the custom border previously set by the user, the attached test case illustrates the problem. You can see that the visual appearance of the component depends on the order of setting the text and setting the border. Thanks alexp From anthony.petrov at oracle.com Wed Mar 21 05:56:14 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 21 Mar 2012 16:56:14 +0400 Subject: [7u4] Request for review: 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. In-Reply-To: <4F69CE1E.7070202@oracle.com> References: <4F69CE1E.7070202@oracle.com> Message-ID: <4F69CFEE.6060609@oracle.com> Hi Alex, Why is the "instanceof UIResource" check needed? Can a user set a custom border that inherits from this class, and if yes, why do we ignore it in this case? -- best regards, Anthony On 3/21/2012 4:48 PM, Alexander Potochkin wrote: > Hello > > Please review this fix > http://cr.openjdk.java.net/~alexp/7149005 > > The bug is not publicly visible, so I'll describe it here: > > Java Control Panel's UI controls are painted incorrectly > with various painting artifacts > > It happens because AquaLaF changes the custom border previously set by > the user, > the attached test case illustrates the problem. > > You can see that the visual appearance of the component depends on the > order > of setting the text and setting the border. > > Thanks > alexp From Alexander.Potochkin at oracle.com Wed Mar 21 06:33:54 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Wed, 21 Mar 2012 17:33:54 +0400 Subject: [7u4] Request for review: 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. In-Reply-To: <4F69CFEE.6060609@oracle.com> References: <4F69CE1E.7070202@oracle.com> <4F69CFEE.6060609@oracle.com> Message-ID: <4F69D8C2.1010606@oracle.com> Hello Anthony > Hi Alex, > > Why is the "instanceof UIResource" check needed? Can a user set a > custom border that inherits from this class, and if yes, why do we > ignore it in this case? UIResource is an empty tagging interface that all LaF resources should implement, it enables us to differ user's resources from the LaF ones It implies that a UIResource border "belongs" to the current LaF and can be changed by the system, when a border which is not a UIResource must be preserved as is. The pattern I use in this fix is widely used in the Swing code. If a user set a custom border that inherits UIResource he will contradict the UIResource specification: "This interface is used to mark objects created by ComponentUI delegates." Thanks alexp > > -- > best regards, > Anthony > > On 3/21/2012 4:48 PM, Alexander Potochkin wrote: >> Hello >> >> Please review this fix >> http://cr.openjdk.java.net/~alexp/7149005 >> >> The bug is not publicly visible, so I'll describe it here: >> >> Java Control Panel's UI controls are painted incorrectly >> with various painting artifacts >> >> It happens because AquaLaF changes the custom border previously set >> by the user, >> the attached test case illustrates the problem. >> >> You can see that the visual appearance of the component depends on >> the order >> of setting the text and setting the border. >> >> Thanks >> alexp From anthony.petrov at oracle.com Wed Mar 21 06:38:33 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 21 Mar 2012 17:38:33 +0400 Subject: [7u4] Request for review: 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. In-Reply-To: <4F69D8C2.1010606@oracle.com> References: <4F69CE1E.7070202@oracle.com> <4F69CFEE.6060609@oracle.com> <4F69D8C2.1010606@oracle.com> Message-ID: <4F69D9D9.40006@oracle.com> Thank you very much for the detailed explanation! The fix looks great to me. -- best regards, Anthony On 3/21/2012 5:33 PM, Alexander Potochkin wrote: > Hello Anthony >> Hi Alex, >> >> Why is the "instanceof UIResource" check needed? Can a user set a >> custom border that inherits from this class, and if yes, why do we >> ignore it in this case? > > UIResource is an empty tagging interface that all LaF resources should > implement, > it enables us to differ user's resources from the LaF ones > > It implies that a UIResource border "belongs" to the current LaF > and can be changed by the system, when a border which is not a UIResource > must be preserved as is. > > The pattern I use in this fix is widely used in the Swing code. > > If a user set a custom border that inherits UIResource he will > contradict the UIResource specification: > "This interface is used to mark objects created by ComponentUI delegates." > > Thanks > alexp >> >> -- >> best regards, >> Anthony >> >> On 3/21/2012 4:48 PM, Alexander Potochkin wrote: >>> Hello >>> >>> Please review this fix >>> http://cr.openjdk.java.net/~alexp/7149005 >>> >>> The bug is not publicly visible, so I'll describe it here: >>> >>> Java Control Panel's UI controls are painted incorrectly >>> with various painting artifacts >>> >>> It happens because AquaLaF changes the custom border previously set >>> by the user, >>> the attached test case illustrates the problem. >>> >>> You can see that the visual appearance of the component depends on >>> the order >>> of setting the text and setting the border. >>> >>> Thanks >>> alexp > From Alexander.Potochkin at oracle.com Wed Mar 21 07:38:05 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Wed, 21 Mar 2012 18:38:05 +0400 Subject: [7u4] Request for phase 2 approval for CR 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. Message-ID: <4F69E7CD.4050806@oracle.com> Bug:7149005 (not visible via bus.sun.com, please use bugster) Webrev:http://cr.openjdk.java.net/~alexp/7149005/webrev.00/ Reviewer: Anthony Petrov, Dmitry Cherepanov Rationale for inclusion in 7u4: This bug heavily affects painting of the Java Control Panel application which is very visible by the customers Verified by SQE Low risk Thanks alexp From michael.x.mcmahon at oracle.com Wed Mar 21 08:03:36 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 21 Mar 2012 15:03:36 +0000 Subject: RFR: 7155585: Fix ifeq errors in makefiles [macosx] Message-ID: <4F69EDC8.1070808@oracle.com> Could I get the following change reviewed please for jdk 8? It is to fix a number of minor build warnings caused by the macosx changes. http://cr.openjdk.java.net/~michaelm/7155585/webrev.1/ Thanks Michael From ahughes at redhat.com Wed Mar 21 08:44:00 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 21 Mar 2012 11:44:00 -0400 (EDT) Subject: RFR: 7155585: Fix ifeq errors in makefiles [macosx] In-Reply-To: <4F69EDC8.1070808@oracle.com> Message-ID: <2d60e0b5-2dc2-4284-86c8-384a8b92fc87@zmail17.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > Could I get the following change reviewed please for jdk 8? > > It is to fix a number of minor build warnings caused by the macosx > changes. > > http://cr.openjdk.java.net/~michaelm/7155585/webrev.1/ > > Thanks > Michael > Looks good to me. Pretty obvious fix :-) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From swingler at apple.com Wed Mar 21 08:48:51 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 21 Mar 2012 08:48:51 -0700 Subject: [7u4] Request for phase 2 approval for CR 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. In-Reply-To: <4F69E7CD.4050806@oracle.com> References: <4F69E7CD.4050806@oracle.com> Message-ID: <1F76622D-EB08-49F9-9BF8-901BF127FD8A@apple.com> On Mar 21, 2012, at 7:38 AM, Alexander Potochkin wrote: > Bug:7149005 > (not visible via bus.sun.com, please use bugster) > > Webrev:http://cr.openjdk.java.net/~alexp/7149005/webrev.00/ > Reviewer: Anthony Petrov, Dmitry Cherepanov > > Rationale for inclusion in 7u4: > > This bug heavily affects painting of the Java Control Panel application > which is very visible by the customers > > Verified by SQE > > Low risk The change looks fine...but could you provide any screen shots or steps to reproduce? Thanks, Mike Swingler Apple Inc. From Alexander.Potochkin at oracle.com Wed Mar 21 09:08:52 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Wed, 21 Mar 2012 20:08:52 +0400 Subject: [7u4] Request for phase 2 approval for CR 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. In-Reply-To: <1F76622D-EB08-49F9-9BF8-901BF127FD8A@apple.com> References: <4F69E7CD.4050806@oracle.com> <1F76622D-EB08-49F9-9BF8-901BF127FD8A@apple.com> Message-ID: <4F69FD14.7030300@oracle.com> Hello Mike Please find the test case attached there are two buttons each of them set text and border for a checkbox, they work differently depending on the lines' order this problem breaks the painting of the control panel's when they use a checkbox as a tree renderer Thanks alexp > On Mar 21, 2012, at 7:38 AM, Alexander Potochkin wrote: > >> Bug:7149005 >> (not visible via bus.sun.com, please use bugster) >> >> Webrev:http://cr.openjdk.java.net/~alexp/7149005/webrev.00/ >> Reviewer: Anthony Petrov, Dmitry Cherepanov >> >> Rationale for inclusion in 7u4: >> >> This bug heavily affects painting of the Java Control Panel application >> which is very visible by the customers >> >> Verified by SQE >> >> Low risk > The change looks fine...but could you provide any screen shots or steps to reproduce? > > Thanks, > Mike Swingler > Apple Inc. > From swingler at apple.com Wed Mar 21 09:14:32 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 21 Mar 2012 09:14:32 -0700 Subject: [7u4] Request for phase 2 approval for CR 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. In-Reply-To: <4F69FD14.7030300@oracle.com> References: <4F69E7CD.4050806@oracle.com> <1F76622D-EB08-49F9-9BF8-901BF127FD8A@apple.com> <4F69FD14.7030300@oracle.com> Message-ID: <908CD140-6B75-49E6-8EBA-B1753E76080E@apple.com> I think attachments are getting stripped out...perhaps there should be a way to provide them as side-car data to a webrev, but made clear that they aren't intended to be checked into a repo. :-/ Anyway, the fix looks reasonable. Thanks, ~Mike On Mar 21, 2012, at 9:08 AM, Alexander Potochkin wrote: > Hello Mike > > Please find the test case attached > > there are two buttons each of them set text and border for a checkbox, > they work differently depending on the lines' order > > this problem breaks the painting of the control panel's > when they use a checkbox as a tree renderer > > Thanks > alexp >> On Mar 21, 2012, at 7:38 AM, Alexander Potochkin wrote: >> >>> Bug:7149005 >>> (not visible via bus.sun.com, please use bugster) >>> >>> Webrev:http://cr.openjdk.java.net/~alexp/7149005/webrev.00/ >>> Reviewer: Anthony Petrov, Dmitry Cherepanov >>> >>> Rationale for inclusion in 7u4: >>> >>> This bug heavily affects painting of the Java Control Panel application >>> which is very visible by the customers >>> >>> Verified by SQE >>> >>> Low risk >> The change looks fine...but could you provide any screen shots or steps to reproduce? >> >> Thanks, >> Mike Swingler >> Apple Inc. >> > From Alexander.Potochkin at oracle.com Wed Mar 21 09:42:15 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Wed, 21 Mar 2012 20:42:15 +0400 Subject: [7u4] Request for phase 2 approval for CR 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. In-Reply-To: <908CD140-6B75-49E6-8EBA-B1753E76080E@apple.com> References: <4F69E7CD.4050806@oracle.com> <1F76622D-EB08-49F9-9BF8-901BF127FD8A@apple.com> <4F69FD14.7030300@oracle.com> <908CD140-6B75-49E6-8EBA-B1753E76080E@apple.com> Message-ID: <4F6A04E7.9070105@oracle.com> Hello Mike > I think attachments are getting stripped out...perhaps there should be a way to provide them as side-car data to a webrev, but made clear that they aren't intended to be checked into a repo. :-/ > > Anyway, the fix looks reasonable. Thanks Here is the test case: import javax.swing.*; import javax.swing.border.Border; import java.awt.*; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import java.awt.event.MouseAdapter; import java.awt.event.MouseEvent; public class CustomBorderTest extends JFrame { public CustomBorderTest() { setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); setLayout(new FlowLayout()); final JCheckBox cb = new JCheckBox("JCheckBox") { @Override public void setBorder(Border border) { super.setBorder(border); System.out.println("border = " + border); } }; cb.setBorderPainted(true); add(cb); JButton b1 = new JButton("Test1"); b1.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { cb.setText("Test1"); cb.setBorder(BorderFactory.createLineBorder(Color.RED, 10)); } }); add(b1); JButton b2 = new JButton("Test2"); b2.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { cb.setBorder(BorderFactory.createLineBorder(Color.GREEN, 10)); cb.setText("Test2"); } }); add(b2); pack(); } public static void main(String... args) throws Exception { SwingUtilities.invokeLater(new Runnable() { public void run() { new CustomBorderTest().setVisible(true); } }); } } > > Thanks, > ~Mike > > On Mar 21, 2012, at 9:08 AM, Alexander Potochkin wrote: > >> Hello Mike >> >> Please find the test case attached >> >> there are two buttons each of them set text and border for a checkbox, >> they work differently depending on the lines' order >> >> this problem breaks the painting of the control panel's >> when they use a checkbox as a tree renderer >> >> Thanks >> alexp >>> On Mar 21, 2012, at 7:38 AM, Alexander Potochkin wrote: >>> >>>> Bug:7149005 >>>> (not visible via bus.sun.com, please use bugster) >>>> >>>> Webrev:http://cr.openjdk.java.net/~alexp/7149005/webrev.00/ >>>> Reviewer: Anthony Petrov, Dmitry Cherepanov >>>> >>>> Rationale for inclusion in 7u4: >>>> >>>> This bug heavily affects painting of the Java Control Panel application >>>> which is very visible by the customers >>>> >>>> Verified by SQE >>>> >>>> Low risk >>> The change looks fine...but could you provide any screen shots or steps to reproduce? >>> >>> Thanks, >>> Mike Swingler >>> Apple Inc. >>> From anthony.petrov at oracle.com Thu Mar 22 05:24:36 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 22 Mar 2012 16:24:36 +0400 Subject: RFR: 7155585: Fix ifeq errors in makefiles [macosx] In-Reply-To: <4F69EDC8.1070808@oracle.com> References: <4F69EDC8.1070808@oracle.com> Message-ID: <4F6B1A04.9000705@oracle.com> Hi Michael, Changes to awt/font makefiles look fine to me. -- best regards, Anthony On 03/21/12 19:03, Michael McMahon wrote: > Could I get the following change reviewed please for jdk 8? > > It is to fix a number of minor build warnings caused by the macosx changes. > > http://cr.openjdk.java.net/~michaelm/7155585/webrev.1/ > > Thanks > Michael From sergey.bylokhov at oracle.com Thu Mar 22 07:05:09 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 22 Mar 2012 18:05:09 +0400 Subject: [8] Request for review: 7149913 [macosx] Deadlock in LWTextComponentPeer Message-ID: <4F6B3195.2070909@oracle.com> Hi Everyone, This is a forward port from jdk 7u4: http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/91ede930328c Deadlock happens when 2 threads lock delegateLock and DefaultCaret object in different order. Removed code initially was added to stop recursion between paintPeer and addDirtyRegion( repaintPeer()->paintPeer()->print()->addDirtyRegion()->repaintPeer()-> etc), but it is impossible now because repaintPeer() asynchronous. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 Webrev can be found at: http://cr.openjdk.java.net/~serb/7149913/webrev.00/ -- Best regards, Sergey. From sergey.bylokhov at oracle.com Thu Mar 22 07:13:57 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 22 Mar 2012 18:13:57 +0400 Subject: [8] Request for approval: 7124528 [macosx] Selection is not cleared properly in text component. Message-ID: <4F6B33A5.7080309@oracle.com> Hi Everyone, This is a forward port from jdk 7u4: hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/7816a64158c4 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.01 -- Best regards, Sergey. From edvard.wendelin at oracle.com Thu Mar 22 09:15:16 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 22 Mar 2012 09:15:16 -0700 Subject: [7u4] Request for phase 2 approval for CR 7154516: [macosx] Popup menus have no visible borders In-Reply-To: <4F6995EC.20205@oracle.com> References: <4F6995EC.20205@oracle.com> Message-ID: Approved. On Mar 21, 2012, at 1:48 AM, Dmitry Cherepanov wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7154516 > Webrev: http://cr.openjdk.java.net/~dcherepanov/7154516/webrev.0/ > Review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003642.html > Reviewer: Sergey Bylokhov (serb) > > Rationale for inclusion in 7u4: This is a very visible problem - shadows don't get drawn for popup windows. Also, it's a regression from Apple's JDK. Low-risk fix (one-liner). > > Thanks, > Dmitry From edvard.wendelin at oracle.com Thu Mar 22 09:16:52 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 22 Mar 2012 09:16:52 -0700 Subject: [7u4] Request for phase 2 approval for CR 7124286: [macosx] Option modifier should work like AltGr as in Apple jdk 6 In-Reply-To: <9920109D-868D-4ACC-9B0D-178A09BA93F4@oracle.com> References: <9920109D-868D-4ACC-9B0D-178A09BA93F4@oracle.com> Message-ID: <83201281-880E-414E-B782-D8316A05787A@oracle.com> Approved. On Mar 21, 2012, at 2:43 AM, Leonid Romanov wrote: > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124286 > Webrev: http://cr.openjdk.java.net/~leonidr/7124286/webrev.00/ > Reviewer: swingler, alexp > > Rationale for inclusion in 7u4: the ability to enter characters from the extended characters set via option+letter combo is a basic functionality, expected by many international users. > > Thanks, > Leonid. From edvard.wendelin at oracle.com Thu Mar 22 09:17:45 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Thu, 22 Mar 2012 09:17:45 -0700 Subject: [7u4] Request for phase 2 approval for CR 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. In-Reply-To: <4F69E7CD.4050806@oracle.com> References: <4F69E7CD.4050806@oracle.com> Message-ID: <8C511872-5881-4BCC-9208-8253EDA58844@oracle.com> Approved. On Mar 21, 2012, at 7:38 AM, Alexander Potochkin wrote: > Bug:7149005 > (not visible via bus.sun.com, please use bugster) > > Webrev:http://cr.openjdk.java.net/~alexp/7149005/webrev.00/ > Reviewer: Anthony Petrov, Dmitry Cherepanov > > Rationale for inclusion in 7u4: > > This bug heavily affects painting of the Java Control Panel application > which is very visible by the customers > > Verified by SQE > > Low risk > > Thanks > alexp > From anthony.petrov at oracle.com Fri Mar 23 05:17:52 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 23 Mar 2012 16:17:52 +0400 Subject: [8] Request for review: 7149913 [macosx] Deadlock in LWTextComponentPeer In-Reply-To: <4F6B3195.2070909@oracle.com> References: <4F6B3195.2070909@oracle.com> Message-ID: <4F6C69F0.4050400@oracle.com> Fine with me. -- best regards, Anthony On 3/22/2012 6:05 PM, Sergey Bylokhov wrote: > Hi Everyone, > This is a forward port from jdk 7u4: > http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/91ede930328c > > Deadlock happens when 2 threads lock delegateLock and DefaultCaret > object in different order. Removed code initially was added to stop > recursion between paintPeer and addDirtyRegion( > repaintPeer()->paintPeer()->print()->addDirtyRegion()->repaintPeer()-> > etc), but it is impossible now because repaintPeer() asynchronous. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7149913/webrev.00/ > From anthony.petrov at oracle.com Fri Mar 23 05:18:59 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 23 Mar 2012 16:18:59 +0400 Subject: [8] Request for approval: 7124528 [macosx] Selection is not cleared properly in text component. In-Reply-To: <4F6B33A5.7080309@oracle.com> References: <4F6B33A5.7080309@oracle.com> Message-ID: <4F6C6A33.7020104@oracle.com> OK with me, too. -- best regards, Anthony On 3/22/2012 6:13 PM, Sergey Bylokhov wrote: > Hi Everyone, > This is a forward port from jdk 7u4: > hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/7816a64158c4 > > 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.01 > From leonid.romanov at oracle.com Fri Mar 23 10:48:52 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 23 Mar 2012 10:48:52 -0700 (PDT) Subject: [7u4] Review request for 7154480: [macosx] Not all popup menu items are visible Message-ID: Hi, Release team has decided that we'd better fix 7154480 for 7u4 because of its high impact on users, so please review a fix for it. The fix prevents popups from overlapping with the Dock/menu bar on OS X, keeping the old behavior for other platforms. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480 Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/ Thanks, Leonid. From anthony.petrov at oracle.com Fri Mar 23 11:14:32 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 23 Mar 2012 22:14:32 +0400 Subject: [7u4] Review request for 7154480: [macosx] Not all popup menu items are visible In-Reply-To: References: Message-ID: <4F6CBD88.8070004@oracle.com> Hi Leonid, The code changes look good to me. I'm approving the fix given the emergency of the issue. However, I think that a more elegant solution for this bug would be to -setLevel: for always-on-top Java windows of the type POPUP to a value that pushes the windows above the dock. This way we wouldn't need an overridable method in the SunToolkit class. Could you file a CR to investigate this possibility in a future release please? -- best regards, Anthony On 3/23/2012 9:48 PM, Leonid Romanov wrote: > Hi, > Release team has decided that we'd better fix 7154480 for 7u4 because of its high impact on users, so please review a fix for it. The fix prevents popups from overlapping with the Dock/menu bar on OS X, keeping the old behavior for other platforms. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480 > Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/ > > Thanks, > Leonid. > > > > From scott.kovatch at oracle.com Fri Mar 23 11:36:21 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 23 Mar 2012 11:36:21 -0700 Subject: [7u4] Review request for 7154480: [macosx] Not all popup menu items are visible In-Reply-To: <4F6CBD88.8070004@oracle.com> References: <4F6CBD88.8070004@oracle.com> Message-ID: <2A93DB9F-83BA-479F-A4EA-6D05CF4E319D@oracle.com> No, that's not the right behavior on OS X. The Dock sits above everything else when it's visible -- popups never cover the Dock. You can see this by taking just about any window and dragging it down so it goes behind the dock, then right-click on the window. The context menu always gets pushed up so the bottom of the popup menu sits right above the dock. I think this is the right fix. Out of curiosity, why is it necessary to look for SET_WINDOW_ALWAYS_ON_TOP_PERMISSION? Is it considered bad form or some kind of security issue to block a task bar on Windows? -- Scott On Mar 23, 2012, at 11:14 AM, Anthony Petrov wrote: > Hi Leonid, > > The code changes look good to me. I'm approving the fix given the emergency of the issue. > > However, I think that a more elegant solution for this bug would be to -setLevel: for always-on-top Java windows of the type POPUP to a value that pushes the windows above the dock. This way we wouldn't need an overridable method in the SunToolkit class. Could you file a CR to investigate this possibility in a future release please? > > -- > best regards, > Anthony > > On 3/23/2012 9:48 PM, Leonid Romanov wrote: >> Hi, >> Release team has decided that we'd better fix 7154480 for 7u4 because of its high impact on users, so please review a fix for it. The fix prevents popups from overlapping with the Dock/menu bar on OS X, keeping the old behavior for other platforms. >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480 >> Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/ >> Thanks, >> Leonid. From swingler at apple.com Fri Mar 23 11:49:43 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 23 Mar 2012 11:49:43 -0700 Subject: [7u4] Review request for 7154480: [macosx] Not all popup menu items are visible In-Reply-To: <2A93DB9F-83BA-479F-A4EA-6D05CF4E319D@oracle.com> References: <4F6CBD88.8070004@oracle.com> <2A93DB9F-83BA-479F-A4EA-6D05CF4E319D@oracle.com> Message-ID: <69FC6D44-8B81-4048-82BF-771321B83972@apple.com> Actually, popups _can_ occlude the Dock, but it's very bad form for them to do so. Every effort should be taken to push the popup into the usable insets of the screen?but popups definitely overlap the menubar and the Dock when forced. ~Mike On Mar 23, 2012, at 11:36 AM, Scott Kovatch wrote: > No, that's not the right behavior on OS X. The Dock sits above everything else when it's visible -- popups never cover the Dock. You can see this by taking just about any window and dragging it down so it goes behind the dock, then right-click on the window. The context menu always gets pushed up so the bottom of the popup menu sits right above the dock. I think this is the right fix. > > Out of curiosity, why is it necessary to look for SET_WINDOW_ALWAYS_ON_TOP_PERMISSION? Is it considered bad form or some kind of security issue to block a task bar on Windows? > > -- Scott > > On Mar 23, 2012, at 11:14 AM, Anthony Petrov wrote: > >> Hi Leonid, >> >> The code changes look good to me. I'm approving the fix given the emergency of the issue. >> >> However, I think that a more elegant solution for this bug would be to -setLevel: for always-on-top Java windows of the type POPUP to a value that pushes the windows above the dock. This way we wouldn't need an overridable method in the SunToolkit class. Could you file a CR to investigate this possibility in a future release please? >> >> -- >> best regards, >> Anthony >> >> On 3/23/2012 9:48 PM, Leonid Romanov wrote: >>> Hi, >>> Release team has decided that we'd better fix 7154480 for 7u4 because of its high impact on users, so please review a fix for it. The fix prevents popups from overlapping with the Dock/menu bar on OS X, keeping the old behavior for other platforms. >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480 >>> Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/ >>> Thanks, >>> Leonid. > From scott.kovatch at oracle.com Fri Mar 23 11:56:36 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 23 Mar 2012 11:56:36 -0700 Subject: [7u4] Review request for 7154480: [macosx] Not all popup menu items are visible In-Reply-To: <69FC6D44-8B81-4048-82BF-771321B83972@apple.com> References: <4F6CBD88.8070004@oracle.com> <2A93DB9F-83BA-479F-A4EA-6D05CF4E319D@oracle.com> <69FC6D44-8B81-4048-82BF-771321B83972@apple.com> Message-ID: Looks like that's only true when the dock is on the side like you have it configured in that screen shot. I can't get it to happen when the Dock is at the bottom of the screen. That makes sense, though. This bug is about not being able to autoscroll the popup because you can't move the mouse into the auto-scroll area. That's not an issue when the dock is on the side. - Scott On Mar 23, 2012, at 11:49 AM, Mike Swingler wrote: > Actually, popups _can_ occlude the Dock, but it's very bad form for them to do so. Every effort should be taken to push the popup into the usable insets of the screen?but popups definitely overlap the menubar and the Dock when forced. > > > > ~Mike > > On Mar 23, 2012, at 11:36 AM, Scott Kovatch wrote: > >> No, that's not the right behavior on OS X. The Dock sits above everything else when it's visible -- popups never cover the Dock. You can see this by taking just about any window and dragging it down so it goes behind the dock, then right-click on the window. The context menu always gets pushed up so the bottom of the popup menu sits right above the dock. I think this is the right fix. >> >> Out of curiosity, why is it necessary to look for SET_WINDOW_ALWAYS_ON_TOP_PERMISSION? Is it considered bad form or some kind of security issue to block a task bar on Windows? >> >> -- Scott >> >> On Mar 23, 2012, at 11:14 AM, Anthony Petrov wrote: >> >>> Hi Leonid, >>> >>> The code changes look good to me. I'm approving the fix given the emergency of the issue. >>> >>> However, I think that a more elegant solution for this bug would be to -setLevel: for always-on-top Java windows of the type POPUP to a value that pushes the windows above the dock. This way we wouldn't need an overridable method in the SunToolkit class. Could you file a CR to investigate this possibility in a future release please? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 3/23/2012 9:48 PM, Leonid Romanov wrote: >>>> Hi, >>>> Release team has decided that we'd better fix 7154480 for 7u4 because of its high impact on users, so please review a fix for it. The fix prevents popups from overlapping with the Dock/menu bar on OS X, keeping the old behavior for other platforms. >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480 >>>> Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/ >>>> Thanks, >>>> Leonid. >> > From swingler at apple.com Fri Mar 23 12:25:34 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 23 Mar 2012 12:25:34 -0700 Subject: [7u4] Review request for 7154480: [macosx] Not all popup menu items are visible In-Reply-To: References: <4F6CBD88.8070004@oracle.com> <2A93DB9F-83BA-479F-A4EA-6D05CF4E319D@oracle.com> <69FC6D44-8B81-4048-82BF-771321B83972@apple.com> Message-ID: I agree that the proper fix is to make the popup code evade the screen insets?is there a bug tracking that? Regards, Mike Swingler Apple Inc On Mar 23, 2012, at 11:56 AM, Scott Kovatch wrote: > Looks like that's only true when the dock is on the side like you have it configured in that screen shot. I can't get it to happen when the Dock is at the bottom of the screen. > > That makes sense, though. This bug is about not being able to autoscroll the popup because you can't move the mouse into the auto-scroll area. That's not an issue when the dock is on the side. > > - Scott > > On Mar 23, 2012, at 11:49 AM, Mike Swingler wrote: > >> Actually, popups _can_ occlude the Dock, but it's very bad form for them to do so. Every effort should be taken to push the popup into the usable insets of the screen?but popups definitely overlap the menubar and the Dock when forced. >> >> >> >> ~Mike >> >> On Mar 23, 2012, at 11:36 AM, Scott Kovatch wrote: >> >>> No, that's not the right behavior on OS X. The Dock sits above everything else when it's visible -- popups never cover the Dock. You can see this by taking just about any window and dragging it down so it goes behind the dock, then right-click on the window. The context menu always gets pushed up so the bottom of the popup menu sits right above the dock. I think this is the right fix. >>> >>> Out of curiosity, why is it necessary to look for SET_WINDOW_ALWAYS_ON_TOP_PERMISSION? Is it considered bad form or some kind of security issue to block a task bar on Windows? >>> >>> -- Scott >>> >>> On Mar 23, 2012, at 11:14 AM, Anthony Petrov wrote: >>> >>>> Hi Leonid, >>>> >>>> The code changes look good to me. I'm approving the fix given the emergency of the issue. >>>> >>>> However, I think that a more elegant solution for this bug would be to -setLevel: for always-on-top Java windows of the type POPUP to a value that pushes the windows above the dock. This way we wouldn't need an overridable method in the SunToolkit class. Could you file a CR to investigate this possibility in a future release please? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 3/23/2012 9:48 PM, Leonid Romanov wrote: >>>>> Hi, >>>>> Release team has decided that we'd better fix 7154480 for 7u4 because of its high impact on users, so please review a fix for it. The fix prevents popups from overlapping with the Dock/menu bar on OS X, keeping the old behavior for other platforms. >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480 >>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/ >>>>> Thanks, >>>>> Leonid. >>> >> > From scott.kovatch at oracle.com Fri Mar 23 13:43:06 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 23 Mar 2012 13:43:06 -0700 Subject: [7u4] Review request for 7154480: [macosx] Not all popup menu items are visible In-Reply-To: References: <4F6CBD88.8070004@oracle.com> <2A93DB9F-83BA-479F-A4EA-6D05CF4E319D@oracle.com> <69FC6D44-8B81-4048-82BF-771321B83972@apple.com> Message-ID: <42FDE33D-B499-4BA2-916E-ED1C4FFB8C52@oracle.com> I think that's effectively what this bug does. JPopupMenu was only accounting for insets when there was a security manager in effect and a permission wasn't being granted. Now it asks the toolkit what the behavior is, and LWCToolkit says it's never okay for that to happen. Untrusted code on other platforms still can't hide the task bar with a popup. -- Scott On Mar 23, 2012, at 12:25 PM, Mike Swingler wrote: > I agree that the proper fix is to make the popup code evade the screen insets?is there a bug tracking that? > > Regards, > Mike Swingler > Apple Inc > > On Mar 23, 2012, at 11:56 AM, Scott Kovatch wrote: > >> Looks like that's only true when the dock is on the side like you have it configured in that screen shot. I can't get it to happen when the Dock is at the bottom of the screen. >> >> That makes sense, though. This bug is about not being able to autoscroll the popup because you can't move the mouse into the auto-scroll area. That's not an issue when the dock is on the side. >> >> - Scott >> >> On Mar 23, 2012, at 11:49 AM, Mike Swingler wrote: >> >>> Actually, popups _can_ occlude the Dock, but it's very bad form for them to do so. Every effort should be taken to push the popup into the usable insets of the screen?but popups definitely overlap the menubar and the Dock when forced. >>> >>> >>> >>> ~Mike >>> >>> On Mar 23, 2012, at 11:36 AM, Scott Kovatch wrote: >>> >>>> No, that's not the right behavior on OS X. The Dock sits above everything else when it's visible -- popups never cover the Dock. You can see this by taking just about any window and dragging it down so it goes behind the dock, then right-click on the window. The context menu always gets pushed up so the bottom of the popup menu sits right above the dock. I think this is the right fix. >>>> >>>> Out of curiosity, why is it necessary to look for SET_WINDOW_ALWAYS_ON_TOP_PERMISSION? Is it considered bad form or some kind of security issue to block a task bar on Windows? >>>> >>>> -- Scott >>>> >>>> On Mar 23, 2012, at 11:14 AM, Anthony Petrov wrote: >>>> >>>>> Hi Leonid, >>>>> >>>>> The code changes look good to me. I'm approving the fix given the emergency of the issue. >>>>> >>>>> However, I think that a more elegant solution for this bug would be to -setLevel: for always-on-top Java windows of the type POPUP to a value that pushes the windows above the dock. This way we wouldn't need an overridable method in the SunToolkit class. Could you file a CR to investigate this possibility in a future release please? >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 3/23/2012 9:48 PM, Leonid Romanov wrote: >>>>>> Hi, >>>>>> Release team has decided that we'd better fix 7154480 for 7u4 because of its high impact on users, so please review a fix for it. The fix prevents popups from overlapping with the Dock/menu bar on OS X, keeping the old behavior for other platforms. >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480 >>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/ >>>>>> Thanks, >>>>>> Leonid. >>>> >>> >> > From oehrstroem at gmail.com Fri Mar 23 14:28:22 2012 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 23 Mar 2012 22:28:22 +0100 Subject: Question about /usr/bin/gen_bridge_metadata Message-ID: When building build-infra/jdk8 build for mac, it hangs on: /usr/bin/gen_bridge_metadata -d -F complete --framework Foundation.framework -o Foundation.bridgesupport which seems to take forever. At least, I have never seen it finish. Also it also seems to exercise bash which runs a single thread full speed, but not ruby. I have a powerful 27" Corei7 8GBRAM, so clearly I should not have to wait this long. The -d option does not give much more info. How can I debug this problem? Almost all of my other problems arrived when I upgraded to OSX lion and Xcode 4.3, could this be caused by the upgrade as well? Thanks! //Fredrik From henri.gomez at gmail.com Fri Mar 23 15:31:29 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 23 Mar 2012 23:31:29 +0100 Subject: Question about /usr/bin/gen_bridge_metadata In-Reply-To: References: Message-ID: Did you use xcode-select to choose latest XCode to be used ? Le 23 mars 2012 ? 22:28, Fredrik ?hrstr?m a ?crit : > When building build-infra/jdk8 build for mac, it hangs on: > > /usr/bin/gen_bridge_metadata -d -F complete --framework > Foundation.framework -o Foundation.bridgesupport > > which seems to take forever. At least, I have never seen it finish. > Also it also seems to exercise bash which runs a single thread full > speed, but not ruby. > > I have a powerful 27" Corei7 8GBRAM, so clearly I should not have to > wait this long. > The -d option does not give much more info. > > How can I debug this problem? Almost all of my other problems arrived > when I upgraded to OSX lion and > Xcode 4.3, could this be caused by the upgrade as well? > > Thanks! > > //Fredrik From oehrstroem at gmail.com Fri Mar 23 18:05:14 2012 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Sat, 24 Mar 2012 02:05:14 +0100 Subject: Question about /usr/bin/gen_bridge_metadata In-Reply-To: References: Message-ID: Thank you very much! That did the trick! Now I have added enough fixes to build-infra/jdk8 so that it actually builds everything on my mac. (Though not sctp for the moment.) What is left is to get the linking parameters for the java launcher (and the other launchers) right. They link, but do not work. //Fredrik 2012/3/23 Henri Gomez : > Did you use xcode-select to choose latest XCode to be used ? > > Le 23 mars 2012 ? 22:28, Fredrik ?hrstr?m a ?crit : > >> When building build-infra/jdk8 build for mac, it hangs on: >> >> /usr/bin/gen_bridge_metadata -d -F complete --framework >> Foundation.framework -o Foundation.bridgesupport >> >> which seems to take forever. At least, I have never seen it finish. >> Also it also seems to exercise bash which runs a single thread full >> speed, but not ruby. >> >> I have a powerful 27" Corei7 8GBRAM, so clearly I should not have to >> wait this long. >> The -d option does not give much more info. >> >> How can I debug this problem? Almost all of my other problems arrived >> when I upgraded to OSX lion and >> Xcode 4.3, could this be caused by the upgrade as well? >> >> Thanks! >> >> //Fredrik From alexander.zuev at oracle.com Sat Mar 24 02:44:53 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Sat, 24 Mar 2012 13:44:53 +0400 Subject: [7u4] Review request for 7154480: [macosx] Not all popup menu items are visible In-Reply-To: References: <4F6CBD88.8070004@oracle.com> <2A93DB9F-83BA-479F-A4EA-6D05CF4E319D@oracle.com> <69FC6D44-8B81-4048-82BF-771321B83972@apple.com> Message-ID: <950368AF-BBFB-4D96-A753-615198595F02@oracle.com> Actually that was the behavior of popups till some time ago it was changed by the fix filled exactly about it - on Windows with the taskbar tall enough the popup populated off the tray icon were placed too far from the icon making it look unnatural. Just my $0.02 With best regards, Alexander Zuev 23.03.2012, ? 23:25, Mike Swingler ???????(?): > I agree that the proper fix is to make the popup code evade the screen insets?is there a bug tracking that? > > Regards, > Mike Swingler > Apple Inc > > On Mar 23, 2012, at 11:56 AM, Scott Kovatch wrote: > >> Looks like that's only true when the dock is on the side like you have it configured in that screen shot. I can't get it to happen when the Dock is at the bottom of the screen. >> >> That makes sense, though. This bug is about not being able to autoscroll the popup because you can't move the mouse into the auto-scroll area. That's not an issue when the dock is on the side. >> >> - Scott >> >> On Mar 23, 2012, at 11:49 AM, Mike Swingler wrote: >> >>> Actually, popups _can_ occlude the Dock, but it's very bad form for them to do so. Every effort should be taken to push the popup into the usable insets of the screen?but popups definitely overlap the menubar and the Dock when forced. >>> >>> >>> >>> ~Mike >>> >>> On Mar 23, 2012, at 11:36 AM, Scott Kovatch wrote: >>> >>>> No, that's not the right behavior on OS X. The Dock sits above everything else when it's visible -- popups never cover the Dock. You can see this by taking just about any window and dragging it down so it goes behind the dock, then right-click on the window. The context menu always gets pushed up so the bottom of the popup menu sits right above the dock. I think this is the right fix. >>>> >>>> Out of curiosity, why is it necessary to look for SET_WINDOW_ALWAYS_ON_TOP_PERMISSION? Is it considered bad form or some kind of security issue to block a task bar on Windows? >>>> >>>> -- Scott >>>> >>>> On Mar 23, 2012, at 11:14 AM, Anthony Petrov wrote: >>>> >>>>> Hi Leonid, >>>>> >>>>> The code changes look good to me. I'm approving the fix given the emergency of the issue. >>>>> >>>>> However, I think that a more elegant solution for this bug would be to -setLevel: for always-on-top Java windows of the type POPUP to a value that pushes the windows above the dock. This way we wouldn't need an overridable method in the SunToolkit class. Could you file a CR to investigate this possibility in a future release please? >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 3/23/2012 9:48 PM, Leonid Romanov wrote: >>>>>> Hi, >>>>>> Release team has decided that we'd better fix 7154480 for 7u4 because of its high impact on users, so please review a fix for it. The fix prevents popups from overlapping with the Dock/menu bar on OS X, keeping the old behavior for other platforms. >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480 >>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/ >>>>>> Thanks, >>>>>> Leonid. >>>> >>> >> > From sven.reimers at gmail.com Sat Mar 24 11:07:07 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Sat, 24 Mar 2012 19:07:07 +0100 Subject: JDK 7 preview installs only with Lion Message-ID: Hi guys, the preview builds from http://jdk7.java.net/macportpreview/ does install on Snow Leopard. Will this change in the future? What is the reasoning? Thanks for all your hard work Sven -- Sven Reimers * Senior Expert Software Architecture * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader? NetBeans: http://community.java.net/netbeans ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=107402 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From leonid.romanov at oracle.com Sat Mar 24 11:48:37 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Sat, 24 Mar 2012 22:48:37 +0400 Subject: [7u4] Review request for 7154480: [macosx] Not all popup menu items are visible In-Reply-To: <42FDE33D-B499-4BA2-916E-ED1C4FFB8C52@oracle.com> References: <4F6CBD88.8070004@oracle.com> <2A93DB9F-83BA-479F-A4EA-6D05CF4E319D@oracle.com> <69FC6D44-8B81-4048-82BF-771321B83972@apple.com> <42FDE33D-B499-4BA2-916E-ED1C4FFB8C52@oracle.com> Message-ID: <54B8D9AE-C1F4-4293-BCAE-8293FC867B6B@oracle.com> Interesting thing is that combo box popup always takes screen insets into account (see computePopupBounds() method of BasicComboPopup class). It is only plain popup menu that relies on the aforementioned security check. No idea why. On 24.03.2012, at 0:43, Scott Kovatch wrote: > I think that's effectively what this bug does. JPopupMenu was only accounting for insets when there was a security manager in effect and a permission wasn't being granted. Now it asks the toolkit what the behavior is, and LWCToolkit says it's never okay for that to happen. > > Untrusted code on other platforms still can't hide the task bar with a popup. > > -- Scott > > On Mar 23, 2012, at 12:25 PM, Mike Swingler wrote: > >> I agree that the proper fix is to make the popup code evade the screen insets?is there a bug tracking that? >> >> Regards, >> Mike Swingler >> Apple Inc >> >> On Mar 23, 2012, at 11:56 AM, Scott Kovatch wrote: >> >>> Looks like that's only true when the dock is on the side like you have it configured in that screen shot. I can't get it to happen when the Dock is at the bottom of the screen. >>> >>> That makes sense, though. This bug is about not being able to autoscroll the popup because you can't move the mouse into the auto-scroll area. That's not an issue when the dock is on the side. >>> >>> - Scott >>> >>> On Mar 23, 2012, at 11:49 AM, Mike Swingler wrote: >>> >>>> Actually, popups _can_ occlude the Dock, but it's very bad form for them to do so. Every effort should be taken to push the popup into the usable insets of the screen?but popups definitely overlap the menubar and the Dock when forced. >>>> >>>> >>>> >>>> ~Mike >>>> >>>> On Mar 23, 2012, at 11:36 AM, Scott Kovatch wrote: >>>> >>>>> No, that's not the right behavior on OS X. The Dock sits above everything else when it's visible -- popups never cover the Dock. You can see this by taking just about any window and dragging it down so it goes behind the dock, then right-click on the window. The context menu always gets pushed up so the bottom of the popup menu sits right above the dock. I think this is the right fix. >>>>> >>>>> Out of curiosity, why is it necessary to look for SET_WINDOW_ALWAYS_ON_TOP_PERMISSION? Is it considered bad form or some kind of security issue to block a task bar on Windows? >>>>> >>>>> -- Scott >>>>> >>>>> On Mar 23, 2012, at 11:14 AM, Anthony Petrov wrote: >>>>> >>>>>> Hi Leonid, >>>>>> >>>>>> The code changes look good to me. I'm approving the fix given the emergency of the issue. >>>>>> >>>>>> However, I think that a more elegant solution for this bug would be to -setLevel: for always-on-top Java windows of the type POPUP to a value that pushes the windows above the dock. This way we wouldn't need an overridable method in the SunToolkit class. Could you file a CR to investigate this possibility in a future release please? >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 3/23/2012 9:48 PM, Leonid Romanov wrote: >>>>>>> Hi, >>>>>>> Release team has decided that we'd better fix 7154480 for 7u4 because of its high impact on users, so please review a fix for it. The fix prevents popups from overlapping with the Dock/menu bar on OS X, keeping the old behavior for other platforms. >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480 >>>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/ >>>>>>> Thanks, >>>>>>> Leonid. >>>>> >>>> >>> >> > From alexander.zuev at oracle.com Sat Mar 24 13:20:36 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Sun, 25 Mar 2012 00:20:36 +0400 Subject: [7u4] Request for review for 7153735: [macosx] Text with diacritics is pasted with broken encoding Message-ID: <4F6E2C94.4040500@oracle.com> Hello, please review my fix for CR 7153735: [macosx] Text with diacritics is pasted with broken encoding The cause of the bug is that we are using flavormap.properties file specific for Solaris OS and for Mac OS X it should slightly differ. As i'm sure that problems like that will occur time to time the best way to deal with them all is to create the macosx-specific set of .property files in src/macosx/lib and to modify the makefiles so we can define where to get properties files on every platform without redefining the PLATFORM_SRC variable. The bug description: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153735 Webrev with proposed fix: http://cr.openjdk.java.net/~kizune/7153735/webrev.00/ With best regards, Alex From henri.gomez at gmail.com Mon Mar 26 01:33:15 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 26 Mar 2012 10:33:15 +0200 Subject: JDK 7 preview installs only with Lion In-Reply-To: References: Message-ID: I may be related to build process performed on Lion where some libraries level (like freetype) are not compatible with SnowLeopard. 2012/3/24 Sven Reimers : > Hi guys, > > the preview builds from http://jdk7.java.net/macportpreview/ does > install on Snow Leopard. > > Will this change in the future? What is the reasoning? > > Thanks for all your hard work > > Sven > > -- > Sven Reimers > > * Senior Expert Software Architecture > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html > * Community Leader? NetBeans: http://community.java.net/netbeans > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=107402 > ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 From andrew.brygin at oracle.com Mon Mar 26 04:51:47 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Mon, 26 Mar 2012 15:51:47 +0400 Subject: [7u4] Request for review for 7153735: [macosx] Text with diacritics is pasted with broken encoding In-Reply-To: <4F6E2C94.4040500@oracle.com> References: <4F6E2C94.4040500@oracle.com> Message-ID: <4F705853.1090506@oracle.com> The change looks fine to me. Thanks, Andrew On 25.03.2012 0:20, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7153735: [macosx] Text with diacritics > is pasted with broken encoding > The cause of the bug is that we are using flavormap.properties file > specific for Solaris OS and for Mac OS X > it should slightly differ. As i'm sure that problems like that will > occur time to time the best way to deal with > them all is to create the macosx-specific set of .property files in > src/macosx/lib and to modify the makefiles > so we can define where to get properties files on every platform > without redefining the PLATFORM_SRC variable. > > The bug description: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153735 > Webrev with proposed fix: > http://cr.openjdk.java.net/~kizune/7153735/webrev.00/ > > With best regards, > Alex From artem.ananiev at oracle.com Mon Mar 26 06:04:11 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 26 Mar 2012 17:04:11 +0400 Subject: [7u4] Review request for 7154480: [macosx] Not all popup menu items are visible In-Reply-To: <950368AF-BBFB-4D96-A753-615198595F02@oracle.com> References: <4F6CBD88.8070004@oracle.com> <2A93DB9F-83BA-479F-A4EA-6D05CF4E319D@oracle.com> <69FC6D44-8B81-4048-82BF-771321B83972@apple.com> <950368AF-BBFB-4D96-A753-615198595F02@oracle.com> Message-ID: <4F70694B.5080901@oracle.com> The proposed fix implies the problem is only observed if no security manager is installed, is that correct? In that case, the fix looks fine... On 3/24/2012 1:44 PM, Alexander Zuev wrote: > Actually that was the behavior of popups till some time ago it was changed by the fix filled exactly about it - on Windows with the taskbar tall enough the popup populated off the tray icon were placed too far from the icon making it look unnatural. Just my $0.02 ... but the whole approach in JPopupMenu when it's allowed to cover taskbar doesn't. What is "taskbar" here? Is Mac OS X dock area a taskbar? What if it's configured to be on the left/right side of the screen? Why JPopupMenu is related to tray icons, while native popups are expected to be used in this case? Could anyone from the Swing group comment, please? Thanks, Artem > With best regards, > Alexander Zuev > > 23.03.2012, ? 23:25, Mike Swingler ???????(?): > >> I agree that the proper fix is to make the popup code evade the screen insets?is there a bug tracking that? >> >> Regards, >> Mike Swingler >> Apple Inc >> >> On Mar 23, 2012, at 11:56 AM, Scott Kovatch wrote: >> >>> Looks like that's only true when the dock is on the side like you have it configured in that screen shot. I can't get it to happen when the Dock is at the bottom of the screen. >>> >>> That makes sense, though. This bug is about not being able to autoscroll the popup because you can't move the mouse into the auto-scroll area. That's not an issue when the dock is on the side. >>> >>> - Scott >>> >>> On Mar 23, 2012, at 11:49 AM, Mike Swingler wrote: >>> >>>> Actually, popups _can_ occlude the Dock, but it's very bad form for them to do so. Every effort should be taken to push the popup into the usable insets of the screen?but popups definitely overlap the menubar and the Dock when forced. >>>> >>>> >>>> >>>> ~Mike >>>> >>>> On Mar 23, 2012, at 11:36 AM, Scott Kovatch wrote: >>>> >>>>> No, that's not the right behavior on OS X. The Dock sits above everything else when it's visible -- popups never cover the Dock. You can see this by taking just about any window and dragging it down so it goes behind the dock, then right-click on the window. The context menu always gets pushed up so the bottom of the popup menu sits right above the dock. I think this is the right fix. >>>>> >>>>> Out of curiosity, why is it necessary to look for SET_WINDOW_ALWAYS_ON_TOP_PERMISSION? Is it considered bad form or some kind of security issue to block a task bar on Windows? >>>>> >>>>> -- Scott >>>>> >>>>> On Mar 23, 2012, at 11:14 AM, Anthony Petrov wrote: >>>>> >>>>>> Hi Leonid, >>>>>> >>>>>> The code changes look good to me. I'm approving the fix given the emergency of the issue. >>>>>> >>>>>> However, I think that a more elegant solution for this bug would be to -setLevel: for always-on-top Java windows of the type POPUP to a value that pushes the windows above the dock. This way we wouldn't need an overridable method in the SunToolkit class. Could you file a CR to investigate this possibility in a future release please? >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 3/23/2012 9:48 PM, Leonid Romanov wrote: >>>>>>> Hi, >>>>>>> Release team has decided that we'd better fix 7154480 for 7u4 because of its high impact on users, so please review a fix for it. The fix prevents popups from overlapping with the Dock/menu bar on OS X, keeping the old behavior for other platforms. >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480 >>>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/ >>>>>>> Thanks, >>>>>>> Leonid. >>>>> >>>> >>> >> From artem.ananiev at oracle.com Mon Mar 26 06:09:58 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 26 Mar 2012 17:09:58 +0400 Subject: [7u4] Request for review for 7153735: [macosx] Text with diacritics is pasted with broken encoding In-Reply-To: <4F6E2C94.4040500@oracle.com> References: <4F6E2C94.4040500@oracle.com> Message-ID: <4F706AA6.7000701@oracle.com> Hi, Alex, did you consider defining $(PLATFORM_PROPERTIES) in Defs.gmk to $(PLATFORM_SRC)/lib by default and then overriding it in Defs-macosx.gmk to $(BUILDDIR)/../src/macosx/lib? Thanks, Artem On 3/25/2012 12:20 AM, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7153735: [macosx] Text with diacritics is > pasted with broken encoding > The cause of the bug is that we are using flavormap.properties file > specific for Solaris OS and for Mac OS X > it should slightly differ. As i'm sure that problems like that will > occur time to time the best way to deal with > them all is to create the macosx-specific set of .property files in > src/macosx/lib and to modify the makefiles > so we can define where to get properties files on every platform without > redefining the PLATFORM_SRC variable. > > The bug description: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153735 > Webrev with proposed fix: > http://cr.openjdk.java.net/~kizune/7153735/webrev.00/ > > With best regards, > Alex From alexander.zuev at oracle.com Mon Mar 26 06:21:34 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 26 Mar 2012 17:21:34 +0400 Subject: [7u4] Review request for 7154480: [macosx] Not all popup menu items are visible In-Reply-To: <4F70694B.5080901@oracle.com> References: <4F6CBD88.8070004@oracle.com> <2A93DB9F-83BA-479F-A4EA-6D05CF4E319D@oracle.com> <69FC6D44-8B81-4048-82BF-771321B83972@apple.com> <950368AF-BBFB-4D96-A753-615198595F02@oracle.com> <4F70694B.5080901@oracle.com> Message-ID: <4F706D5E.7010907@oracle.com> On 3/26/12 17:04, Artem Ananiev wrote: > > The proposed fix implies the problem is only observed if no security > manager is installed, is that correct? In that case, the fix looks > fine... > > On 3/24/2012 1:44 PM, Alexander Zuev wrote: >> Actually that was the behavior of popups till some time ago it was >> changed by the fix filled exactly about it - on Windows with the >> taskbar tall enough the popup populated off the tray icon were placed >> too far from the icon making it look unnatural. Just my $0.02 > > ... but the whole approach in JPopupMenu when it's allowed to cover > taskbar doesn't. What is "taskbar" here? Is Mac OS X dock area a > taskbar? What if it's configured to be on the left/right side of the > screen? Why JPopupMenu is related to tray icons, while native popups > are expected to be used in this case? I only pointed out why we don't obey screen insets when placing popup on the screen - the reason was taskbar on Windows (there is no such thing on Mac OS X) was counted as an screen inset and placing popup inside screen insets caused visual troubles for customers and this is exactly why this behavior (accounting screen insets when positioning popup on screen) was changed. I don't think that new behavior is correct for all platforms but OTOH it was not my fix. >> With best regards, >> Alexander Zuev >> >> 23.03.2012, ? 23:25, Mike Swingler ???????(?): >> >>> I agree that the proper fix is to make the popup code evade the >>> screen insets?is there a bug tracking that? >>> >>> Regards, >>> Mike Swingler >>> Apple Inc >>> >>> On Mar 23, 2012, at 11:56 AM, Scott Kovatch wrote: >>> >>>> Looks like that's only true when the dock is on the side like you >>>> have it configured in that screen shot. I can't get it to happen >>>> when the Dock is at the bottom of the screen. >>>> >>>> That makes sense, though. This bug is about not being able to >>>> autoscroll the popup because you can't move the mouse into the >>>> auto-scroll area. That's not an issue when the dock is on the side. >>>> >>>> - Scott >>>> >>>> On Mar 23, 2012, at 11:49 AM, Mike Swingler wrote: >>>> >>>>> Actually, popups _can_ occlude the Dock, but it's very bad form >>>>> for them to do so. Every effort should be taken to push the popup >>>>> into the usable insets of the screen?but popups definitely overlap >>>>> the menubar and the Dock when forced. >>>>> >>>>> >>>>> >>>>> ~Mike >>>>> >>>>> On Mar 23, 2012, at 11:36 AM, Scott Kovatch wrote: >>>>> >>>>>> No, that's not the right behavior on OS X. The Dock sits above >>>>>> everything else when it's visible -- popups never cover the >>>>>> Dock. You can see this by taking just about any window and >>>>>> dragging it down so it goes behind the dock, then right-click on >>>>>> the window. The context menu always gets pushed up so the bottom >>>>>> of the popup menu sits right above the dock. I think this is the >>>>>> right fix. >>>>>> >>>>>> Out of curiosity, why is it necessary to look for >>>>>> SET_WINDOW_ALWAYS_ON_TOP_PERMISSION? Is it considered bad form or >>>>>> some kind of security issue to block a task bar on Windows? >>>>>> >>>>>> -- Scott >>>>>> >>>>>> On Mar 23, 2012, at 11:14 AM, Anthony Petrov wrote: >>>>>> >>>>>>> Hi Leonid, >>>>>>> >>>>>>> The code changes look good to me. I'm approving the fix given >>>>>>> the emergency of the issue. >>>>>>> >>>>>>> However, I think that a more elegant solution for this bug would >>>>>>> be to -setLevel: for always-on-top Java windows of the type >>>>>>> POPUP to a value that pushes the windows above the dock. This >>>>>>> way we wouldn't need an overridable method in the SunToolkit >>>>>>> class. Could you file a CR to investigate this possibility in a >>>>>>> future release please? >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 3/23/2012 9:48 PM, Leonid Romanov wrote: >>>>>>>> Hi, >>>>>>>> Release team has decided that we'd better fix 7154480 for 7u4 >>>>>>>> because of its high impact on users, so please review a fix for >>>>>>>> it. The fix prevents popups from overlapping with the Dock/menu >>>>>>>> bar on OS X, keeping the old behavior for other platforms. >>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480 >>>>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/ >>>>>>>> Thanks, >>>>>>>> Leonid. >>>>>> >>>>> >>>> >>> From alexander.zuev at oracle.com Mon Mar 26 06:28:16 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 26 Mar 2012 17:28:16 +0400 Subject: [7u4] Request for review for 7153735: [macosx] Text with diacritics is pasted with broken encoding In-Reply-To: <4F706AA6.7000701@oracle.com> References: <4F6E2C94.4040500@oracle.com> <4F706AA6.7000701@oracle.com> Message-ID: <4F706EF0.8040903@oracle.com> Artem, i did, but then it would be inconsistent with what is done with the PLATFORM_SRC definition and will probably cause some misunderstanding of why it happened this way. Defining of the platform-specific things in platform-specific makefiles is the way to go for me. With best regards, Alex On 3/26/12 17:09, Artem Ananiev wrote: > Hi, Alex, > > did you consider defining $(PLATFORM_PROPERTIES) in Defs.gmk to > $(PLATFORM_SRC)/lib by default and then overriding it in > Defs-macosx.gmk to $(BUILDDIR)/../src/macosx/lib? > > Thanks, > > Artem > > On 3/25/2012 12:20 AM, Alexander Zuev wrote: >> Hello, >> >> please review my fix for CR 7153735: [macosx] Text with diacritics is >> pasted with broken encoding >> The cause of the bug is that we are using flavormap.properties file >> specific for Solaris OS and for Mac OS X >> it should slightly differ. As i'm sure that problems like that will >> occur time to time the best way to deal with >> them all is to create the macosx-specific set of .property files in >> src/macosx/lib and to modify the makefiles >> so we can define where to get properties files on every platform without >> redefining the PLATFORM_SRC variable. >> >> The bug description: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153735 >> Webrev with proposed fix: >> http://cr.openjdk.java.net/~kizune/7153735/webrev.00/ >> >> With best regards, >> Alex From artem.ananiev at oracle.com Mon Mar 26 06:37:10 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 26 Mar 2012 17:37:10 +0400 Subject: [8] Request for review: 7149913 [macosx] Deadlock in LWTextComponentPeer In-Reply-To: <4F6B3195.2070909@oracle.com> References: <4F6B3195.2070909@oracle.com> Message-ID: <4F707106.3030700@oracle.com> Hi, Sergey, On 3/22/2012 6:05 PM, Sergey Bylokhov wrote: > Hi Everyone, > This is a forward port from jdk 7u4: > http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/91ede930328c > > Deadlock happens when 2 threads lock delegateLock and DefaultCaret > object in different order. Removed code initially was added to stop > recursion between paintPeer and addDirtyRegion( > repaintPeer()->paintPeer()->print()->addDirtyRegion()->repaintPeer()-> > etc), but it is impossible now because repaintPeer() asynchronous. according to the stack trace in bug description, the evaluation above doesn't look right. Initially reported deadlock involved AWT tree lock, not delegate lock. Thanks, Artem > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7149913/webrev.00/ > From sergey.bylokhov at oracle.com Mon Mar 26 06:37:55 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 26 Mar 2012 17:37:55 +0400 Subject: [8] Request for review: 7149913 [macosx] Deadlock in LWTextComponentPeer In-Reply-To: <4F707106.3030700@oracle.com> References: <4F6B3195.2070909@oracle.com> <4F707106.3030700@oracle.com> Message-ID: <4F707133.90808@oracle.com> Hi, Artem. AWT tree lock used for locking delegate. 26.03.2012 17:37, Artem Ananiev wrote: > Hi, Sergey, > > On 3/22/2012 6:05 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> This is a forward port from jdk 7u4: >> http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/91ede930328c >> >> Deadlock happens when 2 threads lock delegateLock and DefaultCaret >> object in different order. Removed code initially was added to stop >> recursion between paintPeer and addDirtyRegion( >> repaintPeer()->paintPeer()->print()->addDirtyRegion()->repaintPeer()-> >> etc), but it is impossible now because repaintPeer() asynchronous. > > according to the stack trace in bug description, the evaluation above > doesn't look right. Initially reported deadlock involved AWT tree > lock, not delegate lock. > > Thanks, > > Artem > >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7149913/webrev.00/ >> -- Best regards, Sergey. From artem.ananiev at oracle.com Mon Mar 26 06:44:28 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 26 Mar 2012 17:44:28 +0400 Subject: [7u4] Request for review for 7153735: [macosx] Text with diacritics is pasted with broken encoding In-Reply-To: <4F706EF0.8040903@oracle.com> References: <4F6E2C94.4040500@oracle.com> <4F706AA6.7000701@oracle.com> <4F706EF0.8040903@oracle.com> Message-ID: <4F7072BC.8060208@oracle.com> On 3/26/2012 5:28 PM, Alexander Zuev wrote: > Artem, > > i did, but then it would be inconsistent with what is done with the > PLATFORM_SRC definition > and will probably cause some misunderstanding of why it happened this > way. Defining of the platform-specific > things in platform-specific makefiles is the way to go for me. I'm personally fine with either way. It would be fine to get comments from anyone who is more familiar to JDK makefiles, though... Thanks, Artem > With best regards, > Alex > > On 3/26/12 17:09, Artem Ananiev wrote: >> Hi, Alex, >> >> did you consider defining $(PLATFORM_PROPERTIES) in Defs.gmk to >> $(PLATFORM_SRC)/lib by default and then overriding it in >> Defs-macosx.gmk to $(BUILDDIR)/../src/macosx/lib? >> >> Thanks, >> >> Artem >> >> On 3/25/2012 12:20 AM, Alexander Zuev wrote: >>> Hello, >>> >>> please review my fix for CR 7153735: [macosx] Text with diacritics is >>> pasted with broken encoding >>> The cause of the bug is that we are using flavormap.properties file >>> specific for Solaris OS and for Mac OS X >>> it should slightly differ. As i'm sure that problems like that will >>> occur time to time the best way to deal with >>> them all is to create the macosx-specific set of .property files in >>> src/macosx/lib and to modify the makefiles >>> so we can define where to get properties files on every platform without >>> redefining the PLATFORM_SRC variable. >>> >>> The bug description: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153735 >>> Webrev with proposed fix: >>> http://cr.openjdk.java.net/~kizune/7153735/webrev.00/ >>> >>> With best regards, >>> Alex > From dmitry.cherepanov at oracle.com Mon Mar 26 06:54:08 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 26 Mar 2012 17:54:08 +0400 Subject: Request for review 7156194: [macosx] Can't type non-ASCII characters into applets Message-ID: <4F707500.10801@oracle.com> Hello, Here's a fix for 7156194 ([macosx] Can't type non-ASCII characters into applets]) The fix implements CEmbeddedFrame.handleInputEvent (NPCocoaEventTextInput handler) and sends KEY_TYPED event for each character of the incoming string. Also, it introduces new "needsKeyTyped" parameter to CEmbeddedFrame.handleKeyEvent method to prevent getting double KEY_TYPED events. http://cr.openjdk.java.net/~dcherepanov/7156194/webrev.0/ Thanks, Dmitry From dmitry.cherepanov at oracle.com Mon Mar 26 07:37:17 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 26 Mar 2012 18:37:17 +0400 Subject: Request for review 7156191 [macosx] Can't type into applet demos in Pivot Message-ID: <4F707F1D.3080204@oracle.com> Hello, Here's a fix for 7156191 ([macosx] Can't type into applet demos in Pivot) The current implementation of focus event handlers in CEmbeddedFrame dispatches focus events directly to the embedded frame. The fix changes the implementation and now it calls peer.notifyActivation() like it's done in standalone mode. http://cr.openjdk.java.net/~dcherepanov/7156191/webrev.0/ Thanks, Dmitry From anthony.petrov at oracle.com Mon Mar 26 07:38:56 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 26 Mar 2012 18:38:56 +0400 Subject: Request for review 7156194: [macosx] Can't type non-ASCII characters into applets In-Reply-To: <4F707500.10801@oracle.com> References: <4F707500.10801@oracle.com> Message-ID: <4F707F80.1080203@oracle.com> Hi Dmitry, Do we ever pass 'false' as the needsKeyTyped argument? I see only one call to the handleKeyEvent() method at CPlatformView, and it always passes true. Where is the CEmbeddedFrame.handleKeyEvent() called from? -- best regards, Anthony On 03/26/12 17:54, Dmitry Cherepanov wrote: > Hello, > > Here's a fix for 7156194 ([macosx] Can't type non-ASCII characters into > applets]) > > The fix implements CEmbeddedFrame.handleInputEvent > (NPCocoaEventTextInput handler) and sends KEY_TYPED event for each > character of the incoming string. Also, it introduces new > "needsKeyTyped" parameter to CEmbeddedFrame.handleKeyEvent method to > prevent getting double KEY_TYPED events. > > http://cr.openjdk.java.net/~dcherepanov/7156194/webrev.0/ > > Thanks, > Dmitry > From dmitry.cherepanov at oracle.com Mon Mar 26 07:56:04 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 26 Mar 2012 18:56:04 +0400 Subject: Request for review 7156194: [macosx] Can't type non-ASCII characters into applets In-Reply-To: <4F707F80.1080203@oracle.com> References: <4F707500.10801@oracle.com> <4F707F80.1080203@oracle.com> Message-ID: <4F708384.3060805@oracle.com> Anthony Petrov wrote: > Hi Dmitry, > > Do we ever pass 'false' as the needsKeyTyped argument? I see only one > call to the handleKeyEvent() method at CPlatformView, and it always > passes true. > > Where is the CEmbeddedFrame.handleKeyEvent() called from? Hi Anthony, It's called from the Plugin code and it's 'false' for Firefox. In this case, the Plugin gets TextInput event even if it's US layout and we would get double KEY_TYPED events without suppressing one of these events. Thanks, Dmitry > > -- > best regards, > Anthony > > On 03/26/12 17:54, Dmitry Cherepanov wrote: >> Hello, >> >> Here's a fix for 7156194 ([macosx] Can't type non-ASCII characters into >> applets]) >> >> The fix implements CEmbeddedFrame.handleInputEvent >> (NPCocoaEventTextInput handler) and sends KEY_TYPED event for each >> character of the incoming string. Also, it introduces new >> "needsKeyTyped" parameter to CEmbeddedFrame.handleKeyEvent method to >> prevent getting double KEY_TYPED events. >> >> http://cr.openjdk.java.net/~dcherepanov/7156194/webrev.0/ >> >> Thanks, >> Dmitry >> From anthony.petrov at oracle.com Mon Mar 26 07:56:29 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 26 Mar 2012 18:56:29 +0400 Subject: Request for review 7156194: [macosx] Can't type non-ASCII characters into applets In-Reply-To: <4F708384.3060805@oracle.com> References: <4F707500.10801@oracle.com> <4F707F80.1080203@oracle.com> <4F708384.3060805@oracle.com> Message-ID: <4F70839D.4090202@oracle.com> Thanks for the clarification. The fix looks fine to me then. -- best regards, Anthony On 03/26/12 18:56, Dmitry Cherepanov wrote: > Anthony Petrov wrote: >> Hi Dmitry, >> >> Do we ever pass 'false' as the needsKeyTyped argument? I see only one >> call to the handleKeyEvent() method at CPlatformView, and it always >> passes true. >> >> Where is the CEmbeddedFrame.handleKeyEvent() called from? > > Hi Anthony, > > It's called from the Plugin code and it's 'false' for Firefox. In this > case, the Plugin gets TextInput event even if it's US layout and we > would get double KEY_TYPED events without suppressing one of these events. > > Thanks, > Dmitry > >> >> -- >> best regards, >> Anthony >> >> On 03/26/12 17:54, Dmitry Cherepanov wrote: >>> Hello, >>> >>> Here's a fix for 7156194 ([macosx] Can't type non-ASCII characters into >>> applets]) >>> >>> The fix implements CEmbeddedFrame.handleInputEvent >>> (NPCocoaEventTextInput handler) and sends KEY_TYPED event for each >>> character of the incoming string. Also, it introduces new >>> "needsKeyTyped" parameter to CEmbeddedFrame.handleKeyEvent method to >>> prevent getting double KEY_TYPED events. >>> >>> http://cr.openjdk.java.net/~dcherepanov/7156194/webrev.0/ >>> >>> Thanks, >>> Dmitry >>> > From artem.ananiev at oracle.com Mon Mar 26 08:26:15 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 26 Mar 2012 19:26:15 +0400 Subject: [8] Request for review: 7149913 [macosx] Deadlock in LWTextComponentPeer In-Reply-To: <4F707133.90808@oracle.com> References: <4F6B3195.2070909@oracle.com> <4F707106.3030700@oracle.com> <4F707133.90808@oracle.com> Message-ID: <4F708A97.40706@oracle.com> On 3/26/2012 5:37 PM, Sergey Bylokhov wrote: > Hi, Artem. > AWT tree lock used for locking delegate. Ah, right, I was confused by the method name, getDelegateLock()... OK, could you add some information to the bug, please? Right now Evaluation contains a statement about the deadlock, but not about what it is caused by and how it can be resolved. Thanks, Artem > 26.03.2012 17:37, Artem Ananiev wrote: >> Hi, Sergey, >> >> On 3/22/2012 6:05 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> This is a forward port from jdk 7u4: >>> http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/91ede930328c >>> >>> Deadlock happens when 2 threads lock delegateLock and DefaultCaret >>> object in different order. Removed code initially was added to stop >>> recursion between paintPeer and addDirtyRegion( >>> repaintPeer()->paintPeer()->print()->addDirtyRegion()->repaintPeer()-> >>> etc), but it is impossible now because repaintPeer() asynchronous. >> >> according to the stack trace in bug description, the evaluation above >> doesn't look right. Initially reported deadlock involved AWT tree >> lock, not delegate lock. >> >> Thanks, >> >> Artem >> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7149913/webrev.00/ >>> > > From artem.ananiev at oracle.com Mon Mar 26 08:37:24 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 26 Mar 2012 19:37:24 +0400 Subject: Request for review 7156191 [macosx] Can't type into applet demos in Pivot In-Reply-To: <4F707F1D.3080204@oracle.com> References: <4F707F1D.3080204@oracle.com> Message-ID: <4F708D34.7020708@oracle.com> The fix looks fine. CEmbeddedFrame.updateOverlayWindowActiveState() JavaDoc may be corrected, though: does it still post a WINDOW_ACTIVATED event? Thanks, Artem On 3/26/2012 6:37 PM, Dmitry Cherepanov wrote: > Hello, > > Here's a fix for 7156191 ([macosx] Can't type into applet demos in Pivot) > > The current implementation of focus event handlers in CEmbeddedFrame > dispatches focus events directly to the embedded frame. The fix changes > the implementation and now it calls peer.notifyActivation() like it's > done in standalone mode. > > http://cr.openjdk.java.net/~dcherepanov/7156191/webrev.0/ > > Thanks, > Dmitry > From sergey.bylokhov at oracle.com Mon Mar 26 09:25:31 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 26 Mar 2012 20:25:31 +0400 Subject: [8] Request for review: 7149913 [macosx] Deadlock in LWTextComponentPeer In-Reply-To: <4F708A97.40706@oracle.com> References: <4F6B3195.2070909@oracle.com> <4F707106.3030700@oracle.com> <4F707133.90808@oracle.com> <4F708A97.40706@oracle.com> Message-ID: <4F70987B.3040404@oracle.com> Hi Artem. Done. 26.03.2012 19:26, Artem Ananiev ???????: > > On 3/26/2012 5:37 PM, Sergey Bylokhov wrote: >> Hi, Artem. >> AWT tree lock used for locking delegate. > > Ah, right, I was confused by the method name, getDelegateLock()... OK, > could you add some information to the bug, please? Right now > Evaluation contains a statement about the deadlock, but not about what > it is caused by and how it can be resolved. > > Thanks, > > Artem > >> 26.03.2012 17:37, Artem Ananiev wrote: >>> Hi, Sergey, >>> >>> On 3/22/2012 6:05 PM, Sergey Bylokhov wrote: >>>> Hi Everyone, >>>> This is a forward port from jdk 7u4: >>>> http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/91ede930328c >>>> >>>> Deadlock happens when 2 threads lock delegateLock and DefaultCaret >>>> object in different order. Removed code initially was added to stop >>>> recursion between paintPeer and addDirtyRegion( >>>> repaintPeer()->paintPeer()->print()->addDirtyRegion()->repaintPeer()-> >>>> etc), but it is impossible now because repaintPeer() asynchronous. >>> >>> according to the stack trace in bug description, the evaluation above >>> doesn't look right. Initially reported deadlock involved AWT tree >>> lock, not delegate lock. >>> >>> Thanks, >>> >>> Artem >>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149913 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7149913/webrev.00/ >>>> >> >> -- Best regards, Sergey. From dmitry.cherepanov at oracle.com Mon Mar 26 08:55:21 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 26 Mar 2012 19:55:21 +0400 Subject: Request for review 7156191 [macosx] Can't type into applet demos in Pivot In-Reply-To: <4F708D34.7020708@oracle.com> References: <4F707F1D.3080204@oracle.com> <4F708D34.7020708@oracle.com> Message-ID: <4F709169.70503@oracle.com> Hi Artem, Artem Ananiev wrote: > > The fix looks fine. CEmbeddedFrame.updateOverlayWindowActiveState() > JavaDoc may be corrected, though: does it still post a > WINDOW_ACTIVATED event? I think that the comment is still valid. The code generates a WINDOW_ACTIVATED event when the embedded frame becomes the active window. Thanks, Dmitry > > Thanks, > > Artem > > On 3/26/2012 6:37 PM, Dmitry Cherepanov wrote: >> Hello, >> >> Here's a fix for 7156191 ([macosx] Can't type into applet demos in >> Pivot) >> >> The current implementation of focus event handlers in CEmbeddedFrame >> dispatches focus events directly to the embedded frame. The fix changes >> the implementation and now it calls peer.notifyActivation() like it's >> done in standalone mode. >> >> http://cr.openjdk.java.net/~dcherepanov/7156191/webrev.0/ >> >> Thanks, >> Dmitry >> From scott.kovatch at oracle.com Mon Mar 26 10:28:12 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 26 Mar 2012 13:28:12 -0400 Subject: Request for review 7156194: [macosx] Can't type non-ASCII characters into applets In-Reply-To: <4F708384.3060805@oracle.com> References: <4F707500.10801@oracle.com> <4F707F80.1080203@oracle.com> <4F708384.3060805@oracle.com> Message-ID: <99FB877C-CCAA-4207-939D-68F56932BC21@oracle.com> Dmitry, It occurred to me this morning that we should also define a handleKeyEvent() with the previous signature that just calls the new method with the last parameter always 'true'. That way, deploy will still build until this JDK change makes its way to the master. I also don't think I'll be able to check in the corresponding deploy changes right away. We can remove it later, but for now just document it so that it's clear it's transitional. -- Scott On Mar 26, 2012, at 10:56 AM, Dmitry Cherepanov wrote: > Anthony Petrov wrote: >> Hi Dmitry, >> >> Do we ever pass 'false' as the needsKeyTyped argument? I see only one call to the handleKeyEvent() method at CPlatformView, and it always passes true. >> >> Where is the CEmbeddedFrame.handleKeyEvent() called from? > > Hi Anthony, > > It's called from the Plugin code and it's 'false' for Firefox. In this case, the Plugin gets TextInput event even if it's US layout and we would get double KEY_TYPED events without suppressing one of these events. > > Thanks, > Dmitry > >> >> -- >> best regards, >> Anthony >> >> On 03/26/12 17:54, Dmitry Cherepanov wrote: >>> Hello, >>> >>> Here's a fix for 7156194 ([macosx] Can't type non-ASCII characters into >>> applets]) >>> >>> The fix implements CEmbeddedFrame.handleInputEvent >>> (NPCocoaEventTextInput handler) and sends KEY_TYPED event for each >>> character of the incoming string. Also, it introduces new >>> "needsKeyTyped" parameter to CEmbeddedFrame.handleKeyEvent method to >>> prevent getting double KEY_TYPED events. >>> >>> http://cr.openjdk.java.net/~dcherepanov/7156194/webrev.0/ >>> >>> Thanks, >>> Dmitry >>> > From sergey.bylokhov at oracle.com Mon Mar 26 10:58:43 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 26 Mar 2012 21:58:43 +0400 Subject: [8] Request for review: 7124551 [macosx] Once added, Menu shortcut cannot be removed Message-ID: <4F70AE53.6060204@oracle.com> Hi Everyone, We should accept empty KeyEquivalent in case of shortcut removing. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124551 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124551/webrev.00/ -- Best regards, Sergey. From dmitry.cherepanov at oracle.com Mon Mar 26 11:27:34 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 26 Mar 2012 22:27:34 +0400 Subject: Request for review 7156194: [macosx] Can't type non-ASCII characters into applets In-Reply-To: <99FB877C-CCAA-4207-939D-68F56932BC21@oracle.com> References: <4F707500.10801@oracle.com> <4F707F80.1080203@oracle.com> <4F708384.3060805@oracle.com> <99FB877C-CCAA-4207-939D-68F56932BC21@oracle.com> Message-ID: <4F70B516.4080903@oracle.com> Hi Scott, Scott Kovatch wrote: > Dmitry, > > It occurred to me this morning that we should also define a handleKeyEvent() with the previous signature that just calls the new method with the last parameter always 'true'. That way, deploy will still build until this JDK change makes its way to the master. I also don't think I'll be able to check in the corresponding deploy changes right away. We can remove it later, but for now just document it so that it's clear it's transitional. > That makes sense. I've updated the webrev at: http://cr.openjdk.java.net/~dcherepanov/7156194/webrev.1/ Thanks, Dmitry From alexandr.scherbatiy at oracle.com Tue Mar 27 01:08:47 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 27 Mar 2012 12:08:47 +0400 Subject: Find the topmost window under a mouse cursor Message-ID: <4F71758F.6050808@oracle.com> Hello, Does the Mac OS X contains a method that allows to find the topmost window under a mouse cursor? There is the issue when a window is created under a mouse cursor or it is moved under a mouse cursor the system does not generate the NSMouseEntered event. It is possible to synthetically generate the MouseEntered event for window creation and moving in Java because we need that a window behavior on Mac OS X was the same as on others platforms. But it is necessary to have a way to know is this window the topmost under a mouse cursor. Thanks, Alexandr. From anthony.petrov at oracle.com Tue Mar 27 02:26:34 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 27 Mar 2012 13:26:34 +0400 Subject: Find the topmost window under a mouse cursor In-Reply-To: <4F71758F.6050808@oracle.com> References: <4F71758F.6050808@oracle.com> Message-ID: <4F7187CA.5030209@oracle.com> Hi Alexander, I suggest to track the MouseIsOver state with a boolean flag per window, and send a synthetic Entered event upon receiving any other mouse event (Moved, Clicked, etc.) if the flag indicates we haven't yet sent an Entered event for this window. The flag should be set/reset in the Entered/Exited mouse handlers. We use this approach in FX and everyone seems to be happy about that. -- best regards, Anthony On 3/27/2012 12:08 PM, Alexander Scherbatiy wrote: > > Hello, > > Does the Mac OS X contains a method that allows to find the topmost > window under a mouse cursor? > > There is the issue when a window is created under a mouse cursor or it > is moved under a mouse cursor the system does not generate the > NSMouseEntered event. > > It is possible to synthetically generate the MouseEntered event for > window creation and moving in Java because we need that a window > behavior on Mac OS X was the same as on others platforms. > But it is necessary to have a way to know is this window the topmost > under a mouse cursor. > > Thanks, > Alexandr. > > > From dmitry.cherepanov at oracle.com Tue Mar 27 03:19:40 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Tue, 27 Mar 2012 14:19:40 +0400 Subject: Find the topmost window under a mouse cursor In-Reply-To: <4F7187CA.5030209@oracle.com> References: <4F71758F.6050808@oracle.com> <4F7187CA.5030209@oracle.com> Message-ID: <4F71943C.1040606@oracle.com> Anthony Petrov wrote: > Hi Alexander, > > I suggest to track the MouseIsOver state with a boolean flag per > window, and send a synthetic Entered event upon receiving any other > mouse event (Moved, Clicked, etc.) We should probably synthesize such mouse enter/exit events upon changing window's bounds. Synthesizing the mouse enter/exit event upon receiving any other mouse event wouldn't changes the mouse cursor until the user performs any mouse action. Thanks, Dmitry > if the flag indicates we haven't yet sent an Entered event for this > window. The flag should be set/reset in the Entered/Exited mouse > handlers. > > We use this approach in FX and everyone seems to be happy about that. > > -- > best regards, > Anthony > > On 3/27/2012 12:08 PM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Does the Mac OS X contains a method that allows to find the topmost >> window under a mouse cursor? >> >> There is the issue when a window is created under a mouse cursor or >> it is moved under a mouse cursor the system does not generate the >> NSMouseEntered event. >> >> It is possible to synthetically generate the MouseEntered event for >> window creation and moving in Java because we need that a window >> behavior on Mac OS X was the same as on others platforms. >> But it is necessary to have a way to know is this window the topmost >> under a mouse cursor. >> >> Thanks, >> Alexandr. >> >> >> From anthony.petrov at oracle.com Tue Mar 27 03:23:21 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 27 Mar 2012 14:23:21 +0400 Subject: Find the topmost window under a mouse cursor In-Reply-To: <4F71943C.1040606@oracle.com> References: <4F71758F.6050808@oracle.com> <4F7187CA.5030209@oracle.com> <4F71943C.1040606@oracle.com> Message-ID: <4F719519.2070105@oracle.com> On 3/27/2012 2:19 PM, Dmitry Cherepanov wrote: >> I suggest to track the MouseIsOver state with a boolean flag per >> window, and send a synthetic Entered event upon receiving any other >> mouse event (Moved, Clicked, etc.) > > We should probably synthesize such mouse enter/exit events upon changing > window's bounds. Synthesizing the mouse enter/exit event upon receiving > any other mouse event wouldn't changes the mouse cursor until the user > performs any mouse action. Is this exact behavior specified anywhere (i.e. that the cursor must be updated as soon as a component appears under the mouse even if the mouse holds still)? If not, I'd just state that the behavior is platform-specific. -- best regards, Anthony > > Thanks, > Dmitry > >> if the flag indicates we haven't yet sent an Entered event for this >> window. The flag should be set/reset in the Entered/Exited mouse >> handlers. >> >> We use this approach in FX and everyone seems to be happy about that. >> >> -- >> best regards, >> Anthony >> >> On 3/27/2012 12:08 PM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Does the Mac OS X contains a method that allows to find the topmost >>> window under a mouse cursor? >>> >>> There is the issue when a window is created under a mouse cursor or >>> it is moved under a mouse cursor the system does not generate the >>> NSMouseEntered event. >>> >>> It is possible to synthetically generate the MouseEntered event for >>> window creation and moving in Java because we need that a window >>> behavior on Mac OS X was the same as on others platforms. >>> But it is necessary to have a way to know is this window the topmost >>> under a mouse cursor. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> > From anthony.petrov at oracle.com Tue Mar 27 03:42:16 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 27 Mar 2012 14:42:16 +0400 Subject: [8] Request for review: 7124551 [macosx] Once added, Menu shortcut cannot be removed In-Reply-To: <4F70AE53.6060204@oracle.com> References: <4F70AE53.6060204@oracle.com> Message-ID: <4F719988.8090403@oracle.com> Looks fine to me. -- best regards, Anthony On 3/26/2012 9:58 PM, Sergey Bylokhov wrote: > Hi Everyone, > We should accept empty KeyEquivalent in case of shortcut removing. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124551 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124551/webrev.00/ > From artem.ananiev at oracle.com Tue Mar 27 04:04:39 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 27 Mar 2012 15:04:39 +0400 Subject: Find the topmost window under a mouse cursor In-Reply-To: <4F7187CA.5030209@oracle.com> References: <4F71758F.6050808@oracle.com> <4F7187CA.5030209@oracle.com> Message-ID: <4F719EC7.10304@oracle.com> On 3/27/2012 1:26 PM, Anthony Petrov wrote: > Hi Alexander, > > I suggest to track the MouseIsOver state with a boolean flag per window, > and send a synthetic Entered event upon receiving any other mouse event > (Moved, Clicked, etc.) if the flag indicates we haven't yet sent an > Entered event for this window. The flag should be set/reset in the > Entered/Exited mouse handlers. Alexander's question is exactly about how to implement such MouseIsOver flag. The problem is when a window is shown, even if its bounds include current mouse position, it may not be the window under cursor (e.g. if another always-on-top window is there, or the window is blocked by a modal dialog). So for every window size/location/visibility change we need to query for a window under cursor to generate Entered/Exited events. Thanks, Artem > We use this approach in FX and everyone seems to be happy about that. > > -- > best regards, > Anthony > > On 3/27/2012 12:08 PM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Does the Mac OS X contains a method that allows to find the topmost >> window under a mouse cursor? >> >> There is the issue when a window is created under a mouse cursor or it >> is moved under a mouse cursor the system does not generate the >> NSMouseEntered event. >> >> It is possible to synthetically generate the MouseEntered event for >> window creation and moving in Java because we need that a window >> behavior on Mac OS X was the same as on others platforms. >> But it is necessary to have a way to know is this window the topmost >> under a mouse cursor. >> >> Thanks, >> Alexandr. >> >> >> From dmitry.cherepanov at oracle.com Tue Mar 27 04:24:06 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Tue, 27 Mar 2012 15:24:06 +0400 Subject: Find the topmost window under a mouse cursor In-Reply-To: <4F719519.2070105@oracle.com> References: <4F71758F.6050808@oracle.com> <4F7187CA.5030209@oracle.com> <4F71943C.1040606@oracle.com> <4F719519.2070105@oracle.com> Message-ID: <4F71A356.9070009@oracle.com> Anthony Petrov wrote: > On 3/27/2012 2:19 PM, Dmitry Cherepanov wrote: >>> I suggest to track the MouseIsOver state with a boolean flag per >>> window, and send a synthetic Entered event upon receiving any other >>> mouse event (Moved, Clicked, etc.) >> >> We should probably synthesize such mouse enter/exit events upon >> changing window's bounds. Synthesizing the mouse enter/exit event >> upon receiving any other mouse event wouldn't changes the mouse >> cursor until the user performs any mouse action. > > Is this exact behavior specified anywhere (i.e. that the cursor must > be updated as soon as a component appears under the mouse even if the > mouse holds still)? If not, I'd just state that the behavior is > platform-specific. Looks like it's a part of the AWT specification: http://docs.oracle.com/javase/7/docs/api/java/awt/Component.html#setCursor(java.awt.Cursor) "This cursor image is displayed when the contains method for this component returns true for the current cursor location, and this Component is visible, displayable, and enabled" Thanks, Dmitry > > -- > best regards, > Anthony > >> >> Thanks, >> Dmitry >> >>> if the flag indicates we haven't yet sent an Entered event for this >>> window. The flag should be set/reset in the Entered/Exited mouse >>> handlers. >>> >>> We use this approach in FX and everyone seems to be happy about that. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 3/27/2012 12:08 PM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Does the Mac OS X contains a method that allows to find the topmost >>>> window under a mouse cursor? >>>> >>>> There is the issue when a window is created under a mouse cursor or >>>> it is moved under a mouse cursor the system does not generate the >>>> NSMouseEntered event. >>>> >>>> It is possible to synthetically generate the MouseEntered event >>>> for window creation and moving in Java because we need that a >>>> window behavior on Mac OS X was the same as on others platforms. >>>> But it is necessary to have a way to know is this window the >>>> topmost under a mouse cursor. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> >> From anthony.petrov at oracle.com Tue Mar 27 04:27:48 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 27 Mar 2012 15:27:48 +0400 Subject: Find the topmost window under a mouse cursor In-Reply-To: <4F71A356.9070009@oracle.com> References: <4F71758F.6050808@oracle.com> <4F7187CA.5030209@oracle.com> <4F71943C.1040606@oracle.com> <4F719519.2070105@oracle.com> <4F71A356.9070009@oracle.com> Message-ID: <4F71A434.1030701@oracle.com> On 3/27/2012 3:24 PM, Dmitry Cherepanov wrote: > Anthony Petrov wrote: >> On 3/27/2012 2:19 PM, Dmitry Cherepanov wrote: >>>> I suggest to track the MouseIsOver state with a boolean flag per >>>> window, and send a synthetic Entered event upon receiving any other >>>> mouse event (Moved, Clicked, etc.) >>> >>> We should probably synthesize such mouse enter/exit events upon >>> changing window's bounds. Synthesizing the mouse enter/exit event >>> upon receiving any other mouse event wouldn't changes the mouse >>> cursor until the user performs any mouse action. >> >> Is this exact behavior specified anywhere (i.e. that the cursor must >> be updated as soon as a component appears under the mouse even if the >> mouse holds still)? If not, I'd just state that the behavior is >> platform-specific. > > Looks like it's a part of the AWT specification: > > http://docs.oracle.com/javase/7/docs/api/java/awt/Component.html#setCursor(java.awt.Cursor) > > > "This cursor image is displayed when the contains method for this > component returns true for the current cursor location, and this > Component is visible, displayable, and enabled" The contains() method doesn't take into account if a component (or a window for that matter) is obscured by its siblings in the z-order. It seems that the spec needs to be clarified. As such, I'd suggest to specify that whether or not the cursor is updated instantly once the component becomes visible and appears right under the mouse cursor depends on the platform. Which is quite true. -- best regards, Anthony > > Thanks, > Dmitry > >> >> -- >> best regards, >> Anthony >> >>> >>> Thanks, >>> Dmitry >>> >>>> if the flag indicates we haven't yet sent an Entered event for this >>>> window. The flag should be set/reset in the Entered/Exited mouse >>>> handlers. >>>> >>>> We use this approach in FX and everyone seems to be happy about that. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 3/27/2012 12:08 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Does the Mac OS X contains a method that allows to find the topmost >>>>> window under a mouse cursor? >>>>> >>>>> There is the issue when a window is created under a mouse cursor or >>>>> it is moved under a mouse cursor the system does not generate the >>>>> NSMouseEntered event. >>>>> >>>>> It is possible to synthetically generate the MouseEntered event >>>>> for window creation and moving in Java because we need that a >>>>> window behavior on Mac OS X was the same as on others platforms. >>>>> But it is necessary to have a way to know is this window the >>>>> topmost under a mouse cursor. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>> >>> > From andrew.brygin at oracle.com Tue Mar 27 05:02:27 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Tue, 27 Mar 2012 16:02:27 +0400 Subject: [7u4] request for review: 7154047: [macosx]When we choose print one page in the print dialog,it still prints all the pages. Message-ID: <4F71AC53.30301@oracle.com> Hello, could you please review a small fix for CR 7154047? On macosx, the set of printing attributes does not contain a SunPageSelection attribute. Due to this, the shared code in RasterPrinterJob ignores PargeRanges attribute, that causes printing of all pages. Suggested fix just injects the SunPageSelection attribute into the set in order to force the shared code take the PargeRanges attribute into account. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154047 Webrev: http://cr.openjdk.java.net/~bae/7154047/webrev/ Thanks, Andrew From anthony.petrov at oracle.com Tue Mar 27 05:17:12 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 27 Mar 2012 16:17:12 +0400 Subject: [7u4] request for review: 7154047: [macosx]When we choose print one page in the print dialog,it still prints all the pages. In-Reply-To: <4F71AC53.30301@oracle.com> References: <4F71AC53.30301@oracle.com> Message-ID: <4F71AFC8.8040500@oracle.com> Hi Andrew, At line 160 there's a check of 'attributes' for null. I assume it may be null. So you should check it for null at line 150, too, to avoid an NPE. Looks good otherwise (though I'm not an expert in printing code). -- best regards, Anthony On 3/27/2012 4:02 PM, Andrew Brygin wrote: > Hello, > > could you please review a small fix for CR 7154047? > > On macosx, the set of printing attributes does not contain > a SunPageSelection attribute. Due to this, the shared code > in RasterPrinterJob ignores PargeRanges attribute, that causes > printing of all pages. > > Suggested fix just injects the SunPageSelection attribute into > the set in order to force the shared code take the PargeRanges > attribute into account. > > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154047 > Webrev: http://cr.openjdk.java.net/~bae/7154047/webrev/ > > Thanks, > Andrew From sergey.bylokhov at oracle.com Tue Mar 27 05:35:55 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 27 Mar 2012 16:35:55 +0400 Subject: [8] Request for review: 7125657 [macosx] SpreadSheet demo has the broken display when clicking outside of the table Message-ID: <4F71B42B.9070606@oracle.com> Hi Everyone, This is a forward port from jdk 7u4: http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/fab57f1dc2aa The general bug is that we repaint native part of the LWPanelPeer after UPDATE event. This is not mac specific bug, because we do the same things on XToolkit too. But this demo works there because XPanel.paintPeer is noop. Fox XToolkit new bug will be created. Note that testworks in MToolkit and WToolkit. 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 andrew.brygin at oracle.com Tue Mar 27 05:38:25 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Tue, 27 Mar 2012 16:38:25 +0400 Subject: [7u4] request for review: 7154047: [macosx]When we choose print one page in the print dialog,it still prints all the pages. In-Reply-To: <4F71AFC8.8040500@oracle.com> References: <4F71AC53.30301@oracle.com> <4F71AFC8.8040500@oracle.com> Message-ID: <4F71B4C1.7090609@oracle.com> Hi Anthony, thanks for the review. I have updated the fix with a check for null attributes set: http://cr.openjdk.java.net/~bae/7154047/webrev/ Thanks, Andrew On 27.03.2012 16:17, Anthony Petrov wrote: > Hi Andrew, > > At line 160 there's a check of 'attributes' for null. I assume it may > be null. So you should check it for null at line 150, too, to avoid an > NPE. Looks good otherwise (though I'm not an expert in printing code). > > -- > best regards, > Anthony > > On 3/27/2012 4:02 PM, Andrew Brygin wrote: >> Hello, >> >> could you please review a small fix for CR 7154047? >> >> On macosx, the set of printing attributes does not contain >> a SunPageSelection attribute. Due to this, the shared code >> in RasterPrinterJob ignores PargeRanges attribute, that causes >> printing of all pages. >> >> Suggested fix just injects the SunPageSelection attribute into >> the set in order to force the shared code take the PargeRanges >> attribute into account. >> >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154047 >> Webrev: http://cr.openjdk.java.net/~bae/7154047/webrev/ >> >> Thanks, >> Andrew From anthony.petrov at oracle.com Tue Mar 27 05:44:50 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 27 Mar 2012 16:44:50 +0400 Subject: [7u4] request for review: 7154047: [macosx]When we choose print one page in the print dialog,it still prints all the pages. In-Reply-To: <4F71B4C1.7090609@oracle.com> References: <4F71AC53.30301@oracle.com> <4F71AFC8.8040500@oracle.com> <4F71B4C1.7090609@oracle.com> Message-ID: <4F71B642.6040806@oracle.com> Looks great. -- best regards, Anthony On 3/27/2012 4:38 PM, Andrew Brygin wrote: > Hi Anthony, > > thanks for the review. I have updated the fix with a check for null > attributes set: > http://cr.openjdk.java.net/~bae/7154047/webrev/ > > Thanks, > Andrew > > On 27.03.2012 16:17, Anthony Petrov wrote: >> Hi Andrew, >> >> At line 160 there's a check of 'attributes' for null. I assume it may >> be null. So you should check it for null at line 150, too, to avoid an >> NPE. Looks good otherwise (though I'm not an expert in printing code). >> >> -- >> best regards, >> Anthony >> >> On 3/27/2012 4:02 PM, Andrew Brygin wrote: >>> Hello, >>> >>> could you please review a small fix for CR 7154047? >>> >>> On macosx, the set of printing attributes does not contain >>> a SunPageSelection attribute. Due to this, the shared code >>> in RasterPrinterJob ignores PargeRanges attribute, that causes >>> printing of all pages. >>> >>> Suggested fix just injects the SunPageSelection attribute into >>> the set in order to force the shared code take the PargeRanges >>> attribute into account. >>> >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154047 >>> Webrev: http://cr.openjdk.java.net/~bae/7154047/webrev/ >>> >>> Thanks, >>> Andrew > From anton.tarasov at oracle.com Tue Mar 27 06:20:03 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 27 Mar 2012 17:20:03 +0400 Subject: Request for review 7156191 [macosx] Can't type into applet demos in Pivot In-Reply-To: <4F707F1D.3080204@oracle.com> References: <4F707F1D.3080204@oracle.com> Message-ID: <4F71BE83.9030909@oracle.com> Hi Dmitry, Let me share my thoughts on it. We have two focus related callbacks: 1. handleWindowFocusEvent 2. handleFocusEvent The 1st one is called when the toplevel (browser) parent becomes active (focused), right? This doesn't yet mean the plugin itself should gain focus. However, from the method you call the following: 118 private void updateOverlayWindowActiveState() { 119 final boolean showAsFocused = parentWindowActive&& focused; 120 responder.handleWindowFocusEvent(showAsFocused); 121 } When focused==false the responder will initiate deactivation of the EmbeddedFrame which seems unrelated. I think we shouldn't call responder.handleWindowFocusEvent here at all. That's what the 2nd method is called for. It tells us the plug-in (EmbeddedFrame) itself gains/loses focus and here we can respond with calling handleWindowFocusEvent which in its turn will check the parentWindowActive==true condition. In case parentWindowActive==false && focused==true (is that possible?) I think we shouldn't activate the plug-in as well. Another question is whether handleFocusEvent(false) is called in response to deactivating the browser window by, say, alt-tab? I would expect the methods are called in the following order: handleFocusEvent(false) handleWindowFocusEvent(false) If that is true then what I suggested above should work if I got all that stuff right. What do you think? Thanks, Anton. On 26.03.2012 18:37, Dmitry Cherepanov wrote: > Hello, > > Here's a fix for 7156191 ([macosx] Can't type into applet demos in Pivot) > > The current implementation of focus event handlers in CEmbeddedFrame dispatches focus events > directly to the embedded frame. The fix changes the implementation and now it calls > peer.notifyActivation() like it's done in standalone mode. > > http://cr.openjdk.java.net/~dcherepanov/7156191/webrev.0/ > > Thanks, > Dmitry > From anton.tarasov at oracle.com Tue Mar 27 06:28:52 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 27 Mar 2012 17:28:52 +0400 Subject: Request for review 7156191 [macosx] Can't type into applet demos in Pivot In-Reply-To: <4F709169.70503@oracle.com> References: <4F707F1D.3080204@oracle.com> <4F708D34.7020708@oracle.com> <4F709169.70503@oracle.com> Message-ID: <4F71C094.30500@oracle.com> On 26.03.2012 19:55, Dmitry Cherepanov wrote: > Hi Artem, > > Artem Ananiev wrote: >> >> The fix looks fine. CEmbeddedFrame.updateOverlayWindowActiveState() JavaDoc may be corrected, >> though: does it still post a WINDOW_ACTIVATED event? > > I think that the comment is still valid. The code generates a WINDOW_ACTIVATED event when the > embedded frame becomes the active window. The comment is formally valid indeed, but for me it doesn't convey any meaningful info. The method initiates window activation or deactivation which means it will notify KFMPeer that the focused window has changed and will post WINDOW_GAINED_FOCUS or WINDOW_LOST_FOCUS. When the event gets dispatched by the shared KFM (asynchronously and deeply further) it will eventually generate WINDOW_ACTIVATED or WINDOW_DEACTIVATED. The comment mentions only one event from that chain of actions. Is it so important to document in this context? May be we should remove the comment at all? Thanks, Anton. > > Thanks, > Dmitry > >> >> Thanks, >> >> Artem >> >> On 3/26/2012 6:37 PM, Dmitry Cherepanov wrote: >>> Hello, >>> >>> Here's a fix for 7156191 ([macosx] Can't type into applet demos in Pivot) >>> >>> The current implementation of focus event handlers in CEmbeddedFrame >>> dispatches focus events directly to the embedded frame. The fix changes >>> the implementation and now it calls peer.notifyActivation() like it's >>> done in standalone mode. >>> >>> http://cr.openjdk.java.net/~dcherepanov/7156191/webrev.0/ >>> >>> Thanks, >>> Dmitry >>> > From artem.ananiev at oracle.com Tue Mar 27 07:01:52 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 27 Mar 2012 18:01:52 +0400 Subject: [8] Request for review: 7124551 [macosx] Once added, Menu shortcut cannot be removed In-Reply-To: <4F70AE53.6060204@oracle.com> References: <4F70AE53.6060204@oracle.com> Message-ID: <4F71C850.8000604@oracle.com> Looks fine. Thanks, Artem On 3/26/2012 9:58 PM, Sergey Bylokhov wrote: > Hi Everyone, > We should accept empty KeyEquivalent in case of shortcut removing. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124551 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124551/webrev.00/ > From michael.x.mcmahon at oracle.com Tue Mar 27 07:05:18 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 27 Mar 2012 15:05:18 +0100 Subject: RFR: 7134701 [macosx] Support legacy native library names Message-ID: <4F71C91E.8080604@oracle.com> JDK 8 fix for this issue. For readers not familiar with Mac OS, this is to fix an issue which Apple's JDK 6 supports, but we broke in the jdk 7 initial port. The preferred native library file suffix is .dylib on Mac, but some legacy libraries use the suffix .jnilib. Currently openjdk on mac does not recognise the .jnilib suffix. This change is to restore that behavior http://cr.openjdk.java.net/~michaelm/7134701/webrev.1/ If this change is accepted, we will look for approval to make the same change in 7u4. Thanks, Michael. From Alan.Bateman at oracle.com Tue Mar 27 07:47:22 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Mar 2012 15:47:22 +0100 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F71C91E.8080604@oracle.com> References: <4F71C91E.8080604@oracle.com> Message-ID: <4F71D2FA.9080502@oracle.com> On 27/03/2012 15:05, Michael McMahon wrote: > JDK 8 fix for this issue. For readers not familiar with Mac OS, this > is to > fix an issue which Apple's JDK 6 supports, but we broke in the jdk 7 > initial port. > The preferred native library file suffix is .dylib on Mac, but some > legacy libraries > use the suffix .jnilib. Currently openjdk on mac does not recognise > the .jnilib suffix. > > This change is to restore that behavior > > http://cr.openjdk.java.net/~michaelm/7134701/webrev.1/ > > If this change is accepted, we will look for approval to make the same > change in 7u4. Looks okay to me. Minor nit is that there are a couple of blank lines at the end of each ClassLoaderHelper. -Alan. From leonid.romanov at oracle.com Tue Mar 27 07:49:41 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 27 Mar 2012 18:49:41 +0400 Subject: [8] Request for review: 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField Message-ID: Hi, Please review a fix for 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField. This fix has already been pushed into 7u4. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124272 Webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-675/webrev.02/ Thanks, Leonid. From daniel.daugherty at oracle.com Tue Mar 27 08:03:02 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 27 Mar 2012 09:03:02 -0600 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F71C91E.8080604@oracle.com> References: <4F71C91E.8080604@oracle.com> Message-ID: <4F71D6A6.5050507@oracle.com> On 3/27/12 8:05 AM, Michael McMahon wrote: > JDK 8 fix for this issue. For readers not familiar with Mac OS, this > is to > fix an issue which Apple's JDK 6 supports, but we broke in the jdk 7 > initial port. > The preferred native library file suffix is .dylib on Mac, but some > legacy libraries > use the suffix .jnilib. Currently openjdk on mac does not recognise > the .jnilib suffix. > > This change is to restore that behavior > > http://cr.openjdk.java.net/~michaelm/7134701/webrev.1/ > > If this change is accepted, we will look for approval to make the same > change in 7u4. > > Thanks, > Michael. make/java/java/FILES_java.gmk Please update the copyright year to 2012. src/share/classes/java/lang/ClassLoader.java Please update the copyright year to 2012. The loadLibrary0() calls on lines 1826 and 1839 are not followed by the new alternate name retry. It looks like these two locations could benefit. src/macosx/classes/java/lang/ClassLoaderHelper.java No comments. src/solaris/classes/java/lang/ClassLoaderHelper.java No comments. src/windows/classes/java/lang/ClassLoaderHelper.java No comments. From anthony.petrov at oracle.com Tue Mar 27 09:07:43 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 27 Mar 2012 20:07:43 +0400 Subject: [8] Request for review: 7125657 [macosx] SpreadSheet demo has the broken display when clicking outside of the table In-Reply-To: <4F71B42B.9070606@oracle.com> References: <4F71B42B.9070606@oracle.com> Message-ID: <4F71E5CF.2050201@oracle.com> Looks good. -- best regards, Anthony On 3/27/2012 4:35 PM, Sergey Bylokhov wrote: > Hi Everyone, > This is a forward port from jdk 7u4: > http://hg.openjdk.java.net/jdk7u/jdk7u4-dev/jdk/rev/fab57f1dc2aa > > The general bug is that we repaint native part of the LWPanelPeer after > UPDATE event. This is not mac specific bug, because we do the same > things on XToolkit too. But this demo works there because > XPanel.paintPeer is noop. > > Fox XToolkit new bug will be created. Note that testworks in MToolkit > and WToolkit. > > 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/ > From stephen.bannasch at deanbrook.org Tue Mar 27 09:28:13 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Tue, 27 Mar 2012 12:28:13 -0400 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> <4F554C5B.6030309@oracle.com> <4F55EECC.4040206@oracle.com> <4F570538.1070104@oracle.com> <4F57899B.7050305@oracle.com> <4F57DF2B.7060804@oracle.com> Message-ID: At 6:31 PM -0500 3/7/12, Stephen Bannasch wrote: >At 10:20 PM +0000 3/7/12, Michael McMahon wrote: >>I've just realised there was a hotspot change in my local forest that I had forgotten about. >>Hotspot changes are pushed through a different route. So, I'm not sure when exactly this >>will get fixed. I will file a bug on it right now. But, here is the relevant patch, which you >>can apply yourself. >> >>- Michael, >> > >diff -r 0ed0960af27d src/os/bsd/vm/os_bsd.cpp >>--- a/src/os/bsd/vm/os_bsd.cpp Thu Feb 23 12:03:08 2012 -0800 >>+++ b/src/os/bsd/vm/os_bsd.cpp Wed Mar 07 22:14:09 2012 +0000 >>@@ -5811,7 +5811,7 @@ >> char buf[MAXPATHLEN]; >> char libmawtpath[MAXPATHLEN]; >> const char *xawtstr = "/xawt/libmawt" JNI_LIB_SUFFIX; > >- const char *new_xawtstr = "/libawt_xawt" JNI_LIB_SUFFIX; >>+ const char *new_xawtstr = "/xawt/libawt_xawt" JNI_LIB_SUFFIX; >> char *p; >> >> // Get path to libjvm.so > >Thanks, > >That fixed the problem running SwingSet2.jar FYI, building jdk8/tl today the problem with SwingSet2 jar is back: ./build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java -jar /Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar => $ Exception in thread "main" java.awt.HeadlessException at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) at SwingSet2.main(SwingSet2.java:251) I normally run these jtreg tests after a build: jdk/test/java/lang/invoke/ -- they all pass. More info on the build: .build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java -Xinternalversion OpenJDK 64-Bit Server VM (24.0-b02) for bsd-amd64 JRE (1.8.0-internal-stephen_2012_03_27_11_57-b00), built on Mar 27 2012 12:03:14 by "stephen" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6) From henri.gomez at gmail.com Tue Mar 27 10:53:39 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 27 Mar 2012 19:53:39 +0200 Subject: RFR: 7113349 JDK8 port to macosx In-Reply-To: References: <4F456320.60202@oracle.com> <4F4BF078.3030708@oracle.com> <4F4C160D.2030701@oracle.com> <4F4F90A9.5060306@oracle.com> <4F4FF0A7.2090505@oracle.com> <261BEB8B-465E-4934-AD88-ACECE6293AEA@oracle.com> <4F5092CC.1070805@oracle.com> <10AC78FA-BCBC-4A50-AA44-58D9E6F52B2E@oracle.com> <4F54E446.6010205@oracle.com> <4F554C5B.6030309@oracle.com> <4F55EECC.4040206@oracle.com> <4F570538.1070104@oracle.com> <4F57899B.7050305@oracle.com> <4F57DF2B.7060804@oracle.com> Message-ID: No problem here with build from jdk8/jdk8 or lambda/lambda OpenJDK 64-Bit Server VM (24.0-b04) for bsd-amd64 JRE (1.8.0-jdk8-b31-20120323), built on Mar 23 2012 09:54:32 by "henri" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) OpenJDK 64-Bit Server VM (24.0-b04) for bsd-amd64 JRE (1.8.0-jdk8-b30-20120326), built on Mar 26 2012 11:58:10 by "henri" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00) 2012/3/27 Stephen Bannasch : > At 6:31 PM -0500 3/7/12, Stephen Bannasch wrote: >>At 10:20 PM +0000 3/7/12, Michael McMahon wrote: >>>I've just realised there was a hotspot change in my local forest that I had forgotten about. >>>Hotspot changes are pushed through a different route. So, I'm not sure when exactly this >>>will get fixed. I will file a bug on it right now. But, here is the relevant patch, which you >>>can apply yourself. >>> >>>- Michael, >>> >> >diff -r 0ed0960af27d src/os/bsd/vm/os_bsd.cpp >>>--- a/src/os/bsd/vm/os_bsd.cpp ? ?Thu Feb 23 12:03:08 2012 -0800 >>>+++ b/src/os/bsd/vm/os_bsd.cpp ? ?Wed Mar 07 22:14:09 2012 +0000 >>>@@ -5811,7 +5811,7 @@ >>> ? ? char buf[MAXPATHLEN]; >>> ? ? char libmawtpath[MAXPATHLEN]; >>> ? ? const char *xawtstr ?= "/xawt/libmawt" JNI_LIB_SUFFIX; >> >- ? ?const char *new_xawtstr = "/libawt_xawt" JNI_LIB_SUFFIX; >>>+ ? ?const char *new_xawtstr = "/xawt/libawt_xawt" JNI_LIB_SUFFIX; >>> ? ? char *p; >>> >>> ? ? // Get path to libjvm.so >> >>Thanks, >> >>That fixed the problem running SwingSet2.jar > > FYI, building jdk8/tl today the problem with SwingSet2 jar is back: > > ./build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java -jar /Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar > > => > > $ Exception in thread "main" java.awt.HeadlessException > at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77) > at SwingSet2.main(SwingSet2.java:251) > > I normally run these jtreg tests after a build: jdk/test/java/lang/invoke/ -- they all pass. > > More info on the build: > > .build/macosx-amd64/j2sdk-bundle/1.8.0.jdk/Contents/Home/bin/java -Xinternalversion > > OpenJDK 64-Bit Server VM (24.0-b02) for bsd-amd64 JRE (1.8.0-internal-stephen_2012_03_27_11_57-b00), built on Mar 27 2012 12:03:14 by "stephen" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6) > > From michael.x.mcmahon at oracle.com Tue Mar 27 11:46:03 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 27 Mar 2012 19:46:03 +0100 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F71D6A6.5050507@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F71D6A6.5050507@oracle.com> Message-ID: <4F720AEB.7080106@oracle.com> On 27/03/12 16:03, Daniel D. Daugherty wrote: > On 3/27/12 8:05 AM, Michael McMahon wrote: >> JDK 8 fix for this issue. For readers not familiar with Mac OS, this >> is to >> fix an issue which Apple's JDK 6 supports, but we broke in the jdk 7 >> initial port. >> The preferred native library file suffix is .dylib on Mac, but some >> legacy libraries >> use the suffix .jnilib. Currently openjdk on mac does not recognise >> the .jnilib suffix. >> >> This change is to restore that behavior >> >> http://cr.openjdk.java.net/~michaelm/7134701/webrev.1/ >> >> If this change is accepted, we will look for approval to make the >> same change in 7u4. >> >> Thanks, >> Michael. > > make/java/java/FILES_java.gmk > Please update the copyright year to 2012. > > src/share/classes/java/lang/ClassLoader.java > Please update the copyright year to 2012. > > The loadLibrary0() calls on lines 1826 and 1839 are not followed > by the new alternate name retry. It looks like these two locations > could benefit. > > src/macosx/classes/java/lang/ClassLoaderHelper.java > No comments. > > src/solaris/classes/java/lang/ClassLoaderHelper.java > No comments. > > src/windows/classes/java/lang/ClassLoaderHelper.java > No comments. Dan, Thanks. Will update the copyright notices. The other loadLibrary0() calls you refer to weren't included in the original macosx work from Apple. So, I'm guessing they aren't in their JDK6 version. In any case, the first one is invoked when an absolute path is provided (including an explicit suffix). In that case we probably should not substitute alternate filenames. For the second case, I'd argue the same, since it is not the bootstrap classloader, and we are delegating to the classloader's findLibrary() method, which has to return a full absolute path as well. - Michael. From daniel.daugherty at oracle.com Tue Mar 27 11:57:28 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 27 Mar 2012 12:57:28 -0600 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F720AEB.7080106@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F71D6A6.5050507@oracle.com> <4F720AEB.7080106@oracle.com> Message-ID: <4F720D98.1020506@oracle.com> On 3/27/12 12:46 PM, Michael McMahon wrote: > On 27/03/12 16:03, Daniel D. Daugherty wrote: >> On 3/27/12 8:05 AM, Michael McMahon wrote: >>> JDK 8 fix for this issue. For readers not familiar with Mac OS, this >>> is to >>> fix an issue which Apple's JDK 6 supports, but we broke in the jdk 7 >>> initial port. >>> The preferred native library file suffix is .dylib on Mac, but some >>> legacy libraries >>> use the suffix .jnilib. Currently openjdk on mac does not recognise >>> the .jnilib suffix. >>> >>> This change is to restore that behavior >>> >>> http://cr.openjdk.java.net/~michaelm/7134701/webrev.1/ >>> >>> If this change is accepted, we will look for approval to make the >>> same change in 7u4. >>> >>> Thanks, >>> Michael. >> >> make/java/java/FILES_java.gmk >> Please update the copyright year to 2012. >> >> src/share/classes/java/lang/ClassLoader.java >> Please update the copyright year to 2012. >> >> The loadLibrary0() calls on lines 1826 and 1839 are not followed >> by the new alternate name retry. It looks like these two locations >> could benefit. >> >> src/macosx/classes/java/lang/ClassLoaderHelper.java >> No comments. >> >> src/solaris/classes/java/lang/ClassLoaderHelper.java >> No comments. >> >> src/windows/classes/java/lang/ClassLoaderHelper.java >> No comments. > Dan, > > Thanks. Will update the copyright notices. The other loadLibrary0() calls > you refer to weren't included in the original macosx work from Apple. > So, I'm guessing they aren't in their JDK6 version. > > In any case, the first one is invoked when an absolute path is provided > (including an explicit suffix). In that case we probably should not > substitute alternate filenames. For the second case, I'd argue the same, > since it is not the bootstrap classloader, and we are delegating to the > classloader's findLibrary() method, which has to return a full > absolute path as well. Sounds reasonable to me. Might be worth a comment or two so someone else doesn't wonder in a couple of years... Dan > > - Michael. From michael.x.mcmahon at oracle.com Tue Mar 27 14:23:56 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 27 Mar 2012 22:23:56 +0100 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F71C91E.8080604@oracle.com> References: <4F71C91E.8080604@oracle.com> Message-ID: <4F722FEC.1060309@oracle.com> Could I get the following webrev for 7u4 reviewed please? It is the same code change as for jdk 8 http://cr.openjdk.java.net/~michaelm/7134701/webrev.7u4.1/ Thanks, Michael. From daniel.daugherty at oracle.com Tue Mar 27 14:44:50 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 27 Mar 2012 15:44:50 -0600 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F722FEC.1060309@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F722FEC.1060309@oracle.com> Message-ID: <4F7234D2.1040800@oracle.com> On 3/27/12 3:23 PM, Michael McMahon wrote: > Could I get the following webrev for 7u4 reviewed please? > > It is the same code change as for jdk 8 > > http://cr.openjdk.java.net/~michaelm/7134701/webrev.7u4.1/ > > Thanks, > Michael. Thumbs up. Dan make/java/java/FILES_java.gmk src/share/classes/java/lang/ClassLoader.java src/macosx/classes/java/lang/ClassLoaderHelper.java src/solaris/classes/java/lang/ClassLoaderHelper.java src/windows/classes/java/lang/ClassLoaderHelper.java No comments. From david.holmes at oracle.com Tue Mar 27 19:06:41 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Mar 2012 12:06:41 +1000 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F71C91E.8080604@oracle.com> References: <4F71C91E.8080604@oracle.com> Message-ID: <4F727231.7070608@oracle.com> The change to look for the alternate library name looks good to me. I'm happy to see this handled in this way. I can't comment on whether there are any other cases where the alternate name should be considered. David On 28/03/2012 12:05 AM, Michael McMahon wrote: > JDK 8 fix for this issue. For readers not familiar with Mac OS, this is to > fix an issue which Apple's JDK 6 supports, but we broke in the jdk 7 > initial port. > The preferred native library file suffix is .dylib on Mac, but some > legacy libraries > use the suffix .jnilib. Currently openjdk on mac does not recognise the > .jnilib suffix. > > This change is to restore that behavior > > http://cr.openjdk.java.net/~michaelm/7134701/webrev.1/ > > If this change is accepted, we will look for approval to make the same > change in 7u4. > > Thanks, > Michael. From scott.kovatch at oracle.com Tue Mar 27 20:51:35 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 27 Mar 2012 23:51:35 -0400 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F720AEB.7080106@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F71D6A6.5050507@oracle.com> <4F720AEB.7080106@oracle.com> Message-ID: <12715007-AA8C-4C31-81E5-F7716C829E87@oracle.com> With this patch in place I can load the applet at Runescape.com now. I can't log in yet due to an AWT bug I probably haven't patched yet, but this is better than what it was. Minecraft.net is still giving me problems because it's bailing out before this change takes place. Here's the method in question: private static void doLoadLibrary(final String lib_name) { AccessController.doPrivileged(new PrivilegedAction() { public Object run() { String library_path = System.getProperty("org.lwjgl.librarypath"); if (library_path != null) { System.load(library_path + File.separator + System.mapLibraryName(lib_name)); } else { System.loadLibrary(lib_name); } return null; } }); } It's failing because System.mapLibraryName is constructing a library named liblwjgl.dylib, but lwjgl only has 'liblwjgl.jnilib'. Apple's JDK 6 (and I suspect macosx-port) gives me 'liblwjgl.jnilib' for System.mapLibraryName("lwjgl"). I can't even get this far with Apple's JDK 6 on minecraft.net, so it's hard to say this is a pure regression. I'm hesitant to suggest that we have mapLibraryName start returning a library named lib.jnilib at this point. Any ideas for a workaround? I think your ClassLoader/System change shown here should still go in, but in this particular case we still have problems. I don't know how much code is out there that uses mapLibraryName in this way. -- Scott On Mar 27, 2012, at 2:46 PM, Michael McMahon wrote: > On 27/03/12 16:03, Daniel D. Daugherty wrote: >> On 3/27/12 8:05 AM, Michael McMahon wrote: >>> JDK 8 fix for this issue. For readers not familiar with Mac OS, this is to >>> fix an issue which Apple's JDK 6 supports, but we broke in the jdk 7 initial port. >>> The preferred native library file suffix is .dylib on Mac, but some legacy libraries >>> use the suffix .jnilib. Currently openjdk on mac does not recognise the .jnilib suffix. >>> >>> This change is to restore that behavior >>> >>> http://cr.openjdk.java.net/~michaelm/7134701/webrev.1/ >>> >>> If this change is accepted, we will look for approval to make the same change in 7u4. >>> >>> Thanks, >>> Michael. >> >> make/java/java/FILES_java.gmk >> Please update the copyright year to 2012. >> >> src/share/classes/java/lang/ClassLoader.java >> Please update the copyright year to 2012. >> >> The loadLibrary0() calls on lines 1826 and 1839 are not followed >> by the new alternate name retry. It looks like these two locations >> could benefit. >> >> src/macosx/classes/java/lang/ClassLoaderHelper.java >> No comments. >> >> src/solaris/classes/java/lang/ClassLoaderHelper.java >> No comments. >> >> src/windows/classes/java/lang/ClassLoaderHelper.java >> No comments. > Dan, > > Thanks. Will update the copyright notices. The other loadLibrary0() calls > you refer to weren't included in the original macosx work from Apple. > So, I'm guessing they aren't in their JDK6 version. > > In any case, the first one is invoked when an absolute path is provided > (including an explicit suffix). In that case we probably should not > substitute alternate filenames. For the second case, I'd argue the same, > since it is not the bootstrap classloader, and we are delegating to the > classloader's findLibrary() method, which has to return a full absolute path as well. > > - Michael. From Alan.Bateman at oracle.com Wed Mar 28 00:27:30 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Mar 2012 08:27:30 +0100 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F722FEC.1060309@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F722FEC.1060309@oracle.com> Message-ID: <4F72BD62.3060508@oracle.com> On 27/03/2012 22:23, Michael McMahon wrote: > Could I get the following webrev for 7u4 reviewed please? > > It is the same code change as for jdk 8 > > http://cr.openjdk.java.net/~michaelm/7134701/webrev.7u4.1/ > > Thanks, > Michael. The change for 7u4 looks fine but you will need to get approval jdk7u-dev. A minor comment on the change-set pushed to 8 [1] is that the copyright date on ClassLoader.java no longer has the starting year. I assume that slipped in when addressing Dan's comment request to update the year. -Alan [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/396533b75ea0 From Alan.Bateman at oracle.com Wed Mar 28 00:40:58 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Mar 2012 08:40:58 +0100 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <12715007-AA8C-4C31-81E5-F7716C829E87@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F71D6A6.5050507@oracle.com> <4F720AEB.7080106@oracle.com> <12715007-AA8C-4C31-81E5-F7716C829E87@oracle.com> Message-ID: <4F72C08A.7000106@oracle.com> On 28/03/2012 04:51, Scott Kovatch wrote: > With this patch in place I can load the applet at Runescape.com now. I can't log in yet due to an AWT bug I probably haven't patched yet, but this is better than what it was. > > Minecraft.net is still giving me problems because it's bailing out before this change takes place. Here's the method in question: > > private static void doLoadLibrary(final String lib_name) { > AccessController.doPrivileged(new PrivilegedAction() { > public Object run() { > String library_path = System.getProperty("org.lwjgl.librarypath"); > if (library_path != null) { > System.load(library_path + File.separator + > System.mapLibraryName(lib_name)); > } else { > System.loadLibrary(lib_name); > } > return null; > } > }); > } > > It's failing because System.mapLibraryName is constructing a library named liblwjgl.dylib, but lwjgl only has 'liblwjgl.jnilib'. Apple's JDK 6 (and I suspect macosx-port) gives me 'liblwjgl.jnilib' for System.mapLibraryName("lwjgl"). > > I can't even get this far with Apple's JDK 6 on minecraft.net, so it's hard to say this is a pure regression. I'm hesitant to suggest that we have mapLibraryName start returning a library named lib.jnilib at this point. > > Any ideas for a workaround? I think your ClassLoader/System change shown here should still go in, but in this particular case we still have problems. I don't know how much code is out there that uses mapLibraryName in this way. > > -- Scott I just checked a Mac OSX 10.6.8 system with 6u29 installed and System.mapLibraryName("foo") returns foo.jnilib. Do you know if this was always the case? If so then I think there is an argument to be made that the default should be .jnilib and .dynlib be the fallback, especially if it's going to break anyone using mapLibraryName (my guess is that mapLibraryName usages are rare, at least compared to System.loadLibrary). -Alan From dmitry.cherepanov at oracle.com Wed Mar 28 00:48:35 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Wed, 28 Mar 2012 11:48:35 +0400 Subject: Request for review 7156191 [macosx] Can't type into applet demos in Pivot In-Reply-To: <4F71BE83.9030909@oracle.com> References: <4F707F1D.3080204@oracle.com> <4F71BE83.9030909@oracle.com> Message-ID: <4F72C253.3080007@oracle.com> Hi Anton, Anton V. Tarasov wrote: > Hi Dmitry, > > Let me share my thoughts on it. Thanks for your feedback! > Another question is whether handleFocusEvent(false) is called in > response to deactivating the browser window by, say, alt-tab? I would > expect the methods are called in the following order: > > handleFocusEvent(false) > handleWindowFocusEvent(false) Not exactly. The plugin receives the FocusChanged event when it gains/loses focus but it doesn't receive the event when the top-level window becomes the active (or inactive) window (by pressing alt-tab or mouse click). That is, if the user deactivates the browser and then activates it back by pressing alt-tab twice, we receive the following events: WindowFocusChanged(false) WindowFocusChanged(true) That means we still need to activate/deactivate the embedded frame upon receiving the WindowFocusChanged event if the plugin gained focus before. Indeed, we shouldn't activate/deactivate the embedded frame when the plugin doesn't have focus. I've updated the implementation of the updateOverlayWindowActiveState method: if (focused) { responder.handleWindowFocusEvent(parentWindowActive); } Does it make sense? I've verified that the modified change fixes the bug and I haven't found any regression. Thanks again, Dmitry From tobi at ultramixer.com Wed Mar 28 01:34:20 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 28 Mar 2012 10:34:20 +0200 Subject: Oracle Licence and Apple AppStore violation Message-ID: Hi Mike, I just read the Oracle licence for JavaSE and noticed that you are not allowed to modify the redistributable. The problem is: When you want to bundle the OpenJDK7 inside your mac app to submit to the AppStore you have to modify the JRE...stripping out PPC code....signing...and so on. So in my opinion there is no legal way to use the new OpenJDK7 for bundled mac applications :)? Best regards, Tobi From neugens.limasoftware at gmail.com Wed Mar 28 02:30:45 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 28 Mar 2012 11:30:45 +0200 Subject: Oracle Licence and Apple AppStore violation In-Reply-To: References: Message-ID: 2012/3/28 Tobias Bley : > Hi Mike, > > I just read the Oracle licence for JavaSE and noticed that you are not allowed to modify the redistributable. The problem is: When you want to bundle the OpenJDK7 inside your mac app to submit to the AppStore you have to modify the JRE...stripping out PPC code....signing...and so on. > > So in my opinion there is no legal way to use the new OpenJDK7 for bundled mac applications :)? > > Best regards, > Tobi Hi Tobi, IANAL, but I think you're confusing OpenJDK with Oracle JDK here. *OpenJDK* is GPL code (+ Classpath exception, which is an important detail), you are permitted to do any modification you feel necessary as soon as you respect the license. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA? FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From andrew.brygin at oracle.com Wed Mar 28 02:47:36 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 28 Mar 2012 13:47:36 +0400 Subject: [7u4] Request for phase 2 approval for CR 7154047 - [macosx] When we choose print one page in the print dialog, it still prints all the pages. Message-ID: <4F72DE38.4060907@oracle.com> CR: http://bugs.sun.com/view_bug.do?bug_id=7154047 Webrev: http://cr.openjdk.java.net/~bae/7154047/webrev Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003731.html Reviewers: Anthony Petrov Rationale for inclusion in 7u4: recently discovered JCK failure. Thanks, Andrew From michael.x.mcmahon at oracle.com Wed Mar 28 02:52:57 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 28 Mar 2012 10:52:57 +0100 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F72C08A.7000106@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F71D6A6.5050507@oracle.com> <4F720AEB.7080106@oracle.com> <12715007-AA8C-4C31-81E5-F7716C829E87@oracle.com> <4F72C08A.7000106@oracle.com> Message-ID: <4F72DF79.5080907@oracle.com> On 28/03/12 08:40, Alan Bateman wrote: > On 28/03/2012 04:51, Scott Kovatch wrote: >> With this patch in place I can load the applet at Runescape.com now. >> I can't log in yet due to an AWT bug I probably haven't patched yet, >> but this is better than what it was. >> >> Minecraft.net is still giving me problems because it's bailing out >> before this change takes place. Here's the method in question: >> >> private static void doLoadLibrary(final String lib_name) { >> AccessController.doPrivileged(new PrivilegedAction() { >> public Object run() { >> String library_path = >> System.getProperty("org.lwjgl.librarypath"); >> if (library_path != null) { >> System.load(library_path + File.separator + >> System.mapLibraryName(lib_name)); >> } else { >> System.loadLibrary(lib_name); >> } >> return null; >> } >> }); >> } >> >> It's failing because System.mapLibraryName is constructing a library >> named liblwjgl.dylib, but lwjgl only has 'liblwjgl.jnilib'. Apple's >> JDK 6 (and I suspect macosx-port) gives me 'liblwjgl.jnilib' for >> System.mapLibraryName("lwjgl"). >> >> I can't even get this far with Apple's JDK 6 on minecraft.net, so >> it's hard to say this is a pure regression. I'm hesitant to suggest >> that we have mapLibraryName start returning a library named >> lib.jnilib at this point. >> >> Any ideas for a workaround? I think your ClassLoader/System change >> shown here should still go in, but in this particular case we still >> have problems. I don't know how much code is out there that uses >> mapLibraryName in this way. >> >> -- Scott > I just checked a Mac OSX 10.6.8 system with 6u29 installed and > System.mapLibraryName("foo") returns foo.jnilib. Do you know if this > was always the case? If so then I think there is an argument to be > made that the default should be .jnilib and .dynlib be the fallback, > especially if it's going to break anyone using mapLibraryName (my > guess is that mapLibraryName usages are rare, at least compared to > System.loadLibrary). > > -Alan > > > Maybe, we should be doing what Dan Daugherty suggested yesterday and re-mapping the native filename in the case where a full absolute path is passed in (which is the code-path when System.load() is called above) My reasoning (for rejecting that) was that an absolute path is a request for an explicit name eg. System.load("/abs/path/libfoo.dylib") and it seems odd to go modifying the path that the user provided (as opposed to the System.loadLibrary("foo") case, where we have to construct the path internally). But, I hadn't considered the case above where the path is constructed by calling System.mapLibraryName(). So, I think a better approach might be to just to check for the old ".jnilib" suffix in all the cases, rather than changing System.mapLibraryName(). Otherwise, we'll have an inconsistency forever more between the output of that method and the library suffix that we want people to use. I've attached the jdk8 diffs for doing this. - Michael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diffs Url: http://mail.openjdk.java.net/pipermail/macosx-port-dev/attachments/20120328/60347f61/diffs.ksh From tobi at ultramixer.com Wed Mar 28 03:04:37 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 28 Mar 2012 12:04:37 +0200 Subject: Oracle Licence and Apple AppStore violation In-Reply-To: References: Message-ID: Hi Mario, oh I know, but what's about an redistributable JRE? Tobi Am 28.03.2012 um 11:30 schrieb Mario Torre : > 2012/3/28 Tobias Bley : >> Hi Mike, >> >> I just read the Oracle licence for JavaSE and noticed that you are not allowed to modify the redistributable. The problem is: When you want to bundle the OpenJDK7 inside your mac app to submit to the AppStore you have to modify the JRE...stripping out PPC code....signing...and so on. >> >> So in my opinion there is no legal way to use the new OpenJDK7 for bundled mac applications :)? >> >> Best regards, >> Tobi > > Hi Tobi, > > IANAL, but I think you're confusing OpenJDK with Oracle JDK here. > *OpenJDK* is GPL code (+ Classpath exception, which is an important > detail), you are permitted to do any modification you feel necessary > as soon as you respect the license. > > Cheers, > Mario > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From anton.tarasov at oracle.com Wed Mar 28 03:09:48 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 28 Mar 2012 14:09:48 +0400 Subject: Request for review 7156191 [macosx] Can't type into applet demos in Pivot In-Reply-To: <4F72C253.3080007@oracle.com> References: <4F707F1D.3080204@oracle.com> <4F71BE83.9030909@oracle.com> <4F72C253.3080007@oracle.com> Message-ID: <4F72E36C.9060105@oracle.com> Hi Dmitry, On 28.03.2012 11:48, Dmitry Cherepanov wrote: > Hi Anton, > > Anton V. Tarasov wrote: >> Hi Dmitry, >> >> Let me share my thoughts on it. > > Thanks for your feedback! > >> Another question is whether handleFocusEvent(false) is called in response to deactivating the >> browser window by, say, alt-tab? I would expect the methods are called in the following order: >> >> handleFocusEvent(false) >> handleWindowFocusEvent(false) > > Not exactly. The plugin receives the FocusChanged event when it gains/loses focus but it doesn't > receive the event when the top-level window becomes the active (or inactive) window (by pressing > alt-tab or mouse click). That is, if the user deactivates the browser and then activates it back > by pressing alt-tab twice, we receive the following events: > > WindowFocusChanged(false) > WindowFocusChanged(true) > > That means we still need to activate/deactivate the embedded frame upon receiving the > WindowFocusChanged event if the plugin gained focus before. Oh, that is surprising... Ok, let it be so then. > > Indeed, we shouldn't activate/deactivate the embedded frame when the plugin doesn't have focus. > I've updated the implementation of the updateOverlayWindowActiveState method: > > if (focused) { > responder.handleWindowFocusEvent(parentWindowActive); > } > > Does it make sense? I've verified that the modified change fixes the bug and I haven't found any > regression. This works for handleWindowFocusEvent(boolean parentWindowActive), but what about switching focus somewhere inside the browser but outside the plugin? 100 public void handleFocusEvent(boolean focused) { 101 this.focused = focused; 102 updateOverlayWindowActiveState(); 103 } This will call updateOverlayWindowActiveState() where focused==false and so the EmbeddedFrame won't be notified about deactivation. Also, is it possible to have handleFocusEvent(true) called when the browser is inactive? If so, the EmbeddedFrame will receive unrelated notification. Did I get it right? Thanks, Anton. > > Thanks again, > Dmitry > From dmitry.cherepanov at oracle.com Wed Mar 28 03:53:54 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Wed, 28 Mar 2012 14:53:54 +0400 Subject: Request for review 7156191 [macosx] Can't type into applet demos in Pivot In-Reply-To: <4F72E36C.9060105@oracle.com> References: <4F707F1D.3080204@oracle.com> <4F71BE83.9030909@oracle.com> <4F72C253.3080007@oracle.com> <4F72E36C.9060105@oracle.com> Message-ID: <4F72EDC2.4080003@oracle.com> Anton V. Tarasov wrote: > This works for handleWindowFocusEvent(boolean parentWindowActive), but > what about switching focus somewhere inside the browser but outside > the plugin? > > 100 public void handleFocusEvent(boolean focused) { > 101 this.focused = focused; > 102 updateOverlayWindowActiveState(); > 103 } > > > > This will call updateOverlayWindowActiveState() where focused==false > and so the EmbeddedFrame won't be notified about deactivation. > > Also, is it possible to have handleFocusEvent(true) called when the > browser is inactive? If so, the EmbeddedFrame will receive unrelated > notification. > > Did I get it right? You're right. Here's the new version of the fix: http://cr.openjdk.java.net/~dcherepanov/7156191/webrev.1/ I hope that this addresses your concerns. Thanks, Dmitry From stephen.bannasch at deanbrook.org Wed Mar 28 04:57:20 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 28 Mar 2012 07:57:20 -0400 Subject: Oracle Licence and Apple AppStore violation In-Reply-To: References: Message-ID: At 12:04 PM +0200 3/28/12, Tobias Bley wrote: >Hi Mario, > >oh I know, but what's about an redistributable JRE? You have to build it yourself with the OpenJDK code. Oaracle's licensing prevents you from re-distributing or modifying a JRE/JDK from Oracle. From anton.tarasov at oracle.com Wed Mar 28 09:24:08 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 28 Mar 2012 20:24:08 +0400 Subject: Request for review 7156191 [macosx] Can't type into applet demos in Pivot In-Reply-To: <4F72EDC2.4080003@oracle.com> References: <4F707F1D.3080204@oracle.com> <4F71BE83.9030909@oracle.com> <4F72C253.3080007@oracle.com> <4F72E36C.9060105@oracle.com> <4F72EDC2.4080003@oracle.com> Message-ID: <4F733B28.50005@oracle.com> Now it looks fine for me. Thanks! Anton. On 3/28/12 2:53 PM, Dmitry Cherepanov wrote: > Anton V. Tarasov wrote: >> This works for handleWindowFocusEvent(boolean parentWindowActive), >> but what about switching focus somewhere inside the browser but >> outside the plugin? >> >> 100 public void handleFocusEvent(boolean focused) { >> 101 this.focused = focused; >> 102 updateOverlayWindowActiveState(); >> 103 } >> >> >> >> This will call updateOverlayWindowActiveState() where focused==false >> and so the EmbeddedFrame won't be notified about deactivation. >> >> Also, is it possible to have handleFocusEvent(true) called when the >> browser is inactive? If so, the EmbeddedFrame will receive unrelated >> notification. >> >> Did I get it right? > > You're right. Here's the new version of the fix: > > http://cr.openjdk.java.net/~dcherepanov/7156191/webrev.1/ > > I hope that this addresses your concerns. > > Thanks, > Dmitry > > From scott.kovatch at oracle.com Wed Mar 28 05:35:03 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 28 Mar 2012 08:35:03 -0400 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F72DF79.5080907@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F71D6A6.5050507@oracle.com> <4F720AEB.7080106@oracle.com> <12715007-AA8C-4C31-81E5-F7716C829E87@oracle.com> <4F72C08A.7000106@oracle.com> <4F72DF79.5080907@oracle.com> Message-ID: On Mar 28, 2012, at 5:52 AM, Michael McMahon wrote: > On 28/03/12 08:40, Alan Bateman wrote: >> I just checked a Mac OSX 10.6.8 system with 6u29 installed and System.mapLibraryName("foo") returns foo.jnilib. Do you know if this was always the case? If so then I think there is an argument to be made that the default should be .jnilib and .dynlib be the fallback, especially if it's going to break anyone using mapLibraryName (my guess is that mapLibraryName usages are rare, at least compared to System.loadLibrary). I don't know this for certain, but I suspect it's been that way for a long time. > Maybe, we should be doing what Dan Daugherty suggested yesterday and re-mapping the native > filename in the case where a full absolute path is passed in (which is the code-path > when System.load() is called above) > > My reasoning (for rejecting that) was that an absolute path is a request for an explicit name > eg. System.load("/abs/path/libfoo.dylib") and it seems odd to go modifying the path that > the user provided (as opposed to the System.loadLibrary("foo") case, where we have to > construct the path internally). But, I hadn't considered the case above where the path > is constructed by calling System.mapLibraryName(). > > So, I think a better approach might be to just to check for the old ".jnilib" suffix in all > the cases, rather than changing System.mapLibraryName(). Otherwise, we'll have an inconsistency > forever more between the output of that method and the library suffix that we want people > to use. > > I've attached the jdk8 diffs for doing this. Thanks! I'll give it a try this morning. I have a couple of JNLP-based apps that were hitting this, too, so I'll do some extra testing. -- Scott From Fabrizio.Giudici at tidalwave.it Wed Mar 28 05:52:09 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Wed, 28 Mar 2012 14:52:09 +0200 Subject: Oracle Licence and Apple AppStore violation In-Reply-To: References: Message-ID: On Wed, 28 Mar 2012 13:57:20 +0200, Stephen Bannasch wrote: > At 12:04 PM +0200 3/28/12, Tobias Bley wrote: >> Hi Mario, >> >> oh I know, but what's about an redistributable JRE? > > You have to build it yourself with the OpenJDK code. > > Oaracle's licensing prevents you from re-distributing or modifying a > JRE/JDK from Oracle. I think that you can also just take the OpenJDK binaries, manipulate them (e.g. you were talking of stripping PPC code) and redistribute (together with the code - e.g. a script - that you used to do the manipulation). I mean, in function of what you need, you don't necessarily have to rebuild from sources. The important thing is that the modified JRE is redistributed as a separate artifact under the GPL+CPE license. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." fabrizio.giudici at tidalwave.it http://tidalwave.it - http://fabriziogiudici.it From dmitry.cherepanov at oracle.com Wed Mar 28 06:18:59 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Wed, 28 Mar 2012 17:18:59 +0400 Subject: [7u6] Request for approval for 7156194: [macosx] Can't type non-ASCII characters into applets Message-ID: <4F730FC3.8000702@oracle.com> This is a request to push the following fix to jdk7u-dev: Bug: 7156194 "[macosx] Can't type non-ASCII characters into applets" Webrev: http://cr.openjdk.java.net/~dcherepanov/7156194/webrev.1/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003711.html Thanks, Dmitry From daniel.daugherty at oracle.com Wed Mar 28 07:42:29 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 28 Mar 2012 08:42:29 -0600 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F72DF79.5080907@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F71D6A6.5050507@oracle.com> <4F720AEB.7080106@oracle.com> <12715007-AA8C-4C31-81E5-F7716C829E87@oracle.com> <4F72C08A.7000106@oracle.com> <4F72DF79.5080907@oracle.com> Message-ID: <4F732355.3060905@oracle.com> On 3/28/12 3:52 AM, Michael McMahon wrote: > On 28/03/12 08:40, Alan Bateman wrote: >> On 28/03/2012 04:51, Scott Kovatch wrote: >>> With this patch in place I can load the applet at Runescape.com now. >>> I can't log in yet due to an AWT bug I probably haven't patched yet, >>> but this is better than what it was. >>> >>> Minecraft.net is still giving me problems because it's bailing out >>> before this change takes place. Here's the method in question: >>> >>> private static void doLoadLibrary(final String lib_name) { >>> AccessController.doPrivileged(new PrivilegedAction() { >>> public Object run() { >>> String library_path = >>> System.getProperty("org.lwjgl.librarypath"); >>> if (library_path != null) { >>> System.load(library_path + File.separator + >>> System.mapLibraryName(lib_name)); >>> } else { >>> System.loadLibrary(lib_name); >>> } >>> return null; >>> } >>> }); >>> } >>> >>> It's failing because System.mapLibraryName is constructing a library >>> named liblwjgl.dylib, but lwjgl only has 'liblwjgl.jnilib'. Apple's >>> JDK 6 (and I suspect macosx-port) gives me 'liblwjgl.jnilib' for >>> System.mapLibraryName("lwjgl"). >>> >>> I can't even get this far with Apple's JDK 6 on minecraft.net, so >>> it's hard to say this is a pure regression. I'm hesitant to suggest >>> that we have mapLibraryName start returning a library named >>> lib.jnilib at this point. >>> >>> Any ideas for a workaround? I think your ClassLoader/System change >>> shown here should still go in, but in this particular case we still >>> have problems. I don't know how much code is out there that uses >>> mapLibraryName in this way. >>> >>> -- Scott >> I just checked a Mac OSX 10.6.8 system with 6u29 installed and >> System.mapLibraryName("foo") returns foo.jnilib. Do you know if this >> was always the case? If so then I think there is an argument to be >> made that the default should be .jnilib and .dynlib be the fallback, >> especially if it's going to break anyone using mapLibraryName (my >> guess is that mapLibraryName usages are rare, at least compared to >> System.loadLibrary). >> >> -Alan >> >> >> > Maybe, we should be doing what Dan Daugherty suggested yesterday and > re-mapping the native > filename in the case where a full absolute path is passed in (which is > the code-path > when System.load() is called above) > > My reasoning (for rejecting that) was that an absolute path is a > request for an explicit name > eg. System.load("/abs/path/libfoo.dylib") and it seems odd to go > modifying the path that > the user provided (as opposed to the System.loadLibrary("foo") case, > where we have to > construct the path internally). But, I hadn't considered the case > above where the path > is constructed by calling System.mapLibraryName(). > > So, I think a better approach might be to just to check for the old > ".jnilib" suffix in all > the cases, rather than changing System.mapLibraryName(). Otherwise, > we'll have an inconsistency > forever more between the output of that method and the library suffix > that we want people > to use. > > I've attached the jdk8 diffs for doing this. > > - Michael This difference caught my eye: + File libfile = new File(name); and + final File libfile = ClassLoaderHelper.mapAlternativeName(file); Not a big deal, but it wasn't clear to me why you used 'final' for the second libfile and not the first one... Dan From edvard.wendelin at oracle.com Wed Mar 28 08:49:16 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 28 Mar 2012 08:49:16 -0700 Subject: [7u6] Request for approval for 7156194: [macosx] Can't type non-ASCII characters into applets In-Reply-To: <4F730FC3.8000702@oracle.com> References: <4F730FC3.8000702@oracle.com> Message-ID: Approved. On Mar 28, 2012, at 6:18 AM, Dmitry Cherepanov wrote: > This is a request to push the following fix to jdk7u-dev: > > Bug: 7156194 "[macosx] Can't type non-ASCII characters into applets" > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7156194/webrev.1/ > > Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003711.html > > Thanks, > Dmitry > From edvard.wendelin at oracle.com Wed Mar 28 08:49:41 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 28 Mar 2012 08:49:41 -0700 Subject: [7u4] Request for phase 2 approval for CR 7154047 - [macosx] When we choose print one page in the print dialog, it still prints all the pages. In-Reply-To: <4F72DE38.4060907@oracle.com> References: <4F72DE38.4060907@oracle.com> Message-ID: <6A70A801-4436-4D5A-8EF5-FEBE3374D3C4@oracle.com> Approved. On Mar 28, 2012, at 2:47 AM, Andrew Brygin wrote: > CR: http://bugs.sun.com/view_bug.do?bug_id=7154047 > Webrev: http://cr.openjdk.java.net/~bae/7154047/webrev > Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003731.html > > Reviewers: Anthony Petrov > Rationale for inclusion in 7u4: recently discovered JCK failure. > > Thanks, > Andrew From dmitry.cherepanov at oracle.com Wed Mar 28 09:02:20 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Wed, 28 Mar 2012 20:02:20 +0400 Subject: [7u6] Request for approval for 7156191: [macosx] Can't type into applet demos in Pivot Message-ID: <4F73360C.70805@oracle.com> This is a request to push the following fix to jdk7u-dev: Bug: 7156191 "[macosx] Can't type into applet demos in Pivot" Webrev: http://cr.openjdk.java.net/~dcherepanov/7156191/webrev.1/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003712.html Thanks, Dmitry From sergey.bylokhov at oracle.com Wed Mar 28 09:05:23 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 28 Mar 2012 20:05:23 +0400 Subject: [8] Request for review: 7150100 [macosx] "0123456789" is selected in the TextField. Message-ID: <4F7336C3.80907@oracle.com> Hi Everyone, Two issues resolved: 1) We should set caret position before the text selection. 2) On macosx we clear selection when the test component lost its focus, so test was simplified and instructions dialog was removed (because sometimes it steal the focus from the text component) Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150100 ** Webrev can be found at: http://cr.openjdk.java.net/~serb/7150100/webrev.00/ -- Best regards, Sergey. From swingler at apple.com Wed Mar 28 09:18:28 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 28 Mar 2012 09:18:28 -0700 Subject: [8] Request for review: 7150100 [macosx] "0123456789" is selected in the TextField. In-Reply-To: <4F7336C3.80907@oracle.com> References: <4F7336C3.80907@oracle.com> Message-ID: On Mar 28, 2012, at 9:05 AM, Sergey Bylokhov wrote: > Hi Everyone, > Two issues resolved: > 1) We should set caret position before the text selection. > 2) On macosx we clear selection when the test component lost its focus, so test was simplified and instructions dialog was removed (because sometimes it steal the focus from the text component) > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150100 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7150100/webrev.00/ Does this change the behavior of where the cursor ends up if you press the left or right keys while there is a selection? We get this wrong in Java SE 6, and I was wondering if this corrects that behavior. Regards, Mike Swingler Apple Inc. From edvard.wendelin at oracle.com Wed Mar 28 10:21:19 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 28 Mar 2012 10:21:19 -0700 Subject: [7u6] Request for approval for 7156191: [macosx] Can't type into applet demos in Pivot In-Reply-To: <4F73360C.70805@oracle.com> References: <4F73360C.70805@oracle.com> Message-ID: Approved. On Mar 28, 2012, at 9:02 AM, Dmitry Cherepanov wrote: > This is a request to push the following fix to jdk7u-dev: > > Bug: 7156191 "[macosx] Can't type into applet demos in Pivot" > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7156191/webrev.1/ > > Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003712.html > > Thanks, > Dmitry > From jcpalmer at rochester.rr.com Wed Mar 28 12:56:40 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Wed, 28 Mar 2012 15:56:40 -0400 Subject: Oracle Licence and Apple AppStore violation In-Reply-To: Message-ID: This reminds me of problems XMLVM had with OpenJDK and the iOS store. I do not know if the mac store will be the same, but I looked over a whole set of message from a year ago & here was their problem (I am grabbing some stuff from others & I am not a lawyer): - iOS store requires static linking. - The freedoms that come with the lgpl apply to anyone, not just the devs. anyone must have the ability to exchange the lgpl portion of an app with a newer version. Even if the mac store does not require static linking, if the second bullet is really true, what does that mean for bundling? I am using JWS, due to the distributed nature of my application (interdependent code / db across desktop, server, android). Bundling would mean large bandwidth requirements during upgrade, that would not be scalable. Tiny little XMLVM just punted by switching to Harmony, but that is not going to be possible here. On 3/28/12 4:34 AM, "Tobias Bley" wrote: > Hi Mike, > > I just read the Oracle licence for JavaSE and noticed that you are not allowed > to modify the redistributable. The problem is: When you want to bundle the > OpenJDK7 inside your mac app to submit to the AppStore you have to modify the > JRE...stripping out PPC code....signing...and so on. > > So in my opinion there is no legal way to use the new OpenJDK7 for bundled mac > applications :)? > > Best regards, > Tobi > > > > > > From michael.x.mcmahon at oracle.com Thu Mar 29 03:25:37 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 29 Mar 2012 11:25:37 +0100 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F722FEC.1060309@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F722FEC.1060309@oracle.com> Message-ID: <4F7438A1.4090407@oracle.com> On 27/03/12 22:23, Michael McMahon wrote: > Could I get the following webrev for 7u4 reviewed please? > > It is the same code change as for jdk 8 > > http://cr.openjdk.java.net/~michaelm/7134701/webrev.7u4.1/ > > Thanks, > Michael. I've updated the webrev for this 7u4 change, based on the testing yesterday. It simplifies the original jdk 8 change (which will be updated via CR 7157665) So, if an attempt to load a library whose name is X.dylib fails we retry with the name X.jnilib The following examples show the main cases: System.loadLibrary("foo") -> libfoo.dylib, then libfoo.jnilib (tried in each directory of the boot library path and user library path respectively) System.load("/abs/path/libfoo.dylib") -> /abs/path/libfoo.dylib, then /abs/path/libfoo.jnilib System.load("/abs/path/libfoo.jnilib") -> /abs/path/libfoo.jnilib System.load("/abs/path/libfoo.bar") -> /abs/path/libfoo.bar System.mapLibraryName("foo") -> "libfoo.dylib" As before, this change only affects the behavior on Mac OS X. http://cr.openjdk.java.net/~michaelm/7134701/webrev.7u4.2/ Thanks, Michael From sergey.bylokhov at oracle.com Thu Mar 29 04:56:15 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 29 Mar 2012 15:56:15 +0400 Subject: [8] Request for review: 7150100 [macosx] "0123456789" is selected in the TextField. In-Reply-To: References: <4F7336C3.80907@oracle.com> Message-ID: <4F744DDF.1050905@oracle.com> Hi Mike. 28.03.2012 20:18, Mike Swingler wrote: > Does this change the behavior of where the cursor ends up if you press > the left or right keys while there is a selection? We get this wrong > in Java SE 6, and I was wondering if this corrects that behavior. > Regards, Mike Swingler Apple Inc. No. Initial selected text in TextArea/TextField was fixed only(now it works in the same way as in swing). Feel free to file some jdk6 issues in jdk7 database if applicable. -- Best regards, Sergey. From leonid.romanov at oracle.com Thu Mar 29 05:25:09 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 29 Mar 2012 16:25:09 +0400 Subject: [8] Review request for 7124411: [macosx] There's no KEY_TYPED for VK_ESCAPE Message-ID: Hi, Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124411 webrev: http://cr.openjdk.java.net/~leonidr/7124411/webrev.00/ Thanks, Leonid. From artem.ananiev at oracle.com Thu Mar 29 05:31:39 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 29 Mar 2012 16:31:39 +0400 Subject: [8] Request for review: 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField In-Reply-To: References: Message-ID: <4F74562B.5040702@oracle.com> Hi, Leonid, a general question, not tightly related to the fix. Why do we want to generate KEY_TYPED events from Java? Do we receive such events from the native platform? Probably, not, because I see the following method in AWTEvent.m: static void DeliverKeyTypedEvents(JNIEnv *env, NSEvent *nsEvent, jobject peer) but it is not called from anywhere. Should it be deleted, or reused, or what? Thanks, Artem On 3/27/2012 6:49 PM, Leonid Romanov wrote: > Hi, > Please review a fix for 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField. This fix has already been pushed into 7u4. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124272 > Webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-675/webrev.02/ > > Thanks, > Leonid. > > From leonid.romanov at oracle.com Thu Mar 29 05:51:17 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 29 Mar 2012 16:51:17 +0400 Subject: [8] Request for review: 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField In-Reply-To: <4F74562B.5040702@oracle.com> References: <4F74562B.5040702@oracle.com> Message-ID: <6F7AD1B3-C3CF-4A61-8AA4-779AAFD43635@oracle.com> Yes, you are right in your guess: OS X doesn't generate any kind of "key typed" events, this is why we have to do it manually. As for the dead code in AWTEvent.m, the answer is again yes, it could use some cleaning. Perhaps a separate low priority bug could be filled. On 29.03.2012, at 16:31, Artem Ananiev wrote: > Hi, Leonid, > > a general question, not tightly related to the fix. Why do we want to generate KEY_TYPED events from Java? Do we receive such events from the native platform? Probably, not, because I see the following method in AWTEvent.m: > > static void > DeliverKeyTypedEvents(JNIEnv *env, NSEvent *nsEvent, jobject peer) > > but it is not called from anywhere. Should it be deleted, or reused, or what? > > Thanks, > > Artem > > On 3/27/2012 6:49 PM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField. This fix has already been pushed into 7u4. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124272 >> Webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-675/webrev.02/ >> >> Thanks, >> Leonid. >> >> From leonid.romanov at oracle.com Thu Mar 29 06:50:22 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 29 Mar 2012 17:50:22 +0400 Subject: Q: how to display menu accelerators Message-ID: <7F92F03F-B3CD-4A7F-8E80-4B5711EB99B8@oracle.com> Hi, Currently we display menu accelerators (that is, keyboard modifiers one needs to press in order to invoke menu command via keystroke) as "Control", "Alt" and "Meta" text strings. This is obviously not right. However, I'm not sure what is the correct solution here: Apple has these funky symbols that stand for Control, Option and Command, yet they seem to be absent on the most modern Apple keyboards. For example, on my MBP keyboard only Command key has a corresponding symbol above "Command" string. So, what should JDK display: symbols, or just plain "Control", "Option" and "Command"? Thanks, Leonid. From artem.ananiev at oracle.com Thu Mar 29 07:33:10 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 29 Mar 2012 18:33:10 +0400 Subject: [8] Request for review: 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField In-Reply-To: <6F7AD1B3-C3CF-4A61-8AA4-779AAFD43635@oracle.com> References: <4F74562B.5040702@oracle.com> <6F7AD1B3-C3CF-4A61-8AA4-779AAFD43635@oracle.com> Message-ID: <4F7472A6.4020403@oracle.com> On 3/29/2012 4:51 PM, Leonid Romanov wrote: > Yes, you are right in your guess: OS X doesn't generate any kind of "key typed" events, this is why we have to do it manually. As for the dead code in AWTEvent.m, the answer is again yes, it could use some cleaning. Perhaps a separate low priority bug could be filled. As this is a request for JDK8 fix, which is of no urgency (yet), it makes sense to perform this refactoring as a part of 7124272. We all know all those low-priority bugs will never be fixed/implemented. Thanks, Artem > On 29.03.2012, at 16:31, Artem Ananiev wrote: > >> Hi, Leonid, >> >> a general question, not tightly related to the fix. Why do we want to generate KEY_TYPED events from Java? Do we receive such events from the native platform? Probably, not, because I see the following method in AWTEvent.m: >> >> static void >> DeliverKeyTypedEvents(JNIEnv *env, NSEvent *nsEvent, jobject peer) >> >> but it is not called from anywhere. Should it be deleted, or reused, or what? >> >> Thanks, >> >> Artem >> >> On 3/27/2012 6:49 PM, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7124272: [macosx] VK_DELETE does produce an extraneous character in a TextArea or TextField. This fix has already been pushed into 7u4. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124272 >>> Webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-675/webrev.02/ >>> >>> Thanks, >>> Leonid. >>> >>> > From sergey.bylokhov at oracle.com Thu Mar 29 07:30:48 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 29 Mar 2012 18:30:48 +0400 Subject: [7u6] Request for review: 7124551 [macosx] Once added, Menu shortcut cannot be removed Message-ID: <4F747218.8020207@oracle.com> Hi Everyone, We should accept empty KeyEquivalent in case of shortcut removing. This is a back port from jdk 8: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/74a1284ca75a Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124551 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124551/webrev.00/ -- Best regards, Sergey. From daniel.daugherty at oracle.com Thu Mar 29 07:34:49 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 29 Mar 2012 08:34:49 -0600 Subject: RFR: 7134701 [macosx] Support legacy native library names In-Reply-To: <4F7438A1.4090407@oracle.com> References: <4F71C91E.8080604@oracle.com> <4F722FEC.1060309@oracle.com> <4F7438A1.4090407@oracle.com> Message-ID: <4F747309.9050404@oracle.com> On 3/29/12 4:25 AM, Michael McMahon wrote: > On 27/03/12 22:23, Michael McMahon wrote: >> Could I get the following webrev for 7u4 reviewed please? >> >> It is the same code change as for jdk 8 >> >> http://cr.openjdk.java.net/~michaelm/7134701/webrev.7u4.1/ >> >> Thanks, >> Michael. > I've updated the webrev for this 7u4 change, based on the testing > yesterday. > It simplifies the original jdk 8 change (which will be updated via CR > 7157665) > So, if an attempt to load a library whose name is X.dylib fails we > retry with the name X.jnilib > > The following examples show the main cases: > > System.loadLibrary("foo") -> libfoo.dylib, then libfoo.jnilib > (tried in each directory of the boot library path and user library > path respectively) > > System.load("/abs/path/libfoo.dylib") -> /abs/path/libfoo.dylib, then > /abs/path/libfoo.jnilib > System.load("/abs/path/libfoo.jnilib") -> /abs/path/libfoo.jnilib > System.load("/abs/path/libfoo.bar") -> /abs/path/libfoo.bar > > System.mapLibraryName("foo") -> "libfoo.dylib" > > As before, this change only affects the behavior on Mac OS X. > > http://cr.openjdk.java.net/~michaelm/7134701/webrev.7u4.2/ Nicely redone. Thumbs up! make/java/java/FILES_java.gmk src/share/classes/java/lang/ClassLoader.java src/macosx/classes/java/lang/ClassLoaderHelper.java src/solaris/classes/java/lang/ClassLoaderHelper.java src/windows/classes/java/lang/ClassLoaderHelper.java No comments on the above files. > > Thanks, > Michael > > From anthony.petrov at oracle.com Thu Mar 29 07:36:08 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 29 Mar 2012 18:36:08 +0400 Subject: [8] Review request for 7124411: [macosx] There's no KEY_TYPED for VK_ESCAPE In-Reply-To: References: Message-ID: <4F747358.4030109@oracle.com> Looks good to me. -- best regards, Anthony On 03/29/12 16:25, Leonid Romanov wrote: > Hi, > Please review a fix for > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124411 > > webrev: http://cr.openjdk.java.net/~leonidr/7124411/webrev.00/ > > Thanks, > Leonid. From sabax at gmx.net Thu Mar 29 07:36:08 2012 From: sabax at gmx.net (Sandro Sabatini) Date: Thu, 29 Mar 2012 16:36:08 +0200 Subject: Q: how to display menu accelerators In-Reply-To: <7F92F03F-B3CD-4A7F-8E80-4B5711EB99B8@oracle.com> References: <7F92F03F-B3CD-4A7F-8E80-4B5711EB99B8@oracle.com> Message-ID: <3E46F3B0-9CEC-4F23-B5B0-D0848E5A0E9A@gmx.net> Hi, just my .02$: If you use text strings for the keyboard modifiers then don?t forget that they have to be translated. Maybe that?s the reason that Apple still uses the ?funky? symbols? Cheers, Saba > Hi, > Currently we display menu accelerators (that is, keyboard modifiers one needs to press in order to invoke menu command via keystroke) as "Control", "Alt" and "Meta" text strings. This is obviously not right. However, I'm not sure what is the correct solution here: Apple has these funky symbols that stand for Control, Option and Command, yet they seem to be absent on the most modern Apple keyboards. For example, on my MBP keyboard only Command key has a corresponding symbol above "Command" string. So, what should JDK display: symbols, or just plain "Control", "Option" and "Command"? > > Thanks, > Leonid. > From swingler at apple.com Thu Mar 29 08:02:31 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 29 Mar 2012 08:02:31 -0700 Subject: Q: how to display menu accelerators In-Reply-To: <7F92F03F-B3CD-4A7F-8E80-4B5711EB99B8@oracle.com> References: <7F92F03F-B3CD-4A7F-8E80-4B5711EB99B8@oracle.com> Message-ID: On Mar 29, 2012, at 6:50 AM, Leonid Romanov wrote: > Hi, > Currently we display menu accelerators (that is, keyboard modifiers one needs to press in order to invoke menu command via keystroke) as "Control", "Alt" and "Meta" text strings. This is obviously not right. However, I'm not sure what is the correct solution here: Apple has these funky symbols that stand for Control, Option and Command, yet they seem to be absent on the most modern Apple keyboards. For example, on my MBP keyboard only Command key has a corresponding symbol above "Command" string. So, what should JDK display: symbols, or just plain "Control", "Option" and "Command"? My suggestion would be to remain coherent with the Java SE 6 and the rest of OS X by using the symbols. This is an excerpt from an awt.properties file which contains the OS X-specific menu glyphs: # Modifier names AWT.shift=\u21e7 AWT.control=\u2303 AWT.alt=\u2325 AWT.meta=\u2318 AWT.altGraph=\u2325 # Key names AWT.enter=\u23ce AWT.backSpace=\u232b AWT.tab=\u21e5 AWT.cancel=\u238b AWT.clear=\u2327 AWT.pause=Pause AWT.capsLock=\u21ea AWT.escape=\u238b AWT.space=\u2423 AWT.pgup=\u21de AWT.pgdn=\u21df AWT.end=\u2198 AWT.home=\u2196 AWT.left=\u2190 AWT.up=\u2191 AWT.right=\u2192 AWT.down=\u2193 AWT.begin=Begin AWT.comma=, AWT.period=. AWT.slash=/ AWT.semicolon=; AWT.equals=\u003d AWT.openBracket=[ AWT.backSlash=\\ AWT.closeBracket=] AWT.multiply=\u2328 * AWT.add=\u2328 + AWT.separator=\u2328 , AWT.separater=\u2328 , AWT.subtract=\u2328 - AWT.decimal=\u2328 . AWT.divide=\u2328 / AWT.delete=\u2326 AWT.numLock=Num Lock AWT.scrollLock=Scroll Lock AWT.f1=F1 AWT.f2=F2 AWT.f3=F3 AWT.f4=F4 AWT.f5=F5 AWT.f6=F6 AWT.f7=F7 AWT.f8=F8 AWT.f9=F9 AWT.f10=F10 AWT.f11=F11 AWT.f12=F12 AWT.f13=F13 AWT.f14=F14 AWT.f15=F15 AWT.f16=F16 AWT.f17=F17 AWT.f18=F18 AWT.f19=F19 AWT.f20=F20 AWT.f21=F21 AWT.f22=F22 AWT.f23=F23 AWT.f24=F24 AWT.printScreen=\u2399 AWT.insert=Insert AWT.help=Help AWT.windows=Windows AWT.context=Context Menu AWT.backQuote=` AWT.quote=' AWT.deadGrave=Dead Grave AWT.deadAcute=Dead Acute AWT.deadCircumflex=Dead Circumflex AWT.deadTilde=Dead Tilde AWT.deadMacron=Dead Macron AWT.deadBreve=Dead Breve AWT.deadAboveDot=Dead Above Dot AWT.deadDiaeresis=Dead Diaeresis AWT.deadAboveRing=Dead Above Ring AWT.deadDoubleAcute=Dead Double Acute AWT.deadCaron=Dead Caron AWT.deadCedilla=Dead Cedilla AWT.deadOgonek=Dead Ogonek AWT.deadIota=Dead Iota AWT.deadVoicedSound=Dead Voiced Sound AWT.deadSemivoicedSound=Dead Semivoiced Sound AWT.ampersand=& AWT.asterisk=* AWT.quoteDbl=" AWT.Less=< AWT.greater=> AWT.braceLeft=[ AWT.braceRight=] AWT.at=@ AWT.colon=: AWT.circumflex=^ AWT.dollar=$ AWT.euro=\u20ac AWT.exclamationMark=! AWT.invertedExclamationMark=\u00a1 AWT.leftParenthesis=( AWT.numberSign=# AWT.plus=+ AWT.minus=- AWT.rightParenthesis=) AWT.underscore=_ AWT.final=Final AWT.convert=Convert AWT.noconvert=No Convert AWT.accept=Accept AWT.modechange=Mode Change AWT.kana=Kana AWT.kanji=Kanji AWT.alphanumeric=Alphanumeric AWT.katakana=Katakana AWT.hiragana=Hiragana AWT.fullWidth=Full-Width AWT.halfWidth=Half-Width AWT.romanCharacters=Roman Characters AWT.allCandidates=All Candidates AWT.previousCandidate=Previous Candidate AWT.codeInput=Code Input AWT.japaneseKatakana=Japanese Katakana AWT.japaneseHiragana=Japanese Hiragana AWT.japaneseRoman=Japanese Roman AWT.kanaLock=Kana Lock AWT.inputMethodOnOff=Input Method On/Off AWT.again=Again AWT.undo=Undo AWT.copy=Copy AWT.paste=Paste AWT.cut=Cut AWT.find=Find AWT.props=Props AWT.stop=Stop AWT.compose=Compose # Numeric Keypad AWT.numpad=\u2328 AWT.unknown=Unknown AWT.undefined=Undefined Regards, Mike Swingler Apple Inc. From sergey.bylokhov at oracle.com Thu Mar 29 08:55:12 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 29 Mar 2012 19:55:12 +0400 Subject: [8] Request for review: 7124401 [macosx] After call Frame dispose() application continues to work Message-ID: <4F7485E0.3070102@oracle.com> Hi Everyone, On the latest version the dispose works as expected, but the test expects that the window will be fully red. But it is not true on the mac because of resizegrowboxwindow. Testcase updated. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124401 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124401/webrev.00/ -- Best regards, Sergey. From Alexander.Potochkin at oracle.com Thu Mar 29 09:32:39 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 29 Mar 2012 20:32:39 +0400 Subject: [7u6] Request for review: 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent Message-ID: <4F748EA7.8000305@oracle.com> Hello Please review this fix: http://cr.openjdk.java.net/~alexp/7124210/webrev.00/ Thanks alexp From Alexander.Potochkin at oracle.com Thu Mar 29 09:35:09 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 29 Mar 2012 20:35:09 +0400 Subject: [8] Request for review: 7124401 [macosx] After call Frame dispose() application continues to work In-Reply-To: <4F7485E0.3070102@oracle.com> References: <4F7485E0.3070102@oracle.com> Message-ID: <4F748F3D.3080709@oracle.com> Hello Sergey Looks good! Thanks alexp > Hi Everyone, > On the latest version the dispose works as expected, but the test > expects that the window will be fully red. But it is not true on the > mac because of resizegrowboxwindow. Testcase updated. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124401 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124401/webrev.00/ > From rick.hillegas at oracle.com Thu Mar 29 10:59:29 2012 From: rick.hillegas at oracle.com (Rick Hillegas) Date: Thu, 29 Mar 2012 10:59:29 -0700 Subject: installing the latest jdk7 for mac Message-ID: <4F74A301.8000403@oracle.com> I downloaded the latest installer from http://jdk7.java.net/macportpreview/ and then ran it. When I got to the step which was supposed to let me choose where to install the jdk, I did not see any control for configuring this location or any indication of where the files would be dropped. I continued with the installation, nonetheless. Afterward, I was not able to find the installation with this command: find / -name "*jdk1.7.0_04*" Any ideas about what I am doing wrong, how I can coax the installer into letting me choose a destination directory, and/or where the files were written? I am running Mac OSX 10.7.3 on a macbook pro. Thanks, -Rick From pranav.bhat at oracle.com Thu Mar 29 11:35:44 2012 From: pranav.bhat at oracle.com (pranav bhat) Date: Thu, 29 Mar 2012 14:35:44 -0400 Subject: installing the latest jdk7 for mac In-Reply-To: <4F74A301.8000403@oracle.com> References: <4F74A301.8000403@oracle.com> Message-ID: <4F74AB80.1000309@oracle.com> On 3/29/2012 1:59 PM, Rick Hillegas wrote: > I downloaded the latest installer from > http://jdk7.java.net/macportpreview/ and then ran it. When I got to > the step which was supposed to let me choose where to install the > jdk, I did not see any control for configuring this location or any > indication of where the files would be dropped. I continued with the > installation, nonetheless. Afterward, I was not able to find the > installation with this command: > > find / -name "*jdk1.7.0_04*" > Hello Rick, The bundle is called 1.7.0.jdk on the mac platform. > Any ideas about what I am doing wrong, how I can coax the installer > into letting me choose a destination directory, The ability to select the destination directory is disabled by the installer. > and/or where the files were written? /Library/Java/JavaVirtualMachines Thanks, - Pranav > I am running Mac OSX 10.7.3 on a macbook pro. > > Thanks, > -Rick From scott.kovatch at oracle.com Thu Mar 29 12:16:20 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 29 Mar 2012 12:16:20 -0700 Subject: installing the latest jdk7 for mac In-Reply-To: <4F74A301.8000403@oracle.com> References: <4F74A301.8000403@oracle.com> Message-ID: <832AE696-0215-4189-8CBF-0A23BD8C862A@oracle.com> On Mar 29, 2012, at 10:59 AM, Rick Hillegas wrote: > I downloaded the latest installer from http://jdk7.java.net/macportpreview/ and then ran it. When I got to the step which was supposed to let me choose where to install the jdk, I did not see any control for configuring this location or any indication of where the files would be dropped. I continued with the installation, nonetheless. Afterward, I was not able to find the installation with this command: > > find / -name "*jdk1.7.0_04*" > > Any ideas about what I am doing wrong, how I can coax the installer into letting me choose a destination directory, and/or where the files were written? I am running Mac OSX 10.7.3 on a macbook pro. The JDK must go into /Library/Java/JavaVirtualMachines. We do this because doing so will make it the default JDK for all of the command-line tools. Why do you want to put it into a custom location? Java VMs on the Mac have been installed into this location for some time now. I do have a to-do item to write up some instructions on how to verify that you have JDK 7 and that it is the default JDK, but just open up a Terminal window and type 'java -version'. /usr/libexec/java_home will tell you, too. -- Scott From henri.gomez at gmail.com Thu Mar 29 12:32:36 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 29 Mar 2012 21:32:36 +0200 Subject: installing the latest jdk7 for mac In-Reply-To: <832AE696-0215-4189-8CBF-0A23BD8C862A@oracle.com> References: <4F74A301.8000403@oracle.com> <832AE696-0215-4189-8CBF-0A23BD8C862A@oracle.com> Message-ID: > The JDK must go into /Library/Java/JavaVirtualMachines. We do this because doing so will make it the default JDK for all of the command-line tools. > > Why do you want to put it into a custom location? ?Java VMs on the Mac have been installed into this location for some time now. > > I do have a to-do item to write up some instructions on how to verify that you have JDK 7 and that it is the default JDK, but just open up a Terminal window and type 'java -version'. ?/usr/libexec/java_home will tell you, too. openjdk-osx-build project install all JVM under /Library/Java/JavaVirtualMachines since it's the location for 'alternates' JVM (aka non system) : Here is a list of JVM installed : drwxr-xr-x 3 root wheel 102 29 jui 2011 1.6.0_26-b03-383.jdk drwxr-xr-x 3 root wheel 102 22 sep 2011 1.6.0_27-b07-395.jdk drwxr-xr-x 3 root wheel 102 14 oct 23:55 1.6.0_29-b11-397.jdk drwxr-xr-x 3 root wheel 102 15 d?c 22:45 1.6.0_30-b12-404.jdk drwxr-xr-x 3 root wheel 102 30 jan 19:50 1.6.0_30-b12-409.jdk drwxr-xr-x 3 root wheel 102 14 f?v 21:31 1.6.0_31-b04-411.jdk drwxr-xr-x@ 4 henri wheel 136 14 mar 09:35 1.7.0u.jdk drwxr-xr-x@ 4 henri wheel 136 29 mar 12:00 1.7.0u4.jdk drwxr-xr-x@ 4 henri wheel 136 26 mar 12:15 1.8.0-lambda.jdk drwxr-xr-x@ 4 henri wheel 136 29 mar 09:23 1.8.0.jdk drwxr-xr-x@ 4 henri wheel 136 12 jan 22:44 JDK 1.7.0 Developer Preview.jdk From rick.hillegas at oracle.com Thu Mar 29 12:41:50 2012 From: rick.hillegas at oracle.com (Rick Hillegas) Date: Thu, 29 Mar 2012 12:41:50 -0700 Subject: installing the latest jdk7 for mac In-Reply-To: <832AE696-0215-4189-8CBF-0A23BD8C862A@oracle.com> References: <4F74A301.8000403@oracle.com> <832AE696-0215-4189-8CBF-0A23BD8C862A@oracle.com> Message-ID: <4F74BAFE.3040505@oracle.com> Thanks, Pranav, Scott, and Henri, that did the trick. One response inline... On 3/29/12 12:16 PM, Scott Kovatch wrote: > ... > > Why do you want to put it into a custom location? Java VMs on the Mac have been installed into this location for some time now. > Perhaps for superstitious reasons. I have a bad experience with well-intentioned upgrades disappearing old revs of Java. I like to be able to reproduce a bug on the bad old rev that the customer is using so that I can confidently say that the good new rev fixes the problem. Thanks, -Rick From swingler at apple.com Thu Mar 29 12:50:54 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 29 Mar 2012 12:50:54 -0700 Subject: installing the latest jdk7 for mac In-Reply-To: <4F74BAFE.3040505@oracle.com> References: <4F74A301.8000403@oracle.com> <832AE696-0215-4189-8CBF-0A23BD8C862A@oracle.com> <4F74BAFE.3040505@oracle.com> Message-ID: <5B6A5AB0-047E-4C7B-AB38-3EB1D05C56AB@apple.com> On Mar 29, 2012, at 12:41 PM, Rick Hillegas wrote: > Thanks, Pranav, Scott, and Henri, that did the trick. One response inline... > > On 3/29/12 12:16 PM, Scott Kovatch wrote: >> ... >> >> Why do you want to put it into a custom location? Java VMs on the Mac have been installed into this location for some time now. > > Perhaps for superstitious reasons. I have a bad experience with well-intentioned upgrades disappearing old revs of Java. I like to be able to reproduce a bug on the bad old rev that the customer is using so that I can confidently say that the good new rev fixes the problem. This is another good reason why Oracle should ditch the .pkg installer for the .jdk bundles, use the old drag-install process, and ship each .dmg with distinct names for each bundle (i.e. "1.7.0u4-b123.jdk"). It's a lot more transparent to developers, allows multiple concurrent installations, and has an obvious uninstallation process. Regards, Mike Swingler Apple Inc. From scott.kovatch at oracle.com Thu Mar 29 17:18:18 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 29 Mar 2012 17:18:18 -0700 Subject: installing the latest jdk7 for mac In-Reply-To: <4F74BAFE.3040505@oracle.com> References: <4F74A301.8000403@oracle.com> <832AE696-0215-4189-8CBF-0A23BD8C862A@oracle.com> <4F74BAFE.3040505@oracle.com> Message-ID: <3315EF20-8042-460D-AB6F-241E317DFE8B@oracle.com> On Mar 29, 2012, at 12:41 PM, Rick Hillegas wrote: > Thanks, Pranav, Scott, and Henri, that did the trick. One response inline... > > On 3/29/12 12:16 PM, Scott Kovatch wrote: >> ... >> >> Why do you want to put it into a custom location? Java VMs on the Mac have been installed into this location for some time now. >> > Perhaps for superstitious reasons. I have a bad experience with well-intentioned upgrades disappearing old revs of Java. I like to be able to reproduce a bug on the bad old rev that the customer is using so that I can confidently say that the good new rev fixes the problem. For a JDK that shouldn't ever be an issue. Each release of the JDK will (eventually) have its own unique name, so the JDK bundle for 7u6 will be named jdk1.7.0_06.jdk. For the JRE, we will keep it up to date, but it will also be trivial to roll back to an older version if you need to. It will offer to update itself right away, but you should be able to do your testing before that happens. -- Scott K. From anthony.petrov at oracle.com Fri Mar 30 02:51:14 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 30 Mar 2012 13:51:14 +0400 Subject: [7u6] Request for review: 7124551 [macosx] Once added, Menu shortcut cannot be removed In-Reply-To: <4F747218.8020207@oracle.com> References: <4F747218.8020207@oracle.com> Message-ID: <4F758212.8060803@oracle.com> Looks fine. -- best regards, Anthony On 3/29/2012 6:30 PM, Sergey Bylokhov wrote: > Hi Everyone, > We should accept empty KeyEquivalent in case of shortcut removing. > This is a back port from jdk 8: > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/74a1284ca75a > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124551 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124551/webrev.00/ > From sergey.bylokhov at oracle.com Fri Mar 30 04:29:29 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 30 Mar 2012 15:29:29 +0400 Subject: [7u6] Request for review: 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent In-Reply-To: <4F748EA7.8000305@oracle.com> References: <4F748EA7.8000305@oracle.com> Message-ID: <4F759919.6010003@oracle.com> Fix looks ok for me. 29.03.2012 20:32, Alexander Potochkin wrote: > Hello > > Please review this fix: > http://cr.openjdk.java.net/~alexp/7124210/webrev.00/ > > Thanks > alexp -- Best regards, Sergey. From scott.kovatch at oracle.com Fri Mar 30 10:03:49 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 30 Mar 2012 10:03:49 -0700 Subject: Oracle Licence and Apple AppStore violation In-Reply-To: References: Message-ID: <4A627E53-7F1E-4499-835A-B4BE4C427F2F@oracle.com> On Mar 28, 2012, at 12:56 PM, Jeff Palmer wrote: > Even if the mac store does not require static linking, if the second bullet > is really true, what does that mean for bundling? Since this is a technical list you won't get any specific legal advice about redistribution here. I would offer an alternative, but I can't right now. Sorry. > I am using JWS, due to the distributed nature of my application > (interdependent code / db across desktop, server, android). Bundling would > mean large bandwidth requirements during upgrade, that would not be > scalable. Java Web Start will have no overlap and nothing to do whatsoever with the App Store. Your users just need to get the Java 7 runtime for Mac OS X. Mac OS X has a hidden app that is registered as the handler for .jnlp files and will use Java 7 if it's available. Users will not be able to get the runtime from the Mac OS X app store because the runtime is a component that we want to have full functionality. -- Scott From jcpalmer at rochester.rr.com Fri Mar 30 12:58:21 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Fri, 30 Mar 2012 15:58:21 -0400 Subject: Oracle Licence and Apple AppStore violation In-Reply-To: <4A627E53-7F1E-4499-835A-B4BE4C427F2F@oracle.com> Message-ID: On 3/30/12 1:03 PM, "Scott Kovatch" wrote: > On Mar 28, 2012, at 12:56 PM, Jeff Palmer wrote: > >> Even if the mac store does not require static linking, if the second bullet >> is really true, what does that mean for bundling? > > Since this is a technical list you won't get any specific legal advice about > redistribution here. I would offer an alternative, but I can't right now. > Sorry. > >> I am using JWS, due to the distributed nature of my application >> (interdependent code / db across desktop, server, android). Bundling would >> mean large bandwidth requirements during upgrade, that would not be >> scalable. > > Java Web Start will have no overlap and nothing to do whatsoever with the App > Store. Your users just need to get the Java 7 runtime for Mac OS X. Mac OS X > has a hidden app that is registered as the handler for .jnlp files and will > use Java 7 if it's available. > > Users will not be able to get the runtime from the Mac OS X app store because > the runtime is a component that we want to have full functionality. > > -- Scott > Thanks for replying. I actually thought I was closer giving a legal "heads up" (advice seem too strong), not asking for it. This was directed to those thinking about using the bundling process under development here. This is an actual quote from the preamble of GNU Lesser General Public License, version 2.1, http://www.gnu.org/licenses/lgpl-2.1.html "Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library." People who would run one of these bundled programs would seem to have the the right to switch out the JRE, but how can they? If you have customers that want to cause a developer problems, this is a wide open way for them to do it. Saying what I am doing with Java Webstart, was maybe too much info. I have no interest in using the Mac store anyway. It is no where close to sub-second to publish updates. Jeff From swpalmer at gmail.com Fri Mar 30 13:15:07 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 30 Mar 2012 16:15:07 -0400 Subject: Oracle Licence and Apple AppStore violation In-Reply-To: References: Message-ID: On 2012-03-30, at 3:58 PM, Jeff Palmer wrote: > Thanks for replying. I actually thought I was closer giving a legal "heads > up" (advice seem too strong), not asking for it. This was directed to those > thinking about using the bundling process under development here. > > This is an actual quote from the preamble of GNU Lesser General Public > License, version 2.1, http://www.gnu.org/licenses/lgpl-2.1.html > > "Although the Lesser General Public License is Less protective of the users' > freedom, it does ensure that the user of a program that is linked with the > Library has the freedom and the wherewithal to run that program using a > modified version of the Library." > > People who would run one of these bundled programs would seem to have the > the right to switch out the JRE, but how can they? If you have customers > that want to cause a developer problems, this is a wide open way for them to > do it. It says they have the right to switch it out.. But does it say you have to tell them how to do that or help them in any way? Has LGPL ever been successfully defended anyway? Even the Linux kernel folks happily let nVidia ignore it? nobody but Richard Stallman actually cares. Scott From Fabrizio.Giudici at tidalwave.it Fri Mar 30 14:14:47 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Fri, 30 Mar 2012 23:14:47 +0200 Subject: Oracle Licence and Apple AppStore violation In-Reply-To: References: Message-ID: On Fri, 30 Mar 2012 22:15:07 +0200, Scott Palmer wrote: > > On 2012-03-30, at 3:58 PM, Jeff Palmer wrote: > >> Thanks for replying. I actually thought I was closer giving a legal >> "heads >> up" (advice seem too strong), not asking for it. This was directed to >> those >> thinking about using the bundling process under development here. >> >> This is an actual quote from the preamble of GNU Lesser General Public >> License, version 2.1, http://www.gnu.org/licenses/lgpl-2.1.html Anyway I'm failing to see the connection between OpenJRE and LGPL... -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." fabrizio.giudici at tidalwave.it http://tidalwave.it - http://fabriziogiudici.it From sergey.bylokhov at oracle.com Sat Mar 31 09:47:23 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 31 Mar 2012 20:47:23 +0400 Subject: [7u6] Request for review: 7124210: [macosx] Replacing text in a TextField does generate an extra TextEvent In-Reply-To: <4F748EA7.8000305@oracle.com> References: <4F748EA7.8000305@oracle.com> Message-ID: <4F77351B.4000608@oracle.com> Hi Alexander, I assume we have the same behavior in xawt too? Should we create additional CR for xawt? 29.03.2012 20:32, Alexander Potochkin wrote: > Hello > > Please review this fix: > http://cr.openjdk.java.net/~alexp/7124210/webrev.00/ > > Thanks > alexp -- Best regards, Sergey. From sergey.bylokhov at oracle.com Sat Mar 31 13:04:29 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 01 Apr 2012 00:04:29 +0400 Subject: [8] Request for review: 7150105 [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor. Message-ID: <4F77634D.1020707@oracle.com> Hi Everyone, A subcomponents may want to override the cursor over some of their parts(LWTextAreaPeer changes the cursor over scrollbars). Changes description: 1. LWComponentPeer.java: - Just one method added getCursor(); 2. LWCursorManager.java: - updateCursorImpl now use LWComponentPeer.getCursor() if applicable. - cleanup + TODO implemented "// TODO: it's possible to get the component under cursor directly as" 3. LWTextAreaPeer.java: - Changes the cursor over scrollbars. 4. LWWindowPeer.java: - We should update cursor even on MOUSE_EXIT event. 5. CCursorManager.java: - currentCursor was always null. Unused method getNativeWindow() removed. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7150105 Webrev can be found at: http://cr.openjdk.java.net/~serb/7150105/webrev.00/ -- Best regards, Sergey.