From neugens.limasoftware at gmail.com Fri Jun 1 01:07:36 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 1 Jun 2012 10:07:36 +0200 Subject: Transitioning from Apple extensions In-Reply-To: References: Message-ID: 2012/6/1 Chris Harshman : > On Wed, May 30, 2012 at 4:29 AM, Artem Ananiev wrote: > >> We at Oracle do our best to support all Java apps on Mac OS X that were >> written for Apple's JDK6 and relied on Apple's extensions (system >> properties, command line args, com.apple classes, etc.), but we don't >> provide any official support for anything except public APIs. >> > > Is there any sort of guide (official or otherwise) mapping Apple's > extensions to public API replacement/equivalent/work-arounds? (I.e., is > there a way current developers can hedge their bets, coding to the 'rich' > Apple JDK6 experience but also degrading as gracefully as possible for > OpenJDK 7+?) That's the bet that people lose when use proprietary extensions. What are the specific "features" you're missing? Perhaps the most popular ones will be reintroduced, but I doubt that Apple specific functionality will end in the main JDK, that's not the place for it. 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 henri.gomez at gmail.com Fri Jun 1 01:47:58 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 1 Jun 2012 10:47:58 +0200 Subject: [8] Review request for: 7172722: Latest jdk7u from OSX broke universal build In-Reply-To: <4FC60EDE.4020805@oracle.com> References: <4FC60EDE.4020805@oracle.com> Message-ID: Tested and it works for me. I just produced jdk7u b12 with it : http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u6-b12-20120601.dmg Cheers 2012/5/30 Anthony Petrov : > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7172722 at: > > http://cr.openjdk.java.net/~anthony/8-33-MacUniversalBuild-7172722.0/ > > I've simplified the fix comparing to original Henri's proposal [1] to follow > the same pattern as we use with other properties: we simply give ?the > corresponding class fields the same names as to the properties themselves. > > Henri: please verify if the new patch works for you. > > [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-May/003191.html > > -- > best regards, > Anthony From alexander.zuev at oracle.com Fri Jun 1 02:40:50 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 01 Jun 2012 13:40:50 +0400 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() Message-ID: <4FC88E22.10701@oracle.com> Hello, please review my fix for CR 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() CR description can be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 Webrev with the proposed change can be seen here: http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 With best regards, Alex From swpalmer at gmail.com Fri Jun 1 04:30:04 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 1 Jun 2012 07:30:04 -0400 Subject: Transitioning from Apple extensions In-Reply-To: References: Message-ID: <50E6C9A1-3F91-454F-9AEE-058B3397A8EB@gmail.com> On 2012-06-01, at 4:07 AM, Mario Torre wrote: > 2012/6/1 Chris Harshman : >> On Wed, May 30, 2012 at 4:29 AM, Artem Ananiev wrote: >> >>> We at Oracle do our best to support all Java apps on Mac OS X that were >>> written for Apple's JDK6 and relied on Apple's extensions (system >>> properties, command line args, com.apple classes, etc.), but we don't >>> provide any official support for anything except public APIs. >>> >> >> Is there any sort of guide (official or otherwise) mapping Apple's >> extensions to public API replacement/equivalent/work-arounds? (I.e., is >> there a way current developers can hedge their bets, coding to the 'rich' >> Apple JDK6 experience but also degrading as gracefully as possible for >> OpenJDK 7+?) > > That's the bet that people lose when use proprietary extensions. > > What are the specific "features" you're missing? Perhaps the most > popular ones will be reintroduced, but I doubt that Apple specific > functionality will end in the main JDK, that's not the place for it. It is in cases where it is the JREs job to provide a reasonable user experience. Such as supporting the native platform's look and feel. Let's face it, that's all the Apple "extensions" we're doing. Scott From neugens.limasoftware at gmail.com Fri Jun 1 05:05:01 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 1 Jun 2012 14:05:01 +0200 Subject: Transitioning from Apple extensions In-Reply-To: <50E6C9A1-3F91-454F-9AEE-058B3397A8EB@gmail.com> References: <50E6C9A1-3F91-454F-9AEE-058B3397A8EB@gmail.com> Message-ID: The Apple LAF is being worked on, and I think is pretty good already. I don't know if the system properties that were used to alter the LAF will be supported, I guess this would be ok, but someone more close to the Mac development is more qualified than me to answer that question. 2012/6/1 Scott Palmer : > On 2012-06-01, at 4:07 AM, Mario Torre wrote: > >> 2012/6/1 Chris Harshman : >>> On Wed, May 30, 2012 at 4:29 AM, Artem Ananiev wrote: >>> >>>> We at Oracle do our best to support all Java apps on Mac OS X that were >>>> written for Apple's JDK6 and relied on Apple's extensions (system >>>> properties, command line args, com.apple classes, etc.), but we don't >>>> provide any official support for anything except public APIs. >>>> >>> >>> Is there any sort of guide (official or otherwise) mapping Apple's >>> extensions to public API replacement/equivalent/work-arounds? (I.e., is >>> there a way current developers can hedge their bets, coding to the 'rich' >>> Apple JDK6 experience but also degrading as gracefully as possible for >>> OpenJDK 7+?) >> >> That's the bet that people lose when use proprietary extensions. >> >> What are the specific "features" you're missing? Perhaps the most >> popular ones will be reintroduced, but I doubt that Apple specific >> functionality will end in the main JDK, that's not the place for it. > > It is in cases where it is the JREs job to provide a reasonable user experience. Such as supporting the native platform's look and feel. ?Let's face it, that's all the Apple "extensions" we're doing. > > Scott > -- 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 swpalmer at gmail.com Fri Jun 1 06:17:53 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 1 Jun 2012 09:17:53 -0400 Subject: Transitioning from Apple extensions In-Reply-To: References: <50E6C9A1-3F91-454F-9AEE-058B3397A8EB@gmail.com> Message-ID: <50689596-5212-44FE-9D28-FA95DE9FF13A@gmail.com> On 2012-06-01, at 8:05 AM, Mario Torre wrote: > The Apple LAF is being worked on, and I think is pretty good already. > > I don't know if the system properties that were used to alter the LAF > will be supported, I guess this would be ok, but someone more close to > the Mac development is more qualified than me to answer that question. There are certain things that would just be unreasonable to drop. Like the screen menu bar. Support for Apple events, like opening a document or responding to Quit, are rather essential as well. It's simply part of the look and feel? so to suggest that it is a "proprietary extension" in my opinion is rather silly. That the Java look and feel model isn't robust enough to properly support it is a whole other issue that needs to be addressed on a higher level. Scott > 2012/6/1 Scott Palmer : >> On 2012-06-01, at 4:07 AM, Mario Torre wrote: >> >>> 2012/6/1 Chris Harshman : >>>> On Wed, May 30, 2012 at 4:29 AM, Artem Ananiev wrote: >>>> >>>>> We at Oracle do our best to support all Java apps on Mac OS X that were >>>>> written for Apple's JDK6 and relied on Apple's extensions (system >>>>> properties, command line args, com.apple classes, etc.), but we don't >>>>> provide any official support for anything except public APIs. >>>>> >>>> >>>> Is there any sort of guide (official or otherwise) mapping Apple's >>>> extensions to public API replacement/equivalent/work-arounds? (I.e., is >>>> there a way current developers can hedge their bets, coding to the 'rich' >>>> Apple JDK6 experience but also degrading as gracefully as possible for >>>> OpenJDK 7+?) >>> >>> That's the bet that people lose when use proprietary extensions. >>> >>> What are the specific "features" you're missing? Perhaps the most >>> popular ones will be reintroduced, but I doubt that Apple specific >>> functionality will end in the main JDK, that's not the place for it. >> >> It is in cases where it is the JREs job to provide a reasonable user experience. Such as supporting the native platform's look and feel. Let's face it, that's all the Apple "extensions" we're doing. >> >> Scott >> > > > > -- > 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 leonid.romanov at oracle.com Fri Jun 1 08:27:58 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 1 Jun 2012 19:27:58 +0400 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: <99A4EEA8-726B-4319-AEDE-DC84E9F9D32F@oracle.com> References: <4FC373A5.9030508@oracle.com> <89803632-78F2-410F-B66B-09AEFC8CAB11@oracle.com> <4FC39B2F.6070805@oracle.com> <32533319-5E00-483F-AE69-6E79419C3757@oracle.com> <4FC78E82.1030500@oracle.com> <99A4EEA8-726B-4319-AEDE-DC84E9F9D32F@oracle.com> Message-ID: Hi Scott, Could you please provide me with instructions how to create my own bundled app? There is a couple of things I want to test... On 31.05.2012, at 20:20, Scott Kovatch wrote: > I think what Artem is saying is that if the application is bundled, and CFBundleName is set, it should take higher priority than JAVA_MAIN_CLASS_. > > If that is what you are saying, Artem, I agree. :-) > > We're straying away from the original review, though. > > -- Scott > > On May 31, 2012, at 8:30 AM, Artem Ananiev wrote: > >> Hi, Leonid, >> >> shouldn't app name set in the bundler be of higher priority than JAVA_MAIN_CLASS_ value, set by Java launcher? >> >> Thanks, >> >> Artem >> >> On 5/29/2012 8:59 PM, Leonid Romanov wrote: >>> Well, the order is the following: first, we check if -Xdock:name has been set. If it hasn't, we check for the "apple.awt.application.name" property. If this property hasn't been set, we try to get the app name from the JAVA_MAIN_CLASS_ environment variable, which is used to pass the name of a Java class whose main() method was invoked by the Java launcher code to start the application. If JAVA_MAIN_CLASS_ hasn't been set, then as the last resort we try to get the app name from the bundle. >>> >>> On 28.05.2012, at 19:35, Artem Ananiev wrote: >>> >>>> >>>> On 5/28/2012 6:06 PM, Leonid Romanov wrote: >>>>> Hi, >>>>> The problem with the application name is that the app in question uses "com.apple.mrj.application.apple.menu.about.name" property to set its name. Mu understanding is that we don't support this property in OpenJDK. >>>> >>>> OK, fine. Is the application name set correctly when it is passed from app bundle or as -Xdock:name? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>>> On 28.05.2012, at 16:46, Artem Ananiev wrote: >>>>> >>>>>> Hi, Leonid, >>>>>> >>>>>> the fix looks fine. Is the application name issue (also mentioned in 7159381) addressed in another fix? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>> On 5/24/2012 5:23 PM, Leonid Romanov wrote: >>>>>>> Hi, >>>>>>> Please review a fix for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category. The problem here is that we ignore the fact that for the bundled app its icon might be specified via Info.plist file. In this case OS X sets the icon for us, so we don't have to do anything. >>>>>>> >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 >>>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7159381/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Leonid. >>>>>>> >>>>> >>> > From anthony.petrov at oracle.com Fri Jun 1 08:35:00 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 01 Jun 2012 19:35:00 +0400 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <4FC88E22.10701@oracle.com> References: <4FC88E22.10701@oracle.com> Message-ID: <4FC8E124.70704@oracle.com> Hi Alex, 1. src/macosx/native/sun/awt/CGraphicsDevice.m > 35 // This is a strange mode, where we using 10 pixels per color and pack it into 32 bits s/where we.../in which we use 10 bits per color component and pack them into.../ > 59 for(n = 0; n < numModes; n++ ) { > 60 CGDisplayModeRef cRef = (CGDisplayModeRef) CFArrayGetValueAtIndex(allModes, n); > 61 CFStringRef modeString = CGDisplayModeCopyPixelEncoding(cRef); > 62 thisBpp = getBPPFromModeString(modeString); > 63 CFRelease(modeString); > 64 if (cRef == NULL || thisBpp != bpp || CGDisplayModeGetHeight(cRef) != h || CGDisplayModeGetWidth(cRef) != w) { It looks like it's a bit late to check cRef for NULL at line 64 since we've already used it at line 61. :) > 135 static JNF_CLASS_CACHE(jc_DisplayMode, "java/awt/DisplayMode"); > 136 static JNF_MEMBER_CACHE(getWidthMethod, jc_DisplayMode, "getWidth", "()I"); > 137 static JNF_MEMBER_CACHE(getHeightMethod, jc_DisplayMode, "getHeight", "()I"); > 138 static JNF_MEMBER_CACHE(getBitDepthMethod, jc_DisplayMode, "getBitDepth", "()I"); > 139 static JNF_MEMBER_CACHE(getRefreshRateMethod, jc_DisplayMode, "getRefreshRate", "()I"); > 140 > 141 w = JNFCallIntMethod(env, newMode, getWidthMethod); > 142 h = JNFCallIntMethod(env, newMode, getHeightMethod); > 143 bpp = JNFCallIntMethod(env, newMode, getBitDepthMethod); > 144 refrate = JNFCallIntMethod(env, newMode, getRefreshRateMethod); I suggest to do that in Java and pass all the parameters to the native method. We simply don't need the newMode reference in native. > 182 ret = JNFNewObject(env, jc_DisplayMode_ctor, w, h, bpp, refrate); I haven't read the spec for public methods yet, but just want to check: do we have to return a new object each time the current mode is requested, or should the returned object belong to a cached array of supported display modes? If we have to/may return a new object though, then I suggest to minimize code duplication between the getDisplayMode and getDispalyModes implementations since both create these objects. -- best regards, Anthony On 6/1/2012 1:40 PM, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7124247: [macosx] Implement > GraphicsDevice.setDisplayMode() > > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 > > With best regards, > Alex From artem.ananiev at oracle.com Fri Jun 1 08:57:57 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 01 Jun 2012 19:57:57 +0400 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <4FC88E22.10701@oracle.com> References: <4FC88E22.10701@oracle.com> Message-ID: <4FC8E685.20705@oracle.com> Hi, Alex, here are some comments: 1. Please, update copyright dates in file headers. 2. I would pass w, h, bpp and refrate as method params to setDisplayMode() to avoid extra JNI calls from native 3. Is it possible to call setDisplayMode() with a DisplayMode object that was not obtained via previous getDisplayModes() call? If the answer is "no", why don't you just check for exact match for all parameters (w, h, bpp, refrate) in getBestModeForParameters()? Thanks, Artem On 6/1/2012 1:40 PM, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7124247: [macosx] Implement > GraphicsDevice.setDisplayMode() > > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 > > With best regards, > Alex From harshman+javadev at gmail.com Fri Jun 1 10:32:23 2012 From: harshman+javadev at gmail.com (Chris Harshman) Date: Fri, 1 Jun 2012 10:32:23 -0700 Subject: Transitioning from Apple extensions In-Reply-To: References: Message-ID: On Fri, Jun 1, 2012 at 1:07 AM, Mario Torre wrote: > That's the bet that people lose when use proprietary extensions. > Well, in fairness to OS X Java developers everywhere, Apple pitched Java as a first-class dev environment for the Mac for years, before abdicating; remember Steve Jobs joining McNealy during a JavaOne keynote ? At least the 'proprietary extensions' are still (from the developer's perspective) Java, and can be coded around; i.e., it's *preferable* (for Mac users/developers), but not *absolutely necessary* to use: - The apple.laf.useScreenMenuBar system property (which itself takes over from the deprecated com.apple.macos.useScreenMenuBar ) to use the Mac's native top-of-screen menu bar instead of a menu bar attached to a window (er, JFrame) instance; - The apple.laf.AquaLookAndFeel Swing look and feel - The com.apple.eawt.Application (i.e., .setDockIconImage(), .setDockMenu(), etc) package to manage an application's dock presence; - Apple's 'native' java.awt.FileDialog; - The apple.awt.fileDialogForDirectories property (that begat this thread that I've hijacked); - The Window.documentModified property to indicate a 'dirty' (unsaved changes) window state (this one may not be Mac-centric); - The com.apple.eawt.* classes to handle Apple events (with, e.g., ApplicationAdapter already deprecated in favor of com.apple.eawt.AppEvent.* events...); etc. Is there a more recent comprehensive guide to OS X development in Java than Apple's circa-2010[1] "Java Development Guide for Mac OS X"? [1] And thus pre-"Java for Mac OS X 10.6 Update 3, Java for Mac OS X 10.5 Update 8" What are the specific "features" you're missing? > Perhaps the most > popular ones will be reintroduced, but I doubt that Apple specific > functionality will end in the main JDK, that's not the place for it. > > 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 alexander.zuev at oracle.com Fri Jun 1 10:55:23 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 01 Jun 2012 21:55:23 +0400 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <4FC8E685.20705@oracle.com> References: <4FC88E22.10701@oracle.com> <4FC8E685.20705@oracle.com> Message-ID: <4FC9020B.50507@oracle.com> Artem, 1. Done 2. Yes, it's a wonderful idea, done. 3. User can construct a new DisplayMode object and ask us to set corresponding mode. New webrev can be found at http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.01 With best regards, Alex On 6/1/12 19:57, Artem Ananiev wrote: > Hi, Alex, > > here are some comments: > > 1. Please, update copyright dates in file headers. > > 2. I would pass w, h, bpp and refrate as method params to > setDisplayMode() to avoid extra JNI calls from native > > 3. Is it possible to call setDisplayMode() with a DisplayMode object > that was not obtained via previous getDisplayModes() call? If the > answer is "no", why don't you just check for exact match for all > parameters (w, h, bpp, refrate) in getBestModeForParameters()? > > Thanks, > > Artem > > On 6/1/2012 1:40 PM, Alexander Zuev wrote: >> Hello, >> >> please review my fix for CR 7124247: [macosx] Implement >> GraphicsDevice.setDisplayMode() >> >> CR description can be found here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 >> >> Webrev with the proposed change can be seen here: >> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 >> >> With best regards, >> Alex From swpalmer at gmail.com Fri Jun 1 11:44:46 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 1 Jun 2012 14:44:46 -0400 Subject: Transitioning from Apple extensions In-Reply-To: References: Message-ID: On 2012-06-01, at 1:32 PM, Chris Harshman wrote: > On Fri, Jun 1, 2012 at 1:07 AM, Mario Torre > wrote: > >> That's the bet that people lose when use proprietary extensions. >> > > Well, in fairness to OS X Java developers everywhere, Apple pitched Java as > a first-class dev environment for the Mac for years, before abdicating; > remember Steve Jobs joining McNealy during a JavaOne > keynote > ? > > At least the 'proprietary extensions' are still (from the developer's > perspective) Java, and can be coded around; i.e., it's *preferable* (for > Mac users/developers), but not *absolutely necessary* to use: > > > - The apple.laf.useScreenMenuBar system property (which itself takes > over from the deprecated com.apple.macos.useScreenMenuBar ) to use the > Mac's native top-of-screen menu bar instead of a menu bar attached to a > window (er, JFrame) instance; > - The apple.laf.AquaLookAndFeel Swing look and feel > - The com.apple.eawt.Application (i.e., .setDockIconImage(), > .setDockMenu(), etc) package to manage an application's dock presence; > - Apple's 'native' java.awt.FileDialog; > - The apple.awt.fileDialogForDirectories property (that begat this > thread that I've hijacked); > - The Window.documentModified property to indicate a 'dirty' (unsaved > changes) window state (this one may not be Mac-centric); > - The com.apple.eawt.* classes to handle Apple events (with, e.g., > ApplicationAdapter already deprecated in favor of > com.apple.eawt.AppEvent.* events...); etc. I think Windows 7 has the equivalent of a dock (the "taskbar"), and a dock menu, and changing dock icons (with progress indicators and such), etc? There is probably a windows equivalent of a quit message (independent of closing a window). Windows has a directory chooser, so the "fileDialogForDirectories" is not Mac-only either. There are lots of overlapping features that are not covered by the JRE. Given the Microsoft eventually just clones features from Mac OS? Maybe Oracle should simply use Mac OS as the basis of what will eventually become common functionality and provide support from the beginning. :-) There is already more than one place in the JRE that states the functionality may not be available on all platforms. So when Windows catches up the implementation can be fleshed out. Scott From swingler at apple.com Fri Jun 1 12:18:12 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 01 Jun 2012 12:18:12 -0700 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <4FC9020B.50507@oracle.com> References: <4FC88E22.10701@oracle.com> <4FC8E685.20705@oracle.com> <4FC9020B.50507@oracle.com> Message-ID: <3702960D-8492-4B10-A90E-F378F3B17555@apple.com> A few notes here: 1. getBestModeForParameters() should be called copyBestModeForParameters() - This is to pass the static-analyzer to validate that the retain/release balance is correct: copy implies returning a retained object, get implies non-retained. In this case you are returning a retained object that needs to be released. 2. getBestModeForParameters() is declared to return a CGDisplayModeRef, but you are actually returning a bestGuess CFStringRef. Which is it? 3. getBPPFromModeString() returns an int, but in one case you are assigning to a jint in Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode(). - Technically not an issue, but unexpected. 4. In Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode() you call CGDisplayModeGetRefreshRate(currentMode), but don't do anything with the return value, then later call it again, assigning it to the jint refrate. - What's up with this? Why call it twice? 5. In some places you use (*env)->FindClass(), and in others you use JNF_CLASS_CACHE(). - You can create array types using JNFNewObjectArray() and JNF_CLASS_CACHE(), which will benefit from fewer lines, and automatic exception throwing into Java, instead of just printing and suppressing the exception. 6. Your NSLog() in Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() says "CGRaphivsGevice". - I think you meant to say "CGraphicsDevice". 7. None of the if checks in getBestModeForParameters() need else { } blocks, because they implicitly exit the for loop. 8. getBPPFromModeString() can simply return the depth directly without assigning to a temporary. - I know this is more of a style thing, but I prefer fewer lines if possible. 9. Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode() leaks the closestMatch CGDisplayModeRef. - The "Create Rule" explains why this is a leak when fixed in conjunction with (1) above. - 10. What happens in the case of Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() where one of the CGDisplayModeRef's itterated on in the for loop is null? Is it OK to have empty nil holes in the returned array? Overall, I'm discouraged by this lack of attention to detail by both the author and reviewers. Mike Swingler Apple Inc. On Jun 1, 2012, at 10:55 AM, Alexander Zuev wrote: > Artem, > > 1. Done > 2. Yes, it's a wonderful idea, done. > 3. User can construct a new DisplayMode object and ask us to set corresponding mode. > > New webrev can be found at http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.01 > > With best regards, > Alex > > On 6/1/12 19:57, Artem Ananiev wrote: >> Hi, Alex, >> >> here are some comments: >> >> 1. Please, update copyright dates in file headers. >> >> 2. I would pass w, h, bpp and refrate as method params to setDisplayMode() to avoid extra JNI calls from native >> >> 3. Is it possible to call setDisplayMode() with a DisplayMode object that was not obtained via previous getDisplayModes() call? If the answer is "no", why don't you just check for exact match for all parameters (w, h, bpp, refrate) in getBestModeForParameters()? >> >> Thanks, >> >> Artem >> >> On 6/1/2012 1:40 PM, Alexander Zuev wrote: >>> Hello, >>> >>> please review my fix for CR 7124247: [macosx] Implement >>> GraphicsDevice.setDisplayMode() >>> >>> CR description can be found here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 >>> >>> Webrev with the proposed change can be seen here: >>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 >>> >>> With best regards, >>> Alex > From tomas.hurka at googlemail.com Fri Jun 1 23:54:58 2012 From: tomas.hurka at googlemail.com (Tomas Hurka) Date: Sat, 2 Jun 2012 08:54:58 +0200 Subject: autoreleased with no pool in place - just leaking Message-ID: <902CE961-E96A-4C39-AD34-2D27820BDF15@googlemail.com> Hi, when running Java2Demo with current JDK8 build, I have got the following warnings on the console: jdk8-tl thurka$ ./build/macosx-x86_64/j2sdk-image/bin/java -jar /Users/thurka/Projects/Source/Java2D/Java2Demo.jar 2012-06-02 08:44:23.751 java[4727:8107] *** __NSAutoreleaseNoPool(): Object 0x1002450d0 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-06-02 08:44:23.753 java[4727:8107] *** __NSAutoreleaseNoPool(): Object 0x1001e3530 of class NSConcreteValue autoreleased with no pool in place - just leaking 2012-06-02 08:44:23.753 java[4727:8107] *** __NSAutoreleaseNoPool(): Object 0x100234090 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-06-02 08:44:23.754 java[4727:8107] *** __NSAutoreleaseNoPool(): Object 0x1002cd7d0 of class NSConcreteValue autoreleased with no pool in place - just leaking 2012-06-02 08:44:23.754 java[4727:8107] *** __NSAutoreleaseNoPool(): Object 0x1002c0b70 of class NSCFDictionary autoreleased with no pool in place - just leaking jdk8-tl thurka$ The attached patch fixes this warning. Should I file CR for it? Bye, -- Tomas Hurka NetBeans Profiler http://profiler.netbeans.org VisualVM http://visualvm.java.net Software Developer Oracle, Praha Czech Republic From mik3hall at gmail.com Sat Jun 2 20:05:15 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 2 Jun 2012 22:05:15 -0500 Subject: Mac specific file meta information using nio.2 attributes Message-ID: I have put together something to provide some Mac platform api meta data using nio.2 and a little jni. Possibly it's to the point where there might be some feedback. If not of interest skip the rest. The download if you want to skip to that? http://www195.pair.com/mik3hall/trz.zip Mostly this is a follow up to this old java-dev list post http://lists.apple.com/archives/java-dev/2011/Jul/msg00031.html Re: JDK 1.7 & listing MacOS X file metadata? [was Re: OpenJDK 1.7] It attempts to provide a default 'file' scheme FileSystemProvider that is pass through for everything except the attributes which are overridden. Currently it supports 9 different Finder, mac_finder, attributes. Both getAttributes and setAttributes should be supported. For example for the locked flag that the above post was concerned with you could use something like? Files.setAttribute(p,"mac_finder:locked","true"); or Files.getAttribute(p,"mac_finder:locked"); It supports 13 different Launch Services, mac_ls, attributes, currently read only, getters there but setters shouldn't work. Some probably could have setters, some not. I decided not to do the application specific file type meta data that is mentioned in the list post. Although applications are meta rich files the Apple api's don't really support getting at it. I thought about hacking something using lsregister -dump maybe but decided against forcing an api. I still think if you have a meta rich file type that you work with a lot you could use this approach to provide custom attributes just for that file type. I am considering providing additional Cocoa NSFileManager meta information though. However, avoiding any more overlap than what is in the two views mentioned. How many ways do you need to access type/creator? It doesn't support BasicFileAttribute FileAttribute classes, so the bulk readAtttribute methods passing such classes aren't available. They possibly could be made so. Not a lot of testing to make sure all the pass through works. What JUnit testing there is, is in us.halll.trz.osx.test.MacAttributesTest, this might provide a little example usage to see what it's more or less doing. It would be a little disappointing to hear this is a terrible idea and I've been wasting my time. Other than that feedback would probably be welcome. From Alan.Bateman at oracle.com Sun Jun 3 09:20:00 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 03 Jun 2012 17:20:00 +0100 Subject: Mac specific file meta information using nio.2 attributes In-Reply-To: References: Message-ID: <4FCB8EB0.2050501@oracle.com> On 03/06/2012 04:05, Michael Hall wrote: > I have put together something to provide some Mac platform api meta data using nio.2 and a little jni. Possibly it's to the point where there might be some feedback. > The NIO file system API has many extension points, one of which is to interpose on the default provider, as you are doing, to add additional features. I looked briefly at your zip file and I would say that this is a good approach for prototyping and to help converge on a useful set of additional attributes that should be supported on this platform. For OpenJDK then we will need add better support for HFS+ and Mac specific file system features. If you look at what has been done for Solaris, Linux and Windows already then you'll see that the default provider on these platforms supports several file system and platform specific features beyond what is required by the specification. For Mac and HFS+ then things that come to mind are: - support for Unciode Normalization Form D and case insensitive file name comparison - a kqueue based WatchService (the Mac port is using the brain dead polling implementation that we have for platforms that don't have support for events from the file system). - a default FileSystemDetector for file content type detection - support for HFS+ file attributes like birth time and user flags. There is also extended attributes and ACLs. This seems to be the area that you are looking into now and it would be great to get the support for these attributes into the default provider (assuming they make sense of course). If you look at the existing code then you'll see how the Unix* provider is extended. -Alan. From mik3hall at gmail.com Sun Jun 3 10:51:06 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 3 Jun 2012 12:51:06 -0500 Subject: Mac specific file meta information using nio.2 attributes In-Reply-To: <4FCB8EB0.2050501@oracle.com> References: <4FCB8EB0.2050501@oracle.com> Message-ID: <02D46885-491F-45B2-A50F-1D548E149817@gmail.com> On Jun 3, 2012, at 11:20 AM, Alan Bateman wrote: > On 03/06/2012 04:05, Michael Hall wrote: >> I have put together something to provide some Mac platform api meta data using nio.2 and a little jni. Possibly it's to the point where there might be some feedback. >> > The NIO file system API has many extension points, one of which is to interpose on the default provider, as you are doing, to add additional features. I looked briefly at your zip file and I would say that this is a good approach for prototyping and to help converge on a useful set of additional attributes that should be supported on this platform. > > For OpenJDK then we will need add better support for HFS+ and Mac specific file system features. If you look at what has been done for Solaris, Linux and Windows already then you'll see that the default provider on these platforms supports several file system and platform specific features beyond what is required by the specification. For Mac and HFS+ then things that come to mind are: > > - support for Unciode Normalization Form D and case insensitive file name comparison Not familiar but I'll look into this. > > - a kqueue based WatchService (the Mac port is using the brain dead polling implementation that we have for platforms that don't have support for events from the file system). > Not an area I was into yet. Strictly attributes and related meta data. One advantage being as far as I knew it's not a project to-do item yet so I wouldn't be duplicating anyone's effort. > - a default FileSystemDetector for file content type detection > Not sure I've seen anything on this in what I've looked at so far. Aren't the providers and filesystems pretty much bound? I'll do some searching to see what I find on this. > - support for HFS+ file attributes like birth time and user flags. There is also extended attributes and ACLs. This seems to be the area that you are looking into now and it would be great to get the support for these attributes into the default provider (assuming they make sense of course). If you look at the existing code then you'll see how the Unix* provider is extended. The api's I've looked at so far and included meta data for are Finder and Launch Services. Still planning on also looking into NSFileManager related meta. You seem to consider HFS+ to involve different meta these don't pick up. I will have to look into that as well. I have been looking at the project nio source for the BSD/Unix providers and zip demo as reference and will continue to do this. > > -Alan. Thanks From anthony.petrov at oracle.com Mon Jun 4 06:22:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 04 Jun 2012 17:22:22 +0400 Subject: autoreleased with no pool in place - just leaking In-Reply-To: <902CE961-E96A-4C39-AD34-2D27820BDF15@googlemail.com> References: <902CE961-E96A-4C39-AD34-2D27820BDF15@googlemail.com> Message-ID: <4FCCB68E.5000509@oracle.com> Hi Tomas, Attachments don't work well on this mailing list. Could you please post your patch inline, or upload it somewhere (e.g. cr.openjdk.java.net)? -- best regards, Anthony On 06/02/12 10:54, Tomas Hurka wrote: > Hi, > when running Java2Demo with current JDK8 build, I have got the following warnings on the console: > > jdk8-tl thurka$ ./build/macosx-x86_64/j2sdk-image/bin/java -jar /Users/thurka/Projects/Source/Java2D/Java2Demo.jar > 2012-06-02 08:44:23.751 java[4727:8107] *** __NSAutoreleaseNoPool(): Object 0x1002450d0 of class NSCFNumber autoreleased with no pool in place - just leaking > 2012-06-02 08:44:23.753 java[4727:8107] *** __NSAutoreleaseNoPool(): Object 0x1001e3530 of class NSConcreteValue autoreleased with no pool in place - just leaking > 2012-06-02 08:44:23.753 java[4727:8107] *** __NSAutoreleaseNoPool(): Object 0x100234090 of class NSCFNumber autoreleased with no pool in place - just leaking > 2012-06-02 08:44:23.754 java[4727:8107] *** __NSAutoreleaseNoPool(): Object 0x1002cd7d0 of class NSConcreteValue autoreleased with no pool in place - just leaking > 2012-06-02 08:44:23.754 java[4727:8107] *** __NSAutoreleaseNoPool(): Object 0x1002c0b70 of class NSCFDictionary autoreleased with no pool in place - just leaking > jdk8-tl thurka$ > > The attached patch fixes this warning. Should I file CR for it? > > Bye, > -- > Tomas Hurka > NetBeans Profiler http://profiler.netbeans.org > VisualVM http://visualvm.java.net > Software Developer > Oracle, Praha Czech Republic > > From tomas.hurka at googlemail.com Mon Jun 4 07:44:33 2012 From: tomas.hurka at googlemail.com (Tomas Hurka) Date: Mon, 4 Jun 2012 16:44:33 +0200 Subject: autoreleased with no pool in place - just leaking In-Reply-To: <4FCCB68E.5000509@oracle.com> References: <902CE961-E96A-4C39-AD34-2D27820BDF15@googlemail.com> <4FCCB68E.5000509@oracle.com> Message-ID: Hi Anthony, On 4 Jun 2012, at 15:22, Anthony Petrov wrote: > > Attachments don't work well on this mailing list. I see. > Could you please post your patch inline, or upload it somewhere (e.g. cr.openjdk.java.net)? OK, here is the webrev: Bye, -- Tomas Hurka NetBeans Profiler http://profiler.netbeans.org VisualVM http://visualvm.java.net Software Developer Oracle, Praha Czech Republic From anthony.petrov at oracle.com Mon Jun 4 07:48:44 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 04 Jun 2012 18:48:44 +0400 Subject: [8] Review request for: 7172722: Latest jdk7u from OSX broke universal build In-Reply-To: References: <4FC60EDE.4020805@oracle.com> Message-ID: <4FCCCACC.2090803@oracle.com> AWT/MacOSX-port-dev teams, Could I get a review for this one-line fix please? -- best regards, Anthony On 06/01/12 12:47, Henri Gomez wrote: > Tested and it works for me. > > I just produced jdk7u b12 with it : > > http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u6-b12-20120601.dmg > > Cheers > > 2012/5/30 Anthony Petrov: >> Hello, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7172722 at: >> >> http://cr.openjdk.java.net/~anthony/8-33-MacUniversalBuild-7172722.0/ >> >> I've simplified the fix comparing to original Henri's proposal [1] to follow >> the same pattern as we use with other properties: we simply give the >> corresponding class fields the same names as to the properties themselves. >> >> Henri: please verify if the new patch works for you. >> >> [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-May/003191.html >> >> -- >> best regards, >> Anthony From swingler at apple.com Mon Jun 4 08:04:12 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 04 Jun 2012 08:04:12 -0700 Subject: [8] Review request for: 7172722: Latest jdk7u from OSX broke universal build In-Reply-To: <4FCCCACC.2090803@oracle.com> References: <4FC60EDE.4020805@oracle.com> <4FCCCACC.2090803@oracle.com> Message-ID: Looks great. Mike Swingler Apple Inc. On Jun 4, 2012, at 7:48 AM, Anthony Petrov wrote: > AWT/MacOSX-port-dev teams, > > Could I get a review for this one-line fix please? > > -- > best regards, > Anthony > > On 06/01/12 12:47, Henri Gomez wrote: >> Tested and it works for me. >> >> I just produced jdk7u b12 with it : >> >> http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u6-b12-20120601.dmg >> >> Cheers >> >> 2012/5/30 Anthony Petrov: >>> Hello, >>> >>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7172722 at: >>> >>> http://cr.openjdk.java.net/~anthony/8-33-MacUniversalBuild-7172722.0/ >>> >>> I've simplified the fix comparing to original Henri's proposal [1] to follow >>> the same pattern as we use with other properties: we simply give the >>> corresponding class fields the same names as to the properties themselves. >>> >>> Henri: please verify if the new patch works for you. >>> >>> [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-May/003191.html >>> >>> -- >>> best regards, >>> Anthony From Sergey.Bylokhov at oracle.com Mon Jun 4 08:09:21 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 04 Jun 2012 19:09:21 +0400 Subject: [8] Review request for: 7172722: Latest jdk7u from OSX broke universal build In-Reply-To: <4FCCCACC.2090803@oracle.com> References: <4FC60EDE.4020805@oracle.com> <4FCCCACC.2090803@oracle.com> Message-ID: <4FCCCFA1.1070108@oracle.com> Fix looks good. Thanks. 04.06.2012 18:48, Anthony Petrov wrote: > AWT/MacOSX-port-dev teams, > > Could I get a review for this one-line fix please? > > -- > best regards, > Anthony > > On 06/01/12 12:47, Henri Gomez wrote: >> Tested and it works for me. >> >> I just produced jdk7u b12 with it : >> >> http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u6-b12-20120601.dmg >> >> >> Cheers >> >> 2012/5/30 Anthony Petrov: >>> Hello, >>> >>> Please review a fix for >>> http://bugs.sun.com/view_bug.do?bug_id=7172722 at: >>> >>> http://cr.openjdk.java.net/~anthony/8-33-MacUniversalBuild-7172722.0/ >>> >>> I've simplified the fix comparing to original Henri's proposal [1] >>> to follow >>> the same pattern as we use with other properties: we simply give the >>> corresponding class fields the same names as to the properties >>> themselves. >>> >>> Henri: please verify if the new patch works for you. >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-May/003191.html >>> >>> -- >>> best regards, >>> Anthony -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Jun 4 08:49:47 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 04 Jun 2012 19:49:47 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support Message-ID: <4FCCD91B.30503@oracle.com> Hi Everyone, Please review the fix. Shaped window was implemented as a translucent window with constrained graphics. Now translucent window doesn't use separate BufferedImage as a back buffer. Also alpha value for the swing back buffer was enabled(Shared code changed). Note that shaped windows are affected by this bugs: http://monaco.us.oracle.com/detail.jsf?cr=7124236 - Shadows disappear. - Transparent areas aren't transparent to mouse clicks. http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 - Opacity does not work for non opaque windows. Any suggestions are welcome. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.00 -- Best regards, Sergey. From alexander.zuev at oracle.com Mon Jun 4 11:18:49 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 04 Jun 2012 22:18:49 +0400 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <3702960D-8492-4B10-A90E-F378F3B17555@apple.com> References: <4FC88E22.10701@oracle.com> <4FC8E685.20705@oracle.com> <4FC9020B.50507@oracle.com> <3702960D-8492-4B10-A90E-F378F3B17555@apple.com> Message-ID: <4FCCFC09.7030805@oracle.com> Mike, thanks for a superb review. See comments inline. With best regards, Alex On 6/1/12 23:18, Mike Swingler wrote: > A few notes here: > > 1. getBestModeForParameters() should be called copyBestModeForParameters() > - This is to pass the static-analyzer to validate that the retain/release balance is correct: copy implies returning a retained object, get implies non-retained. In this case you are returning a retained object that needs to be released. I wasn't aware that static-analyzer takes into account the function names. Anyways - in this case you are quite wrong. I'm not creating any new objects here. What i get as a parameter is an array of the references (pointers) and i'm returning one of them that satisfy the conditions based on the other parameters passed. There is no need in releasing the object referred by that pointer - quite contrary if i DO release closestMatch in the Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode then next time i try to set the same display mode i will get the nice application crash. Something like this: 0 libsystem_kernel.dylib 0x00007fff85c55ce2 __pthread_kill + 10 1 libsystem_c.dylib 0x00007fff8b42e7d2 pthread_kill + 95 2 libsystem_c.dylib 0x00007fff8b41fa7a abort + 143 3 libjvm.dylib 0x0000000102fadb79 os::abort(bool) + 25 4 libjvm.dylib 0x0000000103099dd0 VMError::report_and_die() + 2306 5 libjvm.dylib 0x0000000102faf255 JVM_handle_bsd_signal + 1047 6 libsystem_c.dylib 0x00007fff8b480cfa _sigtramp + 26 7 com.apple.CoreFoundation 0x00007fff8d125877 CFDictionaryGetValue + 23 8 com.apple.CoreGraphics 0x00007fff83b0daec CGDisplayModeGetResolution + 40 9 com.apple.CoreGraphics 0x00007fff83b0f84f CGDisplayCopyAllDisplayModes + 278 10 liblwawt.dylib 0x000000015fc1b35d Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode + 57 > 2. getBestModeForParameters() is declared to return a CGDisplayModeRef, but you are actually returning a bestGuess CFStringRef. Which is it? Glitch. Fixed it. Strange that compiler did not issued a warning about this return > 3. getBPPFromModeString() returns an int, but in one case you are assigning to a jint in Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode(). > - Technically not an issue, but unexpected. I can add implicit cast to jint - but technically it is not an issue as you mentioned . > 4. In Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode() you call CGDisplayModeGetRefreshRate(currentMode), but don't do anything with the return value, then later call it again, assigning it to the jint refrate. > - What's up with this? Why call it twice? Another glitch. Friday evening syndrome. > 5. In some places you use (*env)->FindClass(), and in others you use JNF_CLASS_CACHE(). > - You can create array types using JNFNewObjectArray() and JNF_CLASS_CACHE(), which will benefit from fewer lines, and automatic exception throwing into Java, instead of just printing and suppressing the exception. Well, valid point - i'll use the JNF functions for array creation for the sake of consistency. > 6. Your NSLog() in Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() says "CGRaphivsGevice". > - I think you meant to say "CGraphicsDevice". You're absolutely right. > 7. None of the if checks in getBestModeForParameters() need else { } blocks, because they implicitly exit the for loop. I've added them for the better code readability but as it makes code more compact i may as well remove them. > 8. getBPPFromModeString() can simply return the depth directly without assigning to a temporary. > - I know this is more of a style thing, but I prefer fewer lines if possible. Hmm. Ok, not a big deal but if it makes you a little bit happier i'll surely do that. > 9. Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode() leaks the closestMatch CGDisplayModeRef. > - The "Create Rule" explains why this is a leak when fixed in conjunction with (1) above. > - How comes? I do not use Copy-methods to get the exact configuration, i get the array of references to the Quartz DisplayMode's and i don't create any new CGDisplayMode objects. And i do release the array itself. Where is the memory leak? > 10. What happens in the case of Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() where one of the CGDisplayModeRef's itterated on in the for loop is null? Is it OK to have empty nil holes in the returned array? I tried to pass the null as one of the array elements back to Java - seems that it's Ok so i will left it as it is now. > Overall, I'm discouraged by this lack of attention to detail by both the author and reviewers. Stuff happens, especially at Friday evening, but all for all there was no major problems just some non-critical glitches here and there. And you are one of reviewers so the review process is fairly good at the end. Anyways - the new webrev can be found here http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.02 Comments are welcome. > > Mike Swingler > Apple Inc. > > On Jun 1, 2012, at 10:55 AM, Alexander Zuev wrote: > >> Artem, >> >> 1. Done >> 2. Yes, it's a wonderful idea, done. >> 3. User can construct a new DisplayMode object and ask us to set corresponding mode. >> >> New webrev can be found at http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.01 >> >> With best regards, >> Alex >> >> On 6/1/12 19:57, Artem Ananiev wrote: >>> Hi, Alex, >>> >>> here are some comments: >>> >>> 1. Please, update copyright dates in file headers. >>> >>> 2. I would pass w, h, bpp and refrate as method params to setDisplayMode() to avoid extra JNI calls from native >>> >>> 3. Is it possible to call setDisplayMode() with a DisplayMode object that was not obtained via previous getDisplayModes() call? If the answer is "no", why don't you just check for exact match for all parameters (w, h, bpp, refrate) in getBestModeForParameters()? >>> >>> Thanks, >>> >>> Artem >>> >>> On 6/1/2012 1:40 PM, Alexander Zuev wrote: >>>> Hello, >>>> >>>> please review my fix for CR 7124247: [macosx] Implement >>>> GraphicsDevice.setDisplayMode() >>>> >>>> CR description can be found here: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 >>>> >>>> Webrev with the proposed change can be seen here: >>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 >>>> >>>> With best regards, >>>> Alex From mik3hall at gmail.com Mon Jun 4 15:41:09 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 4 Jun 2012 17:41:09 -0500 Subject: Mac specific file meta information using nio.2 attributes In-Reply-To: <02D46885-491F-45B2-A50F-1D548E149817@gmail.com> References: <4FCB8EB0.2050501@oracle.com> <02D46885-491F-45B2-A50F-1D548E149817@gmail.com> Message-ID: <18EC726F-6402-4996-8463-870D5617C1DB@gmail.com> On Jun 3, 2012, at 12:51 PM, Michael Hall wrote: > > On Jun 3, 2012, at 11:20 AM, Alan Bateman wrote: > >> On 03/06/2012 04:05, Michael Hall wrote: >>> I have put together something to provide some Mac platform api meta data using nio.2 and a little jni. Possibly it's to the point where there might be some feedback. >>> >> The NIO file system API has many extension points, one of which is to interpose on the default provider, as you are doing, to add additional features. I looked briefly at your zip file and I would say that this is a good approach for prototyping and to help converge on a useful set of additional attributes that should be supported on this platform. >> >> For OpenJDK then we will need add better support for HFS+ and Mac specific file system features. If you look at what has been done for Solaris, Linux and Windows already then you'll see that the default provider on these platforms supports several file system and platform specific features beyond what is required by the specification. For Mac and HFS+ then things that come to mind are: Judging by feedback there is no hurry for me to get a project set up for this. I sort of like it, extending the filesystem is an interesting feature I thought worth some time. The best I can do for it otherwise for now is make it an official download of mine. http://www195.pair.com/mik3hall/index.html#macattr From henri.gomez at gmail.com Mon Jun 4 23:45:38 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 5 Jun 2012 08:45:38 +0200 Subject: [8] Review request for: 7172722: Latest jdk7u from OSX broke universal build In-Reply-To: <4FCCCFA1.1070108@oracle.com> References: <4FC60EDE.4020805@oracle.com> <4FCCCACC.2090803@oracle.com> <4FCCCFA1.1070108@oracle.com> Message-ID: > Fix looks good. > Thanks. Thanks guys ! From anthony.petrov at oracle.com Tue Jun 5 04:40:31 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 05 Jun 2012 15:40:31 +0400 Subject: [7u6] Review request for: 7172722: Latest jdk7u from OSX broke universal build Message-ID: <4FCDF02F.3040006@oracle.com> Hi Artem and Sergey, Please review a direct back-port of this one-line fix for http://bugs.sun.com/view_bug.do?bug_id=7172722 at: http://cr.openjdk.java.net/~anthony/7u6-11-MacUniversalBuild-7172722.0/ The fix has been verified by Henri Gomez, and has already been pushed to JDK 8. -- best regards, Anthony From henri.gomez at gmail.com Tue Jun 5 05:41:22 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 5 Jun 2012 14:41:22 +0200 Subject: trustAnchors parameter must be non-empty In-Reply-To: <04D7AA73-D23E-4E3C-B93F-563DC895FE13@oracle.com> References: <0CA55830-4615-4DA4-8EE1-60643620E16E@gmail.com> <53F68927-F232-45F7-AD90-12B9C68880E0@apple.com> <40380BCE-A778-413E-A970-1487F237E0AE@apple.com> <04D7AA73-D23E-4E3C-B93F-563DC895FE13@oracle.com> Message-ID: Just found this old thread. cacerts for openjdk-osx-build will now use Mozilla CA Certs and bundled them in its DMG. Cheers 2012/3/4 Scott Kovatch : > 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 Sergey.Bylokhov at oracle.com Tue Jun 5 06:43:27 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 05 Jun 2012 17:43:27 +0400 Subject: [7u6] Review request for: 7172722: Latest jdk7u from OSX broke universal build In-Reply-To: <4FCDF02F.3040006@oracle.com> References: <4FCDF02F.3040006@oracle.com> Message-ID: <4FCE0CFF.8010909@oracle.com> Hi, Anthony. Fix looks good. 05.06.2012 15:40, Anthony Petrov wrote: > Hi Artem and Sergey, > > Please review a direct back-port of this one-line fix for > http://bugs.sun.com/view_bug.do?bug_id=7172722 at: > > http://cr.openjdk.java.net/~anthony/7u6-11-MacUniversalBuild-7172722.0/ > > The fix has been verified by Henri Gomez, and has already been pushed > to JDK 8. > > -- > best regards, > Anthony -- Best regards, Sergey. From alexander.zuev at oracle.com Tue Jun 5 06:46:37 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 05 Jun 2012 17:46:37 +0400 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <4FCCFC09.7030805@oracle.com> References: <4FC88E22.10701@oracle.com> <4FC8E685.20705@oracle.com> <4FC9020B.50507@oracle.com> <3702960D-8492-4B10-A90E-F378F3B17555@apple.com> <4FCCFC09.7030805@oracle.com> Message-ID: <4FCE0DBD.8090507@oracle.com> Yet another version of the webrev - fixed some typos in comments (thanks Scott Palmer) and added updating full screen window size if we are currently in full screen mode. Webrev is here: http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.03 With best regards, Alex On 6/4/12 22:18, Alexander Zuev wrote: > Mike, > > thanks for a superb review. See comments inline. > > With best regards, > Alex > > On 6/1/12 23:18, Mike Swingler wrote: >> A few notes here: >> >> 1. getBestModeForParameters() should be called >> copyBestModeForParameters() >> - This is to pass the static-analyzer to validate that the >> retain/release balance is correct: copy implies returning a retained >> object, get implies non-retained. In this case you are returning a >> retained object that needs to be released. > I wasn't aware that static-analyzer takes into account the function > names. Anyways - in this case you are quite wrong. I'm not creating > any new objects here. What i get as a parameter is an array of the > references (pointers) and i'm returning one of them > that satisfy the conditions based on the other parameters passed. > There is no need in releasing the object referred by that > pointer - quite contrary if i DO release closestMatch in the > Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode then next > time i try to set the same display mode i will get the nice > application crash. Something like this: > > 0 libsystem_kernel.dylib 0x00007fff85c55ce2 > __pthread_kill + 10 > 1 libsystem_c.dylib 0x00007fff8b42e7d2 pthread_kill > + 95 > 2 libsystem_c.dylib 0x00007fff8b41fa7a abort + 143 > 3 libjvm.dylib 0x0000000102fadb79 > os::abort(bool) + 25 > 4 libjvm.dylib 0x0000000103099dd0 > VMError::report_and_die() + 2306 > 5 libjvm.dylib 0x0000000102faf255 > JVM_handle_bsd_signal + 1047 > 6 libsystem_c.dylib 0x00007fff8b480cfa _sigtramp + 26 > 7 com.apple.CoreFoundation 0x00007fff8d125877 > CFDictionaryGetValue + 23 > 8 com.apple.CoreGraphics 0x00007fff83b0daec > CGDisplayModeGetResolution + 40 > 9 com.apple.CoreGraphics 0x00007fff83b0f84f > CGDisplayCopyAllDisplayModes + 278 > 10 liblwawt.dylib 0x000000015fc1b35d > Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode + 57 > >> 2. getBestModeForParameters() is declared to return a >> CGDisplayModeRef, but you are actually returning a bestGuess >> CFStringRef. Which is it? > Glitch. Fixed it. Strange that compiler did not issued a warning about > this return >> 3. getBPPFromModeString() returns an int, but in one case you are >> assigning to a jint in >> Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode(). >> - Technically not an issue, but unexpected. > I can add implicit cast to jint - but technically it is not an issue > as you mentioned . >> 4. In Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode() you call >> CGDisplayModeGetRefreshRate(currentMode), but don't do anything with >> the return value, then later call it again, assigning it to the jint >> refrate. >> - What's up with this? Why call it twice? > Another glitch. Friday evening syndrome. >> 5. In some places you use (*env)->FindClass(), and in others you use >> JNF_CLASS_CACHE(). >> - You can create array types using JNFNewObjectArray() and >> JNF_CLASS_CACHE(), which will benefit from fewer lines, and automatic >> exception throwing into Java, instead of just printing and >> suppressing the exception. > Well, valid point - i'll use the JNF functions for array creation for > the sake of consistency. >> 6. Your NSLog() in >> Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() says >> "CGRaphivsGevice". >> - I think you meant to say "CGraphicsDevice". > You're absolutely right. >> 7. None of the if checks in getBestModeForParameters() need else { } >> blocks, because they implicitly exit the for loop. > I've added them for the better code readability but as it makes code > more compact i may as well remove them. >> 8. getBPPFromModeString() can simply return the depth directly >> without assigning to a temporary. >> - I know this is more of a style thing, but I prefer fewer lines >> if possible. > Hmm. Ok, not a big deal but if it makes you a little bit happier i'll > surely do that. >> 9. Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode() leaks the >> closestMatch CGDisplayModeRef. >> - The "Create Rule" explains why this is a leak when fixed in >> conjunction with (1) above. >> - >> > How comes? I do not use Copy-methods to get the exact configuration, i > get the array of references to the Quartz DisplayMode's > and i don't create any new CGDisplayMode objects. And i do release the > array itself. Where is the memory leak? > >> 10. What happens in the case of >> Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() where one of the >> CGDisplayModeRef's itterated on in the for loop is null? Is it OK to >> have empty nil holes in the returned array? > I tried to pass the null as one of the array elements back to Java - > seems that it's Ok so i will left it as it is now. >> Overall, I'm discouraged by this lack of attention to detail by both >> the author and reviewers. > Stuff happens, especially at Friday evening, but all for all there was > no major problems just some non-critical glitches here and there. And > you are one of reviewers so the review process is fairly good at the end. > > Anyways - the new webrev can be found here > http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.02 > Comments are welcome. > > >> >> Mike Swingler >> Apple Inc. >> >> On Jun 1, 2012, at 10:55 AM, Alexander Zuev wrote: >> >>> Artem, >>> >>> 1. Done >>> 2. Yes, it's a wonderful idea, done. >>> 3. User can construct a new DisplayMode object and ask us to set >>> corresponding mode. >>> >>> New webrev can be found at >>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.01 >>> >>> With best regards, >>> Alex >>> >>> On 6/1/12 19:57, Artem Ananiev wrote: >>>> Hi, Alex, >>>> >>>> here are some comments: >>>> >>>> 1. Please, update copyright dates in file headers. >>>> >>>> 2. I would pass w, h, bpp and refrate as method params to >>>> setDisplayMode() to avoid extra JNI calls from native >>>> >>>> 3. Is it possible to call setDisplayMode() with a DisplayMode >>>> object that was not obtained via previous getDisplayModes() call? >>>> If the answer is "no", why don't you just check for exact match for >>>> all parameters (w, h, bpp, refrate) in getBestModeForParameters()? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 6/1/2012 1:40 PM, Alexander Zuev wrote: >>>>> Hello, >>>>> >>>>> please review my fix for CR 7124247: [macosx] Implement >>>>> GraphicsDevice.setDisplayMode() >>>>> >>>>> CR description can be found here: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 >>>>> >>>>> Webrev with the proposed change can be seen here: >>>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 >>>>> >>>>> With best regards, >>>>> Alex > From anthony.petrov at oracle.com Tue Jun 5 07:38:01 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 05 Jun 2012 18:38:01 +0400 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <4FCE0DBD.8090507@oracle.com> References: <4FC88E22.10701@oracle.com> <4FC8E685.20705@oracle.com> <4FC9020B.50507@oracle.com> <3702960D-8492-4B10-A90E-F378F3B17555@apple.com> <4FCCFC09.7030805@oracle.com> <4FCE0DBD.8090507@oracle.com> Message-ID: <4FCE19C9.5080001@oracle.com> Hi Alex, The code at lines 163-171 and 202-209 is very similar, and I believe it can be extracted into a separate utility function. -- best regards, Anthony On 6/5/2012 5:46 PM, Alexander Zuev wrote: > Yet another version of the webrev - fixed some typos in comments (thanks > Scott Palmer) and > added updating full screen window size if we are currently in full > screen mode. > > Webrev is here: http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.03 > > With best regards, > Alex > > On 6/4/12 22:18, Alexander Zuev wrote: >> Mike, >> >> thanks for a superb review. See comments inline. >> >> With best regards, >> Alex >> >> On 6/1/12 23:18, Mike Swingler wrote: >>> A few notes here: >>> >>> 1. getBestModeForParameters() should be called >>> copyBestModeForParameters() >>> - This is to pass the static-analyzer to validate that the >>> retain/release balance is correct: copy implies returning a retained >>> object, get implies non-retained. In this case you are returning a >>> retained object that needs to be released. >> I wasn't aware that static-analyzer takes into account the function >> names. Anyways - in this case you are quite wrong. I'm not creating >> any new objects here. What i get as a parameter is an array of the >> references (pointers) and i'm returning one of them >> that satisfy the conditions based on the other parameters passed. >> There is no need in releasing the object referred by that >> pointer - quite contrary if i DO release closestMatch in the >> Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode then next >> time i try to set the same display mode i will get the nice >> application crash. Something like this: >> >> 0 libsystem_kernel.dylib 0x00007fff85c55ce2 >> __pthread_kill + 10 >> 1 libsystem_c.dylib 0x00007fff8b42e7d2 pthread_kill >> + 95 >> 2 libsystem_c.dylib 0x00007fff8b41fa7a abort + 143 >> 3 libjvm.dylib 0x0000000102fadb79 >> os::abort(bool) + 25 >> 4 libjvm.dylib 0x0000000103099dd0 >> VMError::report_and_die() + 2306 >> 5 libjvm.dylib 0x0000000102faf255 >> JVM_handle_bsd_signal + 1047 >> 6 libsystem_c.dylib 0x00007fff8b480cfa _sigtramp + 26 >> 7 com.apple.CoreFoundation 0x00007fff8d125877 >> CFDictionaryGetValue + 23 >> 8 com.apple.CoreGraphics 0x00007fff83b0daec >> CGDisplayModeGetResolution + 40 >> 9 com.apple.CoreGraphics 0x00007fff83b0f84f >> CGDisplayCopyAllDisplayModes + 278 >> 10 liblwawt.dylib 0x000000015fc1b35d >> Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode + 57 >> >>> 2. getBestModeForParameters() is declared to return a >>> CGDisplayModeRef, but you are actually returning a bestGuess >>> CFStringRef. Which is it? >> Glitch. Fixed it. Strange that compiler did not issued a warning about >> this return >>> 3. getBPPFromModeString() returns an int, but in one case you are >>> assigning to a jint in >>> Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode(). >>> - Technically not an issue, but unexpected. >> I can add implicit cast to jint - but technically it is not an issue >> as you mentioned . >>> 4. In Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode() you call >>> CGDisplayModeGetRefreshRate(currentMode), but don't do anything with >>> the return value, then later call it again, assigning it to the jint >>> refrate. >>> - What's up with this? Why call it twice? >> Another glitch. Friday evening syndrome. >>> 5. In some places you use (*env)->FindClass(), and in others you use >>> JNF_CLASS_CACHE(). >>> - You can create array types using JNFNewObjectArray() and >>> JNF_CLASS_CACHE(), which will benefit from fewer lines, and automatic >>> exception throwing into Java, instead of just printing and >>> suppressing the exception. >> Well, valid point - i'll use the JNF functions for array creation for >> the sake of consistency. >>> 6. Your NSLog() in >>> Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() says >>> "CGRaphivsGevice". >>> - I think you meant to say "CGraphicsDevice". >> You're absolutely right. >>> 7. None of the if checks in getBestModeForParameters() need else { } >>> blocks, because they implicitly exit the for loop. >> I've added them for the better code readability but as it makes code >> more compact i may as well remove them. >>> 8. getBPPFromModeString() can simply return the depth directly >>> without assigning to a temporary. >>> - I know this is more of a style thing, but I prefer fewer lines >>> if possible. >> Hmm. Ok, not a big deal but if it makes you a little bit happier i'll >> surely do that. >>> 9. Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode() leaks the >>> closestMatch CGDisplayModeRef. >>> - The "Create Rule" explains why this is a leak when fixed in >>> conjunction with (1) above. >>> >>> - >>> >> How comes? I do not use Copy-methods to get the exact configuration, i >> get the array of references to the Quartz DisplayMode's >> and i don't create any new CGDisplayMode objects. And i do release the >> array itself. Where is the memory leak? >> >>> 10. What happens in the case of >>> Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() where one of the >>> CGDisplayModeRef's itterated on in the for loop is null? Is it OK to >>> have empty nil holes in the returned array? >> I tried to pass the null as one of the array elements back to Java - >> seems that it's Ok so i will left it as it is now. >>> Overall, I'm discouraged by this lack of attention to detail by both >>> the author and reviewers. >> Stuff happens, especially at Friday evening, but all for all there was >> no major problems just some non-critical glitches here and there. And >> you are one of reviewers so the review process is fairly good at the end. >> >> Anyways - the new webrev can be found here >> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.02 >> Comments are welcome. >> >> >>> >>> Mike Swingler >>> Apple Inc. >>> >>> On Jun 1, 2012, at 10:55 AM, Alexander Zuev wrote: >>> >>>> Artem, >>>> >>>> 1. Done >>>> 2. Yes, it's a wonderful idea, done. >>>> 3. User can construct a new DisplayMode object and ask us to set >>>> corresponding mode. >>>> >>>> New webrev can be found at >>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.01 >>>> >>>> With best regards, >>>> Alex >>>> >>>> On 6/1/12 19:57, Artem Ananiev wrote: >>>>> Hi, Alex, >>>>> >>>>> here are some comments: >>>>> >>>>> 1. Please, update copyright dates in file headers. >>>>> >>>>> 2. I would pass w, h, bpp and refrate as method params to >>>>> setDisplayMode() to avoid extra JNI calls from native >>>>> >>>>> 3. Is it possible to call setDisplayMode() with a DisplayMode >>>>> object that was not obtained via previous getDisplayModes() call? >>>>> If the answer is "no", why don't you just check for exact match for >>>>> all parameters (w, h, bpp, refrate) in getBestModeForParameters()? >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 6/1/2012 1:40 PM, Alexander Zuev wrote: >>>>>> Hello, >>>>>> >>>>>> please review my fix for CR 7124247: [macosx] Implement >>>>>> GraphicsDevice.setDisplayMode() >>>>>> >>>>>> CR description can be found here: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 >>>>>> >>>>>> Webrev with the proposed change can be seen here: >>>>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 >>>>>> >>>>>> With best regards, >>>>>> Alex >> > From anthony.petrov at oracle.com Tue Jun 5 08:05:02 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 05 Jun 2012 19:05:02 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FCCD91B.30503@oracle.com> References: <4FCCD91B.30503@oracle.com> Message-ID: <4FCE201E.503@oracle.com> Hi Sergey, A couple of comments: 1. src/macosx/classes/sun/lwawt/LWWindowPeer.java > 576 //flushOnscreenGraphics(); There's no any explanation as to why this line is commented out. Could you either add a remark in the code, or delete this line altogether? 2. How does the fix affect the performance of non-opaque (and opaque, too) windows? -- best regards, Anthony On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > > Shaped window was implemented as a translucent window with constrained > graphics. Now translucent window doesn't use separate BufferedImage as a > back buffer. Also alpha value for the swing back buffer was > enabled(Shared code changed). > Note that shaped windows are affected by this bugs: > http://monaco.us.oracle.com/detail.jsf?cr=7124236 > - Shadows disappear. > - Transparent areas aren't transparent to mouse clicks. > http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 > - Opacity does not work for non opaque windows. > > Any suggestions are welcome. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.00 > From alexander.zuev at oracle.com Tue Jun 5 08:29:03 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 05 Jun 2012 19:29:03 +0400 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <4FCE19C9.5080001@oracle.com> References: <4FC88E22.10701@oracle.com> <4FC8E685.20705@oracle.com> <4FC9020B.50507@oracle.com> <3702960D-8492-4B10-A90E-F378F3B17555@apple.com> <4FCCFC09.7030805@oracle.com> <4FCE0DBD.8090507@oracle.com> <4FCE19C9.5080001@oracle.com> Message-ID: <4FCE25BF.3030903@oracle.com> Yes, they are similar, but making a new function for the 8 lines of code? Don't think it's worth it. With best regards, Alex On 6/5/12 18:38, Anthony Petrov wrote: > Hi Alex, > > The code at lines 163-171 and 202-209 is very similar, and I believe > it can be extracted into a separate utility function. > > -- > best regards, > Anthony > > On 6/5/2012 5:46 PM, Alexander Zuev wrote: >> Yet another version of the webrev - fixed some typos in comments >> (thanks Scott Palmer) and >> added updating full screen window size if we are currently in full >> screen mode. >> >> Webrev is here: >> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.03 >> >> With best regards, >> Alex >> >> On 6/4/12 22:18, Alexander Zuev wrote: >>> Mike, >>> >>> thanks for a superb review. See comments inline. >>> >>> With best regards, >>> Alex >>> >>> On 6/1/12 23:18, Mike Swingler wrote: >>>> A few notes here: >>>> >>>> 1. getBestModeForParameters() should be called >>>> copyBestModeForParameters() >>>> - This is to pass the static-analyzer to validate that the >>>> retain/release balance is correct: copy implies returning a >>>> retained object, get implies non-retained. In this case you are >>>> returning a retained object that needs to be released. >>> I wasn't aware that static-analyzer takes into account the function >>> names. Anyways - in this case you are quite wrong. I'm not creating >>> any new objects here. What i get as a parameter is an array of the >>> references (pointers) and i'm returning one of them >>> that satisfy the conditions based on the other parameters passed. >>> There is no need in releasing the object referred by that >>> pointer - quite contrary if i DO release closestMatch in the >>> Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode then next >>> time i try to set the same display mode i will get the nice >>> application crash. Something like this: >>> >>> 0 libsystem_kernel.dylib 0x00007fff85c55ce2 >>> __pthread_kill + 10 >>> 1 libsystem_c.dylib 0x00007fff8b42e7d2 >>> pthread_kill + 95 >>> 2 libsystem_c.dylib 0x00007fff8b41fa7a abort + 143 >>> 3 libjvm.dylib 0x0000000102fadb79 >>> os::abort(bool) + 25 >>> 4 libjvm.dylib 0x0000000103099dd0 >>> VMError::report_and_die() + 2306 >>> 5 libjvm.dylib 0x0000000102faf255 >>> JVM_handle_bsd_signal + 1047 >>> 6 libsystem_c.dylib 0x00007fff8b480cfa _sigtramp + 26 >>> 7 com.apple.CoreFoundation 0x00007fff8d125877 >>> CFDictionaryGetValue + 23 >>> 8 com.apple.CoreGraphics 0x00007fff83b0daec >>> CGDisplayModeGetResolution + 40 >>> 9 com.apple.CoreGraphics 0x00007fff83b0f84f >>> CGDisplayCopyAllDisplayModes + 278 >>> 10 liblwawt.dylib 0x000000015fc1b35d >>> Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode + 57 >>> >>>> 2. getBestModeForParameters() is declared to return a >>>> CGDisplayModeRef, but you are actually returning a bestGuess >>>> CFStringRef. Which is it? >>> Glitch. Fixed it. Strange that compiler did not issued a warning >>> about this return >>>> 3. getBPPFromModeString() returns an int, but in one case you are >>>> assigning to a jint in >>>> Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode(). >>>> - Technically not an issue, but unexpected. >>> I can add implicit cast to jint - but technically it is not an issue >>> as you mentioned . >>>> 4. In Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode() you call >>>> CGDisplayModeGetRefreshRate(currentMode), but don't do anything >>>> with the return value, then later call it again, assigning it to >>>> the jint refrate. >>>> - What's up with this? Why call it twice? >>> Another glitch. Friday evening syndrome. >>>> 5. In some places you use (*env)->FindClass(), and in others you >>>> use JNF_CLASS_CACHE(). >>>> - You can create array types using JNFNewObjectArray() and >>>> JNF_CLASS_CACHE(), which will benefit from fewer lines, and >>>> automatic exception throwing into Java, instead of just printing >>>> and suppressing the exception. >>> Well, valid point - i'll use the JNF functions for array creation >>> for the sake of consistency. >>>> 6. Your NSLog() in >>>> Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() says >>>> "CGRaphivsGevice". >>>> - I think you meant to say "CGraphicsDevice". >>> You're absolutely right. >>>> 7. None of the if checks in getBestModeForParameters() need else { >>>> } blocks, because they implicitly exit the for loop. >>> I've added them for the better code readability but as it makes code >>> more compact i may as well remove them. >>>> 8. getBPPFromModeString() can simply return the depth directly >>>> without assigning to a temporary. >>>> - I know this is more of a style thing, but I prefer fewer >>>> lines if possible. >>> Hmm. Ok, not a big deal but if it makes you a little bit happier >>> i'll surely do that. >>>> 9. Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode() leaks the >>>> closestMatch CGDisplayModeRef. >>>> - The "Create Rule" explains why this is a leak when fixed in >>>> conjunction with (1) above. >>>> >>>> - >>>> >>> How comes? I do not use Copy-methods to get the exact configuration, >>> i get the array of references to the Quartz DisplayMode's >>> and i don't create any new CGDisplayMode objects. And i do release >>> the array itself. Where is the memory leak? >>> >>>> 10. What happens in the case of >>>> Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() where one of >>>> the CGDisplayModeRef's itterated on in the for loop is null? Is it >>>> OK to have empty nil holes in the returned array? >>> I tried to pass the null as one of the array elements back to Java - >>> seems that it's Ok so i will left it as it is now. >>>> Overall, I'm discouraged by this lack of attention to detail by >>>> both the author and reviewers. >>> Stuff happens, especially at Friday evening, but all for all there >>> was no major problems just some non-critical glitches here and >>> there. And you are one of reviewers so the review process is fairly >>> good at the end. >>> >>> Anyways - the new webrev can be found here >>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.02 >>> Comments are welcome. >>> >>> >>>> >>>> Mike Swingler >>>> Apple Inc. >>>> >>>> On Jun 1, 2012, at 10:55 AM, Alexander Zuev wrote: >>>> >>>>> Artem, >>>>> >>>>> 1. Done >>>>> 2. Yes, it's a wonderful idea, done. >>>>> 3. User can construct a new DisplayMode object and ask us to set >>>>> corresponding mode. >>>>> >>>>> New webrev can be found at >>>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.01 >>>>> >>>>> With best regards, >>>>> Alex >>>>> >>>>> On 6/1/12 19:57, Artem Ananiev wrote: >>>>>> Hi, Alex, >>>>>> >>>>>> here are some comments: >>>>>> >>>>>> 1. Please, update copyright dates in file headers. >>>>>> >>>>>> 2. I would pass w, h, bpp and refrate as method params to >>>>>> setDisplayMode() to avoid extra JNI calls from native >>>>>> >>>>>> 3. Is it possible to call setDisplayMode() with a DisplayMode >>>>>> object that was not obtained via previous getDisplayModes() call? >>>>>> If the answer is "no", why don't you just check for exact match >>>>>> for all parameters (w, h, bpp, refrate) in >>>>>> getBestModeForParameters()? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>> On 6/1/2012 1:40 PM, Alexander Zuev wrote: >>>>>>> Hello, >>>>>>> >>>>>>> please review my fix for CR 7124247: [macosx] Implement >>>>>>> GraphicsDevice.setDisplayMode() >>>>>>> >>>>>>> CR description can be found here: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 >>>>>>> >>>>>>> Webrev with the proposed change can be seen here: >>>>>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 >>>>>>> >>>>>>> With best regards, >>>>>>> Alex >>> >> From anthony.petrov at oracle.com Tue Jun 5 08:47:04 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 05 Jun 2012 19:47:04 +0400 Subject: [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing In-Reply-To: <4FC77592.7020900@oracle.com> References: <4FC77592.7020900@oracle.com> Message-ID: <4FCE29F8.4010503@oracle.com> Hi Sergey, 1. src/macosx/classes/sun/lwawt/LWComponentPeer.java > 196 delegate = createDelegate(); > 197 if (delegate != null) { > 198 delegate.setVisible(false); The call at line 198 looks unnatural here. It looks as if the delegate is created visible initially which isn't true, is it? 2. > 204 delegate.setOpaque(true); Related to the above comment, does this call mean that a delegate is created non-opaque initially? I feel uncomfortable with these calls. Do we workaround something with these calls? Can we give them more appropriate and meaningful names then? 3. src/macosx/classes/sun/lwawt/LWWindowPeer.java > 179 updateInsets(platformWindow.getInsets()); The system may report wrong insets before a window is shown on the screen. Perhaps, instead of initializeImpl() we should introduce preInitialize() (== current initializeImpl()), and postInitialize() (to where this, and the subsequent replaceSurfaceData() calls might go.) 4. > 220 protected void setVisibleImpl(final boolean visible) { > 221 super.setVisibleImpl(visible); Why do we remove a call to replaceSurfaceData() in the beginning of the method? 5. > 983 ((Graphics2D) g).setBackground(getBackground()); I suggest to add an instanceof check before this call. 6. > 227 // invokeLater() can be deleted, but in this case we get a lag between > 228 // windows showing and content painting. Is the lag so very noticeable? On other platforms we don't actually do this, and I don't recall any issues about such lags. -- best regards, Anthony On 5/31/2012 5:43 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > > Notes from the bug and comments: > 1. setVisible() should be called at the end of the peers initialization. > We can move super.initialize() to the end of the peers initializations. > Initialize() was split to initialize() and initializeImpl(). In the > initialize() we call initializeImpl and then we call to setVisible(). > initializeImpl overridden in subclasses. > > 2. Invokelater in the initialization/disposing is a tricky. > Left it as is. Probably later it will be changed. Comments was updated. > > 3. replaceSurfacedata() should be moved outside of > LWWindowPeer.setVisible() > Done. Also duplicate code was extracted to setVisible() method which > call setVisibleImpl(). > > 4. Backbuffer in replaceSurfacedata() should be initialized by clearRect > instead of fillrect(composite is important). > Done. related to composite. > > 5. During lwwindowpeer initialization we call two similar methods > nativeSetNSWindowAlpha() and setAlphaValue(). > nativeSetNSWindowAlpha() removed from CPlatformWindow.java. > > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7142091/webrev.00/ > From anthony.petrov at oracle.com Tue Jun 5 08:49:53 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 05 Jun 2012 19:49:53 +0400 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <4FCE25BF.3030903@oracle.com> References: <4FC88E22.10701@oracle.com> <4FC8E685.20705@oracle.com> <4FC9020B.50507@oracle.com> <3702960D-8492-4B10-A90E-F378F3B17555@apple.com> <4FCCFC09.7030805@oracle.com> <4FCE0DBD.8090507@oracle.com> <4FCE19C9.5080001@oracle.com> <4FCE25BF.3030903@oracle.com> Message-ID: <4FCE2AA1.1040408@oracle.com> Code replication allows for fixing a bug in one place and forgetting about it in another. Extracting common code in functions prevents such issues. Also, in this particular case we would benefit from caching a method ID only once instead of having two copies of it. -- best regards, Anthony On 6/5/2012 7:29 PM, Alexander Zuev wrote: > Yes, they are similar, but making a new function for the 8 lines of > code? Don't think it's worth it. > > With best regards, > Alex > > On 6/5/12 18:38, Anthony Petrov wrote: >> Hi Alex, >> >> The code at lines 163-171 and 202-209 is very similar, and I believe >> it can be extracted into a separate utility function. >> >> -- >> best regards, >> Anthony >> >> On 6/5/2012 5:46 PM, Alexander Zuev wrote: >>> Yet another version of the webrev - fixed some typos in comments >>> (thanks Scott Palmer) and >>> added updating full screen window size if we are currently in full >>> screen mode. >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.03 >>> >>> With best regards, >>> Alex >>> >>> On 6/4/12 22:18, Alexander Zuev wrote: >>>> Mike, >>>> >>>> thanks for a superb review. See comments inline. >>>> >>>> With best regards, >>>> Alex >>>> >>>> On 6/1/12 23:18, Mike Swingler wrote: >>>>> A few notes here: >>>>> >>>>> 1. getBestModeForParameters() should be called >>>>> copyBestModeForParameters() >>>>> - This is to pass the static-analyzer to validate that the >>>>> retain/release balance is correct: copy implies returning a >>>>> retained object, get implies non-retained. In this case you are >>>>> returning a retained object that needs to be released. >>>> I wasn't aware that static-analyzer takes into account the function >>>> names. Anyways - in this case you are quite wrong. I'm not creating >>>> any new objects here. What i get as a parameter is an array of the >>>> references (pointers) and i'm returning one of them >>>> that satisfy the conditions based on the other parameters passed. >>>> There is no need in releasing the object referred by that >>>> pointer - quite contrary if i DO release closestMatch in the >>>> Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode then next >>>> time i try to set the same display mode i will get the nice >>>> application crash. Something like this: >>>> >>>> 0 libsystem_kernel.dylib 0x00007fff85c55ce2 >>>> __pthread_kill + 10 >>>> 1 libsystem_c.dylib 0x00007fff8b42e7d2 >>>> pthread_kill + 95 >>>> 2 libsystem_c.dylib 0x00007fff8b41fa7a abort + 143 >>>> 3 libjvm.dylib 0x0000000102fadb79 >>>> os::abort(bool) + 25 >>>> 4 libjvm.dylib 0x0000000103099dd0 >>>> VMError::report_and_die() + 2306 >>>> 5 libjvm.dylib 0x0000000102faf255 >>>> JVM_handle_bsd_signal + 1047 >>>> 6 libsystem_c.dylib 0x00007fff8b480cfa _sigtramp + 26 >>>> 7 com.apple.CoreFoundation 0x00007fff8d125877 >>>> CFDictionaryGetValue + 23 >>>> 8 com.apple.CoreGraphics 0x00007fff83b0daec >>>> CGDisplayModeGetResolution + 40 >>>> 9 com.apple.CoreGraphics 0x00007fff83b0f84f >>>> CGDisplayCopyAllDisplayModes + 278 >>>> 10 liblwawt.dylib 0x000000015fc1b35d >>>> Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode + 57 >>>> >>>>> 2. getBestModeForParameters() is declared to return a >>>>> CGDisplayModeRef, but you are actually returning a bestGuess >>>>> CFStringRef. Which is it? >>>> Glitch. Fixed it. Strange that compiler did not issued a warning >>>> about this return >>>>> 3. getBPPFromModeString() returns an int, but in one case you are >>>>> assigning to a jint in >>>>> Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode(). >>>>> - Technically not an issue, but unexpected. >>>> I can add implicit cast to jint - but technically it is not an issue >>>> as you mentioned . >>>>> 4. In Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode() you call >>>>> CGDisplayModeGetRefreshRate(currentMode), but don't do anything >>>>> with the return value, then later call it again, assigning it to >>>>> the jint refrate. >>>>> - What's up with this? Why call it twice? >>>> Another glitch. Friday evening syndrome. >>>>> 5. In some places you use (*env)->FindClass(), and in others you >>>>> use JNF_CLASS_CACHE(). >>>>> - You can create array types using JNFNewObjectArray() and >>>>> JNF_CLASS_CACHE(), which will benefit from fewer lines, and >>>>> automatic exception throwing into Java, instead of just printing >>>>> and suppressing the exception. >>>> Well, valid point - i'll use the JNF functions for array creation >>>> for the sake of consistency. >>>>> 6. Your NSLog() in >>>>> Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() says >>>>> "CGRaphivsGevice". >>>>> - I think you meant to say "CGraphicsDevice". >>>> You're absolutely right. >>>>> 7. None of the if checks in getBestModeForParameters() need else { >>>>> } blocks, because they implicitly exit the for loop. >>>> I've added them for the better code readability but as it makes code >>>> more compact i may as well remove them. >>>>> 8. getBPPFromModeString() can simply return the depth directly >>>>> without assigning to a temporary. >>>>> - I know this is more of a style thing, but I prefer fewer >>>>> lines if possible. >>>> Hmm. Ok, not a big deal but if it makes you a little bit happier >>>> i'll surely do that. >>>>> 9. Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode() leaks the >>>>> closestMatch CGDisplayModeRef. >>>>> - The "Create Rule" explains why this is a leak when fixed in >>>>> conjunction with (1) above. >>>>> >>>>> - >>>>> >>>> How comes? I do not use Copy-methods to get the exact configuration, >>>> i get the array of references to the Quartz DisplayMode's >>>> and i don't create any new CGDisplayMode objects. And i do release >>>> the array itself. Where is the memory leak? >>>> >>>>> 10. What happens in the case of >>>>> Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() where one of >>>>> the CGDisplayModeRef's itterated on in the for loop is null? Is it >>>>> OK to have empty nil holes in the returned array? >>>> I tried to pass the null as one of the array elements back to Java - >>>> seems that it's Ok so i will left it as it is now. >>>>> Overall, I'm discouraged by this lack of attention to detail by >>>>> both the author and reviewers. >>>> Stuff happens, especially at Friday evening, but all for all there >>>> was no major problems just some non-critical glitches here and >>>> there. And you are one of reviewers so the review process is fairly >>>> good at the end. >>>> >>>> Anyways - the new webrev can be found here >>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.02 >>>> Comments are welcome. >>>> >>>> >>>>> >>>>> Mike Swingler >>>>> Apple Inc. >>>>> >>>>> On Jun 1, 2012, at 10:55 AM, Alexander Zuev wrote: >>>>> >>>>>> Artem, >>>>>> >>>>>> 1. Done >>>>>> 2. Yes, it's a wonderful idea, done. >>>>>> 3. User can construct a new DisplayMode object and ask us to set >>>>>> corresponding mode. >>>>>> >>>>>> New webrev can be found at >>>>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.01 >>>>>> >>>>>> With best regards, >>>>>> Alex >>>>>> >>>>>> On 6/1/12 19:57, Artem Ananiev wrote: >>>>>>> Hi, Alex, >>>>>>> >>>>>>> here are some comments: >>>>>>> >>>>>>> 1. Please, update copyright dates in file headers. >>>>>>> >>>>>>> 2. I would pass w, h, bpp and refrate as method params to >>>>>>> setDisplayMode() to avoid extra JNI calls from native >>>>>>> >>>>>>> 3. Is it possible to call setDisplayMode() with a DisplayMode >>>>>>> object that was not obtained via previous getDisplayModes() call? >>>>>>> If the answer is "no", why don't you just check for exact match >>>>>>> for all parameters (w, h, bpp, refrate) in >>>>>>> getBestModeForParameters()? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Artem >>>>>>> >>>>>>> On 6/1/2012 1:40 PM, Alexander Zuev wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> please review my fix for CR 7124247: [macosx] Implement >>>>>>>> GraphicsDevice.setDisplayMode() >>>>>>>> >>>>>>>> CR description can be found here: >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 >>>>>>>> >>>>>>>> Webrev with the proposed change can be seen here: >>>>>>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 >>>>>>>> >>>>>>>> With best regards, >>>>>>>> Alex >>>> >>> > From Sergey.Bylokhov at oracle.com Tue Jun 5 09:13:33 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 05 Jun 2012 20:13:33 +0400 Subject: [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing In-Reply-To: <4FCE29F8.4010503@oracle.com> References: <4FC77592.7020900@oracle.com> <4FCE29F8.4010503@oracle.com> Message-ID: <4FCE302D.2070508@oracle.com> Hi Anthony. Thanks for review. See comments inline. 05.06.2012 19:47, Anthony Petrov wrote: > Hi Sergey, > > 1. src/macosx/classes/sun/lwawt/LWComponentPeer.java >> 196 delegate = createDelegate(); >> 197 if (delegate != null) { >> 198 delegate.setVisible(false); > > > The call at line 198 looks unnatural here. It looks as if the delegate > is created visible initially which isn't true, is it? Delegate is visible by default, but our awt peer is not. > > 2. >> 204 delegate.setOpaque(true); > > Related to the above comment, does this call mean that a delegate is > created non-opaque initially? I feel uncomfortable with these calls. > Do we workaround something with these calls? Can we give them more > appropriate and meaningful names then? Most of aqua components are non opaque by default, but our awt peer not. > > 3. src/macosx/classes/sun/lwawt/LWWindowPeer.java >> 179 updateInsets(platformWindow.getInsets()); > > The system may report wrong insets before a window is shown on the > screen. Perhaps, instead of initializeImpl() we should introduce > preInitialize() (== current initializeImpl()), and postInitialize() > (to where this, and the subsequent replaceSurfaceData() calls might go.) Like it was done in XAWT? It is just a nightmare. I assume that updateInsets() should be called by some of the native callbacks, like notifyExpose and reshape? > > 4. >> 220 protected void setVisibleImpl(final boolean visible) { >> 221 super.setVisibleImpl(visible); > > Why do we remove a call to replaceSurfaceData() in the beginning of > the method? Before the fix, setVisible() can be called before surface creation, but after the fix it will be called after. > > 5. >> 983 ((Graphics2D) >> g).setBackground(getBackground()); > > I suggest to add an instanceof check before this call. I guess that Buffered image cannot return something except Graphics2D > > 6. >> 227 // invokeLater() can be deleted, but in this case we get >> a lag between >> 228 // windows showing and content painting. > > Is the lag so very noticeable? On other platforms we don't actually do > this, and I don't recall any issues about such lags. Yes The difference is noticeable. So I update the comments and leave it as is for now. > > -- > best regards, > Anthony > > On 5/31/2012 5:43 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Please review the fix. >> >> Notes from the bug and comments: >> 1. setVisible() should be called at the end of the peers >> initialization. We can move super.initialize() to the end of the >> peers initializations. >> Initialize() was split to initialize() and initializeImpl(). In the >> initialize() we call initializeImpl and then we call to setVisible(). >> initializeImpl overridden in subclasses. >> >> 2. Invokelater in the initialization/disposing is a tricky. >> Left it as is. Probably later it will be changed. Comments was updated. >> >> 3. replaceSurfacedata() should be moved outside of >> LWWindowPeer.setVisible() >> Done. Also duplicate code was extracted to setVisible() method which >> call setVisibleImpl(). >> >> 4. Backbuffer in replaceSurfacedata() should be initialized by >> clearRect instead of fillrect(composite is important). >> Done. related to composite. >> >> 5. During lwwindowpeer initialization we call two similar methods >> nativeSetNSWindowAlpha() and setAlphaValue(). >> nativeSetNSWindowAlpha() removed from CPlatformWindow.java. >> >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7142091/webrev.00/ >> -- Best regards, Sergey. From swingler at apple.com Tue Jun 5 10:21:54 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 05 Jun 2012 10:21:54 -0700 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <4FCE2AA1.1040408@oracle.com> References: <4FC88E22.10701@oracle.com> <4FC8E685.20705@oracle.com> <4FC9020B.50507@oracle.com> <3702960D-8492-4B10-A90E-F378F3B17555@apple.com> <4FCCFC09.7030805@oracle.com> <4FCE0DBD.8090507@oracle.com> <4FCE19C9.5080001@oracle.com> <4FCE25BF.3030903@oracle.com> <4FCE2AA1.1040408@oracle.com> Message-ID: Agreed. A separate function is best. Otherwise this looks good. Mike Swingler Apple Inc. On Jun 5, 2012, at 8:49 AM, Anthony Petrov wrote: > Code replication allows for fixing a bug in one place and forgetting about it in another. Extracting common code in functions prevents such issues. > > Also, in this particular case we would benefit from caching a method ID only once instead of having two copies of it. > > -- > best regards, > Anthony > > On 6/5/2012 7:29 PM, Alexander Zuev wrote: >> Yes, they are similar, but making a new function for the 8 lines of code? Don't think it's worth it. >> With best regards, >> Alex >> On 6/5/12 18:38, Anthony Petrov wrote: >>> Hi Alex, >>> >>> The code at lines 163-171 and 202-209 is very similar, and I believe it can be extracted into a separate utility function. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 6/5/2012 5:46 PM, Alexander Zuev wrote: >>>> Yet another version of the webrev - fixed some typos in comments (thanks Scott Palmer) and >>>> added updating full screen window size if we are currently in full screen mode. >>>> >>>> Webrev is here: http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.03 >>>> >>>> With best regards, >>>> Alex >>>> >>>> On 6/4/12 22:18, Alexander Zuev wrote: >>>>> Mike, >>>>> >>>>> thanks for a superb review. See comments inline. >>>>> >>>>> With best regards, >>>>> Alex >>>>> >>>>> On 6/1/12 23:18, Mike Swingler wrote: >>>>>> A few notes here: >>>>>> >>>>>> 1. getBestModeForParameters() should be called copyBestModeForParameters() >>>>>> - This is to pass the static-analyzer to validate that the retain/release balance is correct: copy implies returning a retained object, get implies non-retained. In this case you are returning a retained object that needs to be released. >>>>> I wasn't aware that static-analyzer takes into account the function names. Anyways - in this case you are quite wrong. I'm not creating any new objects here. What i get as a parameter is an array of the references (pointers) and i'm returning one of them >>>>> that satisfy the conditions based on the other parameters passed. There is no need in releasing the object referred by that >>>>> pointer - quite contrary if i DO release closestMatch in the Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode then next >>>>> time i try to set the same display mode i will get the nice application crash. Something like this: >>>>> >>>>> 0 libsystem_kernel.dylib 0x00007fff85c55ce2 __pthread_kill + 10 >>>>> 1 libsystem_c.dylib 0x00007fff8b42e7d2 pthread_kill + 95 >>>>> 2 libsystem_c.dylib 0x00007fff8b41fa7a abort + 143 >>>>> 3 libjvm.dylib 0x0000000102fadb79 os::abort(bool) + 25 >>>>> 4 libjvm.dylib 0x0000000103099dd0 VMError::report_and_die() + 2306 >>>>> 5 libjvm.dylib 0x0000000102faf255 JVM_handle_bsd_signal + 1047 >>>>> 6 libsystem_c.dylib 0x00007fff8b480cfa _sigtramp + 26 >>>>> 7 com.apple.CoreFoundation 0x00007fff8d125877 CFDictionaryGetValue + 23 >>>>> 8 com.apple.CoreGraphics 0x00007fff83b0daec CGDisplayModeGetResolution + 40 >>>>> 9 com.apple.CoreGraphics 0x00007fff83b0f84f CGDisplayCopyAllDisplayModes + 278 >>>>> 10 liblwawt.dylib 0x000000015fc1b35d Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode + 57 >>>>> >>>>>> 2. getBestModeForParameters() is declared to return a CGDisplayModeRef, but you are actually returning a bestGuess CFStringRef. Which is it? >>>>> Glitch. Fixed it. Strange that compiler did not issued a warning about this return >>>>>> 3. getBPPFromModeString() returns an int, but in one case you are assigning to a jint in Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode(). >>>>>> - Technically not an issue, but unexpected. >>>>> I can add implicit cast to jint - but technically it is not an issue as you mentioned . >>>>>> 4. In Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode() you call CGDisplayModeGetRefreshRate(currentMode), but don't do anything with the return value, then later call it again, assigning it to the jint refrate. >>>>>> - What's up with this? Why call it twice? >>>>> Another glitch. Friday evening syndrome. >>>>>> 5. In some places you use (*env)->FindClass(), and in others you use JNF_CLASS_CACHE(). >>>>>> - You can create array types using JNFNewObjectArray() and JNF_CLASS_CACHE(), which will benefit from fewer lines, and automatic exception throwing into Java, instead of just printing and suppressing the exception. >>>>> Well, valid point - i'll use the JNF functions for array creation for the sake of consistency. >>>>>> 6. Your NSLog() in Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() says "CGRaphivsGevice". >>>>>> - I think you meant to say "CGraphicsDevice". >>>>> You're absolutely right. >>>>>> 7. None of the if checks in getBestModeForParameters() need else { } blocks, because they implicitly exit the for loop. >>>>> I've added them for the better code readability but as it makes code more compact i may as well remove them. >>>>>> 8. getBPPFromModeString() can simply return the depth directly without assigning to a temporary. >>>>>> - I know this is more of a style thing, but I prefer fewer lines if possible. >>>>> Hmm. Ok, not a big deal but if it makes you a little bit happier i'll surely do that. >>>>>> 9. Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode() leaks the closestMatch CGDisplayModeRef. >>>>>> - The "Create Rule" explains why this is a leak when fixed in conjunction with (1) above. >>>>>> - >>>>> How comes? I do not use Copy-methods to get the exact configuration, i get the array of references to the Quartz DisplayMode's >>>>> and i don't create any new CGDisplayMode objects. And i do release the array itself. Where is the memory leak? >>>>> >>>>>> 10. What happens in the case of Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() where one of the CGDisplayModeRef's itterated on in the for loop is null? Is it OK to have empty nil holes in the returned array? >>>>> I tried to pass the null as one of the array elements back to Java - seems that it's Ok so i will left it as it is now. >>>>>> Overall, I'm discouraged by this lack of attention to detail by both the author and reviewers. >>>>> Stuff happens, especially at Friday evening, but all for all there was no major problems just some non-critical glitches here and there. And you are one of reviewers so the review process is fairly good at the end. >>>>> >>>>> Anyways - the new webrev can be found here http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.02 >>>>> Comments are welcome. >>>>> >>>>> >>>>>> >>>>>> Mike Swingler >>>>>> Apple Inc. >>>>>> >>>>>> On Jun 1, 2012, at 10:55 AM, Alexander Zuev wrote: >>>>>> >>>>>>> Artem, >>>>>>> >>>>>>> 1. Done >>>>>>> 2. Yes, it's a wonderful idea, done. >>>>>>> 3. User can construct a new DisplayMode object and ask us to set corresponding mode. >>>>>>> >>>>>>> New webrev can be found at http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.01 >>>>>>> >>>>>>> With best regards, >>>>>>> Alex >>>>>>> >>>>>>> On 6/1/12 19:57, Artem Ananiev wrote: >>>>>>>> Hi, Alex, >>>>>>>> >>>>>>>> here are some comments: >>>>>>>> >>>>>>>> 1. Please, update copyright dates in file headers. >>>>>>>> >>>>>>>> 2. I would pass w, h, bpp and refrate as method params to setDisplayMode() to avoid extra JNI calls from native >>>>>>>> >>>>>>>> 3. Is it possible to call setDisplayMode() with a DisplayMode object that was not obtained via previous getDisplayModes() call? If the answer is "no", why don't you just check for exact match for all parameters (w, h, bpp, refrate) in getBestModeForParameters()? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Artem >>>>>>>> >>>>>>>> On 6/1/2012 1:40 PM, Alexander Zuev wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> please review my fix for CR 7124247: [macosx] Implement >>>>>>>>> GraphicsDevice.setDisplayMode() >>>>>>>>> >>>>>>>>> CR description can be found here: >>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 >>>>>>>>> >>>>>>>>> Webrev with the proposed change can be seen here: >>>>>>>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 >>>>>>>>> >>>>>>>>> With best regards, >>>>>>>>> Alex >>>>> >>>> From alexander.zuev at oracle.com Tue Jun 5 11:11:25 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 05 Jun 2012 22:11:25 +0400 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: References: <4FC88E22.10701@oracle.com> <4FC8E685.20705@oracle.com> <4FC9020B.50507@oracle.com> <3702960D-8492-4B10-A90E-F378F3B17555@apple.com> <4FCCFC09.7030805@oracle.com> <4FCE0DBD.8090507@oracle.com> <4FCE19C9.5080001@oracle.com> <4FCE25BF.3030903@oracle.com> <4FCE2AA1.1040408@oracle.com> Message-ID: <4FCE4BCD.7010604@oracle.com> Ok, if you both say so - i'm convinced :) Here's the new webrev: http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.04 With best regards, Alex On 6/5/12 21:21, Mike Swingler wrote: > Agreed. A separate function is best. Otherwise this looks good. > > Mike Swingler > Apple Inc. > > On Jun 5, 2012, at 8:49 AM, Anthony Petrov wrote: > >> Code replication allows for fixing a bug in one place and forgetting about it in another. Extracting common code in functions prevents such issues. >> >> Also, in this particular case we would benefit from caching a method ID only once instead of having two copies of it. >> >> -- >> best regards, >> Anthony >> >> On 6/5/2012 7:29 PM, Alexander Zuev wrote: >>> Yes, they are similar, but making a new function for the 8 lines of code? Don't think it's worth it. >>> With best regards, >>> Alex >>> On 6/5/12 18:38, Anthony Petrov wrote: >>>> Hi Alex, >>>> >>>> The code at lines 163-171 and 202-209 is very similar, and I believe it can be extracted into a separate utility function. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 6/5/2012 5:46 PM, Alexander Zuev wrote: >>>>> Yet another version of the webrev - fixed some typos in comments (thanks Scott Palmer) and >>>>> added updating full screen window size if we are currently in full screen mode. >>>>> >>>>> Webrev is here: http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.03 >>>>> >>>>> With best regards, >>>>> Alex >>>>> >>>>> On 6/4/12 22:18, Alexander Zuev wrote: >>>>>> Mike, >>>>>> >>>>>> thanks for a superb review. See comments inline. >>>>>> >>>>>> With best regards, >>>>>> Alex >>>>>> >>>>>> On 6/1/12 23:18, Mike Swingler wrote: >>>>>>> A few notes here: >>>>>>> >>>>>>> 1. getBestModeForParameters() should be called copyBestModeForParameters() >>>>>>> - This is to pass the static-analyzer to validate that the retain/release balance is correct: copy implies returning a retained object, get implies non-retained. In this case you are returning a retained object that needs to be released. >>>>>> I wasn't aware that static-analyzer takes into account the function names. Anyways - in this case you are quite wrong. I'm not creating any new objects here. What i get as a parameter is an array of the references (pointers) and i'm returning one of them >>>>>> that satisfy the conditions based on the other parameters passed. There is no need in releasing the object referred by that >>>>>> pointer - quite contrary if i DO release closestMatch in the Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode then next >>>>>> time i try to set the same display mode i will get the nice application crash. Something like this: >>>>>> >>>>>> 0 libsystem_kernel.dylib 0x00007fff85c55ce2 __pthread_kill + 10 >>>>>> 1 libsystem_c.dylib 0x00007fff8b42e7d2 pthread_kill + 95 >>>>>> 2 libsystem_c.dylib 0x00007fff8b41fa7a abort + 143 >>>>>> 3 libjvm.dylib 0x0000000102fadb79 os::abort(bool) + 25 >>>>>> 4 libjvm.dylib 0x0000000103099dd0 VMError::report_and_die() + 2306 >>>>>> 5 libjvm.dylib 0x0000000102faf255 JVM_handle_bsd_signal + 1047 >>>>>> 6 libsystem_c.dylib 0x00007fff8b480cfa _sigtramp + 26 >>>>>> 7 com.apple.CoreFoundation 0x00007fff8d125877 CFDictionaryGetValue + 23 >>>>>> 8 com.apple.CoreGraphics 0x00007fff83b0daec CGDisplayModeGetResolution + 40 >>>>>> 9 com.apple.CoreGraphics 0x00007fff83b0f84f CGDisplayCopyAllDisplayModes + 278 >>>>>> 10 liblwawt.dylib 0x000000015fc1b35d Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode + 57 >>>>>> >>>>>>> 2. getBestModeForParameters() is declared to return a CGDisplayModeRef, but you are actually returning a bestGuess CFStringRef. Which is it? >>>>>> Glitch. Fixed it. Strange that compiler did not issued a warning about this return >>>>>>> 3. getBPPFromModeString() returns an int, but in one case you are assigning to a jint in Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode(). >>>>>>> - Technically not an issue, but unexpected. >>>>>> I can add implicit cast to jint - but technically it is not an issue as you mentioned . >>>>>>> 4. In Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode() you call CGDisplayModeGetRefreshRate(currentMode), but don't do anything with the return value, then later call it again, assigning it to the jint refrate. >>>>>>> - What's up with this? Why call it twice? >>>>>> Another glitch. Friday evening syndrome. >>>>>>> 5. In some places you use (*env)->FindClass(), and in others you use JNF_CLASS_CACHE(). >>>>>>> - You can create array types using JNFNewObjectArray() and JNF_CLASS_CACHE(), which will benefit from fewer lines, and automatic exception throwing into Java, instead of just printing and suppressing the exception. >>>>>> Well, valid point - i'll use the JNF functions for array creation for the sake of consistency. >>>>>>> 6. Your NSLog() in Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() says "CGRaphivsGevice". >>>>>>> - I think you meant to say "CGraphicsDevice". >>>>>> You're absolutely right. >>>>>>> 7. None of the if checks in getBestModeForParameters() need else { } blocks, because they implicitly exit the for loop. >>>>>> I've added them for the better code readability but as it makes code more compact i may as well remove them. >>>>>>> 8. getBPPFromModeString() can simply return the depth directly without assigning to a temporary. >>>>>>> - I know this is more of a style thing, but I prefer fewer lines if possible. >>>>>> Hmm. Ok, not a big deal but if it makes you a little bit happier i'll surely do that. >>>>>>> 9. Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode() leaks the closestMatch CGDisplayModeRef. >>>>>>> - The "Create Rule" explains why this is a leak when fixed in conjunction with (1) above. >>>>>>> - >>>>>> How comes? I do not use Copy-methods to get the exact configuration, i get the array of references to the Quartz DisplayMode's >>>>>> and i don't create any new CGDisplayMode objects. And i do release the array itself. Where is the memory leak? >>>>>> >>>>>>> 10. What happens in the case of Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() where one of the CGDisplayModeRef's itterated on in the for loop is null? Is it OK to have empty nil holes in the returned array? >>>>>> I tried to pass the null as one of the array elements back to Java - seems that it's Ok so i will left it as it is now. >>>>>>> Overall, I'm discouraged by this lack of attention to detail by both the author and reviewers. >>>>>> Stuff happens, especially at Friday evening, but all for all there was no major problems just some non-critical glitches here and there. And you are one of reviewers so the review process is fairly good at the end. >>>>>> >>>>>> Anyways - the new webrev can be found here http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.02 >>>>>> Comments are welcome. >>>>>> >>>>>> >>>>>>> Mike Swingler >>>>>>> Apple Inc. >>>>>>> >>>>>>> On Jun 1, 2012, at 10:55 AM, Alexander Zuev wrote: >>>>>>> >>>>>>>> Artem, >>>>>>>> >>>>>>>> 1. Done >>>>>>>> 2. Yes, it's a wonderful idea, done. >>>>>>>> 3. User can construct a new DisplayMode object and ask us to set corresponding mode. >>>>>>>> >>>>>>>> New webrev can be found at http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.01 >>>>>>>> >>>>>>>> With best regards, >>>>>>>> Alex >>>>>>>> >>>>>>>> On 6/1/12 19:57, Artem Ananiev wrote: >>>>>>>>> Hi, Alex, >>>>>>>>> >>>>>>>>> here are some comments: >>>>>>>>> >>>>>>>>> 1. Please, update copyright dates in file headers. >>>>>>>>> >>>>>>>>> 2. I would pass w, h, bpp and refrate as method params to setDisplayMode() to avoid extra JNI calls from native >>>>>>>>> >>>>>>>>> 3. Is it possible to call setDisplayMode() with a DisplayMode object that was not obtained via previous getDisplayModes() call? If the answer is "no", why don't you just check for exact match for all parameters (w, h, bpp, refrate) in getBestModeForParameters()? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Artem >>>>>>>>> >>>>>>>>> On 6/1/2012 1:40 PM, Alexander Zuev wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> please review my fix for CR 7124247: [macosx] Implement >>>>>>>>>> GraphicsDevice.setDisplayMode() >>>>>>>>>> >>>>>>>>>> CR description can be found here: >>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 >>>>>>>>>> >>>>>>>>>> Webrev with the proposed change can be seen here: >>>>>>>>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 >>>>>>>>>> >>>>>>>>>> With best regards, >>>>>>>>>> Alex From Sergey.Bylokhov at oracle.com Tue Jun 5 11:17:10 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 05 Jun 2012 22:17:10 +0400 Subject: [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing In-Reply-To: <4FCE29F8.4010503@oracle.com> References: <4FC77592.7020900@oracle.com> <4FCE29F8.4010503@oracle.com> Message-ID: <4FCE4D26.8000107@oracle.com> > > The system may report wrong insets before a window is shown on the > screen. Perhaps, instead of initializeImpl() we should introduce > preInitialize() (== current initializeImpl()), and postInitialize() > (to where this, and the subsequent replaceSurfaceData() calls might go.) > In this case In current implementation it works wrong too, because it can be called when the window initially invisible. 05.06.2012 19:47, Anthony Petrov wrote: > Hi Sergey, > > 1. src/macosx/classes/sun/lwawt/LWComponentPeer.java >> 196 delegate = createDelegate(); >> 197 if (delegate != null) { >> 198 delegate.setVisible(false); > > > The call at line 198 looks unnatural here. It looks as if the delegate > is created visible initially which isn't true, is it? > > 2. >> 204 delegate.setOpaque(true); > > Related to the above comment, does this call mean that a delegate is > created non-opaque initially? I feel uncomfortable with these calls. > Do we workaround something with these calls? Can we give them more > appropriate and meaningful names then? > > 3. src/macosx/classes/sun/lwawt/LWWindowPeer.java >> 179 updateInsets(platformWindow.getInsets()); > > The system may report wrong insets before a window is shown on the > screen. Perhaps, instead of initializeImpl() we should introduce > preInitialize() (== current initializeImpl()), and postInitialize() > (to where this, and the subsequent replaceSurfaceData() calls might go.) > > 4. >> 220 protected void setVisibleImpl(final boolean visible) { >> 221 super.setVisibleImpl(visible); > > Why do we remove a call to replaceSurfaceData() in the beginning of > the method? > > 5. >> 983 ((Graphics2D) >> g).setBackground(getBackground()); > > I suggest to add an instanceof check before this call. > > 6. >> 227 // invokeLater() can be deleted, but in this case we get >> a lag between >> 228 // windows showing and content painting. > > Is the lag so very noticeable? On other platforms we don't actually do > this, and I don't recall any issues about such lags. > > -- > best regards, > Anthony > > On 5/31/2012 5:43 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Please review the fix. >> >> Notes from the bug and comments: >> 1. setVisible() should be called at the end of the peers >> initialization. We can move super.initialize() to the end of the >> peers initializations. >> Initialize() was split to initialize() and initializeImpl(). In the >> initialize() we call initializeImpl and then we call to setVisible(). >> initializeImpl overridden in subclasses. >> >> 2. Invokelater in the initialization/disposing is a tricky. >> Left it as is. Probably later it will be changed. Comments was updated. >> >> 3. replaceSurfacedata() should be moved outside of >> LWWindowPeer.setVisible() >> Done. Also duplicate code was extracted to setVisible() method which >> call setVisibleImpl(). >> >> 4. Backbuffer in replaceSurfacedata() should be initialized by >> clearRect instead of fillrect(composite is important). >> Done. related to composite. >> >> 5. During lwwindowpeer initialization we call two similar methods >> nativeSetNSWindowAlpha() and setAlphaValue(). >> nativeSetNSWindowAlpha() removed from CPlatformWindow.java. >> >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7142091/webrev.00/ >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Jun 5 11:25:16 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 05 Jun 2012 22:25:16 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FCE201E.503@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FCE201E.503@oracle.com> Message-ID: <4FCE4F0C.8040800@oracle.com> 05.06.2012 19:05, Anthony Petrov ???????: > Hi Sergey, > > A couple of comments: > > 1. src/macosx/classes/sun/lwawt/LWWindowPeer.java >> 576 //flushOnscreenGraphics(); > > There's no any explanation as to why this line is commented out. Could > you either add a remark in the code, or delete this line altogether? Yes. Thanks. > > 2. How does the fix affect the performance of non-opaque (and opaque, > too) windows? In general a non-opaque window should work better just because now it doesn't use raw BufferedImage. Opaque window should be affected only by changes in RepaintManager(). > > -- > best regards, > Anthony > > On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Please review the fix. >> >> Shaped window was implemented as a translucent window with >> constrained graphics. Now translucent window doesn't use separate >> BufferedImage as a back buffer. Also alpha value for the swing back >> buffer was enabled(Shared code changed). >> Note that shaped windows are affected by this bugs: >> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >> - Shadows disappear. >> - Transparent areas aren't transparent to mouse clicks. >> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >> - Opacity does not work for non opaque windows. >> >> Any suggestions are welcome. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >> -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Jun 6 04:53:46 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 06 Jun 2012 15:53:46 +0400 Subject: [8] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <4FCE4BCD.7010604@oracle.com> References: <4FC88E22.10701@oracle.com> <4FC8E685.20705@oracle.com> <4FC9020B.50507@oracle.com> <3702960D-8492-4B10-A90E-F378F3B17555@apple.com> <4FCCFC09.7030805@oracle.com> <4FCE0DBD.8090507@oracle.com> <4FCE19C9.5080001@oracle.com> <4FCE25BF.3030903@oracle.com> <4FCE2AA1.1040408@oracle.com> <4FCE4BCD.7010604@oracle.com> Message-ID: <4FCF44CA.5080602@oracle.com> Thank you Alex. The fix looks good to me. -- best regards, Anthony On 6/5/2012 10:11 PM, Alexander Zuev wrote: > Ok, if you both say so - i'm convinced :) > > Here's the new webrev: > http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.04 > > With best regards, > Alex > > On 6/5/12 21:21, Mike Swingler wrote: >> Agreed. A separate function is best. Otherwise this looks good. >> >> Mike Swingler >> Apple Inc. >> >> On Jun 5, 2012, at 8:49 AM, Anthony Petrov wrote: >> >>> Code replication allows for fixing a bug in one place and forgetting >>> about it in another. Extracting common code in functions prevents >>> such issues. >>> >>> Also, in this particular case we would benefit from caching a method >>> ID only once instead of having two copies of it. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 6/5/2012 7:29 PM, Alexander Zuev wrote: >>>> Yes, they are similar, but making a new function for the 8 lines of >>>> code? Don't think it's worth it. >>>> With best regards, >>>> Alex >>>> On 6/5/12 18:38, Anthony Petrov wrote: >>>>> Hi Alex, >>>>> >>>>> The code at lines 163-171 and 202-209 is very similar, and I >>>>> believe it can be extracted into a separate utility function. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 6/5/2012 5:46 PM, Alexander Zuev wrote: >>>>>> Yet another version of the webrev - fixed some typos in comments >>>>>> (thanks Scott Palmer) and >>>>>> added updating full screen window size if we are currently in full >>>>>> screen mode. >>>>>> >>>>>> Webrev is here: >>>>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.03 >>>>>> >>>>>> With best regards, >>>>>> Alex >>>>>> >>>>>> On 6/4/12 22:18, Alexander Zuev wrote: >>>>>>> Mike, >>>>>>> >>>>>>> thanks for a superb review. See comments inline. >>>>>>> >>>>>>> With best regards, >>>>>>> Alex >>>>>>> >>>>>>> On 6/1/12 23:18, Mike Swingler wrote: >>>>>>>> A few notes here: >>>>>>>> >>>>>>>> 1. getBestModeForParameters() should be called >>>>>>>> copyBestModeForParameters() >>>>>>>> - This is to pass the static-analyzer to validate that the >>>>>>>> retain/release balance is correct: copy implies returning a >>>>>>>> retained object, get implies non-retained. In this case you are >>>>>>>> returning a retained object that needs to be released. >>>>>>> I wasn't aware that static-analyzer takes into account the >>>>>>> function names. Anyways - in this case you are quite wrong. I'm >>>>>>> not creating any new objects here. What i get as a parameter is >>>>>>> an array of the references (pointers) and i'm returning one of them >>>>>>> that satisfy the conditions based on the other parameters passed. >>>>>>> There is no need in releasing the object referred by that >>>>>>> pointer - quite contrary if i DO release closestMatch in the >>>>>>> Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode then next >>>>>>> time i try to set the same display mode i will get the nice >>>>>>> application crash. Something like this: >>>>>>> >>>>>>> 0 libsystem_kernel.dylib 0x00007fff85c55ce2 >>>>>>> __pthread_kill + 10 >>>>>>> 1 libsystem_c.dylib 0x00007fff8b42e7d2 >>>>>>> pthread_kill + 95 >>>>>>> 2 libsystem_c.dylib 0x00007fff8b41fa7a abort + 143 >>>>>>> 3 libjvm.dylib 0x0000000102fadb79 >>>>>>> os::abort(bool) + 25 >>>>>>> 4 libjvm.dylib 0x0000000103099dd0 >>>>>>> VMError::report_and_die() + 2306 >>>>>>> 5 libjvm.dylib 0x0000000102faf255 >>>>>>> JVM_handle_bsd_signal + 1047 >>>>>>> 6 libsystem_c.dylib 0x00007fff8b480cfa >>>>>>> _sigtramp + 26 >>>>>>> 7 com.apple.CoreFoundation 0x00007fff8d125877 >>>>>>> CFDictionaryGetValue + 23 >>>>>>> 8 com.apple.CoreGraphics 0x00007fff83b0daec >>>>>>> CGDisplayModeGetResolution + 40 >>>>>>> 9 com.apple.CoreGraphics 0x00007fff83b0f84f >>>>>>> CGDisplayCopyAllDisplayModes + 278 >>>>>>> 10 liblwawt.dylib 0x000000015fc1b35d >>>>>>> Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode + 57 >>>>>>> >>>>>>>> 2. getBestModeForParameters() is declared to return a >>>>>>>> CGDisplayModeRef, but you are actually returning a bestGuess >>>>>>>> CFStringRef. Which is it? >>>>>>> Glitch. Fixed it. Strange that compiler did not issued a warning >>>>>>> about this return >>>>>>>> 3. getBPPFromModeString() returns an int, but in one case you >>>>>>>> are assigning to a jint in >>>>>>>> Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode(). >>>>>>>> - Technically not an issue, but unexpected. >>>>>>> I can add implicit cast to jint - but technically it is not an >>>>>>> issue as you mentioned . >>>>>>>> 4. In Java_sun_awt_CGraphicsDevice_nativeGetDisplayMode() you >>>>>>>> call CGDisplayModeGetRefreshRate(currentMode), but don't do >>>>>>>> anything with the return value, then later call it again, >>>>>>>> assigning it to the jint refrate. >>>>>>>> - What's up with this? Why call it twice? >>>>>>> Another glitch. Friday evening syndrome. >>>>>>>> 5. In some places you use (*env)->FindClass(), and in others you >>>>>>>> use JNF_CLASS_CACHE(). >>>>>>>> - You can create array types using JNFNewObjectArray() and >>>>>>>> JNF_CLASS_CACHE(), which will benefit from fewer lines, and >>>>>>>> automatic exception throwing into Java, instead of just printing >>>>>>>> and suppressing the exception. >>>>>>> Well, valid point - i'll use the JNF functions for array creation >>>>>>> for the sake of consistency. >>>>>>>> 6. Your NSLog() in >>>>>>>> Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() says >>>>>>>> "CGRaphivsGevice". >>>>>>>> - I think you meant to say "CGraphicsDevice". >>>>>>> You're absolutely right. >>>>>>>> 7. None of the if checks in getBestModeForParameters() need else >>>>>>>> { } blocks, because they implicitly exit the for loop. >>>>>>> I've added them for the better code readability but as it makes >>>>>>> code more compact i may as well remove them. >>>>>>>> 8. getBPPFromModeString() can simply return the depth directly >>>>>>>> without assigning to a temporary. >>>>>>>> - I know this is more of a style thing, but I prefer fewer >>>>>>>> lines if possible. >>>>>>> Hmm. Ok, not a big deal but if it makes you a little bit happier >>>>>>> i'll surely do that. >>>>>>>> 9. Java_sun_awt_CGraphicsDevice_nativeSetDisplayMode() leaks the >>>>>>>> closestMatch CGDisplayModeRef. >>>>>>>> - The "Create Rule" explains why this is a leak when fixed >>>>>>>> in conjunction with (1) above. >>>>>>>> >>>>>>>> - >>>>>>>> >>>>>>> How comes? I do not use Copy-methods to get the exact >>>>>>> configuration, i get the array of references to the Quartz >>>>>>> DisplayMode's >>>>>>> and i don't create any new CGDisplayMode objects. And i do >>>>>>> release the array itself. Where is the memory leak? >>>>>>> >>>>>>>> 10. What happens in the case of >>>>>>>> Java_sun_awt_CGraphicsDevice_nativeGetDisplayModes() where one >>>>>>>> of the CGDisplayModeRef's itterated on in the for loop is null? >>>>>>>> Is it OK to have empty nil holes in the returned array? >>>>>>> I tried to pass the null as one of the array elements back to >>>>>>> Java - seems that it's Ok so i will left it as it is now. >>>>>>>> Overall, I'm discouraged by this lack of attention to detail by >>>>>>>> both the author and reviewers. >>>>>>> Stuff happens, especially at Friday evening, but all for all >>>>>>> there was no major problems just some non-critical glitches here >>>>>>> and there. And you are one of reviewers so the review process is >>>>>>> fairly good at the end. >>>>>>> >>>>>>> Anyways - the new webrev can be found here >>>>>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.02 >>>>>>> Comments are welcome. >>>>>>> >>>>>>> >>>>>>>> Mike Swingler >>>>>>>> Apple Inc. >>>>>>>> >>>>>>>> On Jun 1, 2012, at 10:55 AM, Alexander Zuev wrote: >>>>>>>> >>>>>>>>> Artem, >>>>>>>>> >>>>>>>>> 1. Done >>>>>>>>> 2. Yes, it's a wonderful idea, done. >>>>>>>>> 3. User can construct a new DisplayMode object and ask us to >>>>>>>>> set corresponding mode. >>>>>>>>> >>>>>>>>> New webrev can be found at >>>>>>>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.01 >>>>>>>>> >>>>>>>>> With best regards, >>>>>>>>> Alex >>>>>>>>> >>>>>>>>> On 6/1/12 19:57, Artem Ananiev wrote: >>>>>>>>>> Hi, Alex, >>>>>>>>>> >>>>>>>>>> here are some comments: >>>>>>>>>> >>>>>>>>>> 1. Please, update copyright dates in file headers. >>>>>>>>>> >>>>>>>>>> 2. I would pass w, h, bpp and refrate as method params to >>>>>>>>>> setDisplayMode() to avoid extra JNI calls from native >>>>>>>>>> >>>>>>>>>> 3. Is it possible to call setDisplayMode() with a DisplayMode >>>>>>>>>> object that was not obtained via previous getDisplayModes() >>>>>>>>>> call? If the answer is "no", why don't you just check for >>>>>>>>>> exact match for all parameters (w, h, bpp, refrate) in >>>>>>>>>> getBestModeForParameters()? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Artem >>>>>>>>>> >>>>>>>>>> On 6/1/2012 1:40 PM, Alexander Zuev wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> please review my fix for CR 7124247: [macosx] Implement >>>>>>>>>>> GraphicsDevice.setDisplayMode() >>>>>>>>>>> >>>>>>>>>>> CR description can be found here: >>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 >>>>>>>>>>> >>>>>>>>>>> Webrev with the proposed change can be seen here: >>>>>>>>>>> http://cr.openjdk.java.net/~kizune/7124247/jdk8/webrev.00 >>>>>>>>>>> >>>>>>>>>>> With best regards, >>>>>>>>>>> Alex > From artem.ananiev at oracle.com Wed Jun 6 08:24:28 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 06 Jun 2012 17:24:28 +0200 Subject: [7u6] Review request for: 7172722: Latest jdk7u from OSX broke universal build In-Reply-To: <4FCDF02F.3040006@oracle.com> References: <4FCDF02F.3040006@oracle.com> Message-ID: <4FCF762C.1030405@oracle.com> Looks fine. Thanks, Artem On 6/5/2012 1:40 PM, Anthony Petrov wrote: > Hi Artem and Sergey, > > Please review a direct back-port of this one-line fix for > http://bugs.sun.com/view_bug.do?bug_id=7172722 at: > > http://cr.openjdk.java.net/~anthony/7u6-11-MacUniversalBuild-7172722.0/ > > The fix has been verified by Henri Gomez, and has already been pushed to > JDK 8. > > -- > best regards, > Anthony From scott.kovatch at oracle.com Wed Jun 6 08:33:29 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 6 Jun 2012 08:33:29 -0700 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: References: <4FC373A5.9030508@oracle.com> <89803632-78F2-410F-B66B-09AEFC8CAB11@oracle.com> <4FC39B2F.6070805@oracle.com> <32533319-5E00-483F-AE69-6E79419C3757@oracle.com> <4FC78E82.1030500@oracle.com> <99A4EEA8-726B-4319-AEDE-DC84E9F9D32F@oracle.com> Message-ID: <734F6A51-08C7-4BE1-8E70-8037752C0A48@oracle.com> Your best bet is to start with the app bundler project on java.net. http://java.net/projects/appbundler It's an ant script that will take a JAR file and turn it into a bundled app. Also, the latest builds of javafxpackager will now generate a bundled app, too. -- Scott On Jun 1, 2012, at 8:27 AM, Leonid Romanov wrote: > Hi Scott, > Could you please provide me with instructions how to create my own bundled app? There is a couple of things I want to test... > > On 31.05.2012, at 20:20, Scott Kovatch wrote: > >> I think what Artem is saying is that if the application is bundled, and CFBundleName is set, it should take higher priority than JAVA_MAIN_CLASS_. >> >> If that is what you are saying, Artem, I agree. :-) >> >> We're straying away from the original review, though. >> >> -- Scott >> >> On May 31, 2012, at 8:30 AM, Artem Ananiev wrote: >> >>> Hi, Leonid, >>> >>> shouldn't app name set in the bundler be of higher priority than JAVA_MAIN_CLASS_ value, set by Java launcher? >>> >>> Thanks, >>> >>> Artem >>> >>> On 5/29/2012 8:59 PM, Leonid Romanov wrote: >>>> Well, the order is the following: first, we check if -Xdock:name has been set. If it hasn't, we check for the "apple.awt.application.name" property. If this property hasn't been set, we try to get the app name from the JAVA_MAIN_CLASS_ environment variable, which is used to pass the name of a Java class whose main() method was invoked by the Java launcher code to start the application. If JAVA_MAIN_CLASS_ hasn't been set, then as the last resort we try to get the app name from the bundle. >>>> >>>> On 28.05.2012, at 19:35, Artem Ananiev wrote: >>>> >>>>> >>>>> On 5/28/2012 6:06 PM, Leonid Romanov wrote: >>>>>> Hi, >>>>>> The problem with the application name is that the app in question uses "com.apple.mrj.application.apple.menu.about.name" property to set its name. Mu understanding is that we don't support this property in OpenJDK. >>>>> >>>>> OK, fine. Is the application name set correctly when it is passed from app bundle or as -Xdock:name? >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>>> On 28.05.2012, at 16:46, Artem Ananiev wrote: >>>>>> >>>>>>> Hi, Leonid, >>>>>>> >>>>>>> the fix looks fine. Is the application name issue (also mentioned in 7159381) addressed in another fix? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Artem >>>>>>> >>>>>>> On 5/24/2012 5:23 PM, Leonid Romanov wrote: >>>>>>>> Hi, >>>>>>>> Please review a fix for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category. The problem here is that we ignore the fact that for the bundled app its icon might be specified via Info.plist file. In this case OS X sets the icon for us, so we don't have to do anything. >>>>>>>> >>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 >>>>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7159381/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Leonid. >>>>>>>> >>>>>> >>>> >> > From jcpalmer at rochester.rr.com Thu Jun 7 07:33:59 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Thu, 7 Jun 2012 10:33:59 -0400 Subject: Getting Netbeans to use OpenJDK Message-ID: <23998865-92DA-4AAF-9FB2-A4713A93EE2B@rochester.rr.com> I have a problem in a JWS application involving the GlassPane. I thought to switch development temporary from a Windows machine, after 2 days of messy / slow isolation progress. - I installed 1.7.0_06_b12 JDK first. It is in the old Apple Java Preferences. - Installed NetBeans 7.1.2. I never got a prompt of what JDK to use. - I added the Java 7 platform to Netbeans. When the program is run, I works fine, but in the application there is a spot where it list the Java version & it is 1.6. Looked in all the Preferences, but see nothing. Started looking at the NetBeans directory in terminal, but this is very tedious since Finder is worthless. Did I do something wrong. Thanks Jeff From jcpalmer at rochester.rr.com Thu Jun 7 08:25:42 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Thu, 7 Jun 2012 11:25:42 -0400 Subject: Getting Netbeans to use OpenJDK In-Reply-To: <23998865-92DA-4AAF-9FB2-A4713A93EE2B@rochester.rr.com> References: <23998865-92DA-4AAF-9FB2-A4713A93EE2B@rochester.rr.com> Message-ID: <4D2BF06C-65C7-4FFA-8E5D-D5BCE773439A@rochester.rr.com> Well found netbeans.conf on windows, located on Mac. Ended up just turning Java 6 JDK off in Apple Preference though. It errors now in Netbeans, which is "Good" On Jun 7, 2012, at 10:33 AM, Jeff Palmer wrote: > I have a problem in a JWS application involving the GlassPane. I thought to switch development temporary from a Windows machine, after 2 days of messy / slow isolation progress. > > - I installed 1.7.0_06_b12 JDK first. It is in the old Apple Java Preferences. > - Installed NetBeans 7.1.2. I never got a prompt of what JDK to use. > - I added the Java 7 platform to Netbeans. > > When the program is run, I works fine, but in the application there is a spot where it list the Java version & it is 1.6. > > Looked in all the Preferences, but see nothing. Started looking at the NetBeans directory in terminal, but this is very tedious since Finder is worthless. Did I do something wrong. > > Thanks > > Jeff From jfinley at tech4learning.com Thu Jun 7 14:26:18 2012 From: jfinley at tech4learning.com (Jessica Finley) Date: Thu, 7 Jun 2012 15:26:18 -0600 Subject: Sandbox Violation on Runtime Exec Message-ID: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> Hiya folks, Our application makes the call 'sysctl hw' to get information about the hardware of a client's system. Since sandboxing our application, this yields the following violation: deny file-read-data /dev/fd In an effort to debug, I've made an objective-c-only test project that calls the same command via an NSTask. This test project has the same sandbox entitlements as my java application, yet the objective-c test project does not get a violation from the sandbox police. Can anyone explain why that would be? And perhaps, what can I do differently in my java app to call this command (we're currently using Runtime.exec()) and not get pulled over by the sandbox police? Thanks! -Jess From marco.dinacci at gmail.com Fri Jun 8 03:11:18 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 8 Jun 2012 11:11:18 +0100 Subject: Sandbox Violation on Runtime Exec In-Reply-To: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> Message-ID: Hi, > Can anyone explain why that would be? ?And perhaps, what can I do differently in my java app to call this command (we're currently using Runtime.exec()) and not get pulled over by the sandbox police? my guess is that it is blocked because Runtime.exec() executes the command in a separate process, which doesn't inherit the sandbox entitlements of his parent. You could try either using the com.apple.security.inherit entitlement or create a small tool as an XPC service. As you say that NSTask works you could also make a dylib and wrap it using JNI. Best, Marco From mik3hall at gmail.com Fri Jun 8 03:24:14 2012 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 8 Jun 2012 05:24:14 -0500 Subject: Sandbox Violation on Runtime Exec In-Reply-To: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> Message-ID: <961E2837-0CF9-49A7-8C47-465E357D7836@gmail.com> On Jun 7, 2012, at 4:26 PM, Jessica Finley wrote: > > > Can anyone explain why that would be? For Runtime exec the command runs in some kind of subprocess. I'm not familiar with sandboxed yet but does it pass entitlements through to subprocesses? If thats it and theres no way to give the subprocess the same entitlements NSTask and jni might be how you have to go? From alexander.zuev at oracle.com Fri Jun 8 03:25:57 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 08 Jun 2012 14:25:57 +0400 Subject: [7u6] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() Message-ID: <4FD1D335.6050508@oracle.com> Hello, please review my fix for CR 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() Actually it is a backport to the 7u6 of the fix for jdk8. CR description can be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 Webrev with the proposed change can be seen here: http://cr.openjdk.java.net/~kizune/7124247/jdk7u6/webrev.01 With best regards, Alex From alexander.zuev at oracle.com Fri Jun 8 04:07:51 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 08 Jun 2012 15:07:51 +0400 Subject: [8] Please review my fix for 7173487: [macosx] Problems with popup menus, tooltips and dialog boxes in dual monitor setup Message-ID: <4FD1DD07.8070006@oracle.com> Hello, please review my fix for CR 7173487: [macosx] Problems with popup menus, tooltips and dialog boxes in dual monitor setup CR description can be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173487 Webrev with the proposed change can be seen here: http://cr.openjdk.java.net/~kizune/7173487/webrev.00 With best regards, Alex From dmitry.cherepanov at oracle.com Fri Jun 8 04:37:12 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 08 Jun 2012 15:37:12 +0400 Subject: [8] Please review my fix for 7173487: [macosx] Problems with popup menus, tooltips and dialog boxes in dual monitor setup In-Reply-To: <4FD1DD07.8070006@oracle.com> References: <4FD1DD07.8070006@oracle.com> Message-ID: <4FD1E3E8.90502@oracle.com> Looks fine to me. Thanks, Dmitry Alexander Zuev wrote: > Hello, > > please review my fix for CR 7173487: [macosx] Problems with popup > menus, tooltips and dialog boxes in dual monitor setup > > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173487 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7173487/webrev.00 > > With best regards, > Alex From alexandr.scherbatiy at oracle.com Fri Jun 8 05:50:58 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 08 Jun 2012 16:50:58 +0400 Subject: [7u6] Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. Message-ID: <4FD1F532.8060004@oracle.com> Hello, This is a request from the AWT team to backport a JDK 8 fix into JDK 7u6: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev7.00 JDK 8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0fad89bd606b This is not a direct backport because there were new changes in the 7u6 AWTView, AWTWindow, and CPlatformWindow classes. So the fix code has been ported manually. The only changes between original fix and new one is that self.nsWindow call is used instead of the self in the AWTWindow.m class in the same way as it is used now in the AWTWindow.m class from the JDK 8 sources. Thank you, Alexandr. From jfinley at tech4learning.com Fri Jun 8 06:27:49 2012 From: jfinley at tech4learning.com (Jessica Finley) Date: Fri, 8 Jun 2012 07:27:49 -0600 Subject: Sandbox Violation on Runtime Exec In-Reply-To: References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> Message-ID: <98737FFA-5704-44AD-8321-7709F56519B3@tech4learning.com> That makes sense? how, though, would I set the inherit entitlement for the new process? The only way I know to set entitlements is at codesigning time, but this process is generated on the fly at runtime. That would be my preferred route.. if that isn't possible, I'll make a dylib. Thanks! -Jess On Jun 8, 2012, at 4:11 AM, Marco Dinacci wrote: > Hi, > >> Can anyone explain why that would be? And perhaps, what can I do differently in my java app to call this command (we're currently using Runtime.exec()) and not get pulled over by the sandbox police? > > my guess is that it is blocked because Runtime.exec() executes the > command in a separate process, which doesn't inherit the sandbox > entitlements of his parent. > > You could try either using the com.apple.security.inherit entitlement > or create a small tool as an XPC service. > As you say that NSTask works you could also make a dylib and wrap it using JNI. > > > Best, > Marco From marco.dinacci at gmail.com Fri Jun 8 07:31:54 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 8 Jun 2012 15:31:54 +0100 Subject: Sandbox Violation on Runtime Exec In-Reply-To: <98737FFA-5704-44AD-8321-7709F56519B3@tech4learning.com> References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <98737FFA-5704-44AD-8321-7709F56519B3@tech4learning.com> Message-ID: Hi, > That makes sense? how, though, would I set the inherit entitlement for the new process? ?The only way I know to set entitlements is at codesigning time, but this process is generated on the fly at runtime. you're right, you can't at runtime. You would have to create a new executable with its own entitlements...I guess JNI may be an easier solution at this point. BTW, it seems Runtime.exec() uses fork() on OSX so AFAIK it may never work in a sandbox. The reason why NSTask works is probably because internally it uses posix_spawn. Best, Marco From jfinley at tech4learning.com Fri Jun 8 07:35:44 2012 From: jfinley at tech4learning.com (Jessica Finley) Date: Fri, 8 Jun 2012 08:35:44 -0600 Subject: Sandbox Violation on Runtime Exec In-Reply-To: References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <98737FFA-5704-44AD-8321-7709F56519B3@tech4learning.com> Message-ID: > you're right, you can't at runtime. > You would have to create a new executable with its own > entitlements...I guess JNI may be an easier solution at this point. > Alrighty, then. Looks like JNI is the way to go. > BTW, it seems Runtime.exec() uses fork() on OSX so AFAIK it may never > work in a sandbox. > The reason why NSTask works is probably because internally it uses posix_spawn. > I was wondering if this was the case. Thank you for your time and insight! -Jess From marco.dinacci at gmail.com Fri Jun 8 08:45:28 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 8 Jun 2012 16:45:28 +0100 Subject: Sandbox Violation on Runtime Exec In-Reply-To: References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <98737FFA-5704-44AD-8321-7709F56519B3@tech4learning.com> Message-ID: Hi, >> BTW, it seems Runtime.exec() uses fork() on OSX so AFAIK it may never >> work in a sandbox. >> The reason why NSTask works is probably because internally it uses posix_spawn. In the light of this, I wonder if this behaviour should be filed as a bug. There is currently no (Java only) way to create a child process if the parent is executed inside a sandbox, any call to Runtime.getRuntime().exec() or ProcessBuilder start() will fail. I think the OpenJDK on OSX should use either posix_spawn or NSTask. Best, Marco From anthony.petrov at oracle.com Fri Jun 8 12:14:51 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 08 Jun 2012 23:14:51 +0400 Subject: [8] Please review my fix for 7173487: [macosx] Problems with popup menus, tooltips and dialog boxes in dual monitor setup In-Reply-To: <4FD1DD07.8070006@oracle.com> References: <4FD1DD07.8070006@oracle.com> Message-ID: <4FD24F2B.5020303@oracle.com> Looks good. -- best regards, Anthony On 6/8/2012 3:07 PM, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7173487: [macosx] Problems with popup > menus, tooltips and dialog boxes in dual monitor setup > > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173487 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7173487/webrev.00 > > With best regards, > Alex From kirk at kodewerk.com Fri Jun 8 14:22:16 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 8 Jun 2012 23:22:16 +0200 Subject: Sandbox Violation on Runtime Exec In-Reply-To: <961E2837-0CF9-49A7-8C47-465E357D7836@gmail.com> References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <961E2837-0CF9-49A7-8C47-465E357D7836@gmail.com> Message-ID: <3A42A9E0-F946-4502-9415-F4A07D8DD8D1@kodewerk.com> IOWs, busted... Regards, Kirk On 2012-06-08, at 12:24 PM, Michael Hall wrote: > > On Jun 7, 2012, at 4:26 PM, Jessica Finley wrote: >> >> >> Can anyone explain why that would be? > > For Runtime exec the command runs in some kind of subprocess. I'm not familiar with sandboxed yet but does it pass entitlements through to subprocesses? > If thats it and theres no way to give the subprocess the same entitlements NSTask and jni might be how you have to go? From mik3hall at gmail.com Fri Jun 8 14:29:47 2012 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 8 Jun 2012 16:29:47 -0500 Subject: Sandbox Violation on Runtime Exec In-Reply-To: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> Message-ID: On Jun 7, 2012, at 4:26 PM, Jessica Finley wrote: > Our application makes the call 'sysctl hw' to get information about the hardware of a client's system. Since sandboxing our application, this yields the following violation: Sorry, I didn't look at Marco's first response closely enough and mine was pretty much redundant on his. One thing I did wonder later though was that since the only other alternative not considered would be to get the hardware information some other way. Curiosity, what hardware information do you get? From mik3hall at gmail.com Fri Jun 8 14:59:37 2012 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 8 Jun 2012 16:59:37 -0500 Subject: Sandbox Violation on Runtime Exec In-Reply-To: <3A42A9E0-F946-4502-9415-F4A07D8DD8D1@kodewerk.com> References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <961E2837-0CF9-49A7-8C47-465E357D7836@gmail.com> <3A42A9E0-F946-4502-9415-F4A07D8DD8D1@kodewerk.com> Message-ID: On Jun 8, 2012, at 4:22 PM, Kirk Pepperdine wrote: > IOWs, busted... Yep, I sometimes browse and miss things. Did come up with this in the mean time though? com.apple.security.inherit entitlement, Supposedly mentioned in the WWDC 2011 Session 204 video "App Sandbox and the Mac App Store" Disclaimer in order to not be considered busted again, I haven't watched it yet or verified it will work with Runtime exec'd Sandboxed java app's. From mik3hall at gmail.com Fri Jun 8 16:23:25 2012 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 8 Jun 2012 18:23:25 -0500 Subject: Sandbox Violation on Runtime Exec In-Reply-To: References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <961E2837-0CF9-49A7-8C47-465E357D7836@gmail.com> <3A42A9E0-F946-4502-9415-F4A07D8DD8D1@kodewerk.com> Message-ID: On Jun 8, 2012, at 4:59 PM, Michael Hall wrote: > > On Jun 8, 2012, at 4:22 PM, Kirk Pepperdine wrote: > >> IOWs, busted... > > > Yep, I sometimes browse and miss things. > Did come up with this in the mean time though? > com.apple.security.inherit entitlement, > Supposedly mentioned in the WWDC 2011 Session 204 video "App Sandbox and the Mac App Store" > Disclaimer in order to not be considered busted again, I haven't watched it yet or verified it will work with Runtime exec'd Sandboxed java app's. > Sorry, tending toward bad list etiquette replying to myself and getting noisy again. First I read your post out of order. You were probably referring to Runtime exec being busted - not me. I may agree with that now after actually listening to the session I mentioned. The 'inherit' entitlement, as I understand what was being said in the session, does nothing except note that you have 'helper' applications/processes that inherit your main sandbox. They always inherit your main sandbox, period. So if you are getting an error in Runtime it is because the Runtime process is doing something your own entitlements do not cover. If I'm still understanding that incorrectly someone please correct me. But the Runtime fix or workaround is to add the correct entitlements to your application that the Runtime process requires. From lordpixel at me.com Fri Jun 8 19:10:00 2012 From: lordpixel at me.com (Andrew Thompson) Date: Fri, 8 Jun 2012 22:10:00 -0400 Subject: System properties In-Reply-To: References: Message-ID: <74AE704A-31CB-4E87-A5D2-60999BF859A6@me.com> On May 27, 2012, at 6:46 PM, Michael Hall wrote: > Apple 1.6 never seems to give UTF-8 contrary to what Andrew said. It is always MacRoman. Either he was not accurate in what he said or is changing the property to UTF-8 somewhere that he isn't aware of it. Well now, that's interesting. Running locale and then my program again in the terminal I see % locale LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL= %uname -a Darwin Bubbles.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64 % java -version java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode) java -cp . FileEncoding MacRoman java.vm.version: 20.6-b01-415 file.encoding.pkg: sun.io java.runtime.version: 1.6.0_31-b04-415-11M3635 java.io.tmpdir: /var/folders/3l/yd1xg64n58l4ll7jnhvc0glm0000gq/T/ sun.jnu.encoding: MacRoman java.class.version: 50.0 os.version: 10.7.3 file.encoding: MacRoman java.specification.version: 1.6 java.vm.specification.version: 1.0 java.version: 1.6.0_31 file.separator: / sun.io.unicode.encoding: UnicodeLittle mrj.version: 1070.1.6.0_31-415 => Mac Roman Running the very same program in Netbeans... which as far as I know execs Java UTF-8 java.vm.version: 20.6-b01-415 file.encoding.pkg: sun.io java.runtime.version: 1.6.0_31-b04-415-11M3635 java.io.tmpdir: /var/folders/3l/yd1xg64n58l4ll7jnhvc0glm0000gq/T/ sun.jnu.encoding: MacRoman java.class.version: 50.0 os.version: 10.7.3 file.encoding: UTF-8 java.specification.version: 1.6 java.vm.specification.version: 1.0 java.version: 1.6.0_31 file.separator: / sun.io.unicode.encoding: UnicodeLittle mrj.version: 1070.1.6.0_31-415 => UTF8 And yet Netbeans' own About window shows Product Version: NetBeans IDE 7.0.1 (Build 201107282000) Java: 1.6.0_31; Java HotSpot(TM) 64-Bit Server VM 20.6-b01-415 System: Mac OS X version 10.7.3 running on x86_64; MacRoman; en_US (nb) Userdir: /Users/pixel/.netbeans/7.0 => MacRoman So this is very strange. The same program can return MacRoman in the Terminal and UTF-8 in Netbeans. There's more to this than first appears. AndyT (lordpixel - the cat who walks through walls) A little bigger on the inside (see you later space cowboy, you can't take the sky from me) From mik3hall at gmail.com Sat Jun 9 02:53:55 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 9 Jun 2012 04:53:55 -0500 Subject: System properties In-Reply-To: <74AE704A-31CB-4E87-A5D2-60999BF859A6@me.com> References: <74AE704A-31CB-4E87-A5D2-60999BF859A6@me.com> Message-ID: <1E78F0B5-606F-4582-AA45-A6DED48DEC74@gmail.com> On Jun 8, 2012, at 9:10 PM, Andrew Thompson wrote: > There's more to this than first appears. In NetBeans? I can only imagine. From alexander.zuev at oracle.com Sat Jun 9 03:39:47 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Sat, 09 Jun 2012 14:39:47 +0400 Subject: [7u6] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() Message-ID: <4FD327F3.1090206@oracle.com> Hello, slightly updated fix for CR 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() Actually it is a backport to the 7u6 of the fix for jdk8 with minor corrections - fixed situation with the getDisplayModes() when we returned the wrong resolutions for the requested modes, fixed crash when we repeatedly asked to set display mode in a quick sentence and now setDisplayMode correctly throws an IllegalArgumentException instead of NullPointerException if null is passed as a parameter. CR description can be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 Webrev with the proposed change can be seen here: http://cr.openjdk.java.net/~kizune/7124247/jdk7u6/webrev.02 With best regards, Alex From anthony.petrov at oracle.com Sat Jun 9 04:24:25 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Sat, 09 Jun 2012 15:24:25 +0400 Subject: [7u6] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <4FD327F3.1090206@oracle.com> References: <4FD327F3.1090206@oracle.com> Message-ID: <4FD33269.7010800@oracle.com> Looks good to me. -- best regards, Anthony On 6/9/2012 2:39 PM, Alexander Zuev wrote: > Hello, > > slightly updated fix for CR 7124247: [macosx] Implement > GraphicsDevice.setDisplayMode() > > Actually it is a backport to the 7u6 of the fix for jdk8 with minor > corrections - fixed situation with the getDisplayModes() when we > returned the wrong resolutions for the requested modes, fixed crash when > we repeatedly asked to set display mode in a quick sentence and now > setDisplayMode correctly throws an IllegalArgumentException instead of > NullPointerException if null is passed as a parameter. > > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7124247/jdk7u6/webrev.02 > > With best regards, > Alex From anthony.petrov at oracle.com Sat Jun 9 06:15:01 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Sat, 09 Jun 2012 17:15:01 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FCE4F0C.8040800@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FCE201E.503@oracle.com> <4FCE4F0C.8040800@oracle.com> Message-ID: <4FD34C55.5000507@oracle.com> Thanks for the comments. Will there be an updated version of the fix? -- best regards, Anthony On 6/5/2012 10:25 PM, Sergey Bylokhov wrote: > 05.06.2012 19:05, Anthony Petrov ???????: >> Hi Sergey, >> >> A couple of comments: >> >> 1. src/macosx/classes/sun/lwawt/LWWindowPeer.java >>> 576 //flushOnscreenGraphics(); >> >> There's no any explanation as to why this line is commented out. Could >> you either add a remark in the code, or delete this line altogether? > Yes. Thanks. >> >> 2. How does the fix affect the performance of non-opaque (and opaque, >> too) windows? > In general a non-opaque window should work better just because now it > doesn't use raw BufferedImage. Opaque window should be affected only by > changes in RepaintManager(). >> >> -- >> best regards, >> Anthony >> >> On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> Please review the fix. >>> >>> Shaped window was implemented as a translucent window with >>> constrained graphics. Now translucent window doesn't use separate >>> BufferedImage as a back buffer. Also alpha value for the swing back >>> buffer was enabled(Shared code changed). >>> Note that shaped windows are affected by this bugs: >>> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >>> - Shadows disappear. >>> - Transparent areas aren't transparent to mouse clicks. >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >>> - Opacity does not work for non opaque windows. >>> >>> Any suggestions are welcome. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >>> > > From anthony.petrov at oracle.com Sat Jun 9 06:34:42 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Sat, 09 Jun 2012 17:34:42 +0400 Subject: [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing In-Reply-To: <4FCE302D.2070508@oracle.com> References: <4FC77592.7020900@oracle.com> <4FCE29F8.4010503@oracle.com> <4FCE302D.2070508@oracle.com> Message-ID: <4FD350F2.4090003@oracle.com> Hi Sergey, Thanks for clarifications. Please find my comments below. On 6/5/2012 8:13 PM, Sergey Bylokhov wrote: >> 3. src/macosx/classes/sun/lwawt/LWWindowPeer.java >>> 179 updateInsets(platformWindow.getInsets()); >> >> The system may report wrong insets before a window is shown on the >> screen. Perhaps, instead of initializeImpl() we should introduce >> preInitialize() (== current initializeImpl()), and postInitialize() >> (to where this, and the subsequent replaceSurfaceData() calls might go.) > Like it was done in XAWT? It is just a nightmare. I assume that What kind of nightmare do you mean? To me it looks logical to perform some tasks before, and some other tasks after disaplying a component. Hence the need for per- and post- initializers. > updateInsets() should be called by some of the native callbacks, like > notifyExpose and reshape? Nope. It's only called from the initialize() method once since on the Mac insets never change. Therefore, it is critical to call it only after showing the window on the screen. On 6/5/2012 10:17 PM, Sergey Bylokhov wrote: > In this case In current implementation it works wrong too, because it can be called when the window initially invisible. So far, it works fine. Please run insets-related tests (simply all automatic tests for Window, Frame, and Dialog both open and closed) to makes sure they pass. >> 4. >>> 220 protected void setVisibleImpl(final boolean visible) { >>> 221 super.setVisibleImpl(visible); >> >> Why do we remove a call to replaceSurfaceData() in the beginning of >> the method? > Before the fix, setVisible() can be called before surface creation, but > after the fix it will be called after. Could you clarify this further please? What exactly is the reason to move the replaceSurfaceData() call from setVisible() to initializeImpl()? >> 5. >>> 983 ((Graphics2D) >>> g).setBackground(getBackground()); >> >> I suggest to add an instanceof check before this call. > I guess that Buffered image cannot return something except Graphics2D I guess so too. Nevertheless, I still suggest to add such a check. >> 6. >>> 227 // invokeLater() can be deleted, but in this case we get >>> a lag between >>> 228 // windows showing and content painting. >> >> Is the lag so very noticeable? On other platforms we don't actually do >> this, and I don't recall any issues about such lags. > Yes The difference is noticeable. So I update the comments and leave it > as is for now. Interesting. This needs to be investigated, perhaps under a separate CR. -- best regards, Anthony >> >> -- >> best regards, >> Anthony >> >> On 5/31/2012 5:43 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> Please review the fix. >>> >>> Notes from the bug and comments: >>> 1. setVisible() should be called at the end of the peers >>> initialization. We can move super.initialize() to the end of the >>> peers initializations. >>> Initialize() was split to initialize() and initializeImpl(). In the >>> initialize() we call initializeImpl and then we call to setVisible(). >>> initializeImpl overridden in subclasses. >>> >>> 2. Invokelater in the initialization/disposing is a tricky. >>> Left it as is. Probably later it will be changed. Comments was updated. >>> >>> 3. replaceSurfacedata() should be moved outside of >>> LWWindowPeer.setVisible() >>> Done. Also duplicate code was extracted to setVisible() method which >>> call setVisibleImpl(). >>> >>> 4. Backbuffer in replaceSurfacedata() should be initialized by >>> clearRect instead of fillrect(composite is important). >>> Done. related to composite. >>> >>> 5. During lwwindowpeer initialization we call two similar methods >>> nativeSetNSWindowAlpha() and setAlphaValue(). >>> nativeSetNSWindowAlpha() removed from CPlatformWindow.java. >>> >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7142091/webrev.00/ >>> > > From Sergey.Bylokhov at oracle.com Sat Jun 9 14:25:02 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 10 Jun 2012 01:25:02 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FD34C55.5000507@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FCE201E.503@oracle.com> <4FCE4F0C.8040800@oracle.com> <4FD34C55.5000507@oracle.com> Message-ID: <4FD3BF2E.2000101@oracle.com> Hi, Anthony. yes I will make the new version soon. 09.06.2012 17:15, Anthony Petrov wrote: > Thanks for the comments. Will there be an updated version of the fix? > > -- > best regards, > Anthony > > On 6/5/2012 10:25 PM, Sergey Bylokhov wrote: >> 05.06.2012 19:05, Anthony Petrov ???????: >>> Hi Sergey, >>> >>> A couple of comments: >>> >>> 1. src/macosx/classes/sun/lwawt/LWWindowPeer.java >>>> 576 //flushOnscreenGraphics(); >>> >>> There's no any explanation as to why this line is commented out. >>> Could you either add a remark in the code, or delete this line >>> altogether? >> Yes. Thanks. >>> >>> 2. How does the fix affect the performance of non-opaque (and >>> opaque, too) windows? >> In general a non-opaque window should work better just because now it >> doesn't use raw BufferedImage. Opaque window should be affected only >> by changes in RepaintManager(). >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >>>> Hi Everyone, >>>> Please review the fix. >>>> >>>> Shaped window was implemented as a translucent window with >>>> constrained graphics. Now translucent window doesn't use separate >>>> BufferedImage as a back buffer. Also alpha value for the swing back >>>> buffer was enabled(Shared code changed). >>>> Note that shaped windows are affected by this bugs: >>>> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >>>> - Shadows disappear. >>>> - Transparent areas aren't transparent to mouse clicks. >>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >>>> - Opacity does not work for non opaque windows. >>>> >>>> Any suggestions are welcome. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >>>> >> >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Jun 9 14:40:36 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 10 Jun 2012 01:40:36 +0400 Subject: [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing In-Reply-To: <4FD350F2.4090003@oracle.com> References: <4FC77592.7020900@oracle.com> <4FCE29F8.4010503@oracle.com> <4FCE302D.2070508@oracle.com> <4FD350F2.4090003@oracle.com> Message-ID: <4FD3C2D4.1070809@oracle.com> Hi Anthony. See my comments inline: 09.06.2012 17:34, Anthony Petrov wrote: > Hi Sergey, > > Thanks for clarifications. Please find my comments below. > > On 6/5/2012 8:13 PM, Sergey Bylokhov wrote: >>> 3. src/macosx/classes/sun/lwawt/LWWindowPeer.java >>>> 179 updateInsets(platformWindow.getInsets()); >>> >>> The system may report wrong insets before a window is shown on the >>> screen. Perhaps, instead of initializeImpl() we should introduce >>> preInitialize() (== current initializeImpl()), and postInitialize() >>> (to where this, and the subsequent replaceSurfaceData() calls might >>> go.) >> Like it was done in XAWT? It is just a nightmare. I assume that > > What kind of nightmare do you mean? To me it looks logical to perform > some tasks before, and some other tasks after disaplying a component. > Hence the need for per- and post- initializers. Because in general nobody know correct place for initialization. Moreover we can do something after component showing in setVisble(true) only. > >> updateInsets() should be called by some of the native callbacks, like >> notifyExpose and reshape? > > Nope. It's only called from the initialize() method once since on the > Mac insets never change. Therefore, it is critical to call it only > after showing the window on the screen. But what happens when the peer is invisible by default? Probably the better place for updateInsets is setVisible()? > > On 6/5/2012 10:17 PM, Sergey Bylokhov wrote: >> In this case In current implementation it works wrong too, because it >> can be called when the window initially invisible. > > So far, it works fine. Please run insets-related tests (simply all > automatic tests for Window, Frame, and Dialog both open and closed) to > makes sure they pass. See previous comment. > >>> 4. >>>> 220 protected void setVisibleImpl(final boolean visible) { >>>> 221 super.setVisibleImpl(visible); >>> >>> Why do we remove a call to replaceSurfaceData() in the beginning of >>> the method? >> Before the fix, setVisible() can be called before surface creation, >> but after the fix it will be called after. > > Could you clarify this further please? What exactly is the reason to > move the replaceSurfaceData() call from setVisible() to initializeImpl()? Just because it is unnecessary in setVisble() because surface already created at the end of LWWindow.initializeImpl(). Why we should try to replace surface each time in setVisible()? > > >>> 5. >>>> 983 ((Graphics2D) >>>> g).setBackground(getBackground()); >>> >>> I suggest to add an instanceof check before this call. >> I guess that Buffered image cannot return something except Graphics2D > > I guess so too. Nevertheless, I still suggest to add such a check. ok I will add. > > >>> 6. >>>> 227 // invokeLater() can be deleted, but in this case we >>>> get a lag between >>>> 228 // windows showing and content painting. >>> >>> Is the lag so very noticeable? On other platforms we don't actually >>> do this, and I don't recall any issues about such lags. >> Yes The difference is noticeable. So I update the comments and leave >> it as is for now. > > Interesting. This needs to be investigated, perhaps under a separate CR. I will create new CR. > > -- > best regards, > Anthony > >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 5/31/2012 5:43 PM, Sergey Bylokhov wrote: >>>> Hi Everyone, >>>> Please review the fix. >>>> >>>> Notes from the bug and comments: >>>> 1. setVisible() should be called at the end of the peers >>>> initialization. We can move super.initialize() to the end of the >>>> peers initializations. >>>> Initialize() was split to initialize() and initializeImpl(). In the >>>> initialize() we call initializeImpl and then we call to >>>> setVisible(). initializeImpl overridden in subclasses. >>>> >>>> 2. Invokelater in the initialization/disposing is a tricky. >>>> Left it as is. Probably later it will be changed. Comments was >>>> updated. >>>> >>>> 3. replaceSurfacedata() should be moved outside of >>>> LWWindowPeer.setVisible() >>>> Done. Also duplicate code was extracted to setVisible() method >>>> which call setVisibleImpl(). >>>> >>>> 4. Backbuffer in replaceSurfacedata() should be initialized by >>>> clearRect instead of fillrect(composite is important). >>>> Done. related to composite. >>>> >>>> 5. During lwwindowpeer initialization we call two similar methods >>>> nativeSetNSWindowAlpha() and setAlphaValue(). >>>> nativeSetNSWindowAlpha() removed from CPlatformWindow.java. >>>> >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7142091/webrev.00/ >>>> >> >> -- Best regards, Sergey. From jfinley at tech4learning.com Mon Jun 11 08:43:39 2012 From: jfinley at tech4learning.com (Jess Finley) Date: Mon, 11 Jun 2012 09:43:39 -0600 Subject: Sandbox Violation on Runtime Exec In-Reply-To: References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> Message-ID: <8FBE48CB-7CF4-4AFA-9E3C-A64696EADBF1@tech4learning.com> Hi, we currently gather the architecture, model, CPU speed, and ram. On Jun 8, 2012, at 15:29, Michael Hall wrote: > > On Jun 7, 2012, at 4:26 PM, Jessica Finley wrote: > >> Our application makes the call 'sysctl hw' to get information about the hardware of a client's system. Since sandboxing our application, this yields the following violation: > > Sorry, I didn't look at Marco's first response closely enough and mine was pretty much redundant on his. One thing I did wonder later though was that since the only other alternative not considered would be to get the hardware information some other way. > Curiosity, what hardware information do you get? From marco.dinacci at gmail.com Mon Jun 11 09:17:09 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Mon, 11 Jun 2012 17:17:09 +0100 Subject: Patch for #7170716, crash in OSXAPP_SetApplicationDelegate Message-ID: Hi, I raised a couple of weeks ago bug #7170716 : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170716 The original discussion is here: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004226.html In short, every time a Java application is opened from a registered file the JVM crash in OSXAPP_SetApplicationDelegate. Today I started looking for a solution and I've found two memory management issues in the code: The first and the one that was causing the bug is related with blocks. In QueuingApplicationDelegate.m there are many methods where you're adding blocks to an NSMutableArray but without copying them. Those blocks literals are created on the stack so even if they're retained once the function exits they no longer exist. Calling [copy] will assure that the block will have a reference on the heap. Then once the block has been consumed it needs to be released. The second issue is that you don't retain the delegate object in QueuingApplicationDelegate.m and in NSApplicationAWT.m. Even if the pointers are static you should still call [retain] because it's not guaranteed that the objects the pointers are pointing to won't be deallocated at one point. Here below a patch that resolve both issues, I tested it successfully with a trivial test case and with my application. Best, Marco diff -r 96dd3a52e76c src/macosx/native/sun/osxapp/NSApplicationAWT.m --- a/src/macosx/native/sun/osxapp/NSApplicationAWT.m Thu May 31 16:35:25 2012 +0100 +++ b/src/macosx/native/sun/osxapp/NSApplicationAWT.m Mon Jun 11 16:49:04 2012 +0100 @@ -334,17 +334,17 @@ AWT_ASSERT_APPKIT_THREAD; } @end void OSXAPP_SetApplicationDelegate(id delegate) { AWT_ASSERT_APPKIT_THREAD; - applicationDelegate = delegate; + applicationDelegate = [delegate retain]; if (NSApp != nil) { [NSApp setDelegate: applicationDelegate]; if (applicationDelegate && qad) { [qad processQueuedEventsWithTargetDelegate: applicationDelegate]; qad = nil; } diff -r 96dd3a52e76c src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m --- a/src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Thu May 31 16:35:25 2012 +0100 +++ b/src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Mon Jun 11 16:49:04 2012 +0100 @@ -104,110 +104,110 @@ static id realDe self->queue = nil; [super dealloc]; } - (void)_handleOpenURLEvent:(NSAppleEventDescriptor *)openURLEvent withReplyEvent:(NSAppleEventDescriptor *)replyEvent { - [self->queue addObject:^(){ + [self->queue addObject:[^(){ [realDelegate _handleOpenURLEvent:openURLEvent withReplyEvent:replyEvent]; - }]; + } copy]]; } - (void)application:(NSApplication *)theApplication openFiles:(NSArray *)fileNames { - [self->queue addObject:^(){ + [self->queue addObject:[^(){ [realDelegate application:theApplication openFiles:fileNames]; - }]; + } copy]]; } - (NSApplicationPrintReply)application:(NSApplication *)application printFiles:(NSArray *)fileNames withSettings:(NSDictionary *)printSettings showPrintPanels:(BOOL)showPrintPanels { if (!fHandlesDocumentTypes) { return NSPrintingCancelled; } - [self->queue addObject:^(){ + [self->queue addObject:[^(){ [realDelegate application:application printFiles:fileNames withSettings:printSettings showPrintPanels:showPrintPanels]; - }]; + } copy]]; // well, a bit premature, but what else can we do?.. return NSPrintingSuccess; } - (void)_willFinishLaunching { - QueuingApplicationDelegate * q = self; - [self->queue addObject:^(){ + [self->queue addObject:[^(){ [[realDelegate class] _willFinishLaunching]; - }]; + } copy]]; } - (BOOL)applicationShouldHandleReopen:(NSApplication *)theApplication hasVisibleWindows:(BOOL)flag { - [self->queue addObject:^(){ + [self->queue addObject:[^(){ [realDelegate applicationShouldHandleReopen:theApplication hasVisibleWindows:flag]; - }]; + } copy]]; return YES; } - (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)app { - [self->queue addObject:^(){ + [self->queue addObject:[^(){ [realDelegate applicationShouldTerminate:app]; - }]; + } copy]]; return NSTerminateLater; } - (void)_systemWillPowerOff { - [self->queue addObject:^(){ + [self->queue addObject:[^(){ [[realDelegate class] _systemWillPowerOff]; - }]; + } copy]]; } - (void)_appDidActivate { - [self->queue addObject:^(){ + [self->queue addObject:[^(){ [[realDelegate class] _appDidActivate]; - }]; + } copy]]; } - (void)_appDidDeactivate { - [self->queue addObject:^(){ + [self->queue addObject:[^(){ [[realDelegate class] _appDidDeactivate]; - }]; + } copy]]; } - (void)_appDidHide { - [self->queue addObject:^(){ + [self->queue addObject:[^(){ [[realDelegate class] _appDidHide]; - }]; + } copy]]; } - (void)_appDidUnhide { - [self->queue addObject:^(){ + [self->queue addObject:[^(){ [[realDelegate class] _appDidUnhide]; - }]; + } copy]]; } - (void)processQueuedEventsWithTargetDelegate:(id )delegate { + realDelegate = [delegate retain]; + NSUInteger i; NSUInteger count = [self->queue count]; - realDelegate = delegate; - for (i = 0; i < count; i++) { void (^event)() = (void (^)())[self->queue objectAtIndex: i]; event(); + [event release]; } [self->queue removeAllObjects]; } @end From swingler at apple.com Mon Jun 11 09:36:29 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 11 Jun 2012 09:36:29 -0700 Subject: Patch for #7170716, crash in OSXAPP_SetApplicationDelegate In-Reply-To: References: Message-ID: <7CE45CCE-8C7B-45B8-B936-EE3EE670598E@apple.com> You don't need to retain blocks when adding them to a collection. The collection implicitly retains them. The blocks will be released once the collection is released. The root problem may be that the delegate is getting released, but I'd need to review the surrounding code more carefully to determine that. The other design issue is that access to the queue is going through a raw pointer, whereas as property would be a safer alternative. Regards, Mike Swingler Apple Inc. On Jun 11, 2012, at 9:17 AM, Marco Dinacci wrote: > Hi, > > I raised a couple of weeks ago bug #7170716 : > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170716 > > The original discussion is here: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004226.html > > In short, every time a Java application is opened from a registered > file the JVM crash in OSXAPP_SetApplicationDelegate. > > Today I started looking for a solution and I've found two memory > management issues in the code: > > The first and the one that was causing the bug is related with blocks. > In QueuingApplicationDelegate.m there are many methods where you're > adding blocks to an NSMutableArray but without copying them. > Those blocks literals are created on the stack so even if they're > retained once the function exits they no longer exist. Calling [copy] > will assure that the block will have a reference on the heap. Then > once the block has been consumed it needs to be released. > > The second issue is that you don't retain the delegate object in > QueuingApplicationDelegate.m and in NSApplicationAWT.m. > Even if the pointers are static you should still call [retain] because > it's not guaranteed that the objects the pointers are pointing to > won't be deallocated at one point. > > Here below a patch that resolve both issues, I tested it successfully > with a trivial test case and with my application. > > Best, > Marco > > diff -r 96dd3a52e76c src/macosx/native/sun/osxapp/NSApplicationAWT.m > --- a/src/macosx/native/sun/osxapp/NSApplicationAWT.m Thu May 31 > 16:35:25 2012 +0100 > +++ b/src/macosx/native/sun/osxapp/NSApplicationAWT.m Mon Jun 11 > 16:49:04 2012 +0100 > @@ -334,17 +334,17 @@ AWT_ASSERT_APPKIT_THREAD; > } > > @end > > > void OSXAPP_SetApplicationDelegate(id delegate) > { > AWT_ASSERT_APPKIT_THREAD; > - applicationDelegate = delegate; > + applicationDelegate = [delegate retain]; > > if (NSApp != nil) { > [NSApp setDelegate: applicationDelegate]; > > if (applicationDelegate && qad) { > [qad processQueuedEventsWithTargetDelegate: applicationDelegate]; > qad = nil; > } > diff -r 96dd3a52e76c src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m > --- a/src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Thu > May 31 16:35:25 2012 +0100 > +++ b/src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Mon > Jun 11 16:49:04 2012 +0100 > @@ -104,110 +104,110 @@ static id realDe > self->queue = nil; > > [super dealloc]; > } > > > - (void)_handleOpenURLEvent:(NSAppleEventDescriptor *)openURLEvent > withReplyEvent:(NSAppleEventDescriptor *)replyEvent > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [realDelegate _handleOpenURLEvent:openURLEvent > withReplyEvent:replyEvent]; > - }]; > + } copy]]; > } > > - (void)application:(NSApplication *)theApplication > openFiles:(NSArray *)fileNames > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [realDelegate application:theApplication openFiles:fileNames]; > - }]; > + } copy]]; > } > > - (NSApplicationPrintReply)application:(NSApplication *)application > printFiles:(NSArray *)fileNames withSettings:(NSDictionary > *)printSettings showPrintPanels:(BOOL)showPrintPanels > { > if (!fHandlesDocumentTypes) { > return NSPrintingCancelled; > } > > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [realDelegate application:application printFiles:fileNames > withSettings:printSettings showPrintPanels:showPrintPanels]; > - }]; > + } copy]]; > > // well, a bit premature, but what else can we do?.. > return NSPrintingSuccess; > } > > - (void)_willFinishLaunching > { > - QueuingApplicationDelegate * q = self; > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [[realDelegate class] _willFinishLaunching]; > - }]; > + } copy]]; > } > > - (BOOL)applicationShouldHandleReopen:(NSApplication *)theApplication > hasVisibleWindows:(BOOL)flag > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [realDelegate applicationShouldHandleReopen:theApplication > hasVisibleWindows:flag]; > - }]; > + } copy]]; > return YES; > } > > - (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)app > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [realDelegate applicationShouldTerminate:app]; > - }]; > + } copy]]; > return NSTerminateLater; > } > > - (void)_systemWillPowerOff > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [[realDelegate class] _systemWillPowerOff]; > - }]; > + } copy]]; > } > > - (void)_appDidActivate > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [[realDelegate class] _appDidActivate]; > - }]; > + } copy]]; > } > > - (void)_appDidDeactivate > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [[realDelegate class] _appDidDeactivate]; > - }]; > + } copy]]; > } > > - (void)_appDidHide > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [[realDelegate class] _appDidHide]; > - }]; > + } copy]]; > } > > - (void)_appDidUnhide > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [[realDelegate class] _appDidUnhide]; > - }]; > + } copy]]; > } > > - (void)processQueuedEventsWithTargetDelegate:(id > )delegate > { > + realDelegate = [delegate retain]; > + > NSUInteger i; > NSUInteger count = [self->queue count]; > > - realDelegate = delegate; > - > for (i = 0; i < count; i++) { > void (^event)() = (void (^)())[self->queue objectAtIndex: i]; > event(); > + [event release]; > } > > [self->queue removeAllObjects]; > } > > @end From marco.dinacci at gmail.com Mon Jun 11 09:48:42 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Mon, 11 Jun 2012 17:48:42 +0100 Subject: Patch for #7170716, crash in OSXAPP_SetApplicationDelegate In-Reply-To: <7CE45CCE-8C7B-45B8-B936-EE3EE670598E@apple.com> References: <7CE45CCE-8C7B-45B8-B936-EE3EE670598E@apple.com> Message-ID: Hi, > You don't need to retain blocks when adding them to a collection. The collection implicitly retains them. The blocks will be released once the collection is released. I know, I'm not suggesting that. I'm saying that those blocks literals are created on the stack and that you have to copy them if you want to keep them around. The retain performed by the collection is not enough. > The root problem may be that the delegate is getting released, but I'd need to review the surrounding code more carefully to determine that. the crash normally happens when accessing the block inside the queue. void (^event)() = (void (^)())[self->queue objectAtIndex: i]; which hints to the fact that the objects inside the array are "gone". Best, Marco From mik3hall at gmail.com Mon Jun 11 14:48:35 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 11 Jun 2012 16:48:35 -0500 Subject: Sandbox Violation on Runtime Exec In-Reply-To: <8FBE48CB-7CF4-4AFA-9E3C-A64696EADBF1@tech4learning.com> References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <8FBE48CB-7CF4-4AFA-9E3C-A64696EADBF1@tech4learning.com> Message-ID: On Jun 11, 2012, at 10:43 AM, Jess Finley wrote: > Hi, we currently gather the architecture, model, CPU speed, and ram. AppleScript might be a temporary solution. Although I believe that is eventually not supposed to work SandBoxed either. Again though , from how I understood what I heard in the WWDC session that I mentioned, what you Runtime should work as long as your application covers the required entitlements. The inherit one mentioned isn't really supposed do anything other than mark your application as having 'helper' applications or processes that get passed your application entitlements. . So the questions as far as Runtime goes to my thinking are still, why it fails when NSTask works? Is this because they are just implemented differently? Then any Runtime should fail. I've been trying to think of something completely harmless you could try Runtime'ing to verify this. The second question would be does it work if you give the application the entitlement to correct the error? deny file-read-data /dev/fd Again, I haven't tried any of this. I've been trying to see if there is some way to quickly standalone test but I don't think so. There is the sandbox-exec command but that doesn't appear to apply to applications. It seems there the first thing you do is sign some code and I'm not sure I'm ready for that yet myself. Maybe someone else more familiar can indicate some way others might try this out? From david.dehaven at oracle.com Tue Jun 12 13:45:46 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 12 Jun 2012 13:45:46 -0700 Subject: Sandbox Violation on Runtime Exec In-Reply-To: <961E2837-0CF9-49A7-8C47-465E357D7836@gmail.com> References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <961E2837-0CF9-49A7-8C47-465E357D7836@gmail.com> Message-ID: <90DEDFD2-A1DD-41C4-9ED4-31E34C10490E@oracle.com> >> Can anyone explain why that would be? > > For Runtime exec the command runs in some kind of subprocess. I'm not familiar with sandboxed yet but does it pass entitlements through to subprocesses? > If thats it and theres no way to give the subprocess the same entitlements NSTask and jni might be how you have to go? Sorry for the long URL: https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html (read "XPC and Privilege Separation") In short, sub-processes spawned with POSIX calls or NSTask inherit the parent process entitlements. If you want different entitlements you need to create an XPC service, which runs in it's own sandbox and communicates with the parent process. -DrD- From david.dehaven at oracle.com Tue Jun 12 13:48:17 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 12 Jun 2012 13:48:17 -0700 Subject: Sandbox Violation on Runtime Exec In-Reply-To: References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <98737FFA-5704-44AD-8321-7709F56519B3@tech4learning.com> Message-ID: <40B5074F-D76C-47C5-8E39-26D960F5F3FE@oracle.com> >>> BTW, it seems Runtime.exec() uses fork() on OSX so AFAIK it may never >>> work in a sandbox. >>> The reason why NSTask works is probably because internally it uses posix_spawn. > > In the light of this, I wonder if this behaviour should be filed as a > bug. There is currently no (Java only) way to create a child process > if the parent is executed inside a sandbox, any call to > Runtime.getRuntime().exec() or ProcessBuilder start() will fail. > I think the OpenJDK on OSX should use either posix_spawn or NSTask. I highly recommend filing a bug, since sandboxing a Java application is something that should be fully supported. If only I'd thought of that earlier this year when I was looking at this stuff? -DrD- From mik3hall at gmail.com Tue Jun 12 15:20:13 2012 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 12 Jun 2012 17:20:13 -0500 Subject: Sandbox Violation on Runtime Exec In-Reply-To: <40B5074F-D76C-47C5-8E39-26D960F5F3FE@oracle.com> References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <98737FFA-5704-44AD-8321-7709F56519B3@tech4learning.com> <40B5074F-D76C-47C5-8E39-26D960F5F3FE@oracle.com> Message-ID: On Jun 12, 2012, at 3:48 PM, David DeHaven wrote: > >>>> BTW, it seems Runtime.exec() uses fork() on OSX so AFAIK it may never >>>> work in a sandbox. >>>> The reason why NSTask works is probably because internally it uses posix_spawn. >> >> In the light of this, I wonder if this behaviour should be filed as a >> bug. There is currently no (Java only) way to create a child process >> if the parent is executed inside a sandbox, any call to >> Runtime.getRuntime().exec() or ProcessBuilder start() will fail. >> I think the OpenJDK on OSX should use either posix_spawn or NSTask. > > I highly recommend filing a bug, since sandboxing a Java application is something that should be fully supported. > To make sure I'm understanding. So Runtime exec is broken sandboxed period? No matter what is done with Runtime? There would be no way to give the application a entitlement correcting the deny file-read-data /dev/fad as a work-around? (That would not result in the application being rejected App Store). The long-term fix would be to change the invocation to posix_spawn which would then need no entitlement? This would be what NSTask does? > > If only I'd thought of that earlier this year when I was looking at this stuff? Curious. If the above is true. None of the jdk standard tests catch that Runtime is broken? Or the tests haven't been run yet sandboxed because that support hasn't got far enough along to be figured in for full test runs? From jhuxhorn at googlemail.com Tue Jun 12 16:07:54 2012 From: jhuxhorn at googlemail.com (Joern Huxhorn) Date: Wed, 13 Jun 2012 01:07:54 +0200 Subject: Strange error messages on the console Message-ID: <0DE49B6B-79B8-4426-B80A-17395F1518BF@googlemail.com> Hi everyone. I just tested my app on Oracle Java 7 U5 & OS X 10.7 and it is printing strange messages: : CGContextGetCTM: invalid context 0x0 : CGContextSetBaseCTM: invalid context 0x0 (those show up multiple times) To reproduce, just download http://sourceforge.net/projects/lilith/files/lilith/0.9.42/lilith-0.9.42.1-all.jar/download and start it with java -jar lilith-0.9.42.1-all.jar Any idea what is causing this? Is there a hidden problem in my app or is this a Java on OS X bug? Everything else seems to work as expected. Cheers, Joern. From marco.dinacci at gmail.com Wed Jun 13 00:32:13 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Wed, 13 Jun 2012 08:32:13 +0100 Subject: Sandbox Violation on Runtime Exec In-Reply-To: References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <98737FFA-5704-44AD-8321-7709F56519B3@tech4learning.com> <40B5074F-D76C-47C5-8E39-26D960F5F3FE@oracle.com> Message-ID: Hi, > To make sure I'm understanding. > So Runtime exec is broken sandboxed period? No matter what is done with Runtime? > There would be no way to give the application a entitlement correcting the > deny file-read-data /dev/fad > as a work-around? (That would not result in the application being rejected App Store). the way I understand it yes, it's broken and there's no workaround. I submitted a bug few days ago here, sorry for not updating the conversation earlier: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172752 but it's not been accepted (yet ?). > The long-term fix would be to change the invocation to posix_spawn which would then need no entitlement? This would be what NSTask does? Apple documentation says that a child process created using posix_spawn or NSTask inherit the sandbox of the process that created it. If I found some time I'll make a test and report. Best, Marco From marco.dinacci at gmail.com Wed Jun 13 00:50:18 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Wed, 13 Jun 2012 08:50:18 +0100 Subject: Sandbox Violation on Runtime Exec In-Reply-To: <40B5074F-D76C-47C5-8E39-26D960F5F3FE@oracle.com> References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <98737FFA-5704-44AD-8321-7709F56519B3@tech4learning.com> <40B5074F-D76C-47C5-8E39-26D960F5F3FE@oracle.com> Message-ID: Hi, > I highly recommend filing a bug, since sandboxing a Java application is something that should be fully supported. I did 5 days ago: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172752 but it seems it's not been accepted. And this is only one of the several problems of executing a Java application in a sandbox. Another bug that I raised in the ML is the JFileChooser also completely broken: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004301.html For which I filed a bug here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172752 which it seems it's not been accepted either as the description is not available. There's also the wrong libfreetype reference in libfontmanager.dylib which is a Makefile issue and for which I posted a workaround in the ML using otool and install_name_tool. I haven't raised a bug for this but see the discussion: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004187.html Best, Marco From tobi at ultramixer.com Wed Jun 13 03:05:09 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 13 Jun 2012 12:05:09 +0200 Subject: jdku6 not usable by Oracles AppBundler Message-ID: <75E7B2AE-81C0-4A47-B48F-D7C3E161C5A7@ultramixer.com> Hi, I noticed that Oracles AppBundler (http://java.net/projects/appbundler/) can't start my app when using the recent OpenJDK7u6 builds from http://code.google.com/p/openjdk-osx-build/downloads/list the following error occurs: 2012-06-13 07:59:46.791 JavaAppLauncher[4087:20f7] Could not load JRE from The operation couldn\U2019t be completed. (NSCocoaErrorDomain error 4.).: ( 0 CoreFoundation 0x00007fff8d663a86 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x00007fff8e7ec410 objc_exception_throw + 43 2 CoreFoundation 0x00007fff8d66385c +[NSException raise:format:] + 204 3 JavaAppLauncher 0x0000000103ba691a launch + 762 4 JavaAppLauncher 0x0000000103ba64f6 main + 102 5 JavaAppLauncher 0x0000000103ba6484 start + 52 6 ??? 0x0000000000000009 0x0 + 9 ) logout I opened a bug report here: http://code.google.com/p/openjdk-osx-build/issues/detail?id=31 Does anybody know the difference in u6 and u4 builds of the openjdk-osx-build project? Henry? Best regards, Tobi -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com From mik3hall at gmail.com Wed Jun 13 03:20:52 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 13 Jun 2012 05:20:52 -0500 Subject: Sandbox Violation on Runtime Exec In-Reply-To: References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <98737FFA-5704-44AD-8321-7709F56519B3@tech4learning.com> <40B5074F-D76C-47C5-8E39-26D960F5F3FE@oracle.com> Message-ID: On Jun 13, 2012, at 2:32 AM, Marco Dinacci wrote: > Hi, > >> To make sure I'm understanding. >> So Runtime exec is broken sandboxed period? No matter what is done with Runtime? >> There would be no way to give the application a entitlement correcting the >> deny file-read-data /dev/fad >> as a work-around? (That would not result in the application being rejected App Store). > > the way I understand it yes, it's broken and there's no workaround. > > I submitted a bug few days ago here, sorry for not updating the > conversation earlier: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172752 > > but it's not been accepted (yet ?). > >> The long-term fix would be to change the invocation to posix_spawn which would then need no entitlement? This would be what NSTask does? > > Apple documentation says that a child process created using > posix_spawn or NSTask inherit the sandbox of the process that created > it. > If I found some time I'll make a test and report. Thanks From Sergey.Bylokhov at oracle.com Wed Jun 13 04:01:06 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 13 Jun 2012 15:01:06 +0400 Subject: [7u6] Please review my fix for 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() In-Reply-To: <4FD327F3.1090206@oracle.com> References: <4FD327F3.1090206@oracle.com> Message-ID: <4FD872F2.9080505@oracle.com> Hi, Alexander. Fix looks good. 09.06.2012 14:39, Alexander Zuev wrote: > Hello, > > slightly updated fix for CR 7124247: [macosx] Implement > GraphicsDevice.setDisplayMode() > > Actually it is a backport to the 7u6 of the fix for jdk8 with minor > corrections - fixed situation with the getDisplayModes() when we > returned the wrong resolutions for the requested modes, fixed crash > when we repeatedly asked to set display mode in a quick sentence and > now setDisplayMode correctly throws an IllegalArgumentException > instead of NullPointerException if null is passed as a parameter. > > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124247 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7124247/jdk7u6/webrev.02 > > With best regards, > Alex -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Jun 13 06:08:26 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 13 Jun 2012 17:08:26 +0400 Subject: [8] Review request for 7170716: JVM crash when opening an AWT app from a registered file. [WAS: Re: Patch for #7170716, crash in OSXAPP_SetApplicationDelegate] In-Reply-To: References: Message-ID: <4FD890CA.1080803@oracle.com> Hi Marco, Thank you for investigating the issue and developing a fix. I've uploaded a webrev for your patch at: http://cr.openjdk.java.net/~anthony/8-34-crashInSetApplicationDelegate-7170716.0/ I've got a concern regarding the retain calls on the delegate instance. With your fix we retain it for the first time at OSXAPP_SetApplicationDelegate(), and then one more time at QAD.processQueuedEventsWithTargetDelegate. However, we never release the object. Moreover, I believe that the NSApplication setDelegate: call also retains it. I'd think that we can retain it in the beginning of the OSXAPP_SetAppDelegate(), and then release it in the end. And we don't need a retain call in the processQEWTD. Could you please verify this? -- best regards, Anthony On 6/11/2012 8:17 PM, Marco Dinacci wrote: > Hi, > > I raised a couple of weeks ago bug #7170716 : > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170716 > > The original discussion is here: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004226.html > > In short, every time a Java application is opened from a registered > file the JVM crash in OSXAPP_SetApplicationDelegate. > > Today I started looking for a solution and I've found two memory > management issues in the code: > > The first and the one that was causing the bug is related with blocks. > In QueuingApplicationDelegate.m there are many methods where you're > adding blocks to an NSMutableArray but without copying them. > Those blocks literals are created on the stack so even if they're > retained once the function exits they no longer exist. Calling [copy] > will assure that the block will have a reference on the heap. Then > once the block has been consumed it needs to be released. > > The second issue is that you don't retain the delegate object in > QueuingApplicationDelegate.m and in NSApplicationAWT.m. > Even if the pointers are static you should still call [retain] because > it's not guaranteed that the objects the pointers are pointing to > won't be deallocated at one point. > > Here below a patch that resolve both issues, I tested it successfully > with a trivial test case and with my application. > > Best, > Marco > > diff -r 96dd3a52e76c src/macosx/native/sun/osxapp/NSApplicationAWT.m > --- a/src/macosx/native/sun/osxapp/NSApplicationAWT.m Thu May 31 > 16:35:25 2012 +0100 > +++ b/src/macosx/native/sun/osxapp/NSApplicationAWT.m Mon Jun 11 > 16:49:04 2012 +0100 > @@ -334,17 +334,17 @@ AWT_ASSERT_APPKIT_THREAD; > } > > @end > > > void OSXAPP_SetApplicationDelegate(id delegate) > { > AWT_ASSERT_APPKIT_THREAD; > - applicationDelegate = delegate; > + applicationDelegate = [delegate retain]; > > if (NSApp != nil) { > [NSApp setDelegate: applicationDelegate]; > > if (applicationDelegate && qad) { > [qad processQueuedEventsWithTargetDelegate: applicationDelegate]; > qad = nil; > } > diff -r 96dd3a52e76c src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m > --- a/src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Thu > May 31 16:35:25 2012 +0100 > +++ b/src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Mon > Jun 11 16:49:04 2012 +0100 > @@ -104,110 +104,110 @@ static id realDe > self->queue = nil; > > [super dealloc]; > } > > > - (void)_handleOpenURLEvent:(NSAppleEventDescriptor *)openURLEvent > withReplyEvent:(NSAppleEventDescriptor *)replyEvent > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [realDelegate _handleOpenURLEvent:openURLEvent > withReplyEvent:replyEvent]; > - }]; > + } copy]]; > } > > - (void)application:(NSApplication *)theApplication > openFiles:(NSArray *)fileNames > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [realDelegate application:theApplication openFiles:fileNames]; > - }]; > + } copy]]; > } > > - (NSApplicationPrintReply)application:(NSApplication *)application > printFiles:(NSArray *)fileNames withSettings:(NSDictionary > *)printSettings showPrintPanels:(BOOL)showPrintPanels > { > if (!fHandlesDocumentTypes) { > return NSPrintingCancelled; > } > > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [realDelegate application:application printFiles:fileNames > withSettings:printSettings showPrintPanels:showPrintPanels]; > - }]; > + } copy]]; > > // well, a bit premature, but what else can we do?.. > return NSPrintingSuccess; > } > > - (void)_willFinishLaunching > { > - QueuingApplicationDelegate * q = self; > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [[realDelegate class] _willFinishLaunching]; > - }]; > + } copy]]; > } > > - (BOOL)applicationShouldHandleReopen:(NSApplication *)theApplication > hasVisibleWindows:(BOOL)flag > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [realDelegate applicationShouldHandleReopen:theApplication > hasVisibleWindows:flag]; > - }]; > + } copy]]; > return YES; > } > > - (NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)app > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [realDelegate applicationShouldTerminate:app]; > - }]; > + } copy]]; > return NSTerminateLater; > } > > - (void)_systemWillPowerOff > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [[realDelegate class] _systemWillPowerOff]; > - }]; > + } copy]]; > } > > - (void)_appDidActivate > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [[realDelegate class] _appDidActivate]; > - }]; > + } copy]]; > } > > - (void)_appDidDeactivate > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [[realDelegate class] _appDidDeactivate]; > - }]; > + } copy]]; > } > > - (void)_appDidHide > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [[realDelegate class] _appDidHide]; > - }]; > + } copy]]; > } > > - (void)_appDidUnhide > { > - [self->queue addObject:^(){ > + [self->queue addObject:[^(){ > [[realDelegate class] _appDidUnhide]; > - }]; > + } copy]]; > } > > - (void)processQueuedEventsWithTargetDelegate:(id > )delegate > { > + realDelegate = [delegate retain]; > + > NSUInteger i; > NSUInteger count = [self->queue count]; > > - realDelegate = delegate; > - > for (i = 0; i < count; i++) { > void (^event)() = (void (^)())[self->queue objectAtIndex: i]; > event(); > + [event release]; > } > > [self->queue removeAllObjects]; > } > > @end From artem.ananiev at oracle.com Wed Jun 13 06:30:25 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 13 Jun 2012 17:30:25 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FCCD91B.30503@oracle.com> References: <4FCCD91B.30503@oracle.com> Message-ID: <4FD895F1.3040605@oracle.com> Hi, Sergey, a few minor comments: 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are corresponding checks just above. 2. invalidateShadow() is not used in sun.lwawt, so it can be just a method in CPlatformWindow. BTW, do you have any ideas, why CGLayer holds a reference to LWWindowPeer, not to CPlatformWindow? 3. As we don't expect isSwingBackbufferTranslucencySupported() to return different values, it would be fine to call it only once to avoid possible perf regressions. Thanks, Artem On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > > Shaped window was implemented as a translucent window with constrained > graphics. Now translucent window doesn't use separate BufferedImage as a > back buffer. Also alpha value for the swing back buffer was > enabled(Shared code changed). > Note that shaped windows are affected by this bugs: > http://monaco.us.oracle.com/detail.jsf?cr=7124236 > - Shadows disappear. > - Transparent areas aren't transparent to mouse clicks. > http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 > - Opacity does not work for non opaque windows. > > Any suggestions are welcome. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.00 > From dmitry.cherepanov at oracle.com Wed Jun 13 06:45:03 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Wed, 13 Jun 2012 17:45:03 +0400 Subject: autoreleased with no pool in place - just leaking In-Reply-To: References: <902CE961-E96A-4C39-AD34-2D27820BDF15@googlemail.com> <4FCCB68E.5000509@oracle.com> Message-ID: <4FD8995F.5090109@oracle.com> Tomas Hurka wrote: >> Could you please post your patch inline, or upload it somewhere (e.g. cr.openjdk.java.net)? >> > OK, here is the webrev: > Seems like a safe fix, looks fine to me. Thanks, Dmitry From marco.dinacci at gmail.com Wed Jun 13 08:32:34 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Wed, 13 Jun 2012 16:32:34 +0100 Subject: [8] Review request for 7170716: JVM crash when opening an AWT app from a registered file. [WAS: Re: Patch for #7170716, crash in OSXAPP_SetApplicationDelegate] In-Reply-To: <4FD890CA.1080803@oracle.com> References: <4FD890CA.1080803@oracle.com> Message-ID: Hi Anthony, thanks for looking at the patch. > I've got a concern regarding the retain calls on the delegate instance. With > your fix we retain it for the first time at OSXAPP_SetApplicationDelegate(), > and then one more time at QAD.processQueuedEventsWithTargetDelegate. > However, we never release the object. Moreover, I believe that the > NSApplication setDelegate: call also retains it. > > I'd think that we can retain it in the beginning of the > OSXAPP_SetAppDelegate(), and then release it in the end. And we don't need a > retain call in the processQEWTD. Could you please verify this? I took a better look at the code, including awt.m, to understand how and when OSXAPP_SetApplicationDelegate is called. It seems to me this function is called only once and always *after* finishLaunching(). *If* this is correct, then this check in finishLaunching() will be always false as applicationDelegate is certainly nil at this point: if (applicationDelegate) { [self setDelegate:applicationDelegate]; } else { qad = [QueuingApplicationDelegate sharedDelegate]; [self setDelegate:qad]; } and the code could be simplified to: qad = [QueuingApplicationDelegate sharedDelegate]; [self setDelegate:qad]; In this case, the applicationDelegate global variable could be eliminated altogether and the code in OSXAPP_SetApplicationDelegate simplified: void OSXAPP_SetApplicationDelegate(id delegate) { AWT_ASSERT_APPKIT_THREAD; if (NSApp != nil) { [NSApp setDelegate: delegate]; if (delegate && qad) { [qad processQueuedEventsWithTargetDelegate: delegate]; qad = nil; } } } As you say NSApp will retain the delegate and qad should guaranteed to be non-nil as it's been initialised in finishLaunching. Regarding the retain in processQueuedEventsWithTargetDelegate, I believe it's correct but you're right that it's not been released afterwards. The problem is that it's a global variable, is there a particular reason why ? I think it's better to convert it to a property, in that case it can be released safely in dealloc. I just tested with both these changes and with both my apps and I have no crash. I'm attaching a new patch, it will probably be stripped out by the ML software but hopefully you should get it. Best, Marco From anthony.petrov at oracle.com Wed Jun 13 08:33:08 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 13 Jun 2012 19:33:08 +0400 Subject: [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing In-Reply-To: <4FD3C2D4.1070809@oracle.com> References: <4FC77592.7020900@oracle.com> <4FCE29F8.4010503@oracle.com> <4FCE302D.2070508@oracle.com> <4FD350F2.4090003@oracle.com> <4FD3C2D4.1070809@oracle.com> Message-ID: <4FD8B2B4.20702@oracle.com> Hi Sergey, On 6/10/2012 1:40 AM, Sergey Bylokhov wrote: >> What kind of nightmare do you mean? To me it looks logical to perform >> some tasks before, and some other tasks after disaplying a component. >> Hence the need for per- and post- initializers. > Because in general nobody know correct place for initialization. This depends on how well we document our code. >>> updateInsets() should be called by some of the native callbacks, like >>> notifyExpose and reshape? >> >> Nope. It's only called from the initialize() method once since on the >> Mac insets never change. Therefore, it is critical to call it only >> after showing the window on the screen. > But what happens when the peer is invisible by default? Probably the > better place for updateInsets is setVisible()? Hmmm... No, because insets may be required earlier. Please see below. >> On 6/5/2012 10:17 PM, Sergey Bylokhov wrote: >>> In this case In current implementation it works wrong too, because it >>> can be called when the window initially invisible. >> >> So far, it works fine. Please run insets-related tests (simply all >> automatic tests for Window, Frame, and Dialog both open and closed) to >> makes sure they pass. > See previous comment. OK. Could you please run the tests with your fix and see if they pass? >>>> 4. >>>>> 220 protected void setVisibleImpl(final boolean visible) { >>>>> 221 super.setVisibleImpl(visible); >>>> >>>> Why do we remove a call to replaceSurfaceData() in the beginning of >>>> the method? >>> Before the fix, setVisible() can be called before surface creation, >>> but after the fix it will be called after. >> >> Could you clarify this further please? What exactly is the reason to >> move the replaceSurfaceData() call from setVisible() to initializeImpl()? > Just because it is unnecessary in setVisble() because surface already > created at the end of LWWindow.initializeImpl(). Why we should try to > replace surface each time in setVisible()? The size (and other attributes) of a window may change while it's been hidden and then gets shown again, which may require this call in setVisible(). If you're sure this is OK to not call it in setVisible(), then I'm fine with this change. >>>> 5. >>>>> 983 ((Graphics2D) >>>>> g).setBackground(getBackground()); >>>> >>>> I suggest to add an instanceof check before this call. >>> I guess that Buffered image cannot return something except Graphics2D >> >> I guess so too. Nevertheless, I still suggest to add such a check. > ok I will add. >> >> >>>> 6. >>>>> 227 // invokeLater() can be deleted, but in this case we >>>>> get a lag between >>>>> 228 // windows showing and content painting. >>>> >>>> Is the lag so very noticeable? On other platforms we don't actually >>>> do this, and I don't recall any issues about such lags. >>> Yes The difference is noticeable. So I update the comments and leave >>> it as is for now. >> >> Interesting. This needs to be investigated, perhaps under a separate CR. > I will create new CR. Thanks! -- best regards, Anthony >> >> -- >> best regards, >> Anthony >> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 5/31/2012 5:43 PM, Sergey Bylokhov wrote: >>>>> Hi Everyone, >>>>> Please review the fix. >>>>> >>>>> Notes from the bug and comments: >>>>> 1. setVisible() should be called at the end of the peers >>>>> initialization. We can move super.initialize() to the end of the >>>>> peers initializations. >>>>> Initialize() was split to initialize() and initializeImpl(). In the >>>>> initialize() we call initializeImpl and then we call to >>>>> setVisible(). initializeImpl overridden in subclasses. >>>>> >>>>> 2. Invokelater in the initialization/disposing is a tricky. >>>>> Left it as is. Probably later it will be changed. Comments was >>>>> updated. >>>>> >>>>> 3. replaceSurfacedata() should be moved outside of >>>>> LWWindowPeer.setVisible() >>>>> Done. Also duplicate code was extracted to setVisible() method >>>>> which call setVisibleImpl(). >>>>> >>>>> 4. Backbuffer in replaceSurfacedata() should be initialized by >>>>> clearRect instead of fillrect(composite is important). >>>>> Done. related to composite. >>>>> >>>>> 5. During lwwindowpeer initialization we call two similar methods >>>>> nativeSetNSWindowAlpha() and setAlphaValue(). >>>>> nativeSetNSWindowAlpha() removed from CPlatformWindow.java. >>>>> >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/7142091/webrev.00/ >>>>> >>> >>> > > From alexander.zuev at oracle.com Wed Jun 13 09:31:05 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 13 Jun 2012 20:31:05 +0400 Subject: [8] Please review my fix for 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock Message-ID: <4FD8C049.2070305@oracle.com> Hello, please review my fix for the 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock Bug can be found at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171163 Webrev can be found at: http://cr.openjdk.java.net/~kizune/7171163/jdk8/webrev.00/ This version of fix is being rewritten for jdk8 to emphasize the change of logic from running an nested event loop to just execute one event from AppKit thread by renaming corresponding native method. With best regards, Alex From leonid.romanov at oracle.com Wed Jun 13 11:43:13 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 13 Jun 2012 22:43:13 +0400 Subject: [7u6] Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: <4FD1F532.8060004@oracle.com> References: <4FD1F532.8060004@oracle.com> Message-ID: <5B532A9F-9526-40C5-B8D6-81E01B67F36E@oracle.com> Hi, Looks good to me. On 08.06.2012, at 16:50, Alexander Scherbatiy wrote: > > Hello, > > This is a request from the AWT team to backport a JDK 8 fix into JDK 7u6: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 > webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev7.00 > > JDK 8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0fad89bd606b > > This is not a direct backport because there were new changes in the 7u6 AWTView, AWTWindow, and CPlatformWindow classes. > > So the fix code has been ported manually. The only changes between original fix and new one is that self.nsWindow call is used instead of the self in the AWTWindow.m class > in the same way as it is used now in the AWTWindow.m class from the JDK 8 sources. > > > Thank you, > Alexandr. > From leonid.romanov at oracle.com Wed Jun 13 13:28:16 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 14 Jun 2012 00:28:16 +0400 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: <4FCF7D71.1040404@oracle.com> References: <4FC373A5.9030508@oracle.com> <89803632-78F2-410F-B66B-09AEFC8CAB11@oracle.com> <4FC39B2F.6070805@oracle.com> <32533319-5E00-483F-AE69-6E79419C3757@oracle.com> <4FC78E82.1030500@oracle.com> <99A4EEA8-726B-4319-AEDE-DC84E9F9D32F@oracle.com> <734F6A51-08C7-4BE1-8E70-8037752C0A48@oracle.com> <4FCF7D71.1040404@oracle.com> Message-ID: <832149A8-388C-467A-B746-F14BAF2DCF48@oracle.com> Ok, I've played with the app bundler project. It looks like we don't have to do anything to ensure that CFBundleName has higher priority than JAVA_MAIN_CLASS_. You see, we don't set the app name directly: instead, we use whatever string we have for the app name to set JRSAppNameKey property, the rest happens in the Apple code. My experiments show that Apple handles JRSAppNameKey the same way my fix handles the Dock icon: if it has already been specified via Info.plist, then don't set it. On 06.06.2012, at 19:55, Igor Nekrestyanov wrote: > IMHO, for testing grab sample from > javaweb.us.oracle.com/~inekrest/native-bundles > > Install it and then tweak Info.plist as needed. > > -igor > > On 6/6/12 8:33 AM, Scott Kovatch wrote: >> Your best bet is to start with the app bundler project on java.net. >> >> http://java.net/projects/appbundler >> >> It's an ant script that will take a JAR file and turn it into a bundled app. >> >> Also, the latest builds of javafxpackager will now generate a bundled app, too. >> >> -- Scott >> >> On Jun 1, 2012, at 8:27 AM, Leonid Romanov wrote: >> >>> Hi Scott, >>> Could you please provide me with instructions how to create my own bundled app? There is a couple of things I want to test... >>> >>> On 31.05.2012, at 20:20, Scott Kovatch wrote: >>> >>>> I think what Artem is saying is that if the application is bundled, and CFBundleName is set, it should take higher priority than JAVA_MAIN_CLASS_. >>>> >>>> If that is what you are saying, Artem, I agree. :-) >>>> >>>> We're straying away from the original review, though. >>>> >>>> -- Scott >>>> >>>> On May 31, 2012, at 8:30 AM, Artem Ananiev wrote: >>>> >>>>> Hi, Leonid, >>>>> >>>>> shouldn't app name set in the bundler be of higher priority than JAVA_MAIN_CLASS_ value, set by Java launcher? >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 5/29/2012 8:59 PM, Leonid Romanov wrote: >>>>>> Well, the order is the following: first, we check if -Xdock:name has been set. If it hasn't, we check for the "apple.awt.application.name" property. If this property hasn't been set, we try to get the app name from the JAVA_MAIN_CLASS_ environment variable, which is used to pass the name of a Java class whose main() method was invoked by the Java launcher code to start the application. If JAVA_MAIN_CLASS_ hasn't been set, then as the last resort we try to get the app name from the bundle. >>>>>> >>>>>> On 28.05.2012, at 19:35, Artem Ananiev wrote: >>>>>> >>>>>>> On 5/28/2012 6:06 PM, Leonid Romanov wrote: >>>>>>>> Hi, >>>>>>>> The problem with the application name is that the app in question uses "com.apple.mrj.application.apple.menu.about.name" property to set its name. Mu understanding is that we don't support this property in OpenJDK. >>>>>>> OK, fine. Is the application name set correctly when it is passed from app bundle or as -Xdock:name? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Artem >>>>>>> >>>>>>>> On 28.05.2012, at 16:46, Artem Ananiev wrote: >>>>>>>> >>>>>>>>> Hi, Leonid, >>>>>>>>> >>>>>>>>> the fix looks fine. Is the application name issue (also mentioned in 7159381) addressed in another fix? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Artem >>>>>>>>> >>>>>>>>> On 5/24/2012 5:23 PM, Leonid Romanov wrote: >>>>>>>>>> Hi, >>>>>>>>>> Please review a fix for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category. The problem here is that we ignore the fact that for the bundled app its icon might be specified via Info.plist file. In this case OS X sets the icon for us, so we don't have to do anything. >>>>>>>>>> >>>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7159381/webrev.00/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Leonid. >>>>>>>>>> > From leonid.romanov at oracle.com Wed Jun 13 21:25:10 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 14 Jun 2012 08:25:10 +0400 Subject: [7u6] Review request for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper Message-ID: Hi, Please review a fix for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper. The problem is that syncNativeQueue() doesn't fully sync the native queue. For example, if there are, say, 25 events in the native queue waiting to be processed, nativeSyncQueue might return after only one event has been processed. realSync() calls syncNativeQueue() in a loop until nativeSyncQueue() reports that no native events have been processed as the result of the call or the maximum number of iterations (which is 20) has been exceeded (which leads to the exception). And since there are more than 20 events in the native queue, we get the exception. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124239 Webrev: http://cr.openjdk.java.net/~leonidr/7124239/webrev.00/ Thanks, Leonid. From anthony.petrov at oracle.com Thu Jun 14 08:12:14 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 14 Jun 2012 19:12:14 +0400 Subject: [7u6] Review request for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper In-Reply-To: References: Message-ID: <4FD9FF4E.7030908@oracle.com> Hi Leonid, 1. In NSApplicationAWT: the NSLog("Here...") statements. I use such debugging output, too! :) However, for production code please either replace them with meaningful messages, or remove them altogether. 2. > 344 - (void)sendEvent:(NSEvent *)event I'm afraid that using the NSApplicationDefined and just skipping it may conflict with other native toolkits, such as SWT, or some custom native libraries. I think we should let such events go through the [super sendEvent]. 3. Isn't the loop in LWCToolkit.m too tight? There's an issue with performSelector on the Mac in that selectors are processed strictly before processing events. If the queue is flooded with posted selectors, the event may never have a chance to be handled. -- best regards, Anthony On 06/14/12 08:25, Leonid Romanov wrote: > Hi, > Please review a fix for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper. > The problem is that syncNativeQueue() doesn't fully sync the native queue. For example, if there are, say, 25 events in the native queue waiting to be processed, nativeSyncQueue might return after only one event has been processed. realSync() calls syncNativeQueue() in a loop until nativeSyncQueue() reports that no native events have been processed as the result of the call or the maximum number of iterations (which is 20) has been exceeded (which leads to the exception). And since there are more than 20 events in the native queue, we get the exception. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124239 > Webrev: http://cr.openjdk.java.net/~leonidr/7124239/webrev.00/ > > Thanks, > Leonid. From david.dehaven at oracle.com Thu Jun 14 10:01:17 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 14 Jun 2012 10:01:17 -0700 Subject: Sandbox Violation on Runtime Exec In-Reply-To: References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <98737FFA-5704-44AD-8321-7709F56519B3@tech4learning.com> <40B5074F-D76C-47C5-8E39-26D960F5F3FE@oracle.com> Message-ID: <7102A9DB-1088-4D18-885E-4F332BCAD006@oracle.com> > To make sure I'm understanding. > So Runtime exec is broken sandboxed period? No matter what is done with Runtime? I'm not intimately familiar with what Runtime does so can't really comment on that. > There would be no way to give the application a entitlement correcting the > deny file-read-data /dev/fad > as a work-around? (That would not result in the application being rejected App Store). The short term (ugly) workaround would be to use a JNI call to invoke posix_spawn or NSTask directly, I don't see any other way if Runtime is absolutely unusable. >> If only I'd thought of that earlier this year when I was looking at this stuff? > > Curious. If the above is true. None of the jdk standard tests catch that Runtime is broken? Or the tests haven't been run yet sandboxed because that support hasn't got far enough along to be figured in for full test runs? Sandboxing is still a very new concept in terms of JDK development. I did a round of testing and filed issues earlier this year (because of my history as a Mac developer), specifically because Apple now requires sandboxed apps in the App store but this is one case I did not think of during testing. I suspect it will become more of a priority considering Windows 8 will have sandboxing as well. I don't work on the JDK though (JavaFX team) so I can't really comment beyond idle speculation and making general suggestions. -DrD- From mik3hall at gmail.com Thu Jun 14 12:25:49 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 14 Jun 2012 14:25:49 -0500 Subject: Sandbox Violation on Runtime Exec In-Reply-To: <7102A9DB-1088-4D18-885E-4F332BCAD006@oracle.com> References: <91EA590C-B180-4194-BD3B-D3EEDB4FF88B@tech4learning.com> <98737FFA-5704-44AD-8321-7709F56519B3@tech4learning.com> <40B5074F-D76C-47C5-8E39-26D960F5F3FE@oracle.com> <7102A9DB-1088-4D18-885E-4F332BCAD006@oracle.com> Message-ID: <5837F6F0-BFC5-4DC7-966A-196CCA0192A3@gmail.com> On Jun 14, 2012, at 12:01 PM, David DeHaven wrote: > > >> There would be no way to give the application a entitlement correcting the >> deny file-read-data /dev/fad >> as a work-around? (That would not result in the application being rejected App Store). > > The short term (ugly) workaround would be to use a JNI call to invoke posix_spawn or NSTask directly, I don't see any other way if Runtime is absolutely unusable. If there are entitlements that aren't possible at all to workaround things like this I would think that could be a concern. I sort of wondered if everything goes through the same test suite and if that wouldn't have caught this. Some situations thats probably not possible. Thanks for the response. From anthony.petrov at oracle.com Thu Jun 14 14:05:08 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 15 Jun 2012 01:05:08 +0400 Subject: [8] Please review my fix for 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock In-Reply-To: <4FD8C049.2070305@oracle.com> References: <4FD8C049.2070305@oracle.com> Message-ID: <4FDA5204.1040002@oracle.com> Looks fine to me. -- best regards, Anthony On 6/13/2012 8:31 PM, Alexander Zuev wrote: > Hello, > > please review my fix for the > 7171163: [macosx] Shortcomings in the design of the secondary native > event loop made JavaFX DnD deadlock > > Bug can be found at > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171163 > > Webrev can be found at: > http://cr.openjdk.java.net/~kizune/7171163/jdk8/webrev.00/ > > This version of fix is being rewritten for jdk8 to emphasize the > change of logic from running an nested event loop to just execute one > event from AppKit thread by renaming corresponding native method. > > With best regards, > Alex From artem.ananiev at oracle.com Fri Jun 15 04:02:23 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 15 Jun 2012 15:02:23 +0400 Subject: [8] Please review my fix for 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock In-Reply-To: <4FD8C049.2070305@oracle.com> References: <4FD8C049.2070305@oracle.com> Message-ID: <4FDB163F.5050509@oracle.com> The fix looks fine. Thanks, Artem On 6/13/2012 8:31 PM, Alexander Zuev wrote: > Hello, > > please review my fix for the > 7171163: [macosx] Shortcomings in the design of the secondary native > event loop made JavaFX DnD deadlock > > Bug can be found at > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171163 > > Webrev can be found at: > http://cr.openjdk.java.net/~kizune/7171163/jdk8/webrev.00/ > > This version of fix is being rewritten for jdk8 to emphasize the change > of logic from running an nested event loop to just execute one event > from AppKit thread by renaming corresponding native method. > > With best regards, > Alex From Sergey.Bylokhov at oracle.com Fri Jun 15 04:34:08 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 15 Jun 2012 15:34:08 +0400 Subject: [7u6] Request for review: 7147055 [macosx] Cursors are changing over a blocked window; also blinking Message-ID: <4FDB1DB0.60209@oracle.com> Hi Everyone, This is a back port from jdk 8 to jdk 7u6. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147055 Webrev can be found at: http://cr.openjdk.java.net/~serb/7147055/webrev.00/ jdk8 changeset: hg.openjdk.java.net/jdk8/awt/jdk/rev/0feee4541f67 -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Jun 15 04:40:23 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 15 Jun 2012 15:40:23 +0400 Subject: [7u6] Request for review: 7150105 [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor. Message-ID: <4FDB1F27.80706@oracle.com> Hi Everyone, This is a back port from jdk 8 to jdk 7u6. Review: http://mail.openjdk.java.net/pipermail/awt-dev/2012-April/002502.html 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/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/933ea89bec06 -- Best regards, Sergey. From leonid.romanov at oracle.com Fri Jun 15 06:00:40 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 15 Jun 2012 17:00:40 +0400 Subject: [7u6] Request for review: 7147055 [macosx] Cursors are changing over a blocked window; also blinking In-Reply-To: <4FDB1DB0.60209@oracle.com> References: <4FDB1DB0.60209@oracle.com> Message-ID: Looks fine. On 15.06.2012, at 15:34, Sergey Bylokhov wrote: > Hi Everyone, > This is a back port from jdk 8 to jdk 7u6. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147055 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7147055/webrev.00/ > jdk8 changeset: hg.openjdk.java.net/jdk8/awt/jdk/rev/0feee4541f67 > > -- > Best regards, Sergey. > From marco.dinacci at gmail.com Fri Jun 15 06:04:59 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 15 Jun 2012 14:04:59 +0100 Subject: JMenuItem keyboard accelerator not showing when using the useScreenMenuBar property Message-ID: Hi, when using the property apple.laf.useScreenMenuBar the keyboard shortcuts are not showing next to the JMenuItems label. The behaviour can be reproduced running this demo from the Swing tutorial: http://docs.oracle.com/javase/tutorial/uiswing/examples/components/MenuLookDemoProject/src/components/MenuLookDemo.java I just found this message on the mailing list talking about the accelerators: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003780.html Does that mean Oracle is already aware of the issue and that a fix already exists or is in development ? Otherwise, any idea what the problem could be ? I can't ship with this problem so I'll have to fix it or find a workaround. Best, Marco From leonid.romanov at oracle.com Fri Jun 15 10:06:18 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 15 Jun 2012 21:06:18 +0400 Subject: [7u6] Review request for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper In-Reply-To: <4FD9FF4E.7030908@oracle.com> References: <4FD9FF4E.7030908@oracle.com> Message-ID: <5A941163-3D9A-4552-A032-5ADB32B2931E@oracle.com> Hi, I've adressed your comments in http://cr.openjdk.java.net/~leonidr/7124239/webrev.01/ More specifically: 1. Removed ) 2. After some consideration I've decided to use timestamp in order to distinguish our event from others: seems like it's the most bulletproof method. 3. You could be right. I've replaced the loop with NSConditionLock machinery. On 14.06.2012, at 19:12, Anthony Petrov wrote: > Hi Leonid, > > 1. In NSApplicationAWT: the NSLog("Here...") statements. I use such debugging output, too! :) However, for production code please either replace them with meaningful messages, or remove them altogether. > > 2. >> 344 - (void)sendEvent:(NSEvent *)event > > I'm afraid that using the NSApplicationDefined and just skipping it may conflict with other native toolkits, such as SWT, or some custom native libraries. I think we should let such events go through the [super sendEvent]. > > 3. Isn't the loop in LWCToolkit.m too tight? There's an issue with performSelector on the Mac in that selectors are processed strictly before processing events. If the queue is flooded with posted selectors, the event may never have a chance to be handled. > > -- > best regards, > Anthony > > On 06/14/12 08:25, Leonid Romanov wrote: >> Hi, >> Please review a fix for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper. >> The problem is that syncNativeQueue() doesn't fully sync the native queue. For example, if there are, say, 25 events in the native queue waiting to be processed, nativeSyncQueue might return after only one event has been processed. realSync() calls syncNativeQueue() in a loop until nativeSyncQueue() reports that no native events have been processed as the result of the call or the maximum number of iterations (which is 20) has been exceeded (which leads to the exception). And since there are more than 20 events in the native queue, we get the exception. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124239 >> Webrev: http://cr.openjdk.java.net/~leonidr/7124239/webrev.00/ >> >> Thanks, >> Leonid. From leonid.romanov at oracle.com Fri Jun 15 11:08:24 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 15 Jun 2012 22:08:24 +0400 Subject: JMenuItem keyboard accelerator not showing when using the useScreenMenuBar property In-Reply-To: References: Message-ID: <722D0EED-4620-4CFB-B9C1-9E2250AAD1B6@oracle.com> Hi, What is the version of JDK you are using? On 15.06.2012, at 17:04, Marco Dinacci wrote: > Hi, > > when using the property apple.laf.useScreenMenuBar the keyboard > shortcuts are not showing next to the JMenuItems label. > > The behaviour can be reproduced running this demo from the Swing tutorial: > http://docs.oracle.com/javase/tutorial/uiswing/examples/components/MenuLookDemoProject/src/components/MenuLookDemo.java > > I just found this message on the mailing list talking about the accelerators: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003780.html > > Does that mean Oracle is already aware of the issue and that a fix > already exists or is in development ? > Otherwise, any idea what the problem could be ? I can't ship with this > problem so I'll have to fix it or find a workaround. > > Best, > Marco From anthony.petrov at oracle.com Fri Jun 15 11:09:05 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 15 Jun 2012 22:09:05 +0400 Subject: [8] Review request for 7170716: JVM crash when opening an AWT app from a registered file. [WAS: Re: Patch for #7170716, crash in OSXAPP_SetApplicationDelegate] In-Reply-To: References: <4FD890CA.1080803@oracle.com> Message-ID: <4FDB7A41.6080402@oracle.com> Hi Marco, Thanks for the updated patch. A webrev with your latest fix is published at: http://cr.openjdk.java.net/~anthony/8-34-crashInSetApplicationDelegate-7170716.1/ Some comments: 1. I think the changes to the NSApplicationAWT.h are unnecessary. 2. I'd recommend to not remove the if (applicationDelegate) check in the NSApplicationAWT.m since in the future we may want to change the logic in awt.m, in which case a real delegate may be set before finishLaunching is executed. The check doesn't hurt, does it? 3. The realDelegate as a property looks fine. Since we use the self. (or self->) notation to access ivars, please update the QAD's callback methods (those that create the blocks to be queued), and use this notation to access the realDelegate property. (I'm wondering though, won't the compiler treat 'self' as a ref to the block instead of the object there?) src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m: > 61 if (!self) { > 62 self.realDelegate = nil; > 63 return self; > 64 } I think it's not safe to assign a value to an ivar when the self reference is nil. Let's just remove the line 62 - the object itself couldn't be initialized, and neither could its member property, I guess. There's no reason to nullify it here. Also, in theory we could nullify the property at the end of processQueuedEventsWithTargetDelegate since we don't need to retain the object after we've flushed all the queued events. I don't have a strong opinion on this though, since the property will be nil'ed in the dealloc anyway. -- best regards, Anthony On 6/13/2012 7:32 PM, Marco Dinacci wrote: > Hi Anthony, > > thanks for looking at the patch. > >> I've got a concern regarding the retain calls on the delegate instance. With >> your fix we retain it for the first time at OSXAPP_SetApplicationDelegate(), >> and then one more time at QAD.processQueuedEventsWithTargetDelegate. >> However, we never release the object. Moreover, I believe that the >> NSApplication setDelegate: call also retains it. >> >> I'd think that we can retain it in the beginning of the >> OSXAPP_SetAppDelegate(), and then release it in the end. And we don't need a >> retain call in the processQEWTD. Could you please verify this? > > I took a better look at the code, including awt.m, to understand how > and when OSXAPP_SetApplicationDelegate is called. > It seems to me this function is called only once and always *after* > finishLaunching(). > > *If* this is correct, then this check in finishLaunching() will be > always false as applicationDelegate is certainly nil at this point: > > if (applicationDelegate) { > [self setDelegate:applicationDelegate]; > } else { > qad = [QueuingApplicationDelegate sharedDelegate]; > [self setDelegate:qad]; > } > > and the code could be simplified to: > > qad = [QueuingApplicationDelegate sharedDelegate]; > [self setDelegate:qad]; > > In this case, the applicationDelegate global variable could be > eliminated altogether and the code in OSXAPP_SetApplicationDelegate > simplified: > > void OSXAPP_SetApplicationDelegate(id delegate) > { > AWT_ASSERT_APPKIT_THREAD; > > if (NSApp != nil) { > [NSApp setDelegate: delegate]; > > if (delegate && qad) { > [qad processQueuedEventsWithTargetDelegate: delegate]; > qad = nil; > } > } > } > > As you say NSApp will retain the delegate and qad should guaranteed to > be non-nil as it's been initialised in finishLaunching. > > Regarding the retain in processQueuedEventsWithTargetDelegate, I > believe it's correct but you're right that it's not been released > afterwards. > The problem is that it's a global variable, is there a particular reason why ? > I think it's better to convert it to a property, in that case it can > be released safely in dealloc. > > I just tested with both these changes and with both my apps and I have > no crash. > I'm attaching a new patch, it will probably be stripped out by the ML > software but hopefully you should get it. > > Best, > Marco From anthony.petrov at oracle.com Fri Jun 15 11:14:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 15 Jun 2012 22:14:22 +0400 Subject: [7u6] Request for review: 7147055 [macosx] Cursors are changing over a blocked window; also blinking In-Reply-To: <4FDB1DB0.60209@oracle.com> References: <4FDB1DB0.60209@oracle.com> Message-ID: <4FDB7B7E.30701@oracle.com> Looks fine. -- best regards, Anthony On 6/15/2012 3:34 PM, Sergey Bylokhov wrote: > Hi Everyone, > This is a back port from jdk 8 to jdk 7u6. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147055 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7147055/webrev.00/ > jdk8 changeset: hg.openjdk.java.net/jdk8/awt/jdk/rev/0feee4541f67 > From anthony.petrov at oracle.com Fri Jun 15 12:02:29 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 15 Jun 2012 23:02:29 +0400 Subject: [7u6] Review request for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper In-Reply-To: <5A941163-3D9A-4552-A032-5ADB32B2931E@oracle.com> References: <4FD9FF4E.7030908@oracle.com> <5A941163-3D9A-4552-A032-5ADB32B2931E@oracle.com> Message-ID: <4FDB86C5.4020503@oracle.com> Hi Leonid, > 93 NSApplicationAWT* theApp = (NSApplicationAWT*)[NSApplication sharedApplication]; Actually, in case an SWT application is running, this conversion may not work as expected. Should we possibly perform an isKindOfClass check, and if it's not our application class, use the previous approach (i.e. spin a single empty block through the event loop)? Otherwise the fix looks fine. -- best regards, Anthony On 6/15/2012 9:06 PM, Leonid Romanov wrote: > Hi, > I've adressed your comments > in http://cr.openjdk.java.net/~leonidr/7124239/webrev.01/ > More specifically: > 1. Removed ) > 2. After some consideration I've decided to use timestamp in order to > distinguish our event from others: seems like it's the most bulletproof > method. > 3. You could be right. I've replaced the loop with NSConditionLock > machinery. > > On 14.06.2012, at 19:12, Anthony Petrov wrote: > >> Hi Leonid, >> >> 1. In NSApplicationAWT: the NSLog("Here...") statements. I use such >> debugging output, too! :) However, for production code please either >> replace them with meaningful messages, or remove them altogether. >> >> 2. >>> 344 - (void)sendEvent:(NSEvent *)event >> >> I'm afraid that using the NSApplicationDefined and just skipping it >> may conflict with other native toolkits, such as SWT, or some custom >> native libraries. I think we should let such events go through the >> [super sendEvent]. >> >> 3. Isn't the loop in LWCToolkit.m too tight? There's an issue with >> performSelector on the Mac in that selectors are processed strictly >> before processing events. If the queue is flooded with posted >> selectors, the event may never have a chance to be handled. >> >> -- >> best regards, >> Anthony >> >> On 06/14/12 08:25, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7124239: [macosx] >>> sun.awt.SunToolkit.InfiniteLoop exception in realSync called from >>> SwingTestHelper. >>> The problem is that syncNativeQueue() doesn't fully sync the native >>> queue. For example, if there are, say, 25 events in the native queue >>> waiting to be processed, nativeSyncQueue might return after only one >>> event has been processed. realSync() calls syncNativeQueue() in a >>> loop until nativeSyncQueue() reports that no native events have been >>> processed as the result of the call or the maximum number of >>> iterations (which is 20) has been exceeded (which leads to the >>> exception). And since there are more than 20 events in the native >>> queue, we get the exception. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124239 >>> Webrev: http://cr.openjdk.java.net/~leonidr/7124239/webrev.00/ >>> >>> Thanks, >>> Leonid. > From marco.dinacci at gmail.com Fri Jun 15 13:26:53 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 15 Jun 2012 21:26:53 +0100 Subject: JMenuItem keyboard accelerator not showing when using the useScreenMenuBar property In-Reply-To: <722D0EED-4620-4CFB-B9C1-9E2250AAD1B6@oracle.com> References: <722D0EED-4620-4CFB-B9C1-9E2250AAD1B6@oracle.com> Message-ID: Hi, > What is the version of JDK you are using? I'm using jdk7u, revision 5070:173daa884b91. I just noticed that Oracle JDK7u4 works fine. Best, Marco From marco.dinacci at gmail.com Sat Jun 16 01:51:38 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Sat, 16 Jun 2012 09:51:38 +0100 Subject: [8] Review request for 7170716: JVM crash when opening an AWT app from a registered file. [WAS: Re: Patch for #7170716, crash in OSXAPP_SetApplicationDelegate] In-Reply-To: <4FDB7A41.6080402@oracle.com> References: <4FD890CA.1080803@oracle.com> <4FDB7A41.6080402@oracle.com> Message-ID: Hi, > 1. I think the changes to the NSApplicationAWT.h are unnecessary. yes this was a mistake. > 2. I'd recommend to not remove the if (applicationDelegate) check in the > NSApplicationAWT.m since in the future we may want to change the logic in > awt.m, in which case a real delegate may be set before finishLaunching is > executed. The check doesn't hurt, does it? ok, I don't know about the future plans. I think the best then is just to revert NSApplicationAWT.m entirely, the bug fix is really in QueuingApplicationDelegate.m anyway. By entirely I also mean removing the [applicationDelegate retain] that I added in the first patch as I now understand that there's no need to keep it (at least for now) once all the events are processed. > 3. The realDelegate as a property looks fine. Since we use the self. (or > self->) notation to access ivars, please update the QAD's callback methods > (those that create the blocks to be queued), and use this notation to access > the realDelegate property. (I'm wondering though, won't the compiler treat > 'self' as a ref to the block instead of the object there?) done > src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m: >> >> ?61 ? ? if (!self) { >> ?62 ? ? ? ? self.realDelegate = nil; >> ?63 ? ? ? ? return self; >> ?64 ? ? } fixed. The usual convention in Cocoa is to do an if(self) instead of if(!self) so I got confused. > Also, in theory we could nullify the property at the end of > processQueuedEventsWithTargetDelegate since we don't need to retain the > object after we've flushed all the queued events. I don't have a strong > opinion on this though, since the property will be nil'ed in the dealloc > anyway. I don't have a strong opinion either, I think it doesn't hurt leaving it like this because as you say it will be dealloced anyway. Attached the new patch, I reverted NSApplicationAWT.m and its header and implemented the changes you suggested above. Best, Marco From marco.dinacci at gmail.com Mon Jun 18 06:05:08 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Mon, 18 Jun 2012 14:05:08 +0100 Subject: JMenuItem keyboard accelerator not showing when using the useScreenMenuBar property In-Reply-To: References: <722D0EED-4620-4CFB-B9C1-9E2250AAD1B6@oracle.com> Message-ID: Hi, I just realised that in the previous message I posted a wrong changeset, in any case I reproduced it also using the latest jdk7u and jdk8. Best, Marco On 15 June 2012 21:26, Marco Dinacci wrote: > Hi, > >> What is the version of JDK you are using? > > I'm using jdk7u, revision 5070:173daa884b91. > > I just noticed that Oracle JDK7u4 works fine. From anthony.petrov at oracle.com Mon Jun 18 07:42:34 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 18 Jun 2012 18:42:34 +0400 Subject: [8] Review request for 7170716: JVM crash when opening an AWT app from a registered file. [WAS: Re: Patch for #7170716, crash in OSXAPP_SetApplicationDelegate] In-Reply-To: References: <4FD890CA.1080803@oracle.com> <4FDB7A41.6080402@oracle.com> Message-ID: <4FDF3E5A.1040102@oracle.com> Hi Marco et al., I've published your latest patch here: http://cr.openjdk.java.net/~anthony/8-34-crashInSetApplicationDelegate-7170716.2/ The fix looks just fine to me. Thank you for fixing the issue. Could anyone else on this mailing list review it please? -- best regards, Anthony On 06/16/12 12:51, Marco Dinacci wrote: > Hi, > >> 1. I think the changes to the NSApplicationAWT.h are unnecessary. > > yes this was a mistake. > >> 2. I'd recommend to not remove the if (applicationDelegate) check in the >> NSApplicationAWT.m since in the future we may want to change the logic in >> awt.m, in which case a real delegate may be set before finishLaunching is >> executed. The check doesn't hurt, does it? > > ok, I don't know about the future plans. I think the best then is just > to revert NSApplicationAWT.m entirely, the bug fix is really in > QueuingApplicationDelegate.m anyway. By entirely I also mean removing > the [applicationDelegate retain] that I added in the first patch as I > now understand that there's no need to keep it (at least for now) once > all the events are processed. > >> 3. The realDelegate as a property looks fine. Since we use the self. (or >> self->) notation to access ivars, please update the QAD's callback methods >> (those that create the blocks to be queued), and use this notation to access >> the realDelegate property. (I'm wondering though, won't the compiler treat >> 'self' as a ref to the block instead of the object there?) > > done > >> src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m: >>> >>> 61 if (!self) { >>> 62 self.realDelegate = nil; >>> 63 return self; >>> 64 } > > fixed. > > The usual convention in Cocoa is to do an if(self) instead of > if(!self) so I got confused. > >> Also, in theory we could nullify the property at the end of >> processQueuedEventsWithTargetDelegate since we don't need to retain the >> object after we've flushed all the queued events. I don't have a strong >> opinion on this though, since the property will be nil'ed in the dealloc >> anyway. > > I don't have a strong opinion either, I think it doesn't hurt leaving > it like this because as you say it will be dealloced anyway. > > Attached the new patch, I reverted NSApplicationAWT.m and its header > and implemented the changes you suggested above. > > Best, > Marco From artem.ananiev at oracle.com Mon Jun 18 08:13:46 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 18 Jun 2012 19:13:46 +0400 Subject: [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing In-Reply-To: <4FC77592.7020900@oracle.com> References: <4FC77592.7020900@oracle.com> Message-ID: <4FDF45AA.4040703@oracle.com> Hi, Sergey, some minor comments (may be unrelated to the fix): 1. LWComponentPeer.setVisible() can be made final. Do expect any subclass to override it instead of setVisibleImpl()? 2. invokeLater() in LWWindowPeer.setVisibleImpl(): I realize this is really painful issue, but I'd vote for removing this workaround. It would result in faster startup (although, the window will be solid gray for some time), and make LWAWT code similar to what we have on other platforms. Then next step will to minimize the delay between showing the window and painting its content. 3. LWWindowPeer.replaceSurfaceData(): what are benefits of setBackground() + clearRect() over setColor() + fillRect()? Although we always expect the Graphics object to be Graphics2D instance, this unconditional cast doesn't look great. Thanks, Artem On 5/31/2012 5:43 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > > Notes from the bug and comments: > 1. setVisible() should be called at the end of the peers initialization. > We can move super.initialize() to the end of the peers initializations. > Initialize() was split to initialize() and initializeImpl(). In the > initialize() we call initializeImpl and then we call to setVisible(). > initializeImpl overridden in subclasses. > > 2. Invokelater in the initialization/disposing is a tricky. > Left it as is. Probably later it will be changed. Comments was updated. > > 3. replaceSurfacedata() should be moved outside of > LWWindowPeer.setVisible() > Done. Also duplicate code was extracted to setVisible() method which > call setVisibleImpl(). > > 4. Backbuffer in replaceSurfacedata() should be initialized by clearRect > instead of fillrect(composite is important). > Done. related to composite. > > 5. During lwwindowpeer initialization we call two similar methods > nativeSetNSWindowAlpha() and setAlphaValue(). > nativeSetNSWindowAlpha() removed from CPlatformWindow.java. > > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7142091/webrev.00/ > From anthony.petrov at oracle.com Mon Jun 18 08:11:32 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 18 Jun 2012 19:11:32 +0400 Subject: [7u6] Request for review: 7150105 [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor. In-Reply-To: <4FDB1F27.80706@oracle.com> References: <4FDB1F27.80706@oracle.com> Message-ID: <4FDF4524.1090105@oracle.com> Looks good. -- best regards, Anthony On 06/15/12 15:40, Sergey Bylokhov wrote: > Hi Everyone, > This is a back port from jdk 8 to jdk 7u6. > Review: > http://mail.openjdk.java.net/pipermail/awt-dev/2012-April/002502.html > > 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/ > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/933ea89bec06 > > From marco.dinacci at gmail.com Mon Jun 18 08:54:24 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Mon, 18 Jun 2012 16:54:24 +0100 Subject: JMenuItem keyboard accelerator not showing when using the useScreenMenuBar property In-Reply-To: References: <722D0EED-4620-4CFB-B9C1-9E2250AAD1B6@oracle.com> Message-ID: Hi Leonid, I think I've found the issue. In ScreenMenuItem.addNotify there's the following code: setAccelerator(fMenuItem.getAccelerator()); final String label = fMenuItem.getText(); if (label != null) { setLabel(label); } setLabel(label) in CMenuItem calls: setLabel(label, (char)0, KeyEvent.VK_UNDEFINED, 0); which resets any accelerator previously set with setAccelerator. If the call to setAccelerator(fMenuItem.getAccelerator()) is placed after setLabel(label) than the accelerator is set again and the shortcut is visible. I don't know if it's the best way to reset the accelerator in setLabel and then setting it back again but at least it works. Here's the test file I used: import java.awt.*; import java.awt.event.*; import javax.swing.*; public class MenuBug { public JMenuBar createMenuBar(final JFrame frame) { JMenuBar menuBar; JMenu menu, submenu; JMenuItem menuItem; menuBar = new JMenuBar(); menu = new JMenu("A Menu"); menu.setMnemonic(KeyEvent.VK_A); menuBar.add(menu); menuItem = new JMenuItem("menu item"); KeyStroke s = KeyStroke.getKeyStroke( KeyEvent.VK_T, ActionEvent.META_MASK); menuItem.setAccelerator(s); menu.add(menuItem); return menuBar; } private static void createAndShowGUI() { JFrame frame = new JFrame("MenuBug"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); MenuBug demo = new MenuBug(); frame.setJMenuBar(demo.createMenuBar(frame)); frame.setVisible(true); } public static void main(String[] args) { javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { createAndShowGUI(); } }); } } Best, Marco From alexander.zuev at oracle.com Mon Jun 18 11:01:34 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 18 Jun 2012 22:01:34 +0400 Subject: [7u6] Please review my fix for 7173487: [macosx] Problems with popup menus, tooltips and dialog boxes in dual monitor setup Message-ID: <4FDF6CFE.3070302@oracle.com> Hello, please review my fix for CR 7173487: [macosx] Problems with popup menus, tooltips and dialog boxes in dual monitor setup CR description can be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173487 Webrev with the proposed change can be seen here: http://cr.openjdk.java.net/~kizune/7173487/webrev.00 This is a backport of the fix implemented for jdk8. With best regards, Alex From dmitry.cherepanov at oracle.com Mon Jun 18 11:15:59 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 18 Jun 2012 22:15:59 +0400 Subject: [7u6] Please review my fix for 7173487: [macosx] Problems with popup menus, tooltips and dialog boxes in dual monitor setup In-Reply-To: <4FDF6CFE.3070302@oracle.com> References: <4FDF6CFE.3070302@oracle.com> Message-ID: <4FDF705F.40500@oracle.com> Looks fine to me. Thanks, Dmitry Alexander Zuev wrote: > Hello, > > please review my fix for CR 7173487: [macosx] Problems with popup > menus, tooltips and dialog boxes in dual monitor setup > > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173487 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7173487/webrev.00 > > This is a backport of the fix implemented for jdk8. > > With best regards, > Alex From Sergey.Bylokhov at oracle.com Mon Jun 18 11:10:24 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 18 Jun 2012 22:10:24 +0400 Subject: [7u6] Please review my fix for 7173487: [macosx] Problems with popup menus, tooltips and dialog boxes in dual monitor setup In-Reply-To: <4FDF6CFE.3070302@oracle.com> References: <4FDF6CFE.3070302@oracle.com> Message-ID: <4FDF6F10.6000804@oracle.com> Hi Alexander. Fix looks good. On 18.06.2012 22:01, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7173487: [macosx] Problems with popup > menus, tooltips and dialog boxes in dual monitor setup > > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173487 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7173487/webrev.00 > > This is a backport of the fix implemented for jdk8. > > With best regards, > Alex -- Best regards, Sergey. From roger.toenz at abacus.ch Mon Jun 18 23:29:20 2012 From: roger.toenz at abacus.ch (=?iso-8859-1?Q?Roger_T=F6nz?=) Date: Tue, 19 Jun 2012 08:29:20 +0200 Subject: KeyEvent modifiersText Message-ID: <9DD435B8-8F27-4CF4-9921-F24DA9C87CAD@abacus.ch> Hi, KeyEvent.getKeyModifiersText(KeyEvent.META_MASK) with Java6 i do get the CommandKey-Char "?" with Java7 i do get "Meta" i think there's something missing in "sun.awt.resources.awt" cheers Roger From Sergey.Bylokhov at oracle.com Tue Jun 19 03:01:17 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 19 Jun 2012 14:01:17 +0400 Subject: [7u6] Request for review: 7150105 [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor. In-Reply-To: <4FDF4524.1090105@oracle.com> References: <4FDB1F27.80706@oracle.com> <4FDF4524.1090105@oracle.com> Message-ID: <4FE04DED.6040301@oracle.com> Thanks, Anthony. Does anybody has a chance to review it? On 18.06.2012 19:11, Anthony Petrov wrote: > Looks good. > > -- > best regards, > Anthony > > On 06/15/12 15:40, Sergey Bylokhov wrote: >> Hi Everyone, >> This is a back port from jdk 8 to jdk 7u6. >> Review: >> http://mail.openjdk.java.net/pipermail/awt-dev/2012-April/002502.html >> >> 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/ >> jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/933ea89bec06 >> >> -- Best regards, Sergey. From alexander.zuev at oracle.com Tue Jun 19 03:26:52 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 19 Jun 2012 14:26:52 +0400 Subject: [7u6] Request for review: 7150105 [macosx] four scroll-buttons don't display. scroll-sliders cursors are TextCursor. In-Reply-To: <4FE04DED.6040301@oracle.com> References: <4FDB1F27.80706@oracle.com> <4FDF4524.1090105@oracle.com> <4FE04DED.6040301@oracle.com> Message-ID: <4FE053EC.4020104@oracle.com> Just finished grocking it. Fix looks fine. With best regards, Alex On 6/19/12 14:01, Sergey Bylokhov wrote: > Thanks, Anthony. > > Does anybody has a chance to review it? > > On 18.06.2012 19:11, Anthony Petrov wrote: >> Looks good. >> >> -- >> best regards, >> Anthony >> >> On 06/15/12 15:40, Sergey Bylokhov wrote: >>> Hi Everyone, >>> This is a back port from jdk 8 to jdk 7u6. >>> Review: >>> http://mail.openjdk.java.net/pipermail/awt-dev/2012-April/002502.html >>> >>> 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/ >>> jdk8 changeset: >>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/933ea89bec06 >>> >>> > > From alexander.zuev at oracle.com Tue Jun 19 04:32:33 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 19 Jun 2012 15:32:33 +0400 Subject: [7u6] Please review my fix for 7172430: [macosx] debug message in non debug jdk build Message-ID: <4FE06351.5000704@oracle.com> Hello, please review my fix for CR 7172430: [macosx] debug message in non debug jdk build CR description can be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172430 Webrev with the proposed change can be seen here: http://cr.openjdk.java.net/~kizune/7172430/webrev.00 The fix is quite simple - i have no idea why this code was not safeguarded by corresponding #if/#endif in the first place, but well.. With best regards, Alex From Sergey.Bylokhov at oracle.com Tue Jun 19 04:34:40 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 19 Jun 2012 15:34:40 +0400 Subject: [7u6] Please review my fix for 7172430: [macosx] debug message in non debug jdk build In-Reply-To: <4FE06351.5000704@oracle.com> References: <4FE06351.5000704@oracle.com> Message-ID: <4FE063D0.7010403@oracle.com> Hi,Alexander Fix looks good. On 19.06.2012 15:32, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7172430: [macosx] debug message in non > debug jdk build > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172430 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7172430/webrev.00 > > The fix is quite simple - i have no idea why this code was not > safeguarded by corresponding #if/#endif in the first place, but well.. > > With best regards, > Alex -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Jun 19 04:39:38 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 19 Jun 2012 15:39:38 +0400 Subject: [7u6] Please review my fix for 7172430: [macosx] debug message in non debug jdk build In-Reply-To: <4FE06351.5000704@oracle.com> References: <4FE06351.5000704@oracle.com> Message-ID: <4FE064FA.7080101@oracle.com> Looks great. -- best regards, Anthony On 6/19/2012 3:32 PM, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7172430: [macosx] debug message in non > debug jdk build > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172430 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7172430/webrev.00 > > The fix is quite simple - i have no idea why this code was not > safeguarded by corresponding #if/#endif in the first place, but well.. > > With best regards, > Alex From anthony.petrov at oracle.com Tue Jun 19 06:09:43 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 19 Jun 2012 17:09:43 +0400 Subject: [7u6] Review request for 7174704: [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure Message-ID: <4FE07A17.9010407@oracle.com> Hi Artem and Leonid, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7174704 at: http://cr.openjdk.java.net/~anthony/7u6-12-headlessPrinting-7174704.0/ With this fix we revert a patch for 7144542 which restores the usage of the CToolkit in the headless mode on the Mac, and thus makes the HeadlessPrintingTest pass. Also, the Busy/Free observers aren't installed in the headless mode anymore, which ensures that we don't regress after reverting 7144542. Please refer to the Evaluation of the bug for more details. -- best regards, Anthony From alexander.zuev at oracle.com Tue Jun 19 06:25:39 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 19 Jun 2012 17:25:39 +0400 Subject: [7u6] Please review my fix for 7172430: [macosx] debug message in non debug jdk build Message-ID: <4FE07DD3.5030603@oracle.com> Hello, please review my fix for CR 7172430: [macosx] debug message in non debug jdk build CR description can be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172430 Webrev with the proposed change can be seen here: http://cr.openjdk.java.net/~kizune/7172430/webrev.00 For consistency i have created the jdk8 sub-cr and need a separate review so change will be in jdk8 before i ask for approval to push to 7u6. Sorry for causing deja vu... With best regards, Alex From anthony.petrov at oracle.com Tue Jun 19 06:27:03 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 19 Jun 2012 17:27:03 +0400 Subject: [7u6] Please review my fix for 7172430: [macosx] debug message in non debug jdk build In-Reply-To: <4FE07DD3.5030603@oracle.com> References: <4FE07DD3.5030603@oracle.com> Message-ID: <4FE07E27.1090707@oracle.com> Still looks great. -- best regards, Anthony On 6/19/2012 5:25 PM, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7172430: [macosx] debug message in non > debug jdk build > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172430 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7172430/webrev.00 > > For consistency i have created the jdk8 sub-cr and need a separate > review so change will be in jdk8 before i ask for approval to push to > 7u6. Sorry for causing deja vu... > > With best regards, > Alex From leonid.romanov at oracle.com Tue Jun 19 07:32:42 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 19 Jun 2012 18:32:42 +0400 Subject: [7u6] Review request for 7174704: [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure In-Reply-To: <4FE07A17.9010407@oracle.com> References: <4FE07A17.9010407@oracle.com> Message-ID: <6BE10F3D-452F-42EE-BC23-16F77F579877@oracle.com> My only complain is that with all these ifdef/ifndef the code is hard to read. Otherwise looks good. On 19.06.2012, at 17:09, Anthony Petrov wrote: > Hi Artem and Leonid, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7174704 at: > > http://cr.openjdk.java.net/~anthony/7u6-12-headlessPrinting-7174704.0/ > > With this fix we revert a patch for 7144542 which restores the usage of the CToolkit in the headless mode on the Mac, and thus makes the HeadlessPrintingTest pass. Also, the Busy/Free observers aren't installed in the headless mode anymore, which ensures that we don't regress after reverting 7144542. Please refer to the Evaluation of the bug for more details. > > -- > best regards, > Anthony From anthony.petrov at oracle.com Tue Jun 19 07:29:47 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 19 Jun 2012 18:29:47 +0400 Subject: [7u6] Review request for 7174704: [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure In-Reply-To: <6BE10F3D-452F-42EE-BC23-16F77F579877@oracle.com> References: <4FE07A17.9010407@oracle.com> <6BE10F3D-452F-42EE-BC23-16F77F579877@oracle.com> Message-ID: <4FE08CDB.4090108@oracle.com> I agree completely. But I'm just reverting a fix that was integrated earlier [1]. We may want to revise this logic in JDK 8. Thanks for the review! [1] http://cr.openjdk.java.net/~anthony/7u6-6-crashInSetBusy-7144542.1/ -- best regards, Anthony On 6/19/2012 6:32 PM, Leonid Romanov wrote: > My only complain is that with all these ifdef/ifndef the code is hard to read. Otherwise looks good. > > On 19.06.2012, at 17:09, Anthony Petrov wrote: > >> Hi Artem and Leonid, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7174704 at: >> >> http://cr.openjdk.java.net/~anthony/7u6-12-headlessPrinting-7174704.0/ >> >> With this fix we revert a patch for 7144542 which restores the usage of the CToolkit in the headless mode on the Mac, and thus makes the HeadlessPrintingTest pass. Also, the Busy/Free observers aren't installed in the headless mode anymore, which ensures that we don't regress after reverting 7144542. Please refer to the Evaluation of the bug for more details. >> >> -- >> best regards, >> Anthony > From leonid.romanov at oracle.com Tue Jun 19 07:40:27 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 19 Jun 2012 18:40:27 +0400 Subject: JMenuItem keyboard accelerator not showing when using the useScreenMenuBar property In-Reply-To: References: <722D0EED-4620-4CFB-B9C1-9E2250AAD1B6@oracle.com> Message-ID: Yep, thanks! The thing is, this code hasn't changed since 7u4, so I need to find out why it works in 7u4. On 18.06.2012, at 19:54, Marco Dinacci wrote: > Hi Leonid, > > I think I've found the issue. In ScreenMenuItem.addNotify there's the > following code: > > setAccelerator(fMenuItem.getAccelerator()); > > final String label = fMenuItem.getText(); > if (label != null) { > setLabel(label); > } > > setLabel(label) in CMenuItem calls: > > setLabel(label, (char)0, KeyEvent.VK_UNDEFINED, 0); > > which resets any accelerator previously set with setAccelerator. > > If the call to setAccelerator(fMenuItem.getAccelerator()) is placed > after setLabel(label) than the accelerator is set again and the > shortcut is visible. I don't know if it's the best way to reset the > accelerator in setLabel and then setting it back again but at least it > works. > > Here's the test file I used: > > import java.awt.*; > import java.awt.event.*; > import javax.swing.*; > > public class MenuBug { > > public JMenuBar createMenuBar(final JFrame frame) { > JMenuBar menuBar; > JMenu menu, submenu; > JMenuItem menuItem; > > menuBar = new JMenuBar(); > > menu = new JMenu("A Menu"); > menu.setMnemonic(KeyEvent.VK_A); > menuBar.add(menu); > > menuItem = new JMenuItem("menu item"); > KeyStroke s = KeyStroke.getKeyStroke( > KeyEvent.VK_T, ActionEvent.META_MASK); > menuItem.setAccelerator(s); > menu.add(menuItem); > > return menuBar; > } > > private static void createAndShowGUI() { > JFrame frame = new JFrame("MenuBug"); > frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > > MenuBug demo = new MenuBug(); > frame.setJMenuBar(demo.createMenuBar(frame)); > > frame.setVisible(true); > } > > public static void main(String[] args) { > javax.swing.SwingUtilities.invokeLater(new Runnable() { > public void run() { > createAndShowGUI(); > } > }); > } > } > > Best, > Marco From artem.ananiev at oracle.com Tue Jun 19 08:09:53 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 19 Jun 2012 19:09:53 +0400 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: <832149A8-388C-467A-B746-F14BAF2DCF48@oracle.com> References: <4FC373A5.9030508@oracle.com> <89803632-78F2-410F-B66B-09AEFC8CAB11@oracle.com> <4FC39B2F.6070805@oracle.com> <32533319-5E00-483F-AE69-6E79419C3757@oracle.com> <4FC78E82.1030500@oracle.com> <99A4EEA8-726B-4319-AEDE-DC84E9F9D32F@oracle.com> <734F6A51-08C7-4BE1-8E70-8037752C0A48@oracle.com> <4FCF7D71.1040404@oracle.com> <832149A8-388C-467A-B746-F14BAF2DCF48@oracle.com> Message-ID: <4FE09641.7070204@oracle.com> Thanks for explanation. I'm fine with the fix then. Thanks, Artem On 6/14/2012 12:28 AM, Leonid Romanov wrote: > Ok, I've played with the app bundler project. It looks like we don't have to do anything to ensure that CFBundleName has higher priority than JAVA_MAIN_CLASS_. You see, we don't set the app name directly: instead, we use whatever string we have for the app name to set JRSAppNameKey property, the rest happens in the Apple code. My experiments show that Apple handles JRSAppNameKey the same way my fix handles the Dock icon: if it has already been specified via Info.plist, then don't set it. > > On 06.06.2012, at 19:55, Igor Nekrestyanov wrote: > >> IMHO, for testing grab sample from >> javaweb.us.oracle.com/~inekrest/native-bundles >> >> Install it and then tweak Info.plist as needed. >> >> -igor >> >> On 6/6/12 8:33 AM, Scott Kovatch wrote: >>> Your best bet is to start with the app bundler project on java.net. >>> >>> http://java.net/projects/appbundler >>> >>> It's an ant script that will take a JAR file and turn it into a bundled app. >>> >>> Also, the latest builds of javafxpackager will now generate a bundled app, too. >>> >>> -- Scott >>> >>> On Jun 1, 2012, at 8:27 AM, Leonid Romanov wrote: >>> >>>> Hi Scott, >>>> Could you please provide me with instructions how to create my own bundled app? There is a couple of things I want to test... >>>> >>>> On 31.05.2012, at 20:20, Scott Kovatch wrote: >>>> >>>>> I think what Artem is saying is that if the application is bundled, and CFBundleName is set, it should take higher priority than JAVA_MAIN_CLASS_. >>>>> >>>>> If that is what you are saying, Artem, I agree. :-) >>>>> >>>>> We're straying away from the original review, though. >>>>> >>>>> -- Scott >>>>> >>>>> On May 31, 2012, at 8:30 AM, Artem Ananiev wrote: >>>>> >>>>>> Hi, Leonid, >>>>>> >>>>>> shouldn't app name set in the bundler be of higher priority than JAVA_MAIN_CLASS_ value, set by Java launcher? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>> On 5/29/2012 8:59 PM, Leonid Romanov wrote: >>>>>>> Well, the order is the following: first, we check if -Xdock:name has been set. If it hasn't, we check for the "apple.awt.application.name" property. If this property hasn't been set, we try to get the app name from the JAVA_MAIN_CLASS_ environment variable, which is used to pass the name of a Java class whose main() method was invoked by the Java launcher code to start the application. If JAVA_MAIN_CLASS_ hasn't been set, then as the last resort we try to get the app name from the bundle. >>>>>>> >>>>>>> On 28.05.2012, at 19:35, Artem Ananiev wrote: >>>>>>> >>>>>>>> On 5/28/2012 6:06 PM, Leonid Romanov wrote: >>>>>>>>> Hi, >>>>>>>>> The problem with the application name is that the app in question uses "com.apple.mrj.application.apple.menu.about.name" property to set its name. Mu understanding is that we don't support this property in OpenJDK. >>>>>>>> OK, fine. Is the application name set correctly when it is passed from app bundle or as -Xdock:name? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Artem >>>>>>>> >>>>>>>>> On 28.05.2012, at 16:46, Artem Ananiev wrote: >>>>>>>>> >>>>>>>>>> Hi, Leonid, >>>>>>>>>> >>>>>>>>>> the fix looks fine. Is the application name issue (also mentioned in 7159381) addressed in another fix? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Artem >>>>>>>>>> >>>>>>>>>> On 5/24/2012 5:23 PM, Leonid Romanov wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> Please review a fix for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category. The problem here is that we ignore the fact that for the bundled app its icon might be specified via Info.plist file. In this case OS X sets the icon for us, so we don't have to do anything. >>>>>>>>>>> >>>>>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7159381/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Leonid. >>>>>>>>>>> >> > From Sergey.Bylokhov at oracle.com Tue Jun 19 08:11:42 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 19 Jun 2012 19:11:42 +0400 Subject: [7u6] Please review my fix for 7172430: [macosx] debug message in non debug jdk build In-Reply-To: <4FE07DD3.5030603@oracle.com> References: <4FE07DD3.5030603@oracle.com> Message-ID: <4FE096AE.3050602@oracle.com> Hi, Alexander. Fix looks good. On 19.06.2012 17:25, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7172430: [macosx] debug message in non > debug jdk build > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172430 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7172430/webrev.00 > > For consistency i have created the jdk8 sub-cr and need a separate > review so change will be in jdk8 before i ask for approval to push to > 7u6. Sorry for causing deja vu... > > With best regards, > Alex -- Best regards, Sergey. From scott.kovatch at oracle.com Tue Jun 19 08:27:28 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 19 Jun 2012 08:27:28 -0700 Subject: KeyEvent modifiersText In-Reply-To: <9DD435B8-8F27-4CF4-9921-F24DA9C87CAD@abacus.ch> References: <9DD435B8-8F27-4CF4-9921-F24DA9C87CAD@abacus.ch> Message-ID: <58F144E3-B52C-4DE7-8E42-4109B27250D8@oracle.com> Oops - yes, you are right, that's a bug. Please file a bug at http://bugreport.sun.com/bugreport/ -- if you have a patch, that's even better. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA On Jun 18, 2012, at 11:29 PM, Roger T?nz wrote: > Hi, > > KeyEvent.getKeyModifiersText(KeyEvent.META_MASK) > > > with Java6 i do get the CommandKey-Char "?" > > with Java7 i do get "Meta" > > i think there's something missing in "sun.awt.resources.awt" > > cheers > Roger From leonid.romanov at oracle.com Tue Jun 19 09:09:37 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 19 Jun 2012 20:09:37 +0400 Subject: KeyEvent modifiersText In-Reply-To: <58F144E3-B52C-4DE7-8E42-4109B27250D8@oracle.com> References: <9DD435B8-8F27-4CF4-9921-F24DA9C87CAD@abacus.ch> <58F144E3-B52C-4DE7-8E42-4109B27250D8@oracle.com> Message-ID: <81C8017A-EB7B-474E-8ABB-C219797F2B7F@oracle.com> We have one already: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129133 The reason why it hasn't been fixed yet is because our build system doesn't support platform specific "awt.properties" files. So, a bit of engineering is needed. On 19.06.2012, at 19:27, Scott Kovatch wrote: > Oops - yes, you are right, that's a bug. Please file a bug at http://bugreport.sun.com/bugreport/ -- if you have a patch, that's even better. > > -- Scott K. > > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > > > On Jun 18, 2012, at 11:29 PM, Roger T?nz wrote: > >> Hi, >> >> KeyEvent.getKeyModifiersText(KeyEvent.META_MASK) >> >> >> with Java6 i do get the CommandKey-Char "?" >> >> with Java7 i do get "Meta" >> >> i think there's something missing in "sun.awt.resources.awt" >> >> cheers >> Roger > From leonid.romanov at oracle.com Tue Jun 19 09:41:19 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 19 Jun 2012 20:41:19 +0400 Subject: [7u6] Review request for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper In-Reply-To: <4FDB86C5.4020503@oracle.com> References: <4FD9FF4E.7030908@oracle.com> <5A941163-3D9A-4552-A032-5ADB32B2931E@oracle.com> <4FDB86C5.4020503@oracle.com> Message-ID: <7CC62B3A-AED1-4930-A428-6EE63DC76548@oracle.com> Sounds like a good idea. Done: http://cr.openjdk.java.net/~leonidr/7124239/webrev.02/ On 15.06.2012, at 23:02, Anthony Petrov wrote: > Hi Leonid, > >> 93 NSApplicationAWT* theApp = (NSApplicationAWT*)[NSApplication sharedApplication]; > > Actually, in case an SWT application is running, this conversion may not work as expected. Should we possibly perform an isKindOfClass check, and if it's not our application class, use the previous approach (i.e. spin a single empty block through the event loop)? > > Otherwise the fix looks fine. > > -- > best regards, > Anthony > > On 6/15/2012 9:06 PM, Leonid Romanov wrote: >> Hi, >> I've adressed your comments in http://cr.openjdk.java.net/~leonidr/7124239/webrev.01/ >> More specifically: 1. Removed ) >> 2. After some consideration I've decided to use timestamp in order to distinguish our event from others: seems like it's the most bulletproof method. 3. You could be right. I've replaced the loop with NSConditionLock machinery. On 14.06.2012, at 19:12, Anthony Petrov wrote: >>> Hi Leonid, >>> >>> 1. In NSApplicationAWT: the NSLog("Here...") statements. I use such debugging output, too! :) However, for production code please either replace them with meaningful messages, or remove them altogether. >>> >>> 2. >>>> 344 - (void)sendEvent:(NSEvent *)event >>> >>> I'm afraid that using the NSApplicationDefined and just skipping it may conflict with other native toolkits, such as SWT, or some custom native libraries. I think we should let such events go through the [super sendEvent]. >>> >>> 3. Isn't the loop in LWCToolkit.m too tight? There's an issue with performSelector on the Mac in that selectors are processed strictly before processing events. If the queue is flooded with posted selectors, the event may never have a chance to be handled. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 06/14/12 08:25, Leonid Romanov wrote: >>>> Hi, >>>> Please review a fix for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper. >>>> The problem is that syncNativeQueue() doesn't fully sync the native queue. For example, if there are, say, 25 events in the native queue waiting to be processed, nativeSyncQueue might return after only one event has been processed. realSync() calls syncNativeQueue() in a loop until nativeSyncQueue() reports that no native events have been processed as the result of the call or the maximum number of iterations (which is 20) has been exceeded (which leads to the exception). And since there are more than 20 events in the native queue, we get the exception. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124239 >>>> Webrev: http://cr.openjdk.java.net/~leonidr/7124239/webrev.00/ >>>> >>>> Thanks, >>>> Leonid. From anthony.petrov at oracle.com Tue Jun 19 10:04:12 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 19 Jun 2012 21:04:12 +0400 Subject: [7u6] Review request for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper In-Reply-To: <7CC62B3A-AED1-4930-A428-6EE63DC76548@oracle.com> References: <4FD9FF4E.7030908@oracle.com> <5A941163-3D9A-4552-A032-5ADB32B2931E@oracle.com> <4FDB86C5.4020503@oracle.com> <7CC62B3A-AED1-4930-A428-6EE63DC76548@oracle.com> Message-ID: <4FE0B10C.8050809@oracle.com> The fix looks fine to me. Thank you. -- best regards, Anthony On 6/19/2012 8:41 PM, Leonid Romanov wrote: > Sounds like a good idea. Done: > http://cr.openjdk.java.net/~leonidr/7124239/webrev.02/ > > On 15.06.2012, at 23:02, Anthony Petrov wrote: > >> Hi Leonid, >> >>> 93 NSApplicationAWT* theApp = (NSApplicationAWT*)[NSApplication >>> sharedApplication]; >> >> Actually, in case an SWT application is running, this conversion may >> not work as expected. Should we possibly perform an isKindOfClass >> check, and if it's not our application class, use the previous >> approach (i.e. spin a single empty block through the event loop)? >> >> Otherwise the fix looks fine. >> >> -- >> best regards, >> Anthony >> >> On 6/15/2012 9:06 PM, Leonid Romanov wrote: >>> Hi, >>> I've adressed your comments in >>> http://cr.openjdk.java.net/~leonidr/7124239/webrev.01/ >>> More specifically: 1. Removed ) >>> 2. After some consideration I've decided to use timestamp in order to >>> distinguish our event from others: seems like it's the most >>> bulletproof method. 3. You could be right. I've replaced the loop >>> with NSConditionLock machinery. On 14.06.2012, at 19:12, Anthony >>> Petrov wrote: >>>> Hi Leonid, >>>> >>>> 1. In NSApplicationAWT: the NSLog("Here...") statements. I use such >>>> debugging output, too! :) However, for production code please either >>>> replace them with meaningful messages, or remove them altogether. >>>> >>>> 2. >>>>> 344 - (void)sendEvent:(NSEvent *)event >>>> >>>> I'm afraid that using the NSApplicationDefined and just skipping it >>>> may conflict with other native toolkits, such as SWT, or some custom >>>> native libraries. I think we should let such events go through the >>>> [super sendEvent]. >>>> >>>> 3. Isn't the loop in LWCToolkit.m too tight? There's an issue with >>>> performSelector on the Mac in that selectors are processed strictly >>>> before processing events. If the queue is flooded with posted >>>> selectors, the event may never have a chance to be handled. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 06/14/12 08:25, Leonid Romanov wrote: >>>>> Hi, >>>>> Please review a fix for 7124239: [macosx] >>>>> sun.awt.SunToolkit.InfiniteLoop exception in realSync called from >>>>> SwingTestHelper. >>>>> The problem is that syncNativeQueue() doesn't fully sync the native >>>>> queue. For example, if there are, say, 25 events in the native >>>>> queue waiting to be processed, nativeSyncQueue might return after >>>>> only one event has been processed. realSync() calls >>>>> syncNativeQueue() in a loop until nativeSyncQueue() reports that no >>>>> native events have been processed as the result of the call or the >>>>> maximum number of iterations (which is 20) has been exceeded (which >>>>> leads to the exception). And since there are more than 20 events in >>>>> the native queue, we get the exception. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124239 >>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7124239/webrev.00/ >>>>> >>>>> Thanks, >>>>> Leonid. > From lordpixel at me.com Wed Jun 20 19:04:14 2012 From: lordpixel at me.com (Andrew Thompson) Date: Wed, 20 Jun 2012 22:04:14 -0400 Subject: System properties In-Reply-To: <74AE704A-31CB-4E87-A5D2-60999BF859A6@me.com> References: <74AE704A-31CB-4E87-A5D2-60999BF859A6@me.com> Message-ID: So when al is said and done on this thread I think our conclusion was this needs to be in the Release notes. How would one file a bug requesting that? Is it important to get the right component? On Jun 8, 2012, at 10:10 PM, Andrew Thompson wrote: > > On May 27, 2012, at 6:46 PM, Michael Hall wrote: > >> Apple 1.6 never seems to give UTF-8 contrary to what Andrew said. It is always MacRoman. Either he was not accurate in what he said or is changing the property to UTF-8 somewhere that he isn't aware of it. > > > Well now, that's interesting. Running locale and then my program again in the terminal I see > > % locale > LANG="en_US.UTF-8" > LC_COLLATE="en_US.UTF-8" > LC_CTYPE="en_US.UTF-8" > LC_MESSAGES="en_US.UTF-8" > LC_MONETARY="en_US.UTF-8" > LC_NUMERIC="en_US.UTF-8" > LC_TIME="en_US.UTF-8" > LC_ALL= > > %uname -a > Darwin Bubbles.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64 > > % java -version > java version "1.6.0_31" > Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635) > Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode) > > java -cp . FileEncoding > MacRoman > java.vm.version: 20.6-b01-415 > file.encoding.pkg: sun.io > java.runtime.version: 1.6.0_31-b04-415-11M3635 > java.io.tmpdir: /var/folders/3l/yd1xg64n58l4ll7jnhvc0glm0000gq/T/ > sun.jnu.encoding: MacRoman > java.class.version: 50.0 > os.version: 10.7.3 > file.encoding: MacRoman > java.specification.version: 1.6 > java.vm.specification.version: 1.0 > java.version: 1.6.0_31 > file.separator: / > sun.io.unicode.encoding: UnicodeLittle > mrj.version: 1070.1.6.0_31-415 > > => Mac Roman > > Running the very same program in Netbeans... which as far as I know execs Java > > UTF-8 > java.vm.version: 20.6-b01-415 > file.encoding.pkg: sun.io > java.runtime.version: 1.6.0_31-b04-415-11M3635 > java.io.tmpdir: /var/folders/3l/yd1xg64n58l4ll7jnhvc0glm0000gq/T/ > sun.jnu.encoding: MacRoman > java.class.version: 50.0 > os.version: 10.7.3 > file.encoding: UTF-8 > java.specification.version: 1.6 > java.vm.specification.version: 1.0 > java.version: 1.6.0_31 > file.separator: / > sun.io.unicode.encoding: UnicodeLittle > mrj.version: 1070.1.6.0_31-415 > > => UTF8 > > And yet Netbeans' own About window shows > > Product Version: NetBeans IDE 7.0.1 (Build 201107282000) > Java: 1.6.0_31; Java HotSpot(TM) 64-Bit Server VM 20.6-b01-415 > System: Mac OS X version 10.7.3 running on x86_64; MacRoman; en_US (nb) > Userdir: /Users/pixel/.netbeans/7.0 > > => MacRoman > > > So this is very strange. The same program can return MacRoman in the Terminal and UTF-8 in Netbeans. > There's more to this than first appears. > > > AndyT (lordpixel - the cat who walks through walls) > A little bigger on the inside > > (see you later space cowboy, you can't take the sky from me) > > AndyT (lordpixel - the cat who walks through walls) A little bigger on the inside (see you later space cowboy, you can't take the sky from me) From swingler at apple.com Wed Jun 20 23:22:44 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 20 Jun 2012 23:22:44 -0700 Subject: [8] Review request for 7170716: JVM crash when opening an AWT app from a registered file. [WAS: Re: Patch for #7170716, crash in OSXAPP_SetApplicationDelegate] In-Reply-To: <4FDF3E5A.1040102@oracle.com> References: <4FD890CA.1080803@oracle.com> <4FDB7A41.6080402@oracle.com> <4FDF3E5A.1040102@oracle.com> Message-ID: <0B900A42-3F78-4CA5-A0C3-FB31C4C06D95@apple.com> This looks good. I'd also suggest making it an atomic property, and also converting the queue to be a property as well. Using -> notation to directly pick at Obj-C ivars across threads is generally considered bad form. Regards, Mike Swingler Apple Inc. On Jun 18, 2012, at 7:42 AM, Anthony Petrov wrote: > Hi Marco et al., > > I've published your latest patch here: > > http://cr.openjdk.java.net/~anthony/8-34-crashInSetApplicationDelegate-7170716.2/ > > The fix looks just fine to me. Thank you for fixing the issue. > > Could anyone else on this mailing list review it please? > > -- > best regards, > Anthony > > On 06/16/12 12:51, Marco Dinacci wrote: >> Hi, >> >>> 1. I think the changes to the NSApplicationAWT.h are unnecessary. >> >> yes this was a mistake. >> >>> 2. I'd recommend to not remove the if (applicationDelegate) check in the >>> NSApplicationAWT.m since in the future we may want to change the logic in >>> awt.m, in which case a real delegate may be set before finishLaunching is >>> executed. The check doesn't hurt, does it? >> >> ok, I don't know about the future plans. I think the best then is just >> to revert NSApplicationAWT.m entirely, the bug fix is really in >> QueuingApplicationDelegate.m anyway. By entirely I also mean removing >> the [applicationDelegate retain] that I added in the first patch as I >> now understand that there's no need to keep it (at least for now) once >> all the events are processed. >> >>> 3. The realDelegate as a property looks fine. Since we use the self. (or >>> self->) notation to access ivars, please update the QAD's callback methods >>> (those that create the blocks to be queued), and use this notation to access >>> the realDelegate property. (I'm wondering though, won't the compiler treat >>> 'self' as a ref to the block instead of the object there?) >> >> done >> >>> src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m: >>>> >>>> 61 if (!self) { >>>> 62 self.realDelegate = nil; >>>> 63 return self; >>>> 64 } >> >> fixed. >> >> The usual convention in Cocoa is to do an if(self) instead of >> if(!self) so I got confused. >> >>> Also, in theory we could nullify the property at the end of >>> processQueuedEventsWithTargetDelegate since we don't need to retain the >>> object after we've flushed all the queued events. I don't have a strong >>> opinion on this though, since the property will be nil'ed in the dealloc >>> anyway. >> >> I don't have a strong opinion either, I think it doesn't hurt leaving >> it like this because as you say it will be dealloced anyway. >> >> Attached the new patch, I reverted NSApplicationAWT.m and its header >> and implemented the changes you suggested above. >> >> Best, >> Marco From artem.ananiev at oracle.com Thu Jun 21 03:22:44 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 21 Jun 2012 14:22:44 +0400 Subject: [7u6] Review request for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper In-Reply-To: <7CC62B3A-AED1-4930-A428-6EE63DC76548@oracle.com> References: <4FD9FF4E.7030908@oracle.com> <5A941163-3D9A-4552-A032-5ADB32B2931E@oracle.com> <4FDB86C5.4020503@oracle.com> <7CC62B3A-AED1-4930-A428-6EE63DC76548@oracle.com> Message-ID: <4FE2F5F4.8010902@oracle.com> Looks fine. Thanks, Artem On 6/19/2012 8:41 PM, Leonid Romanov wrote: > Sounds like a good idea. Done: > http://cr.openjdk.java.net/~leonidr/7124239/webrev.02/ > > On 15.06.2012, at 23:02, Anthony Petrov wrote: > >> Hi Leonid, >> >>> 93 NSApplicationAWT* theApp = (NSApplicationAWT*)[NSApplication >>> sharedApplication]; >> >> Actually, in case an SWT application is running, this conversion may >> not work as expected. Should we possibly perform an isKindOfClass >> check, and if it's not our application class, use the previous >> approach (i.e. spin a single empty block through the event loop)? >> >> Otherwise the fix looks fine. >> >> -- >> best regards, >> Anthony >> >> On 6/15/2012 9:06 PM, Leonid Romanov wrote: >>> Hi, >>> I've adressed your comments in >>> http://cr.openjdk.java.net/~leonidr/7124239/webrev.01/ >>> More specifically: 1. Removed ) >>> 2. After some consideration I've decided to use timestamp in order to >>> distinguish our event from others: seems like it's the most >>> bulletproof method. 3. You could be right. I've replaced the loop >>> with NSConditionLock machinery. On 14.06.2012, at 19:12, Anthony >>> Petrov wrote: >>>> Hi Leonid, >>>> >>>> 1. In NSApplicationAWT: the NSLog("Here...") statements. I use such >>>> debugging output, too! :) However, for production code please either >>>> replace them with meaningful messages, or remove them altogether. >>>> >>>> 2. >>>>> 344 - (void)sendEvent:(NSEvent *)event >>>> >>>> I'm afraid that using the NSApplicationDefined and just skipping it >>>> may conflict with other native toolkits, such as SWT, or some custom >>>> native libraries. I think we should let such events go through the >>>> [super sendEvent]. >>>> >>>> 3. Isn't the loop in LWCToolkit.m too tight? There's an issue with >>>> performSelector on the Mac in that selectors are processed strictly >>>> before processing events. If the queue is flooded with posted >>>> selectors, the event may never have a chance to be handled. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 06/14/12 08:25, Leonid Romanov wrote: >>>>> Hi, >>>>> Please review a fix for 7124239: [macosx] >>>>> sun.awt.SunToolkit.InfiniteLoop exception in realSync called from >>>>> SwingTestHelper. >>>>> The problem is that syncNativeQueue() doesn't fully sync the native >>>>> queue. For example, if there are, say, 25 events in the native >>>>> queue waiting to be processed, nativeSyncQueue might return after >>>>> only one event has been processed. realSync() calls >>>>> syncNativeQueue() in a loop until nativeSyncQueue() reports that no >>>>> native events have been processed as the result of the call or the >>>>> maximum number of iterations (which is 20) has been exceeded (which >>>>> leads to the exception). And since there are more than 20 events in >>>>> the native queue, we get the exception. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124239 >>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7124239/webrev.00/ >>>>> >>>>> Thanks, >>>>> Leonid. > From artem.ananiev at oracle.com Thu Jun 21 03:28:33 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 21 Jun 2012 14:28:33 +0400 Subject: [7u6] Review request for 7174704: [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure In-Reply-To: <4FE07A17.9010407@oracle.com> References: <4FE07A17.9010407@oracle.com> Message-ID: <4FE2F751.1060506@oracle.com> Hi, Anthony, as we discussed this workaround offline, I'm fine with it. Thanks, Artem On 6/19/2012 5:09 PM, Anthony Petrov wrote: > Hi Artem and Leonid, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7174704 at: > > http://cr.openjdk.java.net/~anthony/7u6-12-headlessPrinting-7174704.0/ > > With this fix we revert a patch for 7144542 which restores the usage of > the CToolkit in the headless mode on the Mac, and thus makes the > HeadlessPrintingTest pass. Also, the Busy/Free observers aren't > installed in the headless mode anymore, which ensures that we don't > regress after reverting 7144542. Please refer to the Evaluation of the > bug for more details. > > -- > best regards, > Anthony From Sergey.Bylokhov at oracle.com Thu Jun 21 03:42:58 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 21 Jun 2012 14:42:58 +0400 Subject: [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing In-Reply-To: <4FDF45AA.4040703@oracle.com> References: <4FC77592.7020900@oracle.com> <4FDF45AA.4040703@oracle.com> Message-ID: <4FE2FAB2.7020105@oracle.com> Hello, new version of the fix: http://cr.openjdk.java.net/~serb/7142091/webrev.01/ - invokeLater was removed from setVisible and dispose. - instanceof Graphics2D was added. Run some awt related jck and regression tests, no new issues found. On 18.06.2012 19:13, Artem Ananiev wrote: > Hi, Sergey, > > some minor comments (may be unrelated to the fix): > > 1. LWComponentPeer.setVisible() can be made final. Do expect any > subclass to override it instead of setVisibleImpl()? It is overriden in CPrinterDialogPeer. > > 2. invokeLater() in LWWindowPeer.setVisibleImpl(): I realize this is > really painful issue, but I'd vote for removing this workaround. It > would result in faster startup (although, the window will be solid > gray for some time), and make LWAWT code similar to what we have on > other platforms. removed > > Then next step will to minimize the delay between showing the window > and painting its content. > > 3. LWWindowPeer.replaceSurfaceData(): what are benefits of > setBackground() + clearRect() over setColor() + fillRect()? Although > we always expect the Graphics object to be Graphics2D instance, this > unconditional cast doesn't look great. done > > Thanks, > > Artem > > On 5/31/2012 5:43 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Please review the fix. >> >> Notes from the bug and comments: >> 1. setVisible() should be called at the end of the peers initialization. >> We can move super.initialize() to the end of the peers initializations. >> Initialize() was split to initialize() and initializeImpl(). In the >> initialize() we call initializeImpl and then we call to setVisible(). >> initializeImpl overridden in subclasses. >> >> 2. Invokelater in the initialization/disposing is a tricky. >> Left it as is. Probably later it will be changed. Comments was updated. >> >> 3. replaceSurfacedata() should be moved outside of >> LWWindowPeer.setVisible() >> Done. Also duplicate code was extracted to setVisible() method which >> call setVisibleImpl(). >> >> 4. Backbuffer in replaceSurfacedata() should be initialized by clearRect >> instead of fillrect(composite is important). >> Done. related to composite. >> >> 5. During lwwindowpeer initialization we call two similar methods >> nativeSetNSWindowAlpha() and setAlphaValue(). >> nativeSetNSWindowAlpha() removed from CPlatformWindow.java. >> >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7142091/webrev.00/ >> -- Best regards, Sergey. From marco.dinacci at gmail.com Thu Jun 21 07:11:13 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Thu, 21 Jun 2012 15:11:13 +0100 Subject: [8] Review request for 7170716: JVM crash when opening an AWT app from a registered file. [WAS: Re: Patch for #7170716, crash in OSXAPP_SetApplicationDelegate] In-Reply-To: <0B900A42-3F78-4CA5-A0C3-FB31C4C06D95@apple.com> References: <4FD890CA.1080803@oracle.com> <4FDB7A41.6080402@oracle.com> <4FDF3E5A.1040102@oracle.com> <0B900A42-3F78-4CA5-A0C3-FB31C4C06D95@apple.com> Message-ID: Hi, > This looks good. I'd also suggest making it an atomic property, and also converting the queue to be a property as well. Using -> notation to directly pick at Obj-C ivars across threads is generally considered bad form. I agree making the queue a property, I think using "->" for ivars is an Oracle convention but I changed the code to use the dot syntax since I converted the queue to a property. Thanks for the comments, attached new patch. Best, Marco From anthony.petrov at oracle.com Thu Jun 21 07:24:42 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 21 Jun 2012 18:24:42 +0400 Subject: [8] Review request for 7170716: JVM crash when opening an AWT app from a registered file. [WAS: Re: Patch for #7170716, crash in OSXAPP_SetApplicationDelegate] In-Reply-To: References: <4FD890CA.1080803@oracle.com> <4FDB7A41.6080402@oracle.com> <4FDF3E5A.1040102@oracle.com> <0B900A42-3F78-4CA5-A0C3-FB31C4C06D95@apple.com> Message-ID: <4FE32EAA.9030400@oracle.com> Hi Marco and Mike, I've uploaded the latest patch as a webrev to: http://cr.openjdk.java.net/~anthony/8-34-crashInSetApplicationDelegate-7170716.3/ The fix still looks fine to me. I'll push it to JDK 8 tomorrow unless there are any objections. -- best regards, Anthony On 06/21/12 18:11, Marco Dinacci wrote: > Hi, > >> This looks good. I'd also suggest making it an atomic property, and also converting the queue to be a property as well. Using -> notation to directly pick at Obj-C ivars across threads is generally considered bad form. > > I agree making the queue a property, I think using "->" for ivars is > an Oracle convention but I changed the code to use the dot syntax > since I converted the queue to a property. > > Thanks for the comments, attached new patch. > > Best, > Marco From staffan.larsen at oracle.com Thu Jun 21 07:54:27 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 21 Jun 2012 16:54:27 +0200 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: <4FE316D5.3020502@oracle.com> References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> Message-ID: [adding build-dev and macosx-port-dev] On 21 jun 2012, at 14:43, David Holmes wrote: > On 21/06/2012 10:30 PM, Staffan Larsen wrote: >> Do you mean: >> >> .PHONY: $(UNIVERSAL_LIPO_LIST) $(UNIVERSAL_COPY_LIST) > > Yes. Now they will always be rebuilt. > >> Yes, that seems to have the same effect. Probably a better solution. > > I think both of these simply mask the real problem. I still don't understand how only some of the list items get "rebuilt". The CR says > > "These targets will only be run for the last item in the xxx_LIST variables (which happens to be the client jvm)" > > but I don't understand why that is? Neither do I. Makefiles is black magic to me. I only discovered that building the complete JDK from the top-level directory did not update the hotspot bits in the j2sdk-image and this was the ultimate cause. Here is an updated webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.02/ Thanks, /Staffan > But I also don't understand this universalization process. > > BTW you might want to run this past the bsd-port folks (don't recall the exact alias) and/or build-dev. I seem to recall that last time we changed something to do with universal builds it actually broke something. > > David > >> Thanks, >> /Staffan >> >> On 21 jun 2012, at 14:12, David Holmes wrote: >> >>> Hi Staffan, >>> >>> On 21/06/2012 6:33 PM, Staffan Larsen wrote: >>>> Please review the following fix to makefiles for universal binaries on >>>> max os x. The idea is to force the target to be executed for all items >>>> in the list. >>>> >>>> Fix contributed by Rickard B?ckman (rbackman). >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.01/ >>> >>> I don't understand the problem that this addresses but wouldn't you get the same affect by declaring those targets as PHONY ? >>> >>> David >>> >>> PS. Unrelated but I was astounded to see that bsd/Makefile and linux/Makefile both have a chunk of code conditional on "ifeq ($(OSNAME),solaris)" Huh! >> From henri.gomez at gmail.com Thu Jun 21 08:53:03 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 21 Jun 2012 17:53:03 +0200 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> Message-ID: universal build, on OSX ? Happy to see that some works/fixes around it :) BTW, how did you get in trouble since universal build is disabled for now unless some code is added to : There was an old thread on jdk7u-dev list and a proposed patch for review (http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch) 2012/6/21 Staffan Larsen : > [adding build-dev and macosx-port-dev] > > On 21 jun 2012, at 14:43, David Holmes wrote: > >> On 21/06/2012 10:30 PM, Staffan Larsen wrote: >>> Do you mean: >>> >>> .PHONY: $(UNIVERSAL_LIPO_LIST) $(UNIVERSAL_COPY_LIST) >> >> Yes. Now they will always be rebuilt. >> >>> Yes, that seems to have the same effect. Probably a better solution. >> >> I think both of these simply mask the real problem. I still don't understand how only some of the list items get "rebuilt". The CR says >> >> "These targets will only be run for the last item in the xxx_LIST variables (which happens to be the client jvm)" >> >> but I don't understand why that is? > > Neither do I. Makefiles is black magic to me. I only discovered that building the complete JDK from the top-level directory did not update the hotspot bits in the j2sdk-image and this was the ultimate cause. > > Here is an updated webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.02/ > > Thanks, > /Staffan > > >> But I also don't understand this universalization process. >> >> BTW you might want to run this past the bsd-port folks (don't recall the exact alias) and/or build-dev. I seem to recall that last time we changed something to do with universal builds it actually broke something. >> >> David >> >>> Thanks, >>> /Staffan >>> >>> On 21 jun 2012, at 14:12, David Holmes wrote: >>> >>>> Hi Staffan, >>>> >>>> On 21/06/2012 6:33 PM, Staffan Larsen wrote: >>>>> Please review the following fix to makefiles for universal binaries on >>>>> max os x. The idea is to force the target to be executed for all items >>>>> in the list. >>>>> >>>>> Fix contributed by Rickard B?ckman (rbackman). >>>>> >>>>> webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.01/ >>>> >>>> I don't understand the problem that this addresses but wouldn't you get the same affect by declaring those targets as PHONY ? >>>> >>>> David >>>> >>>> PS. Unrelated but I was astounded to see that bsd/Makefile and linux/Makefile both have a chunk of code conditional on "ifeq ($(OSNAME),solaris)" Huh! >>> > From staffan.larsen at oracle.com Thu Jun 21 09:54:46 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 21 Jun 2012 18:54:46 +0200 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> Message-ID: At least for me, MACOSX_UNIVERSAL ends up being set to true in hotspot/make/bsd/makefiles/defs.make. Line 186 and forward: # Universal build settings ifeq ($(OS_VENDOR), Darwin) # Build universal binaries by default on Mac OS X MACOSX_UNIVERSAL = true If this isn't intentional, then the fix for my problem is something else. /Staffan On 21 jun 2012, at 17:53, Henri Gomez wrote: > universal build, on OSX ? Happy to see that some works/fixes around it :) > > BTW, how did you get in trouble since universal build is disabled for > now unless some code is added to : > > There was an old thread on jdk7u-dev list and a proposed patch for > review (http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch) > > > > > > 2012/6/21 Staffan Larsen : >> [adding build-dev and macosx-port-dev] >> >> On 21 jun 2012, at 14:43, David Holmes wrote: >> >>> On 21/06/2012 10:30 PM, Staffan Larsen wrote: >>>> Do you mean: >>>> >>>> .PHONY: $(UNIVERSAL_LIPO_LIST) $(UNIVERSAL_COPY_LIST) >>> >>> Yes. Now they will always be rebuilt. >>> >>>> Yes, that seems to have the same effect. Probably a better solution. >>> >>> I think both of these simply mask the real problem. I still don't understand how only some of the list items get "rebuilt". The CR says >>> >>> "These targets will only be run for the last item in the xxx_LIST variables (which happens to be the client jvm)" >>> >>> but I don't understand why that is? >> >> Neither do I. Makefiles is black magic to me. I only discovered that building the complete JDK from the top-level directory did not update the hotspot bits in the j2sdk-image and this was the ultimate cause. >> >> Here is an updated webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.02/ >> >> Thanks, >> /Staffan >> >> >>> But I also don't understand this universalization process. >>> >>> BTW you might want to run this past the bsd-port folks (don't recall the exact alias) and/or build-dev. I seem to recall that last time we changed something to do with universal builds it actually broke something. >>> >>> David >>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 21 jun 2012, at 14:12, David Holmes wrote: >>>> >>>>> Hi Staffan, >>>>> >>>>> On 21/06/2012 6:33 PM, Staffan Larsen wrote: >>>>>> Please review the following fix to makefiles for universal binaries on >>>>>> max os x. The idea is to force the target to be executed for all items >>>>>> in the list. >>>>>> >>>>>> Fix contributed by Rickard B?ckman (rbackman). >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.01/ >>>>> >>>>> I don't understand the problem that this addresses but wouldn't you get the same affect by declaring those targets as PHONY ? >>>>> >>>>> David >>>>> >>>>> PS. Unrelated but I was astounded to see that bsd/Makefile and linux/Makefile both have a chunk of code conditional on "ifeq ($(OSNAME),solaris)" Huh! >>>> >> From daniel.daugherty at oracle.com Thu Jun 21 10:08:48 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 21 Jun 2012 11:08:48 -0600 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> Message-ID: <4FE35520.6080201@oracle.com> Staffan and Henri, I think you guys are talking about different levels of support for MacOS X Universal builds. Staffan's change is in HotSpot which has supported MacOS X Universal builds for a while now. Henri is talking about the forest of repos which does not currently support MacOS X Universal builds. Dan On 6/21/12 10:54 AM, Staffan Larsen wrote: > At least for me, MACOSX_UNIVERSAL ends up being set to true in hotspot/make/bsd/makefiles/defs.make. > > Line 186 and forward: > > # Universal build settings > ifeq ($(OS_VENDOR), Darwin) > # Build universal binaries by default on Mac OS X > MACOSX_UNIVERSAL = true > > If this isn't intentional, then the fix for my problem is something else. > > /Staffan > > On 21 jun 2012, at 17:53, Henri Gomez wrote: > >> universal build, on OSX ? Happy to see that some works/fixes around it :) >> >> BTW, how did you get in trouble since universal build is disabled for >> now unless some code is added to : >> >> There was an old thread on jdk7u-dev list and a proposed patch for >> review (http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch) >> >> >> >> >> >> 2012/6/21 Staffan Larsen: >>> [adding build-dev and macosx-port-dev] >>> >>> On 21 jun 2012, at 14:43, David Holmes wrote: >>> >>>> On 21/06/2012 10:30 PM, Staffan Larsen wrote: >>>>> Do you mean: >>>>> >>>>> .PHONY: $(UNIVERSAL_LIPO_LIST) $(UNIVERSAL_COPY_LIST) >>>> Yes. Now they will always be rebuilt. >>>> >>>>> Yes, that seems to have the same effect. Probably a better solution. >>>> I think both of these simply mask the real problem. I still don't understand how only some of the list items get "rebuilt". The CR says >>>> >>>> "These targets will only be run for the last item in the xxx_LIST variables (which happens to be the client jvm)" >>>> >>>> but I don't understand why that is? >>> Neither do I. Makefiles is black magic to me. I only discovered that building the complete JDK from the top-level directory did not update the hotspot bits in the j2sdk-image and this was the ultimate cause. >>> >>> Here is an updated webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.02/ >>> >>> Thanks, >>> /Staffan >>> >>> >>>> But I also don't understand this universalization process. >>>> >>>> BTW you might want to run this past the bsd-port folks (don't recall the exact alias) and/or build-dev. I seem to recall that last time we changed something to do with universal builds it actually broke something. >>>> >>>> David >>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 21 jun 2012, at 14:12, David Holmes wrote: >>>>> >>>>>> Hi Staffan, >>>>>> >>>>>> On 21/06/2012 6:33 PM, Staffan Larsen wrote: >>>>>>> Please review the following fix to makefiles for universal binaries on >>>>>>> max os x. The idea is to force the target to be executed for all items >>>>>>> in the list. >>>>>>> >>>>>>> Fix contributed by Rickard B?ckman (rbackman). >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.01/ >>>>>> I don't understand the problem that this addresses but wouldn't you get the same affect by declaring those targets as PHONY ? >>>>>> >>>>>> David >>>>>> >>>>>> PS. Unrelated but I was astounded to see that bsd/Makefile and linux/Makefile both have a chunk of code conditional on "ifeq ($(OSNAME),solaris)" Huh! From scott.kovatch at oracle.com Thu Jun 21 10:12:04 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 21 Jun 2012 10:12:04 -0700 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> Message-ID: 54 # Package built libraries in a universal binary 55 $(UNIVERSAL_LIPO_LIST): 56 BUILT_LIPO_FILES="`find $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) 2>/dev/null`"; \ 57 if [ -n "$${BUILT_LIPO_FILES}" ]; then \ 58 $(MKDIR) -p $(shell dirname $@); \ 59 lipo -create -output $@ $${BUILT_LIPO_FILES}; \ 60 fi 61 62 63 # Copy built non-universal binaries in place 64 $(UNIVERSAL_COPY_LIST): 65 BUILT_COPY_FILES="`find $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) 2>/dev/null`"; \ 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ 67 for i in $${BUILT_COPY_FILES}; do \ 68 if [ -f $${i} ]; then \ 69 $(MKDIR) -p $(shell dirname $@); \ 70 $(CP) $${i} $@; \ 71 fi; \ 72 done; \ 73 fi 74 This first item will find all object files that were built separately for i386 and amd64 architectures, and then use 'lipo -create -output ?' to create a single universal binary. The next phase copies those combined, universal binaries into EXPORT_JRE_LIB_DIR, since the Mac has never had/needed to break out libraries by architecture. So, it sounds like when you rebuilt, everything was built into jre/lib/i386 and jre/lib/amd64, but never combined (or, in this case, just copied) into jre/lib, and therefore not found. Since we only build x86_64 the lipo command is effectively a cp. -- Scott On Jun 21, 2012, at 9:54 AM, Staffan Larsen wrote: > At least for me, MACOSX_UNIVERSAL ends up being set to true in hotspot/make/bsd/makefiles/defs.make. > > Line 186 and forward: > > # Universal build settings > ifeq ($(OS_VENDOR), Darwin) > # Build universal binaries by default on Mac OS X > MACOSX_UNIVERSAL = true > > If this isn't intentional, then the fix for my problem is something else. > > /Staffan > > On 21 jun 2012, at 17:53, Henri Gomez wrote: > >> universal build, on OSX ? Happy to see that some works/fixes around it :) >> >> BTW, how did you get in trouble since universal build is disabled for >> now unless some code is added to : >> >> There was an old thread on jdk7u-dev list and a proposed patch for >> review (http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch) >> >> >> >> >> >> 2012/6/21 Staffan Larsen : >>> [adding build-dev and macosx-port-dev] >>> >>> On 21 jun 2012, at 14:43, David Holmes wrote: >>> >>>> On 21/06/2012 10:30 PM, Staffan Larsen wrote: >>>>> Do you mean: >>>>> >>>>> .PHONY: $(UNIVERSAL_LIPO_LIST) $(UNIVERSAL_COPY_LIST) >>>> >>>> Yes. Now they will always be rebuilt. >>>> >>>>> Yes, that seems to have the same effect. Probably a better solution. >>>> >>>> I think both of these simply mask the real problem. I still don't understand how only some of the list items get "rebuilt". The CR says >>>> >>>> "These targets will only be run for the last item in the xxx_LIST variables (which happens to be the client jvm)" >>>> >>>> but I don't understand why that is? >>> >>> Neither do I. Makefiles is black magic to me. I only discovered that building the complete JDK from the top-level directory did not update the hotspot bits in the j2sdk-image and this was the ultimate cause. >>> >>> Here is an updated webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.02/ >>> >>> Thanks, >>> /Staffan >>> >>> >>>> But I also don't understand this universalization process. >>>> >>>> BTW you might want to run this past the bsd-port folks (don't recall the exact alias) and/or build-dev. I seem to recall that last time we changed something to do with universal builds it actually broke something. >>>> >>>> David >>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 21 jun 2012, at 14:12, David Holmes wrote: >>>>> >>>>>> Hi Staffan, >>>>>> >>>>>> On 21/06/2012 6:33 PM, Staffan Larsen wrote: >>>>>>> Please review the following fix to makefiles for universal binaries on >>>>>>> max os x. The idea is to force the target to be executed for all items >>>>>>> in the list. >>>>>>> >>>>>>> Fix contributed by Rickard B?ckman (rbackman). >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.01/ >>>>>> >>>>>> I don't understand the problem that this addresses but wouldn't you get the same affect by declaring those targets as PHONY ? >>>>>> >>>>>> David >>>>>> >>>>>> PS. Unrelated but I was astounded to see that bsd/Makefile and linux/Makefile both have a chunk of code conditional on "ifeq ($(OSNAME),solaris)" Huh! >>>>> >>> > From staffan.larsen at oracle.com Thu Jun 21 11:25:01 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 21 Jun 2012 20:25:01 +0200 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> Message-ID: On 21 jun 2012, at 19:12, Scott Kovatch wrote: > 54 # Package built libraries in a universal binary > 55 $(UNIVERSAL_LIPO_LIST): > 56 BUILT_LIPO_FILES="`find $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) 2>/dev/null`"; \ > 57 if [ -n "$${BUILT_LIPO_FILES}" ]; then \ > 58 $(MKDIR) -p $(shell dirname $@); \ > 59 lipo -create -output $@ $${BUILT_LIPO_FILES}; \ > 60 fi > 61 > 62 > 63 # Copy built non-universal binaries in place > 64 $(UNIVERSAL_COPY_LIST): > 65 BUILT_COPY_FILES="`find $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) 2>/dev/null`"; \ > 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ > 67 for i in $${BUILT_COPY_FILES}; do \ > 68 if [ -f $${i} ]; then \ > 69 $(MKDIR) -p $(shell dirname $@); \ > 70 $(CP) $${i} $@; \ > 71 fi; \ > 72 done; \ > 73 fi > 74 > > This first item will find all object files that were built separately for i386 and amd64 architectures, and then use 'lipo -create -output ?' to create a single universal binary. > > The next phase copies those combined, universal binaries into EXPORT_JRE_LIB_DIR, since the Mac has never had/needed to break out libraries by architecture. > > So, it sounds like when you rebuilt, everything was built into jre/lib/i386 and jre/lib/amd64, but never combined (or, in this case, just copied) into jre/lib, and therefore not found. Yes. Or rather, only the client jvm was combined, but the client jvm isn't copied into the j2sdk-image on mac, so nothing was copied. /Staffan > > Since we only build x86_64 the lipo command is effectively a cp. > > -- Scott > > > On Jun 21, 2012, at 9:54 AM, Staffan Larsen wrote: > >> At least for me, MACOSX_UNIVERSAL ends up being set to true in hotspot/make/bsd/makefiles/defs.make. >> >> Line 186 and forward: >> >> # Universal build settings >> ifeq ($(OS_VENDOR), Darwin) >> # Build universal binaries by default on Mac OS X >> MACOSX_UNIVERSAL = true >> >> If this isn't intentional, then the fix for my problem is something else. >> >> /Staffan >> >> On 21 jun 2012, at 17:53, Henri Gomez wrote: >> >>> universal build, on OSX ? Happy to see that some works/fixes around it :) >>> >>> BTW, how did you get in trouble since universal build is disabled for >>> now unless some code is added to : >>> >>> There was an old thread on jdk7u-dev list and a proposed patch for >>> review (http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch) >>> >>> >>> >>> >>> >>> 2012/6/21 Staffan Larsen : >>>> [adding build-dev and macosx-port-dev] >>>> >>>> On 21 jun 2012, at 14:43, David Holmes wrote: >>>> >>>>> On 21/06/2012 10:30 PM, Staffan Larsen wrote: >>>>>> Do you mean: >>>>>> >>>>>> .PHONY: $(UNIVERSAL_LIPO_LIST) $(UNIVERSAL_COPY_LIST) >>>>> >>>>> Yes. Now they will always be rebuilt. >>>>> >>>>>> Yes, that seems to have the same effect. Probably a better solution. >>>>> >>>>> I think both of these simply mask the real problem. I still don't understand how only some of the list items get "rebuilt". The CR says >>>>> >>>>> "These targets will only be run for the last item in the xxx_LIST variables (which happens to be the client jvm)" >>>>> >>>>> but I don't understand why that is? >>>> >>>> Neither do I. Makefiles is black magic to me. I only discovered that building the complete JDK from the top-level directory did not update the hotspot bits in the j2sdk-image and this was the ultimate cause. >>>> >>>> Here is an updated webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.02/ >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>>> But I also don't understand this universalization process. >>>>> >>>>> BTW you might want to run this past the bsd-port folks (don't recall the exact alias) and/or build-dev. I seem to recall that last time we changed something to do with universal builds it actually broke something. >>>>> >>>>> David >>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> On 21 jun 2012, at 14:12, David Holmes wrote: >>>>>> >>>>>>> Hi Staffan, >>>>>>> >>>>>>> On 21/06/2012 6:33 PM, Staffan Larsen wrote: >>>>>>>> Please review the following fix to makefiles for universal binaries on >>>>>>>> max os x. The idea is to force the target to be executed for all items >>>>>>>> in the list. >>>>>>>> >>>>>>>> Fix contributed by Rickard B?ckman (rbackman). >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.01/ >>>>>>> >>>>>>> I don't understand the problem that this addresses but wouldn't you get the same affect by declaring those targets as PHONY ? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> PS. Unrelated but I was astounded to see that bsd/Makefile and linux/Makefile both have a chunk of code conditional on "ifeq ($(OSNAME),solaris)" Huh! >>>>>> >>>> >> > From david.holmes at oracle.com Thu Jun 21 18:20:45 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Jun 2012 11:20:45 +1000 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> Message-ID: <4FE3C86D.2080008@oracle.com> On 22/06/2012 4:25 AM, Staffan Larsen wrote: > On 21 jun 2012, at 19:12, Scott Kovatch wrote: > >> 54 # Package built libraries in a universal binary >> 55 $(UNIVERSAL_LIPO_LIST): >> 56 BUILT_LIPO_FILES="`find $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) 2>/dev/null`"; \ >> 57 if [ -n "$${BUILT_LIPO_FILES}" ]; then \ >> 58 $(MKDIR) -p $(shell dirname $@); \ >> 59 lipo -create -output $@ $${BUILT_LIPO_FILES}; \ >> 60 fi >> 61 >> 62 >> 63 # Copy built non-universal binaries in place >> 64 $(UNIVERSAL_COPY_LIST): >> 65 BUILT_COPY_FILES="`find $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) 2>/dev/null`"; \ >> 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ >> 67 for i in $${BUILT_COPY_FILES}; do \ >> 68 if [ -f $${i} ]; then \ >> 69 $(MKDIR) -p $(shell dirname $@); \ >> 70 $(CP) $${i} $@; \ >> 71 fi; \ >> 72 done; \ >> 73 fi >> 74 >> >> This first item will find all object files that were built separately for i386 and amd64 architectures, and then use 'lipo -create -output ?' to create a single universal binary. >> >> The next phase copies those combined, universal binaries into EXPORT_JRE_LIB_DIR, since the Mac has never had/needed to break out libraries by architecture. I'm not sure what "next phase" relates to here. The two chunks in the make file operate on distinct sets of files. >> So, it sounds like when you rebuilt, everything was built into jre/lib/i386 and jre/lib/amd64, but never combined (or, in this case, just copied) into jre/lib, and therefore not found. > > Yes. Or rather, only the client jvm was combined, but the client jvm isn't copied into the j2sdk-image on mac, so nothing was copied. Which begs the question: if we only build 64-bit on OSX then how/why is client being built in the first place? David ----- > /Staffan > >> >> Since we only build x86_64 the lipo command is effectively a cp. >> >> -- Scott >> >> >> On Jun 21, 2012, at 9:54 AM, Staffan Larsen wrote: >> >>> At least for me, MACOSX_UNIVERSAL ends up being set to true in hotspot/make/bsd/makefiles/defs.make. >>> >>> Line 186 and forward: >>> >>> # Universal build settings >>> ifeq ($(OS_VENDOR), Darwin) >>> # Build universal binaries by default on Mac OS X >>> MACOSX_UNIVERSAL = true >>> >>> If this isn't intentional, then the fix for my problem is something else. >>> >>> /Staffan >>> >>> On 21 jun 2012, at 17:53, Henri Gomez wrote: >>> >>>> universal build, on OSX ? Happy to see that some works/fixes around it :) >>>> >>>> BTW, how did you get in trouble since universal build is disabled for >>>> now unless some code is added to : >>>> >>>> There was an old thread on jdk7u-dev list and a proposed patch for >>>> review (http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch) >>>> >>>> >>>> >>>> >>>> >>>> 2012/6/21 Staffan Larsen: >>>>> [adding build-dev and macosx-port-dev] >>>>> >>>>> On 21 jun 2012, at 14:43, David Holmes wrote: >>>>> >>>>>> On 21/06/2012 10:30 PM, Staffan Larsen wrote: >>>>>>> Do you mean: >>>>>>> >>>>>>> .PHONY: $(UNIVERSAL_LIPO_LIST) $(UNIVERSAL_COPY_LIST) >>>>>> >>>>>> Yes. Now they will always be rebuilt. >>>>>> >>>>>>> Yes, that seems to have the same effect. Probably a better solution. >>>>>> >>>>>> I think both of these simply mask the real problem. I still don't understand how only some of the list items get "rebuilt". The CR says >>>>>> >>>>>> "These targets will only be run for the last item in the xxx_LIST variables (which happens to be the client jvm)" >>>>>> >>>>>> but I don't understand why that is? >>>>> >>>>> Neither do I. Makefiles is black magic to me. I only discovered that building the complete JDK from the top-level directory did not update the hotspot bits in the j2sdk-image and this was the ultimate cause. >>>>> >>>>> Here is an updated webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.02/ >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>>> But I also don't understand this universalization process. >>>>>> >>>>>> BTW you might want to run this past the bsd-port folks (don't recall the exact alias) and/or build-dev. I seem to recall that last time we changed something to do with universal builds it actually broke something. >>>>>> >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 21 jun 2012, at 14:12, David Holmes wrote: >>>>>>> >>>>>>>> Hi Staffan, >>>>>>>> >>>>>>>> On 21/06/2012 6:33 PM, Staffan Larsen wrote: >>>>>>>>> Please review the following fix to makefiles for universal binaries on >>>>>>>>> max os x. The idea is to force the target to be executed for all items >>>>>>>>> in the list. >>>>>>>>> >>>>>>>>> Fix contributed by Rickard B?ckman (rbackman). >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~sla/7178667/webrev.01/ >>>>>>>> >>>>>>>> I don't understand the problem that this addresses but wouldn't you get the same affect by declaring those targets as PHONY ? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> PS. Unrelated but I was astounded to see that bsd/Makefile and linux/Makefile both have a chunk of code conditional on "ifeq ($(OSNAME),solaris)" Huh! >>>>>>> >>>>> >>> >> > From henri.gomez at gmail.com Fri Jun 22 00:08:57 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 22 Jun 2012 09:08:57 +0200 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: <4FE35520.6080201@oracle.com> References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> <4FE35520.6080201@oracle.com> Message-ID: > Staffan and Henri, > > I think you guys are talking about different levels of support > for MacOS X Universal builds. Staffan's change is in HotSpot > which has supported MacOS X Universal builds for a while now. > > Henri is talking about the forest of repos which does not > currently support MacOS X Universal builds. If HotSpot support MacOS X Universal build, may be I could find here some support to fix a problem I get with my OpenJDK 7 universal build when using 32bits supper (-d32) and server mode (no problem in client mode). ... INFO: AJP13 Listener started: port=8009 juin 22, 2012 9:02:16 AM winstone.Logger logInternal INFO: Winstone Servlet Engine v0.9.10 running: controlPort=disabled juin 22, 2012 9:02:17 AM jenkins.InitReactorRunner$1 onAttained INFO: Started initialization # # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0xa) at pc=0x00f5cb88, pid=495, tid=19971 # # JRE version: 7.0 # Java VM: OpenJDK Server VM (23.2-b05 mixed mode bsd-x86 ) # Problematic frame: # J sun.util.calendar.ZoneInfo.getOffsets(J[II)I # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/henri/Downloads/jenkins/hs_err_pid495.log It is easily reproducible : - Install OpenJDK 7 (from jdk7u-dev built in universal mode) from my googlecode site : http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u5-b30-20120621.dmg) Then : export JAVA_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk/Contents/Home mkdir jenkins cd jenkins curl -L http://mirrors.jenkins-ci.org/war/latest/jenkins.war -o jenkins.war mkdir data export JENKINS_HOME=`pwd`/data java -d32 -jar jenkins.war And there is no problem using -d32 -client or -d64. Any help from Hotspot guys will be very useful since this problem prevent me to ask for universal patch to be reintroduce in OpenJDK 7 and 8. Thanks From dkocher at sudo.ch Fri Jun 22 01:40:20 2012 From: dkocher at sudo.ch (David Kocher) Date: Fri, 22 Jun 2012 10:40:20 +0200 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> <4FE35520.6080201@oracle.com> Message-ID: <275E05A0-0934-4AAF-9C1B-F6B49D6DEC69@sudo.ch> I remember having seen this before [1]. [1] http://java.net/jira/browse/MACOSX_PORT-521 On 22.06.2012, at 09:08, Henri Gomez wrote: >> Staffan and Henri, >> >> I think you guys are talking about different levels of support >> for MacOS X Universal builds. Staffan's change is in HotSpot >> which has supported MacOS X Universal builds for a while now. >> >> Henri is talking about the forest of repos which does not >> currently support MacOS X Universal builds. > > If HotSpot support MacOS X Universal build, may be I could find here > some support to fix a problem I get with my OpenJDK 7 universal build > when using 32bits supper (-d32) and server mode (no problem in client > mode). > > ... > > INFO: AJP13 Listener started: port=8009 > juin 22, 2012 9:02:16 AM winstone.Logger logInternal > INFO: Winstone Servlet Engine v0.9.10 running: controlPort=disabled > juin 22, 2012 9:02:17 AM jenkins.InitReactorRunner$1 onAttained > INFO: Started initialization > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGBUS (0xa) at pc=0x00f5cb88, pid=495, tid=19971 > # > # JRE version: 7.0 > # Java VM: OpenJDK Server VM (23.2-b05 mixed mode bsd-x86 ) > # Problematic frame: > # J sun.util.calendar.ZoneInfo.getOffsets(J[II)I > # > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /Users/henri/Downloads/jenkins/hs_err_pid495.log > > > It is easily reproducible : > > - Install OpenJDK 7 (from jdk7u-dev built in universal mode) from my > googlecode site : > > http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u5-b30-20120621.dmg) > > Then : > > export JAVA_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk/Contents/Home > > mkdir jenkins > cd jenkins > curl -L http://mirrors.jenkins-ci.org/war/latest/jenkins.war -o jenkins.war > mkdir data > export JENKINS_HOME=`pwd`/data > java -d32 -jar jenkins.war > > > And there is no problem using -d32 -client or -d64. > > Any help from Hotspot guys will be very useful since this problem > prevent me to ask for universal patch to be reintroduce in OpenJDK 7 > and 8. > > Thanks > From henri.gomez at gmail.com Fri Jun 22 02:51:59 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 22 Jun 2012 11:51:59 +0200 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: <275E05A0-0934-4AAF-9C1B-F6B49D6DEC69@sudo.ch> References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> <4FE35520.6080201@oracle.com> <275E05A0-0934-4AAF-9C1B-F6B49D6DEC69@sudo.ch> Message-ID: Interesting. Problem disappears at some point but came back when rebuilding in universal mode. It will be interesting to find relative fix, may be it's needed in my patch (mainly back port of macosx-port codes) 2012/6/22 David Kocher : > I remember having seen this before [1]. > > [1] http://java.net/jira/browse/MACOSX_PORT-521 > > On 22.06.2012, at 09:08, Henri Gomez wrote: > >>> Staffan and Henri, >>> >>> I think you guys are talking about different levels of support >>> for MacOS X Universal builds. Staffan's change is in HotSpot >>> which has supported MacOS X Universal builds for a while now. >>> >>> Henri is talking about the forest of repos which does not >>> currently support MacOS X Universal builds. >> >> If HotSpot support MacOS X Universal build, may be I could find here >> some support to fix a problem I get with my OpenJDK 7 universal build >> when using 32bits supper (-d32) and server mode (no problem in client >> mode). >> >> ... >> >> INFO: AJP13 Listener started: port=8009 >> juin 22, 2012 9:02:16 AM winstone.Logger logInternal >> INFO: Winstone Servlet Engine v0.9.10 running: controlPort=disabled >> juin 22, 2012 9:02:17 AM jenkins.InitReactorRunner$1 onAttained >> INFO: Started initialization >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # ?SIGBUS (0xa) at pc=0x00f5cb88, pid=495, tid=19971 >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK Server VM (23.2-b05 mixed mode bsd-x86 ) >> # Problematic frame: >> # J ?sun.util.calendar.ZoneInfo.getOffsets(J[II)I >> # >> # Failed to write core dump. Core dumps have been disabled. To enable >> core dumping, try "ulimit -c unlimited" before starting Java again >> # >> # An error report file with more information is saved as: >> # /Users/henri/Downloads/jenkins/hs_err_pid495.log >> >> >> It is easily reproducible : >> >> - Install OpenJDK 7 (from jdk7u-dev built in universal mode) from my >> googlecode site : >> >> http://openjdk-osx-build.googlecode.com/files/OpenJDK-OSX-1.7-universal-u-jdk-jdk7u5-b30-20120621.dmg) >> >> Then : >> >> export JAVA_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk/Contents/Home >> >> mkdir jenkins >> cd jenkins >> curl -L http://mirrors.jenkins-ci.org/war/latest/jenkins.war -o jenkins.war >> mkdir data >> export JENKINS_HOME=`pwd`/data >> java -d32 -jar jenkins.war >> >> >> And there is no problem using -d32 -client or -d64. >> >> Any help from Hotspot guys will be very useful since this problem >> prevent me to ask for universal patch to be reintroduce in OpenJDK 7 >> and 8. >> >> Thanks >> > From anthony.petrov at oracle.com Fri Jun 22 05:42:12 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 22 Jun 2012 16:42:12 +0400 Subject: [8] Review request for 7170716: JVM crash when opening an AWT app from a registered file. [WAS: Re: Patch for #7170716, crash in OSXAPP_SetApplicationDelegate] In-Reply-To: <4FE32EAA.9030400@oracle.com> References: <4FD890CA.1080803@oracle.com> <4FDB7A41.6080402@oracle.com> <4FDF3E5A.1040102@oracle.com> <0B900A42-3F78-4CA5-A0C3-FB31C4C06D95@apple.com> <4FE32EAA.9030400@oracle.com> Message-ID: <4FE46824.6080700@oracle.com> Hi Marco, The fix is now in the repository: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e7dc778d768e Thank you very much for the contribution. -- best regards, Anthony On 6/21/2012 6:24 PM, Anthony Petrov wrote: > Hi Marco and Mike, > > I've uploaded the latest patch as a webrev to: > > http://cr.openjdk.java.net/~anthony/8-34-crashInSetApplicationDelegate-7170716.3/ > > > The fix still looks fine to me. I'll push it to JDK 8 tomorrow unless > there are any objections. > > -- > best regards, > Anthony > > On 06/21/12 18:11, Marco Dinacci wrote: >> Hi, >> >>> This looks good. I'd also suggest making it an atomic property, and >>> also converting the queue to be a property as well. Using -> >>> notation to directly pick at Obj-C ivars across threads is generally >>> considered bad form. >> >> I agree making the queue a property, I think using "->" for ivars is >> an Oracle convention but I changed the code to use the dot syntax >> since I converted the queue to a property. >> >> Thanks for the comments, attached new patch. >> >> Best, >> Marco From anthony.petrov at oracle.com Fri Jun 22 06:13:19 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 22 Jun 2012 17:13:19 +0400 Subject: [7u6] Review request for 7170716: JVM crash when opening an AWT app from a registered file. Message-ID: <4FE46F6F.6080303@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7170716 at: http://cr.openjdk.java.net/~anthony/7u6-13-crashInSetApplicationDelegate-7170716.0/ This is a 100% direct back-port of the same fix from JDK 8. Please refer to this mail thread for more details: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-June/004400.html -- best regards, Anthony From anthony.petrov at oracle.com Fri Jun 22 06:55:01 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 22 Jun 2012 17:55:01 +0400 Subject: [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing In-Reply-To: <4FE2FAB2.7020105@oracle.com> References: <4FC77592.7020900@oracle.com> <4FDF45AA.4040703@oracle.com> <4FE2FAB2.7020105@oracle.com> Message-ID: <4FE47935.6030100@oracle.com> Hi Sergey, The fix looks fine to me, although I don't see changes to the CPrinterDialogPeer in this webrev. -- best regards, Anthony On 6/21/2012 2:42 PM, Sergey Bylokhov wrote: > Hello, > new version of the fix: > http://cr.openjdk.java.net/~serb/7142091/webrev.01/ > - invokeLater was removed from setVisible and dispose. > - instanceof Graphics2D was added. > > Run some awt related jck and regression tests, no new issues found. > > On 18.06.2012 19:13, Artem Ananiev wrote: >> Hi, Sergey, >> >> some minor comments (may be unrelated to the fix): >> >> 1. LWComponentPeer.setVisible() can be made final. Do expect any >> subclass to override it instead of setVisibleImpl()? > It is overriden in CPrinterDialogPeer. >> >> 2. invokeLater() in LWWindowPeer.setVisibleImpl(): I realize this is >> really painful issue, but I'd vote for removing this workaround. It >> would result in faster startup (although, the window will be solid >> gray for some time), and make LWAWT code similar to what we have on >> other platforms. > removed >> >> Then next step will to minimize the delay between showing the window >> and painting its content. >> >> 3. LWWindowPeer.replaceSurfaceData(): what are benefits of >> setBackground() + clearRect() over setColor() + fillRect()? Although >> we always expect the Graphics object to be Graphics2D instance, this >> unconditional cast doesn't look great. > done >> >> Thanks, >> >> Artem >> >> On 5/31/2012 5:43 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> Please review the fix. >>> >>> Notes from the bug and comments: >>> 1. setVisible() should be called at the end of the peers initialization. >>> We can move super.initialize() to the end of the peers initializations. >>> Initialize() was split to initialize() and initializeImpl(). In the >>> initialize() we call initializeImpl and then we call to setVisible(). >>> initializeImpl overridden in subclasses. >>> >>> 2. Invokelater in the initialization/disposing is a tricky. >>> Left it as is. Probably later it will be changed. Comments was updated. >>> >>> 3. replaceSurfacedata() should be moved outside of >>> LWWindowPeer.setVisible() >>> Done. Also duplicate code was extracted to setVisible() method which >>> call setVisibleImpl(). >>> >>> 4. Backbuffer in replaceSurfacedata() should be initialized by clearRect >>> instead of fillrect(composite is important). >>> Done. related to composite. >>> >>> 5. During lwwindowpeer initialization we call two similar methods >>> nativeSetNSWindowAlpha() and setAlphaValue(). >>> nativeSetNSWindowAlpha() removed from CPlatformWindow.java. >>> >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7142091/webrev.00/ >>> > > From anthony.petrov at oracle.com Fri Jun 22 08:55:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 22 Jun 2012 19:55:49 +0400 Subject: [8] Review request for 7174718: [macosx] Regression in 7u6 b12: PopupFactory leaks DefaultFrames. Message-ID: <4FE49585.40206@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7174718 at: http://cr.openjdk.java.net/~anthony/8-37-AWTWindowLeak-7174718.0/ This fix does the following: 1. Restores the correct CFRetainedResource's logic for CPlatformWindow. 2. Releases an instance of AWTWindow when disposing the peer to release a reference to the NSWindow object held in the nsWindow property of AWTWndow. 3. After creating an NSWindow object, it is released because the nsWindow property retains it already. The PopupFactory test passes after these changes. -- best regards, Anthony From xueming.shen at oracle.com Fri Jun 22 10:01:10 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 22 Jun 2012 10:01:10 -0700 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X Message-ID: <4FE4A4D6.4070100@oracle.com> Hi Here is the proposed change to support Unicode nfd/nfc and case insensitive file path on MacOSX file system. 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] While these two bug reports are only against java.io, we have the same issue in javax.nio.file. Here is the webrev http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ Here is the brief summary of the changes java.io.File: (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means we are now passing nfc/composite characters directly into macosx file system APIs without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses nfd. (2) normalize the resulting file name from macosx fs APIs from nfd->nfd before passing back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name (as "usual") for java.io classes/APIs. (3) fs.compare()/hashCode() was updated to be case insensitive (4) hasCode() was updated to use the new String.hash32(). java.nio.file: (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to update those BsdFile... classes directly to address the macosx specific issues. But given there might be developers over there might work on open jdk BSD port and have dependency on these classes, it might be desirable to have another separate layer of MacOSXFile... classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and MacOSXFileSystem. (6) the "main" changes are in MacOSXFileSystem, in which the corresponding methods were added to handle, case insensitive and nfd<=>nfc normalization, including the pathmatcher. (7) compare is now are case-insensitive (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. Though lots of files have been touched, but the line of changes are actually relatively small. The proposed change only deals with the default case-sensitiveness seting, which is case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the mounted vol to be case-sensitive. A possible approach is to have some extra FileStore attributes, such as a isCaseSensitive and to use case sensitive compare/equal on such fs, but this can be dealt with separately later. Thanks, -Sherman From naoto.sato at oracle.com Fri Jun 22 17:36:27 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 22 Jun 2012 17:36:27 -0700 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE4A4D6.4070100@oracle.com> References: <4FE4A4D6.4070100@oracle.com> Message-ID: <4FE50F8B.5090209@oracle.com> Hi Sherman, There are several places where Locale.ENGLISH is used for locale neutral processing. You could instead use Locale.ROOT for that purpose. Naoto On 12/06/22 10:01, Xueming Shen wrote: > Hi > > Here is the proposed change to support Unicode nfd/nfc and case insensitive > file path on MacOSX file system. > > 7130915: File.equals does not give expected results when path contains > Non-English characters on Mac OS X > 7168427: FileInputStream cannot open file where the file path contains > asian characters [macosx] > > While these two bug reports are only against java.io, we have the same > issue in javax.nio.file. > Here is the webrev > > http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ > > Here is the brief summary of the changes > > java.io.File: > (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which > means > we are now passing nfc/composite characters directly into macosx file > system APIs > without normalize them to nfd. It appears macosx fs APIs do take nfc, > though it uses > nfd. > > (2) normalize the resulting file name from macosx fs APIs from nfd->nfd > before passing > back to java.io.File (File.list() and canonicalize()), so we deal with > nfdc file name > (as "usual") for java.io classes/APIs. > > (3) fs.compare()/hashCode() was updated to be case insensitive > > (4) hasCode() was updated to use the new String.hash32(). > > java.nio.file: > > (5) added a setof MacOSXFile... on top of existing BsdFile... classes. > An alternative is to > update those BsdFile... classes directly to address the macosx specific > issues. But given > there might be developers over there might work on open jdk BSD port and > have dependency > on these classes, it might be desirable to have another separate layer > of MacOSXFile... > classes. So now the default FileSystem/Provider is > MacOSXFileSystemProvider and > MacOSXFileSystem. > > (6) the "main" changes are in MacOSXFileSystem, in which the > corresponding methods > were added to handle, case insensitive and nfd<=>nfc normalization, > including the > pathmatcher. > > (7) compare is now are case-insensitive > > (8) hashCode is now murmur3_32(), this is true for all > Solaris/Unix/Linux and maxosx. > > > Though lots of files have been touched, but the line of changes are > actually relatively > small. > > The proposed change only deals with the default case-sensitiveness > seting, which is > case insensitive. On MaxOSX, you actually can configure the HFS+ file > system or the > mounted vol to be case-sensitive. A possible approach is to have some > extra FileStore > attributes, such as a isCaseSensitive and to use case sensitive > compare/equal on > such fs, but this can be dealt with separately later. > > Thanks, > -Sherman From jason.uh at oracle.com Fri Jun 22 18:01:00 2012 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 22 Jun 2012 18:01:00 -0700 Subject: [8] Review request for 7162111 change tests run in headless mode [macosx] Message-ID: <4FE5154C.2090703@oracle.com> Hi, This fix was for regression tests failing on Mac OS X on remotely executed environments. The changed tests now run in headless mode and have been taken off the Problem List. Webrev: http://cr.openjdk.java.net/~juh/7162111/webrev.00/ The CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162111 Note that test/demo/jvmti/mtrace/TraceJFrame.java was not fixed here because headless mode is not supported for JFrame. A separate CR will be created for this. Thanks, Jason From xueming.shen at oracle.com Fri Jun 22 21:09:48 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 22 Jun 2012 21:09:48 -0700 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: References: <4FE4A4D6.4070100@oracle.com> Message-ID: <4FE5418C.1040707@oracle.com> On 6/22/12 11:02 AM, Mike Duigou wrote: > On Jun 22 2012, at 10:01 , Xueming Shen wrote: > >> Hi >> >> Here is the proposed change to support Unicode nfd/nfc and case insensitive >> file path on MacOSX file system. >> >> 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X >> 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] >> >> While these two bug reports are only against java.io, we have the same issue in javax.nio.file. >> Here is the webrev >> >> (3) fs.compare()/hashCode() was updated to be case insensitive > Won't this cause problems on case sensitive file systems? The MacOSX filesystem is by default case insensitive but case sensitive file systems are not entirely uncommon. > > Yes, it might/will cause problem on case sensitive hfs+ file system, but this use scenario is not this patch tries to address. On MacOSX you can format one of your disks to be case sensitive (create a new disk image and set the format to be case sensitive, via the Disk Utility, for example) or you might be able to configure your whole HFS+ file system to be case sensitive, which means the case sensitiveness is actually one of the attributes of the volume (FileStore, in JSR203's term), not the whole file system. But the file system has its default setting regarding the path case sensitiveness. On HFS+ it's case insensitive. This is actually not a unique problem of MacOS file system, you can mount a Windows FAT32 drive on LInux or vise versa, it's a difficult issue. The JSR-203's solution is to use the Path + FileSystem to "modle and be consistent with the platform's virtual file system, not the specific underlying file system", so this means on Unix/Linux, the path matching is case sensitive, on Windows it's case insensitive and on MacOSX, we go with the default case_insensitive. That said, an alternative is to set the default case sensitiveness behavior bases on the setting of the volume that the default file system is mounted on, if the root is on a volume that has case sensitive, then the MaxOSXFileSystem is case sensitive. The code to detect the volume's case sensitive setting is currently committed out. Alan and I chatted about this, we agreed that this is out of the scope of this patch, we can leave that for a future enhancement. -Sherman From Alan.Bateman at oracle.com Sat Jun 23 00:28:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Jun 2012 08:28:25 +0100 Subject: [8] Review request for 7162111 change tests run in headless mode [macosx] In-Reply-To: <4FE5154C.2090703@oracle.com> References: <4FE5154C.2090703@oracle.com> Message-ID: <4FE57019.9090905@oracle.com> On 23/06/2012 02:01, Jason Uh wrote: > Hi, > > This fix was for regression tests failing on Mac OS X on remotely > executed environments. The changed tests now run in headless mode and > have been taken off the Problem List. > > Webrev: http://cr.openjdk.java.net/~juh/7162111/webrev.00/ > The CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162111 > > Note that test/demo/jvmti/mtrace/TraceJFrame.java was not fixed here > because headless mode is not supported for JFrame. A separate CR will > be created for this. > > Thanks, > Jason It's good to see these tests changed to run headless and will make the test execution much more reliable. Aside from the mtrace demo there are a couple of other tests that periodically hang initializing AWT, at least when running via ssh and then depending on whether someone is logged in and other configuration settings. Some of the shell tests for serialization come to mind (BTW: no problem doing that via a separate bug, just mentioning that there are other tests that are problems too). One question, and this may be a question for Artem or others, is that in CommonSetup.sh you set AWT_TOOLKIT=XToolkit. Is that right? -Alan. From Alan.Bateman at oracle.com Sat Jun 23 04:30:22 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Jun 2012 12:30:22 +0100 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: References: <4FE4A4D6.4070100@oracle.com> Message-ID: <4FE5A8CE.4030900@oracle.com> On 22/06/2012 19:02, Mike Duigou wrote: > : > > Won't this cause problems on case sensitive file systems? The MacOSX filesystem is by default case insensitive but case sensitive file systems are not entirely uncommon. > It shouldn't cause any issues accessing files, this is really just about equals, sorting, and path matching. I think it requires a bit of thought as to whether to change this because Apple's JDK6 and older releases does not appear to have changed File#equals. In any case, just to put some context on Sherman's changes, this really just another installation of the port to Mac as this area was not completely ported. In that context then the changes to fix the normalization issues are very welcome. Other missing pieces in this area included the watch service, and also a FileTypeDetector implementation. -Alan. From mik3hall at gmail.com Sat Jun 23 07:44:20 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 23 Jun 2012 09:44:20 -0500 Subject: method name Message-ID: Seems a little trivial but also odd enough to ask about. I'm not trying for a gotcha or anything but I'm seeing getPathForExecptionMessage() and it seems like that should be getPathForExceptionMessage() shouldn't it? Otherwise, Execption is a word I'm unfamiliar with? I'm seeing this in a couple different source versions of the project and a number of different files. UnixException SolarisWatchService UnixPath LinuxWatchService ?. From Alan.Bateman at oracle.com Sat Jun 23 11:26:16 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Jun 2012 19:26:16 +0100 Subject: method name In-Reply-To: References: Message-ID: <4FE60A48.8030207@oracle.com> On 23/06/2012 15:44, Michael Hall wrote: > Seems a little trivial but also odd enough to ask about. I'm not trying for a gotcha or anything but I'm seeing > getPathForExecptionMessage() > > and it seems like that should be getPathForExceptionMessage() > shouldn't it? Yes, it must have been renamed in error at some point. I would suggest submitting a bug and bring a patch to nio-dev to fix this (it's an internal method, not a public API so there isn't any reason for to fix it). -Alan From Alan.Bateman at oracle.com Sat Jun 23 11:52:47 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Jun 2012 19:52:47 +0100 Subject: method name In-Reply-To: <4FE60A48.8030207@oracle.com> References: <4FE60A48.8030207@oracle.com> Message-ID: <4FE6107F.5090604@oracle.com> I've created a bug so that this isn't forgotten: 7179305: (fs) Method name sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled -Alan From mik3hall at gmail.com Sat Jun 23 13:04:54 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 23 Jun 2012 15:04:54 -0500 Subject: method name In-Reply-To: <4FE60A48.8030207@oracle.com> References: <4FE60A48.8030207@oracle.com> Message-ID: On Jun 23, 2012, at 1:26 PM, Alan Bateman wrote: > On 23/06/2012 15:44, Michael Hall wrote: >> Seems a little trivial but also odd enough to ask about. I'm not trying for a gotcha or anything but I'm seeing >> getPathForExecptionMessage() >> >> and it seems like that should be getPathForExceptionMessage() >> shouldn't it? > Yes, it must have been renamed in error at some point. I would suggest submitting a bug and bring a patch to nio-dev to fix this (it's an internal method, not a public API so there isn't any reason for to fix it). One thing on this. With these nio.2 API's going in a more extensible direction. Wouldn't it make sense to have some of these classes more accessible. For example, it looks like the watch service api's follow a similar pattern of including a Runnable Poller class to handle the threaded concerns. These extend a inaccessible, non-public, internal AbstractPoller class. Getting the threaded part of the code right for performance and scalability concerns would be an important concern in attempting a 3rd party watch services implementation. I would and am imagining. Modeling the existing implementations as much as possible would be helpful? From Alan.Bateman at oracle.com Sat Jun 23 13:44:36 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Jun 2012 21:44:36 +0100 Subject: method name In-Reply-To: References: <4FE60A48.8030207@oracle.com> Message-ID: <4FE62AB4.5010809@oracle.com> On 23/06/2012 21:04, Michael Hall wrote: > : > One thing on this. With these nio.2 API's going in a more extensible direction. Wouldn't it make sense to have some of these classes more accessible. > For example, it looks like the watch service api's follow a similar pattern of including a Runnable Poller class to handle the threaded concerns. These extend a inaccessible, non-public, internal AbstractPoller class. Getting the threaded part of the code right for performance and scalability concerns would be an important concern in attempting a 3rd party watch services implementation. I would and am imagining. Modeling the existing implementations as much as possible would be helpful? cc'ing nio-dev as that is the right place for this discussion. The extensions points are via the provider mechanism, see java.nio.file.spi.FileSystemProvider. I can't quite tell what you are doing but if you are looking to "extend" the default provider without changing it then you will need to create your own FileSystemProvider that sits on what would otherwise be the default provider - see the javadoc in FileSystems.getDefault for the details. Also if you rummage around in the tests then you'll find a skeleton implementation that might get your started. The AbstractWatch* and AbstractPoller classes in sun.nio.fs provide the base classes for the 4 implementations that we currently have in OpenJDK. I would be very slow about moving them to java.nio.file.spi (which I think is what you are suggesting) because it is a relatively niche area and likely only interesting when porting to a new platform that has such a facility (many operating systems do not have anything and for those platforms we have the portable PollingWatchService). -Alan. From mik3hall at gmail.com Sat Jun 23 14:14:03 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 23 Jun 2012 16:14:03 -0500 Subject: method name In-Reply-To: <4FE62AB4.5010809@oracle.com> References: <4FE60A48.8030207@oracle.com> <4FE62AB4.5010809@oracle.com> Message-ID: On Jun 23, 2012, at 3:44 PM, Alan Bateman wrote: > On 23/06/2012 21:04, Michael Hall wrote: >> : >> One thing on this. With these nio.2 API's going in a more extensible direction. Wouldn't it make sense to have some of these classes more accessible. >> For example, it looks like the watch service api's follow a similar pattern of including a Runnable Poller class to handle the threaded concerns. These extend a inaccessible, non-public, internal AbstractPoller class. Getting the threaded part of the code right for performance and scalability concerns would be an important concern in attempting a 3rd party watch services implementation. I would and am imagining. Modeling the existing implementations as much as possible would be helpful? > cc'ing nio-dev as that is the right place for this discussion. Fine. I probably should of put it there. I just haven't frequented there as much as OS X port. > > The extensions points are via the provider mechanism, see java.nio.file.spi.FileSystemProvider. I can't quite tell what you are doing but if you are looking to "extend" the default provider without changing it then you will need to create your own FileSystemProvider that sits on what would otherwise be the default provider - see the javadoc in FileSystems.getDefault for the details. Also if you rummage around in the tests then you'll find a skeleton implementation that might get your started. I have the FileSystemProvider mechanism (fwiw [1]), that I used to provide some extended functionality for Mac specific file attributes (Current api's - Finder, Launch Services, NSFileManager derived, and xattr type extended attributes). I was thinking about a possibly custom provider where sync type functionality would be nice. I immediately thought - well this is where watch services is nice now isn't it? I remembered you had mentioned that OS X could use something better than the current polling api for doing this. kqueue I think you mentioned although I've seen it also said that for OS X FSEvents might be a alternative worth considering. I thought I might take a shot at a 'naive' implementation of these two. A learning experience for the api. > > The AbstractWatch* and AbstractPoller classes in sun.nio.fs provide the base classes for the 4 implementations that we currently have in OpenJDK. I would be very slow about moving them to java.nio.file.spi (which I think is what you are suggesting) because it is a relatively niche area and likely only interesting when porting to a new platform that has such a facility (many operating systems do not have anything and for those platforms we have the portable PollingWatchService). Yes, my purpose is for the OS X platform. Although it did occur to me that both kqueue and possibly FSEvents could be cross-platform at least to Unix type systems. > > -Alan. [1] http://www195.pair.com/mik3hall/index.html#macattr From dkocher at sudo.ch Sun Jun 24 07:50:21 2012 From: dkocher at sudo.ch (David Kocher) Date: Sun, 24 Jun 2012 16:50:21 +0200 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE4A4D6.4070100@oracle.com> References: <4FE4A4D6.4070100@oracle.com> Message-ID: <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> Will this address issue MACOSX_PORT-165 [1]? [1] http://java.net/jira/browse/MACOSX_PORT-165 -- David On 22.06.2012, at 19:01, Xueming Shen wrote: > Hi > > Here is the proposed change to support Unicode nfd/nfc and case insensitive > file path on MacOSX file system. > > 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X > 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] > > While these two bug reports are only against java.io, we have the same issue in javax.nio.file. > Here is the webrev > > http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ > > Here is the brief summary of the changes > > java.io.File: > (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means > we are now passing nfc/composite characters directly into macosx file system APIs > without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses > nfd. > > (2) normalize the resulting file name from macosx fs APIs from nfd->nfd before passing > back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name > (as "usual") for java.io classes/APIs. > > (3) fs.compare()/hashCode() was updated to be case insensitive > > (4) hasCode() was updated to use the new String.hash32(). > > java.nio.file: > > (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to > update those BsdFile... classes directly to address the macosx specific issues. But given > there might be developers over there might work on open jdk BSD port and have dependency > on these classes, it might be desirable to have another separate layer of MacOSXFile... > classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and > MacOSXFileSystem. > > (6) the "main" changes are in MacOSXFileSystem, in which the corresponding methods > were added to handle, case insensitive and nfd<=>nfc normalization, including the > pathmatcher. > > (7) compare is now are case-insensitive > > (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. > > > Though lots of files have been touched, but the line of changes are actually relatively > small. > > The proposed change only deals with the default case-sensitiveness seting, which is > case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the > mounted vol to be case-sensitive. A possible approach is to have some extra FileStore > attributes, such as a isCaseSensitive and to use case sensitive compare/equal on > such fs, but this can be dealt with separately later. > > Thanks, > -Sherman > From xueming.shen at oracle.com Sun Jun 24 09:58:01 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 24 Jun 2012 09:58:01 -0700 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> Message-ID: <4FE74719.8080709@oracle.com> Yes, I believe the issue described in MACOSX_PORT-165 is the same issue this patch is trying to solve. Btw, it appears there are typos in the note(2), my mini keyboard obviously is too sticky:-) (2) normalize the resulting file name from macosx fs APIs from nfd->nfc before passing back to java.io.File (File.list() and canonicalize()), so we deal with nfc file name (as "usual") for java.io classes/APIs. -sherman On 6/24/12 7:50 AM, David Kocher wrote: > Will this address issue MACOSX_PORT-165 [1]? > > [1] http://java.net/jira/browse/MACOSX_PORT-165 > > -- David > > On 22.06.2012, at 19:01, Xueming Shen wrote: > >> Hi >> >> Here is the proposed change to support Unicode nfd/nfc and case insensitive >> file path on MacOSX file system. >> >> 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X >> 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] >> >> While these two bug reports are only against java.io, we have the same issue in javax.nio.file. >> Here is the webrev >> >> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ >> >> Here is the brief summary of the changes >> >> java.io.File: >> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means >> we are now passing nfc/composite characters directly into macosx file system APIs >> without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses >> nfd. >> >> (2) normalize the resulting file name from macosx fs APIs from nfd->nfd before passing >> back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name >> (as "usual") for java.io classes/APIs. >> >> (3) fs.compare()/hashCode() was updated to be case insensitive >> >> (4) hasCode() was updated to use the new String.hash32(). >> >> java.nio.file: >> >> (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to >> update those BsdFile... classes directly to address the macosx specific issues. But given >> there might be developers over there might work on open jdk BSD port and have dependency >> on these classes, it might be desirable to have another separate layer of MacOSXFile... >> classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and >> MacOSXFileSystem. >> >> (6) the "main" changes are in MacOSXFileSystem, in which the corresponding methods >> were added to handle, case insensitive and nfd<=>nfc normalization, including the >> pathmatcher. >> >> (7) compare is now are case-insensitive >> >> (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. >> >> >> Though lots of files have been touched, but the line of changes are actually relatively >> small. >> >> The proposed change only deals with the default case-sensitiveness seting, which is >> case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the >> mounted vol to be case-sensitive. A possible approach is to have some extra FileStore >> attributes, such as a isCaseSensitive and to use case sensitive compare/equal on >> such fs, but this can be dealt with separately later. >> >> Thanks, >> -Sherman >> From leonid.romanov at oracle.com Sun Jun 24 11:33:37 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Sun, 24 Jun 2012 22:33:37 +0400 Subject: [7u6] Review request for 7179349: [macosx] Java processes on Mac should not use default Apple icon Message-ID: <8A0DEC93-4B33-4830-8243-05B1A752BD6C@oracle.com> Hi, Please review a fix for 7179349: [macosx] Java processes on Mac should not use default Apple icon. Currently, OpenJDK uses Apple supplied icon found in /System/Library/Frameworks/JavaVM.framework as the default icon for Java apps. This fix makes it use an icon that comes with OpenJDK instead. We do it by converting the icon file to an .h file which contains the icon data as an array of bytes and then including the .h file where the icon data is needed. So, we basically compile in the icon data into the binaries. Such approach was chosen because this is what we do on other platforms (Linux, Windows) and because it is the easiest way to access the icon data during runtime. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179349 Webrev: http://cr.openjdk.java.net/~leonidr/7179349/webrev.00/ Note: this is a freshly filled bug, so my understanding is it may take a while until it becomes visible via bug's link above. Thanks, Leonid. From dkocher at sudo.ch Mon Jun 25 00:20:11 2012 From: dkocher at sudo.ch (David Kocher) Date: Mon, 25 Jun 2012 09:20:11 +0200 Subject: Maintenance of issues in Message-ID: Contrary to the activity on this list and references to bugs.sun.com, I see no significant activity in the bug tracker [1] I follow. Do the issues listed there get updated and is this even relevant anymore or has everything moved to bugs.sun.com? -- David > http://java.net/jira/browse/MACOSX_PORT From staffan.larsen at oracle.com Mon Jun 25 01:36:25 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Jun 2012 10:36:25 +0200 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: <4FE3C86D.2080008@oracle.com> References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> <4FE3C86D.2080008@oracle.com> Message-ID: <47E96839-1BDB-42F2-BC45-D1A98559813C@oracle.com> >>> So, it sounds like when you rebuilt, everything was built into jre/lib/i386 and jre/lib/amd64, but never combined (or, in this case, just copied) into jre/lib, and therefore not found. >> >> Yes. Or rather, only the client jvm was combined, but the client jvm isn't copied into the j2sdk-image on mac, so nothing was copied. > > Which begs the question: if we only build 64-bit on OSX then how/why is client being built in the first place? I should have said: "only the client jvm was _attempted_ to be combined". In fact, the client does not exist, but the universalize makefiles are written to handle client if it did exist. So what happened was: - the product jvm was built - it was copied to the import jdk (into jre/lib/amd64/server/) by the generic_export target - the universalize makefile tried to take the client jvm and universalize it into jre/lib/client/ (notice that there is no amd64 directory level on mac) - the universalize makefile removes all {amd64,i386} directories What should have happened: - the product jvm was built - it was copied to the import jdk (into jre/lib/amd64/server/) by the generic_export target - the universalize makefile makes a universal binary of any existing jvms (client or server) - the universalize makefile copies these jvms into jre/lib/{server,client} - the universalize makefile removes all {amd64,i386} directories But because the targets weren't .PHONY, the third step above failed. I hope that explains the problem in more detail. Who wants to be put down as reviewer? Thanks, /Staffan From Sergey.Bylokhov at oracle.com Mon Jun 25 03:42:04 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Jun 2012 03:42:04 -0700 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FD895F1.3040605@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FD895F1.3040605@oracle.com> Message-ID: <4FE8407C.7060103@oracle.com> Hi, Artem, Anthony. New version of the fix: http://cr.openjdk.java.net/~serb/7124244/webrev.01 13.06.2012 06:30, Artem Ananiev wrote: > Hi, Sergey, > > a few minor comments: > > 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in > CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are > corresponding checks just above. done. > > 2. invalidateShadow() is not used in sun.lwawt, so it can be just a > method in CPlatformWindow. BTW, do you have any ideas, why CGLayer > holds a reference to LWWindowPeer, not to CPlatformWindow? done. > > 3. As we don't expect isSwingBackbufferTranslucencySupported() to > return different values, it would be fine to call it only once to > avoid possible perf regressions. done. > > Thanks, > > Artem > > On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Please review the fix. >> >> Shaped window was implemented as a translucent window with constrained >> graphics. Now translucent window doesn't use separate BufferedImage as a >> back buffer. Also alpha value for the swing back buffer was >> enabled(Shared code changed). >> Note that shaped windows are affected by this bugs: >> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >> - Shadows disappear. >> - Transparent areas aren't transparent to mouse clicks. >> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >> - Opacity does not work for non opaque windows. >> >> Any suggestions are welcome. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >> -- Best regards, Sergey. From artem.ananiev at oracle.com Mon Jun 25 05:28:00 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 25 Jun 2012 16:28:00 +0400 Subject: [7u6] Review request for 7170716: JVM crash when opening an AWT app from a registered file. In-Reply-To: <4FE46F6F.6080303@oracle.com> References: <4FE46F6F.6080303@oracle.com> Message-ID: <4FE85950.2040007@oracle.com> Looks fine. Thanks, Artem On 6/22/2012 5:13 PM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7170716 at: > > http://cr.openjdk.java.net/~anthony/7u6-13-crashInSetApplicationDelegate-7170716.0/ > > > This is a 100% direct back-port of the same fix from JDK 8. Please refer > to this mail thread for more details: > > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-June/004400.html > > > -- > best regards, > Anthony From artem.ananiev at oracle.com Mon Jun 25 05:38:57 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 25 Jun 2012 16:38:57 +0400 Subject: [8] Review request for 7174718: [macosx] Regression in 7u6 b12: PopupFactory leaks DefaultFrames. In-Reply-To: <4FE49585.40206@oracle.com> References: <4FE49585.40206@oracle.com> Message-ID: <4FE85BE1.1000104@oracle.com> Looks fine. Thanks, Artem On 6/22/2012 7:55 PM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7174718 at: > > http://cr.openjdk.java.net/~anthony/8-37-AWTWindowLeak-7174718.0/ > > This fix does the following: > > 1. Restores the correct CFRetainedResource's logic for CPlatformWindow. > > 2. Releases an instance of AWTWindow when disposing the peer to release > a reference to the NSWindow object held in the nsWindow property of > AWTWndow. > > 3. After creating an NSWindow object, it is released because the > nsWindow property retains it already. > > The PopupFactory test passes after these changes. > > -- > best regards, > Anthony From anthony.petrov at oracle.com Mon Jun 25 06:02:50 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 25 Jun 2012 17:02:50 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FE8407C.7060103@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FD895F1.3040605@oracle.com> <4FE8407C.7060103@oracle.com> Message-ID: <4FE8617A.90402@oracle.com> Hi Sergey, The fix looks good overall. Just two comments: 1. src/macosx/classes/sun/lwawt/LWWindowPeer.java > 987 if (oldBB != null) { > 988 backBuffer = (BufferedImage) platformWindow.createBackBuffer(); Since we never create a back buffer in JDK 8 currently, I suggest to comment this code out, and add a remark mentioning a CR number that should make use of the code in the future. 2. src/share/classes/javax/swing/RepaintManager.java > 1501 Graphics2D g2d = (Graphics2D) osg.create(); > 1502 g2d.setBackground(c.getBackground()); > 1503 g2d.clearRect(x, y, bw, bh); > 1504 g2d.dispose(); Please use the try {} finally {} pattern to dispose the G2D object. The same comment applies to the lines 1510-1513. -- best regards, Anthony On 06/25/12 14:42, Sergey Bylokhov wrote: > Hi, Artem, Anthony. > New version of the fix: > http://cr.openjdk.java.net/~serb/7124244/webrev.01 > > 13.06.2012 06:30, Artem Ananiev wrote: >> Hi, Sergey, >> >> a few minor comments: >> >> 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in >> CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are >> corresponding checks just above. > done. >> >> 2. invalidateShadow() is not used in sun.lwawt, so it can be just a >> method in CPlatformWindow. BTW, do you have any ideas, why CGLayer >> holds a reference to LWWindowPeer, not to CPlatformWindow? > done. >> >> 3. As we don't expect isSwingBackbufferTranslucencySupported() to >> return different values, it would be fine to call it only once to >> avoid possible perf regressions. > done. >> >> Thanks, >> >> Artem >> >> On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> Please review the fix. >>> >>> Shaped window was implemented as a translucent window with constrained >>> graphics. Now translucent window doesn't use separate BufferedImage as a >>> back buffer. Also alpha value for the swing back buffer was >>> enabled(Shared code changed). >>> Note that shaped windows are affected by this bugs: >>> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >>> - Shadows disappear. >>> - Transparent areas aren't transparent to mouse clicks. >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >>> - Opacity does not work for non opaque windows. >>> >>> Any suggestions are welcome. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >>> > > From anthony.petrov at oracle.com Mon Jun 25 06:19:50 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 25 Jun 2012 17:19:50 +0400 Subject: [8] Review request for 7162111 change tests run in headless mode [macosx] In-Reply-To: <4FE57019.9090905@oracle.com> References: <4FE5154C.2090703@oracle.com> <4FE57019.9090905@oracle.com> Message-ID: <4FE86576.8020407@oracle.com> Hi Alan and Jason, On 06/23/12 11:28, Alan Bateman wrote: > On 23/06/2012 02:01, Jason Uh wrote: >> This fix was for regression tests failing on Mac OS X on remotely >> executed environments. The changed tests now run in headless mode and >> have been taken off the Problem List. >> >> Webrev: http://cr.openjdk.java.net/~juh/7162111/webrev.00/ >> The CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162111 >> >> Note that test/demo/jvmti/mtrace/TraceJFrame.java was not fixed here >> because headless mode is not supported for JFrame. A separate CR will >> be created for this. >> > It's good to see these tests changed to run headless and will make the > test execution much more reliable. Aside from the mtrace demo there are > a couple of other tests that periodically hang initializing AWT, at > least when running via ssh and then depending on whether someone is > logged in and other configuration settings. Some of the shell tests for > serialization come to mind (BTW: no problem doing that via a separate > bug, just mentioning that there are other tests that are problems too). > > One question, and this may be a question for Artem or others, is that in > CommonSetup.sh you set AWT_TOOLKIT=XToolkit. Is that right? I don't think we need to force XToolkit on the Mac. We don't quite support it on that platform actually. The normal headless CToolkit should work just fine. Could you please revert the changes to CommonSetup.sh and verify if the tests pass? -- best regards, Anthony From Sergey.Bylokhov at oracle.com Mon Jun 25 06:24:48 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Jun 2012 06:24:48 -0700 Subject: [8] Review request for 7174718: [macosx] Regression in 7u6 b12: PopupFactory leaks DefaultFrames. In-Reply-To: <4FE49585.40206@oracle.com> References: <4FE49585.40206@oracle.com> Message-ID: <4FE866A0.5040909@oracle.com> Hi, Anthony. Fix looks good to me. 22.06.2012 08:55, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7174718 > at: > > http://cr.openjdk.java.net/~anthony/8-37-AWTWindowLeak-7174718.0/ > > This fix does the following: > > 1. Restores the correct CFRetainedResource's logic for CPlatformWindow. > > 2. Releases an instance of AWTWindow when disposing the peer to > release a reference to the NSWindow object held in the nsWindow > property of AWTWndow. > > 3. After creating an NSWindow object, it is released because the > nsWindow property retains it already. > > The PopupFactory test passes after these changes. > > -- > best regards, > Anthony -- Best regards, Sergey. From leonid.romanov at oracle.com Mon Jun 25 06:50:36 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 25 Jun 2012 17:50:36 +0400 Subject: [7u6] Review request for 7170716: JVM crash when opening an AWT app from a registered file. In-Reply-To: <4FE46F6F.6080303@oracle.com> References: <4FE46F6F.6080303@oracle.com> Message-ID: <01157D7B-2F73-4C55-A22C-B8A70BF13994@oracle.com> Looks fine. On 22.06.2012, at 17:13, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7170716 at: > > http://cr.openjdk.java.net/~anthony/7u6-13-crashInSetApplicationDelegate-7170716.0/ > > This is a 100% direct back-port of the same fix from JDK 8. Please refer to this mail thread for more details: > > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-June/004400.html > > -- > best regards, > Anthony From anthony.petrov at oracle.com Mon Jun 25 07:08:00 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 25 Jun 2012 18:08:00 +0400 Subject: [7u6] Review request for 7179349: [macosx] Java processes on Mac should not use default Apple icon In-Reply-To: <8A0DEC93-4B33-4830-8243-05B1A752BD6C@oracle.com> References: <8A0DEC93-4B33-4830-8243-05B1A752BD6C@oracle.com> Message-ID: <4FE870C0.1060801@oracle.com> Hi Leonid, Where does the JavaApp.icns file come from? I can't see it in the webrev. src/macosx/native/sun/osxapp/NSApplicationAWT.m > 269 NSString* bundleIcon = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleIconFile"]; > 270 if (bundleIcon == nil && iconImage == nil) { We could probably rewrite this as: if (iconImage == nil) { NSString *bundleIcon... if (bundleIcon == nil) { ... to avoid accessing the bundle when it is unneeded. The fix looks good otherwise. -- best regards, Anthony On 06/24/12 22:33, Leonid Romanov wrote: > Hi, > Please review a fix for 7179349: [macosx] Java processes on Mac should not use default Apple icon. > Currently, OpenJDK uses Apple supplied icon found in /System/Library/Frameworks/JavaVM.framework as the default icon for Java apps. This fix makes it use an icon that comes with OpenJDK instead. > We do it by converting the icon file to an .h file which contains the icon data as an array of bytes and then including the .h file where the icon data is needed. So, we basically compile in the icon data into the binaries. Such approach was chosen because this is what we do on other platforms (Linux, Windows) and because it is the easiest way to access the icon data during runtime. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179349 > Webrev: http://cr.openjdk.java.net/~leonidr/7179349/webrev.00/ > > Note: this is a freshly filled bug, so my understanding is it may take a while until it becomes visible via bug's link above. > > Thanks, > Leonid. > > From anthony.petrov at oracle.com Mon Jun 25 07:10:27 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 25 Jun 2012 18:10:27 +0400 Subject: [7u6] Review request for 7174718: [macosx] Regression in 7u6 b12: PopupFactory leaks DefaultFrames. Message-ID: <4FE87153.7090005@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7174718 at: http://cr.openjdk.java.net/~anthony/7u6-14-AWTWindowLeak-7174718.0/ This is a 100% direct back-port of the same fix from JDK 8. -- best regards, Anthony From Sergey.Bylokhov at oracle.com Mon Jun 25 07:22:39 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Jun 2012 07:22:39 -0700 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FE8617A.90402@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FD895F1.3040605@oracle.com> <4FE8407C.7060103@oracle.com> <4FE8617A.90402@oracle.com> Message-ID: <4FE8742F.6080308@oracle.com> Hi, Artem, Anthony. New version of the fix: http://cr.openjdk.java.net/~serb/7124244/webrev.02/ 25.06.2012 06:02, Anthony Petrov wrote: > Hi Sergey, > > The fix looks good overall. Just two comments: > > 1. src/macosx/classes/sun/lwawt/LWWindowPeer.java >> 987 if (oldBB != null) { >> 988 backBuffer = (BufferedImage) >> platformWindow.createBackBuffer(); > > Since we never create a back buffer in JDK 8 currently, I suggest to > comment this code out, and add a remark mentioning a CR number that > should make use of the code in the future. done > > 2. src/share/classes/javax/swing/RepaintManager.java >> 1501 Graphics2D g2d = (Graphics2D) osg.create(); >> 1502 g2d.setBackground(c.getBackground()); >> 1503 g2d.clearRect(x, y, bw, bh); >> 1504 g2d.dispose(); > > Please use the try {} finally {} pattern to dispose the G2D object. > The same comment applies to the lines 1510-1513. fixed > > -- > best regards, > Anthony > > On 06/25/12 14:42, Sergey Bylokhov wrote: >> Hi, Artem, Anthony. >> New version of the fix: >> http://cr.openjdk.java.net/~serb/7124244/webrev.01 >> >> 13.06.2012 06:30, Artem Ananiev wrote: >>> Hi, Sergey, >>> >>> a few minor comments: >>> >>> 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in >>> CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are >>> corresponding checks just above. >> done. >>> >>> 2. invalidateShadow() is not used in sun.lwawt, so it can be just a >>> method in CPlatformWindow. BTW, do you have any ideas, why CGLayer >>> holds a reference to LWWindowPeer, not to CPlatformWindow? >> done. >>> >>> 3. As we don't expect isSwingBackbufferTranslucencySupported() to >>> return different values, it would be fine to call it only once to >>> avoid possible perf regressions. >> done. >>> >>> Thanks, >>> >>> Artem >>> >>> On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >>>> Hi Everyone, >>>> Please review the fix. >>>> >>>> Shaped window was implemented as a translucent window with constrained >>>> graphics. Now translucent window doesn't use separate BufferedImage >>>> as a >>>> back buffer. Also alpha value for the swing back buffer was >>>> enabled(Shared code changed). >>>> Note that shaped windows are affected by this bugs: >>>> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >>>> - Shadows disappear. >>>> - Transparent areas aren't transparent to mouse clicks. >>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >>>> - Opacity does not work for non opaque windows. >>>> >>>> Any suggestions are welcome. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >>>> >> >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Jun 25 07:33:23 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Jun 2012 07:33:23 -0700 Subject: [7u6] Review request for 7174718: [macosx] Regression in 7u6 b12: PopupFactory leaks DefaultFrames. In-Reply-To: <4FE87153.7090005@oracle.com> References: <4FE87153.7090005@oracle.com> Message-ID: <4FE876B3.1060902@oracle.com> Hi, Anthony. Fix looks good to me. 25.06.2012 07:10, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7174718 > at: > > http://cr.openjdk.java.net/~anthony/7u6-14-AWTWindowLeak-7174718.0/ > > This is a 100% direct back-port of the same fix from JDK 8. > > -- > best regards, > Anthony -- Best regards, Sergey. From anthony.petrov at oracle.com Mon Jun 25 07:38:40 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 25 Jun 2012 18:38:40 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FE8742F.6080308@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FD895F1.3040605@oracle.com> <4FE8407C.7060103@oracle.com> <4FE8617A.90402@oracle.com> <4FE8742F.6080308@oracle.com> Message-ID: <4FE877F0.7050202@oracle.com> Hi Sergey, Thanks for addressing the issues. The fix looks good to me. -- best regards, Anthony On 06/25/12 18:22, Sergey Bylokhov wrote: > Hi, Artem, Anthony. > New version of the fix: > http://cr.openjdk.java.net/~serb/7124244/webrev.02/ > > 25.06.2012 06:02, Anthony Petrov wrote: >> Hi Sergey, >> >> The fix looks good overall. Just two comments: >> >> 1. src/macosx/classes/sun/lwawt/LWWindowPeer.java >>> 987 if (oldBB != null) { >>> 988 backBuffer = (BufferedImage) platformWindow.createBackBuffer(); >> >> Since we never create a back buffer in JDK 8 currently, I suggest to >> comment this code out, and add a remark mentioning a CR number that >> should make use of the code in the future. > done >> >> 2. src/share/classes/javax/swing/RepaintManager.java >>> 1501 Graphics2D g2d = (Graphics2D) osg.create(); >>> 1502 g2d.setBackground(c.getBackground()); >>> 1503 g2d.clearRect(x, y, bw, bh); >>> 1504 g2d.dispose(); >> >> Please use the try {} finally {} pattern to dispose the G2D object. >> The same comment applies to the lines 1510-1513. > fixed >> >> -- >> best regards, >> Anthony >> >> On 06/25/12 14:42, Sergey Bylokhov wrote: >>> Hi, Artem, Anthony. >>> New version of the fix: >>> http://cr.openjdk.java.net/~serb/7124244/webrev.01 >>> >>> 13.06.2012 06:30, Artem Ananiev wrote: >>>> Hi, Sergey, >>>> >>>> a few minor comments: >>>> >>>> 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in >>>> CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are >>>> corresponding checks just above. >>> done. >>>> >>>> 2. invalidateShadow() is not used in sun.lwawt, so it can be just a >>>> method in CPlatformWindow. BTW, do you have any ideas, why CGLayer >>>> holds a reference to LWWindowPeer, not to CPlatformWindow? >>> done. >>>> >>>> 3. As we don't expect isSwingBackbufferTranslucencySupported() to >>>> return different values, it would be fine to call it only once to >>>> avoid possible perf regressions. >>> done. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >>>>> Hi Everyone, >>>>> Please review the fix. >>>>> >>>>> Shaped window was implemented as a translucent window with constrained >>>>> graphics. Now translucent window doesn't use separate BufferedImage >>>>> as a >>>>> back buffer. Also alpha value for the swing back buffer was >>>>> enabled(Shared code changed). >>>>> Note that shaped windows are affected by this bugs: >>>>> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >>>>> - Shadows disappear. >>>>> - Transparent areas aren't transparent to mouse clicks. >>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >>>>> - Opacity does not work for non opaque windows. >>>>> >>>>> Any suggestions are welcome. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >>>>> >>> >>> > > From artem.ananiev at oracle.com Mon Jun 25 08:16:32 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 25 Jun 2012 19:16:32 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FE8407C.7060103@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FD895F1.3040605@oracle.com> <4FE8407C.7060103@oracle.com> Message-ID: <4FE880D0.3080108@oracle.com> Hi, Sergey, a few minor comments: 1. CPlatformWindow.java: invalidateShadow() in native is ready to be called on any thread, so what's the reason behind invokeLater() here? 2. RepaintManager.java: the new field should better be named "volatileBufferType". 3. LWComponentPeer.applyShape() is a peer method, which accepts user-supplied object (right now it's constructed from Shape in AWT internal code, but nothing prevents users from calling this method directly), so it should be stored as a copy, not as a reference. Thanks, Artem On 6/25/2012 2:42 PM, Sergey Bylokhov wrote: > Hi, Artem, Anthony. > New version of the fix: > http://cr.openjdk.java.net/~serb/7124244/webrev.01 > > 13.06.2012 06:30, Artem Ananiev wrote: >> Hi, Sergey, >> >> a few minor comments: >> >> 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in >> CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are >> corresponding checks just above. > done. >> >> 2. invalidateShadow() is not used in sun.lwawt, so it can be just a >> method in CPlatformWindow. BTW, do you have any ideas, why CGLayer >> holds a reference to LWWindowPeer, not to CPlatformWindow? > done. >> >> 3. As we don't expect isSwingBackbufferTranslucencySupported() to >> return different values, it would be fine to call it only once to >> avoid possible perf regressions. > done. >> >> Thanks, >> >> Artem >> >> On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> Please review the fix. >>> >>> Shaped window was implemented as a translucent window with constrained >>> graphics. Now translucent window doesn't use separate BufferedImage as a >>> back buffer. Also alpha value for the swing back buffer was >>> enabled(Shared code changed). >>> Note that shaped windows are affected by this bugs: >>> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >>> - Shadows disappear. >>> - Transparent areas aren't transparent to mouse clicks. >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >>> - Opacity does not work for non opaque windows. >>> >>> Any suggestions are welcome. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >>> > > From leonid.romanov at oracle.com Mon Jun 25 08:15:25 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 25 Jun 2012 19:15:25 +0400 Subject: [7u6] Review request for 7179349: [macosx] Java processes on Mac should not use default Apple icon In-Reply-To: <4FE870C0.1060801@oracle.com> References: <8A0DEC93-4B33-4830-8243-05B1A752BD6C@oracle.com> <4FE870C0.1060801@oracle.com> Message-ID: <8C0F3159-4006-4D71-B10C-118458A412E7@oracle.com> Here is an update webrev that incorporate your suggestion and has the icon file: http://cr.openjdk.java.net/~leonidr/7179349/webrev.01/ On 25.06.2012, at 18:08, Anthony Petrov wrote: > Hi Leonid, > > Where does the JavaApp.icns file come from? I can't see it in the webrev. > > src/macosx/native/sun/osxapp/NSApplicationAWT.m >> 269 NSString* bundleIcon = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleIconFile"]; >> 270 if (bundleIcon == nil && iconImage == nil) { > > We could probably rewrite this as: > > if (iconImage == nil) { > NSString *bundleIcon... > if (bundleIcon == nil) { > ... > > to avoid accessing the bundle when it is unneeded. > > The fix looks good otherwise. > > -- > best regards, > Anthony > > On 06/24/12 22:33, Leonid Romanov wrote: >> Hi, >> Please review a fix for 7179349: [macosx] Java processes on Mac should not use default Apple icon. >> Currently, OpenJDK uses Apple supplied icon found in /System/Library/Frameworks/JavaVM.framework as the default icon for Java apps. This fix makes it use an icon that comes with OpenJDK instead. >> We do it by converting the icon file to an .h file which contains the icon data as an array of bytes and then including the .h file where the icon data is needed. So, we basically compile in the icon data into the binaries. Such approach was chosen because this is what we do on other platforms (Linux, Windows) and because it is the easiest way to access the icon data during runtime. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179349 >> Webrev: http://cr.openjdk.java.net/~leonidr/7179349/webrev.00/ >> >> Note: this is a freshly filled bug, so my understanding is it may take a while until it becomes visible via bug's link above. >> >> Thanks, >> Leonid. >> >> From artem.ananiev at oracle.com Mon Jun 25 08:44:21 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 25 Jun 2012 19:44:21 +0400 Subject: [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing In-Reply-To: <4FE2FAB2.7020105@oracle.com> References: <4FC77592.7020900@oracle.com> <4FDF45AA.4040703@oracle.com> <4FE2FAB2.7020105@oracle.com> Message-ID: <4FE88755.60902@oracle.com> Hi, Sergey, this version looks fine. Thanks, Artem On 6/21/2012 2:42 PM, Sergey Bylokhov wrote: > Hello, > new version of the fix: > http://cr.openjdk.java.net/~serb/7142091/webrev.01/ > - invokeLater was removed from setVisible and dispose. > - instanceof Graphics2D was added. > > Run some awt related jck and regression tests, no new issues found. > > On 18.06.2012 19:13, Artem Ananiev wrote: >> Hi, Sergey, >> >> some minor comments (may be unrelated to the fix): >> >> 1. LWComponentPeer.setVisible() can be made final. Do expect any >> subclass to override it instead of setVisibleImpl()? > It is overriden in CPrinterDialogPeer. >> >> 2. invokeLater() in LWWindowPeer.setVisibleImpl(): I realize this is >> really painful issue, but I'd vote for removing this workaround. It >> would result in faster startup (although, the window will be solid >> gray for some time), and make LWAWT code similar to what we have on >> other platforms. > removed >> >> Then next step will to minimize the delay between showing the window >> and painting its content. >> >> 3. LWWindowPeer.replaceSurfaceData(): what are benefits of >> setBackground() + clearRect() over setColor() + fillRect()? Although >> we always expect the Graphics object to be Graphics2D instance, this >> unconditional cast doesn't look great. > done >> >> Thanks, >> >> Artem >> >> On 5/31/2012 5:43 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> Please review the fix. >>> >>> Notes from the bug and comments: >>> 1. setVisible() should be called at the end of the peers initialization. >>> We can move super.initialize() to the end of the peers initializations. >>> Initialize() was split to initialize() and initializeImpl(). In the >>> initialize() we call initializeImpl and then we call to setVisible(). >>> initializeImpl overridden in subclasses. >>> >>> 2. Invokelater in the initialization/disposing is a tricky. >>> Left it as is. Probably later it will be changed. Comments was updated. >>> >>> 3. replaceSurfacedata() should be moved outside of >>> LWWindowPeer.setVisible() >>> Done. Also duplicate code was extracted to setVisible() method which >>> call setVisibleImpl(). >>> >>> 4. Backbuffer in replaceSurfacedata() should be initialized by clearRect >>> instead of fillrect(composite is important). >>> Done. related to composite. >>> >>> 5. During lwwindowpeer initialization we call two similar methods >>> nativeSetNSWindowAlpha() and setAlphaValue(). >>> nativeSetNSWindowAlpha() removed from CPlatformWindow.java. >>> >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7142091/webrev.00/ >>> > > From Sergey.Bylokhov at oracle.com Mon Jun 25 09:28:49 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Jun 2012 09:28:49 -0700 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FE880D0.3080108@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FD895F1.3040605@oracle.com> <4FE8407C.7060103@oracle.com> <4FE880D0.3080108@oracle.com> Message-ID: <4FE891C1.3070803@oracle.com> Hi, Artem. New version of the fix. http://cr.openjdk.java.net/~serb/7124244/webrev.03/ 25.06.2012 08:16, Artem Ananiev wrote: > Hi, Sergey, > > a few minor comments: > > 1. CPlatformWindow.java: invalidateShadow() in native is ready to be > called on any thread, so what's the reason behind invokeLater() here? It is used to postpone shadow invalidating. > > 2. RepaintManager.java: the new field should better be named > "volatileBufferType". done > > 3. LWComponentPeer.applyShape() is a peer method, which accepts > user-supplied object (right now it's constructed from Shape in AWT > internal code, but nothing prevents users from calling this method > directly), so it should be stored as a copy, not as a reference. done > > Thanks, > > Artem > > On 6/25/2012 2:42 PM, Sergey Bylokhov wrote: >> Hi, Artem, Anthony. >> New version of the fix: >> http://cr.openjdk.java.net/~serb/7124244/webrev.01 >> >> 13.06.2012 06:30, Artem Ananiev wrote: >>> Hi, Sergey, >>> >>> a few minor comments: >>> >>> 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in >>> CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are >>> corresponding checks just above. >> done. >>> >>> 2. invalidateShadow() is not used in sun.lwawt, so it can be just a >>> method in CPlatformWindow. BTW, do you have any ideas, why CGLayer >>> holds a reference to LWWindowPeer, not to CPlatformWindow? >> done. >>> >>> 3. As we don't expect isSwingBackbufferTranslucencySupported() to >>> return different values, it would be fine to call it only once to >>> avoid possible perf regressions. >> done. >>> >>> Thanks, >>> >>> Artem >>> >>> On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >>>> Hi Everyone, >>>> Please review the fix. >>>> >>>> Shaped window was implemented as a translucent window with constrained >>>> graphics. Now translucent window doesn't use separate BufferedImage >>>> as a >>>> back buffer. Also alpha value for the swing back buffer was >>>> enabled(Shared code changed). >>>> Note that shaped windows are affected by this bugs: >>>> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >>>> - Shadows disappear. >>>> - Transparent areas aren't transparent to mouse clicks. >>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >>>> - Opacity does not work for non opaque windows. >>>> >>>> Any suggestions are welcome. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >>>> >> >> -- Best regards, Sergey. From pflahrty at rampageinc.com Mon Jun 25 11:42:53 2012 From: pflahrty at rampageinc.com (Patrick Flaherty) Date: Mon, 25 Jun 2012 14:42:53 -0400 Subject: 32 bit version of MacOSX Port (OpenJDK) Message-ID: Hi, Do we know *yet* whether or not there will be a 32 bit version of the OpenJDK MacOSX Port ? We would need to know as business decisions on present capability may be impacted. Thanks to anyone in the know. -Pat From anthony.petrov at oracle.com Mon Jun 25 12:58:06 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 25 Jun 2012 23:58:06 +0400 Subject: [7u6] Review request for 7179349: [macosx] Java processes on Mac should not use default Apple icon In-Reply-To: <8C0F3159-4006-4D71-B10C-118458A412E7@oracle.com> References: <8A0DEC93-4B33-4830-8243-05B1A752BD6C@oracle.com> <4FE870C0.1060801@oracle.com> <8C0F3159-4006-4D71-B10C-118458A412E7@oracle.com> Message-ID: <4FE8C2CE.70701@oracle.com> This version of the fix looks fine to me. Thanks. -- best regards, Anthony On 6/25/2012 7:15 PM, Leonid Romanov wrote: > Here is an update webrev that incorporate your suggestion and has the > icon file: > http://cr.openjdk.java.net/~leonidr/7179349/webrev.01/ > > On 25.06.2012, at 18:08, Anthony Petrov wrote: > >> Hi Leonid, >> >> Where does the JavaApp.icns file come from? I can't see it in the webrev. >> >> src/macosx/native/sun/osxapp/NSApplicationAWT.m >>> 269 NSString* bundleIcon = [[NSBundle mainBundle] >>> objectForInfoDictionaryKey:@"CFBundleIconFile"]; >>> 270 if (bundleIcon == nil && iconImage == nil) { >> >> We could probably rewrite this as: >> >> if (iconImage == nil) { >> NSString *bundleIcon... >> if (bundleIcon == nil) { >> ... >> >> to avoid accessing the bundle when it is unneeded. >> >> The fix looks good otherwise. >> >> -- >> best regards, >> Anthony >> >> On 06/24/12 22:33, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7179349: [macosx] Java processes on Mac >>> should not use default Apple icon. >>> Currently, OpenJDK uses Apple supplied icon found in >>> /System/Library/Frameworks/JavaVM.framework as the default icon for >>> Java apps. This fix makes it use an icon that comes with OpenJDK instead. >>> We do it by converting the icon file to an .h file which contains the >>> icon data as an array of bytes and then including the .h file where >>> the icon data is needed. So, we basically compile in the icon data >>> into the binaries. Such approach was chosen because this is what we >>> do on other platforms (Linux, Windows) and because it is the easiest >>> way to access the icon data during runtime. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179349 >>> Webrev: http://cr.openjdk.java.net/~leonidr/7179349/webrev.00/ >>> >>> Note: this is a freshly filled bug, so my understanding is it may >>> take a while until it becomes visible via bug's link above. >>> >>> Thanks, >>> Leonid. >>> >>> > From xueming.shen at oracle.com Mon Jun 25 23:00:13 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 25 Jun 2012 23:00:13 -0700 Subject: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE94F6F.2060002@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <4FE94F6F.2060002@oracle.com> Message-ID: <4FE94FED.6050406@oracle.com> On 6/25/12 10:58 PM, Xueming Shen wrote: > Hi, > > While I still believe that case-insensitive is the right choice for > File/Path on MacOSX, it is > suggested that we might want to be a little conservative in this > patch, with the assumption > that this patch will be backport to 7u release after being baked in > jdk8 for a while (given > Apple's JDK6 is case sensitive for File, it might be too much for a > update releases to go > with two in-compatible changes, case sensitive and hash32). > > So here is the webrev for a strip-down version from the original > patch, in which it only > targets the nfd/nfc issue raised in 7130915 and 7168427. The proposed > changes for > case insensitive compare and hash32 for both java.io.File and > java.nio.file.Path are > removed. > > http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev > > (The webrev for the "full" version has been moved to > http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev_full) > > Thanks, > -Sherman > > > On 6/22/12 10:01 AM, Xueming Shen wrote: >> Hi >> >> Here is the proposed change to support Unicode nfd/nfc and case >> insensitive >> file path on MacOSX file system. >> >> 7130915: File.equals does not give expected results when path >> contains Non-English characters on Mac OS X >> 7168427: FileInputStream cannot open file where the file path >> contains asian characters [macosx] >> >> While these two bug reports are only against java.io, we have the >> same issue in javax.nio.file. >> Here is the webrev >> >> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ >> >> Here is the brief summary of the changes >> >> java.io.File: >> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, >> which means >> we are now passing nfc/composite characters directly into macosx >> file system APIs >> without normalize them to nfd. It appears macosx fs APIs do >> take nfc, though it uses >> nfd. >> >> (2) normalize the resulting file name from macosx fs APIs from >> nfd->nfc before passing >> back to java.io.File (File.list() and canonicalize()), so we >> deal with nfc file name >> (as "usual") for java.io classes/APIs. >> >> (3) fs.compare()/hashCode() was updated to be case insensitive >> >> (4) hasCode() was updated to use the new String.hash32(). >> >> java.nio.file: >> >> (5) added a setof MacOSXFile... on top of existing BsdFile... >> classes. An alternative is to >> update those BsdFile... classes directly to address the macosx >> specific issues. But given >> there might be developers over there might work on open jdk BSD port >> and have dependency >> on these classes, it might be desirable to have another separate >> layer of MacOSXFile... >> classes. So now the default FileSystem/Provider is >> MacOSXFileSystemProvider and >> MacOSXFileSystem. >> >> (6) the "main" changes are in MacOSXFileSystem, in which the >> corresponding methods >> were added to handle, case insensitive and nfd<=>nfc normalization, >> including the >> pathmatcher. >> >> (7) compare is now are case-insensitive >> >> (8) hashCode is now murmur3_32(), this is true for all >> Solaris/Unix/Linux and maxosx. >> >> >> Though lots of files have been touched, but the line of changes are >> actually relatively >> small. >> >> The proposed change only deals with the default case-sensitiveness >> seting, which is >> case insensitive. On MaxOSX, you actually can configure the HFS+ file >> system or the >> mounted vol to be case-sensitive. A possible approach is to have some >> extra FileStore >> attributes, such as a isCaseSensitive and to use case sensitive >> compare/equal on >> such fs, but this can be dealt with separately later. >> >> Thanks, >> -Sherman > > From artem.ananiev at oracle.com Tue Jun 26 03:11:55 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 26 Jun 2012 14:11:55 +0400 Subject: [7u6] Review request for 7174718: [macosx] Regression in 7u6 b12: PopupFactory leaks DefaultFrames. In-Reply-To: <4FE87153.7090005@oracle.com> References: <4FE87153.7090005@oracle.com> Message-ID: <4FE98AEB.7040409@oracle.com> Looks fine. Thanks, Artem On 6/25/2012 6:10 PM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7174718 at: > > http://cr.openjdk.java.net/~anthony/7u6-14-AWTWindowLeak-7174718.0/ > > This is a 100% direct back-port of the same fix from JDK 8. > > -- > best regards, > Anthony From artem.ananiev at oracle.com Tue Jun 26 03:38:02 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 26 Jun 2012 14:38:02 +0400 Subject: [7u6] Review request for 7179349: [macosx] Java processes on Mac should not use default Apple icon In-Reply-To: <8C0F3159-4006-4D71-B10C-118458A412E7@oracle.com> References: <8A0DEC93-4B33-4830-8243-05B1A752BD6C@oracle.com> <4FE870C0.1060801@oracle.com> <8C0F3159-4006-4D71-B10C-118458A412E7@oracle.com> Message-ID: <4FE9910A.2020207@oracle.com> On 6/25/2012 7:15 PM, Leonid Romanov wrote: > Here is an update webrev that incorporate your suggestion and has the > icon file: > http://cr.openjdk.java.net/~leonidr/7179349/webrev.01/ Looks fine. Thanks, Artem > On 25.06.2012, at 18:08, Anthony Petrov wrote: > >> Hi Leonid, >> >> Where does the JavaApp.icns file come from? I can't see it in the webrev. >> >> src/macosx/native/sun/osxapp/NSApplicationAWT.m >>> 269 NSString* bundleIcon = [[NSBundle mainBundle] >>> objectForInfoDictionaryKey:@"CFBundleIconFile"]; >>> 270 if (bundleIcon == nil && iconImage == nil) { >> >> We could probably rewrite this as: >> >> if (iconImage == nil) { >> NSString *bundleIcon... >> if (bundleIcon == nil) { >> ... >> >> to avoid accessing the bundle when it is unneeded. >> >> The fix looks good otherwise. >> >> -- >> best regards, >> Anthony >> >> On 06/24/12 22:33, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7179349: [macosx] Java processes on Mac >>> should not use default Apple icon. >>> Currently, OpenJDK uses Apple supplied icon found in >>> /System/Library/Frameworks/JavaVM.framework as the default icon for >>> Java apps. This fix makes it use an icon that comes with OpenJDK instead. >>> We do it by converting the icon file to an .h file which contains the >>> icon data as an array of bytes and then including the .h file where >>> the icon data is needed. So, we basically compile in the icon data >>> into the binaries. Such approach was chosen because this is what we >>> do on other platforms (Linux, Windows) and because it is the easiest >>> way to access the icon data during runtime. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179349 >>> Webrev: http://cr.openjdk.java.net/~leonidr/7179349/webrev.00/ >>> >>> Note: this is a freshly filled bug, so my understanding is it may >>> take a while until it becomes visible via bug's link above. >>> >>> Thanks, >>> Leonid. >>> >>> > From Sergey.Bylokhov at oracle.com Tue Jun 26 04:49:16 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Jun 2012 15:49:16 +0400 Subject: [7u6] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing Message-ID: <4FE9A1BC.1000501@oracle.com> Hi Everyone, Please review the fix. Notes from the bug and comments: 1. setVisible() should be called at the end of the peers initialization. We can move super.initialize() to the end of the peers initializations. Initialize() was split to initialize() and initializeImpl(). In the initialize() we call initializeImpl and then we call to setVisible(). initializeImpl overridden in subclasses. 2. Invokelater in the initialization/disposing is a tricky. Removed. 3. replaceSurfacedata() should be moved outside of LWWindowPeer.setVisible() Done. Also duplicate code was extracted to setVisible() method which call setVisibleImpl(). 4. Backbuffer in replaceSurfacedata() should be initialized by clearRect instead of fillrect(composite is important). Done. related to composite. 5. During lwwindowpeer initialization we call two similar methods nativeSetNSWindowAlpha() and setAlphaValue(). nativeSetNSWindowAlpha() removed from CPlatformWindow.java. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 Webrev can be found at: http://cr.openjdk.java.net/~serb/7142091/webrev.01/ Also note that CR 7177173 depends from this one. -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Jun 26 04:55:38 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 26 Jun 2012 15:55:38 +0400 Subject: [7u6] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing In-Reply-To: <4FE9A1BC.1000501@oracle.com> References: <4FE9A1BC.1000501@oracle.com> Message-ID: <4FE9A33A.4060600@oracle.com> Looks good to me. -- best regards, Anthony On 6/26/2012 3:49 PM, Sergey Bylokhov wrote: > > Hi Everyone, > Please review the fix. > > Notes from the bug and comments: > 1. setVisible() should be called at the end of the peers initialization. > We can move super.initialize() to the end of the peers initializations. > Initialize() was split to initialize() and initializeImpl(). In the > initialize() we call initializeImpl and then we call to setVisible(). > initializeImpl overridden in subclasses. > > 2. Invokelater in the initialization/disposing is a tricky. > Removed. > > 3. replaceSurfacedata() should be moved outside of > LWWindowPeer.setVisible() > Done. Also duplicate code was extracted to setVisible() method which > call setVisibleImpl(). > > 4. Backbuffer in replaceSurfacedata() should be initialized by clearRect > instead of fillrect(composite is important). > Done. related to composite. > > 5. During lwwindowpeer initialization we call two similar methods > nativeSetNSWindowAlpha() and setAlphaValue(). > nativeSetNSWindowAlpha() removed from CPlatformWindow.java. > > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7142091/webrev.01/ > > Also note that CR 7177173 depends from this one. > > -- > Best regards, Sergey. > From anthony.petrov at oracle.com Tue Jun 26 05:19:48 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 26 Jun 2012 16:19:48 +0400 Subject: [8] Review request for 7124326: [macosx] An issue similar to autoshutdown one in two AppContexts situation. Message-ID: <4FE9A8E4.6070209@oracle.com> Hi Artem and Leonid, Please review a one-liner for http://bugs.sun.com/view_bug.do?bug_id=7124326 at: http://cr.openjdk.java.net/~anthony/8-38-AppContextAutoshutdown-7124326.0/ A SystemTrayPeer instance added to a peers map prevents an app from exiting. On other platforms we don't add the SystemTrayPeer to the map (only the TrayIcon peers get added). So I implement the same logic on the Mac by removing a call to targetCreatedPeer() from LWCToolkit.createSystemTray(). -- best regards, Anthony From leonid.romanov at oracle.com Tue Jun 26 05:24:53 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 26 Jun 2012 16:24:53 +0400 Subject: [8] Review request for 7124326: [macosx] An issue similar to autoshutdown one in two AppContexts situation. In-Reply-To: <4FE9A8E4.6070209@oracle.com> References: <4FE9A8E4.6070209@oracle.com> Message-ID: Looks good. On 26.06.2012, at 16:19, Anthony Petrov wrote: > Hi Artem and Leonid, > > Please review a one-liner for http://bugs.sun.com/view_bug.do?bug_id=7124326 at: > > http://cr.openjdk.java.net/~anthony/8-38-AppContextAutoshutdown-7124326.0/ > > A SystemTrayPeer instance added to a peers map prevents an app from exiting. On other platforms we don't add the SystemTrayPeer to the map (only the TrayIcon peers get added). So I implement the same logic on the Mac by removing a call to targetCreatedPeer() from LWCToolkit.createSystemTray(). > > -- > best regards, > Anthony From artem.ananiev at oracle.com Tue Jun 26 06:18:39 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 26 Jun 2012 17:18:39 +0400 Subject: [7u6] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing In-Reply-To: <4FE9A1BC.1000501@oracle.com> References: <4FE9A1BC.1000501@oracle.com> Message-ID: <4FE9B6AF.4070809@oracle.com> Still looks fine. Thanks, Artem On 6/26/2012 3:49 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > > Notes from the bug and comments: > 1. setVisible() should be called at the end of the peers initialization. > We can move super.initialize() to the end of the peers initializations. > Initialize() was split to initialize() and initializeImpl(). In the > initialize() we call initializeImpl and then we call to setVisible(). > initializeImpl overridden in subclasses. > > 2. Invokelater in the initialization/disposing is a tricky. > Removed. > > 3. replaceSurfacedata() should be moved outside of > LWWindowPeer.setVisible() > Done. Also duplicate code was extracted to setVisible() method which > call setVisibleImpl(). > > 4. Backbuffer in replaceSurfacedata() should be initialized by clearRect > instead of fillrect(composite is important). > Done. related to composite. > > 5. During lwwindowpeer initialization we call two similar methods > nativeSetNSWindowAlpha() and setAlphaValue(). > nativeSetNSWindowAlpha() removed from CPlatformWindow.java. > > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7142091 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7142091/webrev.01/ > > Also note that CR 7177173 depends from this one. > > -- > Best regards, Sergey. > From artem.ananiev at oracle.com Tue Jun 26 06:24:07 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 26 Jun 2012 17:24:07 +0400 Subject: [8] Review request for 7124326: [macosx] An issue similar to autoshutdown one in two AppContexts situation. In-Reply-To: <4FE9A8E4.6070209@oracle.com> References: <4FE9A8E4.6070209@oracle.com> Message-ID: <4FE9B7F7.9000601@oracle.com> Looks fine. Thanks, Artem On 6/26/2012 4:19 PM, Anthony Petrov wrote: > Hi Artem and Leonid, > > Please review a one-liner for > http://bugs.sun.com/view_bug.do?bug_id=7124326 at: > > http://cr.openjdk.java.net/~anthony/8-38-AppContextAutoshutdown-7124326.0/ > > A SystemTrayPeer instance added to a peers map prevents an app from > exiting. On other platforms we don't add the SystemTrayPeer to the map > (only the TrayIcon peers get added). So I implement the same logic on > the Mac by removing a call to targetCreatedPeer() from > LWCToolkit.createSystemTray(). > > -- > best regards, > Anthony From anthony.petrov at oracle.com Tue Jun 26 07:28:15 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 26 Jun 2012 18:28:15 +0400 Subject: [7u6] Review request for 7124326: [macosx] An issue similar to autoshutdown one in two AppContexts situation. Message-ID: <4FE9C6FF.7020204@oracle.com> Hi Artem and Leonid, Please review a one-liner for http://bugs.sun.com/view_bug.do?bug_id=7124326 at: http://cr.openjdk.java.net/~anthony/7u6-15-AppContextAutoshutdown-7124326.0/ This is a 100% direct back-port of the same fix from JDK 8. -- best regards, Anthony From leonid.romanov at oracle.com Tue Jun 26 07:31:33 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 26 Jun 2012 18:31:33 +0400 Subject: [7u6] Review request for 7124326: [macosx] An issue similar to autoshutdown one in two AppContexts situation. In-Reply-To: <4FE9C6FF.7020204@oracle.com> References: <4FE9C6FF.7020204@oracle.com> Message-ID: <8F9732DF-8C88-4A3A-9CCC-7575109EA972@oracle.com> Looks good. On 26.06.2012, at 18:28, Anthony Petrov wrote: > Hi Artem and Leonid, > > Please review a one-liner for > http://bugs.sun.com/view_bug.do?bug_id=7124326 at: > > http://cr.openjdk.java.net/~anthony/7u6-15-AppContextAutoshutdown-7124326.0/ > > This is a 100% direct back-port of the same fix from JDK 8. > > -- > best regards, > Anthony From artem.ananiev at oracle.com Tue Jun 26 07:35:39 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 26 Jun 2012 18:35:39 +0400 Subject: [7u6] Review request for 7124326: [macosx] An issue similar to autoshutdown one in two AppContexts situation. In-Reply-To: <4FE9C6FF.7020204@oracle.com> References: <4FE9C6FF.7020204@oracle.com> Message-ID: <4FE9C8BB.4080203@oracle.com> Looks fine. Thanks, Artem On 6/26/2012 6:28 PM, Anthony Petrov wrote: > Hi Artem and Leonid, > > Please review a one-liner for > http://bugs.sun.com/view_bug.do?bug_id=7124326 at: > > http://cr.openjdk.java.net/~anthony/7u6-15-AppContextAutoshutdown-7124326.0/ > > > This is a 100% direct back-port of the same fix from JDK 8. > > -- > best regards, > Anthony From Alan.Bateman at oracle.com Tue Jun 26 08:02:11 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Jun 2012 16:02:11 +0100 Subject: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE94FED.6050406@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <4FE94F6F.2060002@oracle.com> <4FE94FED.6050406@oracle.com> Message-ID: <4FE9CEF3.8080905@oracle.com> On 26/06/2012 07:00, Xueming Shen wrote: > On 6/25/12 10:58 PM, Xueming Shen wrote: >> Hi, >> >> While I still believe that case-insensitive is the right choice for >> File/Path on MacOSX, it is >> suggested that we might want to be a little conservative in this >> patch, with the assumption >> that this patch will be backport to 7u release after being baked in >> jdk8 for a while (given >> Apple's JDK6 is case sensitive for File, it might be too much for a >> update releases to go >> with two in-compatible changes, case sensitive and hash32). >> >> So here is the webrev for a strip-down version from the original >> patch, in which it only >> targets the nfd/nfc issue raised in 7130915 and 7168427. The proposed >> changes for >> case insensitive compare and hash32 for both java.io.File and >> java.nio.file.Path are >> removed. >> >> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev >> >> (The webrev for the "full" version has been moved to >> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev_full) >> >> Thanks, >> -Sherman I had to dig up the File Systems, Unicode, and Normalization presentation [1] before reviewing this, it's been a while. I think the changes for java.io for fine, I just worry that there may be a few odd cases where it will be different to Apple JDK6. I looked through the macosx-port/macosx-port/jdk forest and there is one patch from Apple that does the NFC->NFD conversation. I don't get that patch because you say that the syscalls handle NFC okay. In your changes then you normalize when decoding the file names to Strings, which seems right but that seems to be completely missing from the changes that Apple brought over. The only minor comment is that we probably need to check the return from core foundation functions such as CFStringCreateMutable (this goes for the other native code too). Adding the FileSystemProvider for MacOSX is great to see. The approach is fine for but is somewhat inefficient when ->NFD or ->NFC is needed. One inefficiency that can be fixed is in sun.nio.fs.MacOSXFileSystem. normalizeJavaPath then you can eliminate the second call to toCharArray. I think the new methods on sun.no.fs.UnixFileSystem should be given comments so that it's clear whether they should be overridden (the Unix* provider tends to be starting point for most ports). A minor comment is that MacOSXNativeDispatcher has a bunch of blank lines at the end, also I think "static final" is more normal than "final static". At some point I think we should re-write MacOSXNativeDispatcher.normalizepath so that it deosn't require the critical section or malloc as in this area we try to keep the native methods to a bare minimum. Do the tests assume they are run on HFS? Just wondering if you you need to look at the FileStore name/type to check. Some of variable namesa bit non-standard, very C like. Minor nit is that the copyright in the header isn't right in the tests. Also the tests list 2 CRs whereas I assume this is one CR (with the other closed as a dup). On case sensitive vs. insensitive then I think it should be insensitive as per the first round but that would be a significant change given that Apple's JDK does not appear to have changed File.equals. Maybe we should think about this again once these changes are in 8. -Alan [1] http://developers.sun.com/global/products_platforms/solaris/reference/presentations/IUC29-FileSystems.pdf From Sara.Burke at mathworks.com Tue Jun 26 10:40:58 2012 From: Sara.Burke at mathworks.com (Sara Burke) Date: Tue, 26 Jun 2012 17:40:58 +0000 Subject: : CGContextGetCTM messages Message-ID: <1DB09293-50B5-462F-BD42-6968F40583C3@mathworks.com> Hi all, I am new on this list, so I do apologize for any format issues. I came across a post to this mailing list of which I am having the same issue so I was wondering if anyone has heard of any root causes and/or workarounds: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-June/004407.html More details: My application emits the following messages; for easier reading, MY_APP replaces the actual application name: Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextGetCTM: invalid context 0x0 Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextSetBaseCTM: invalid context 0x0 Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextGetCTM: invalid context 0x0 Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextSetBaseCTM: invalid context 0x0 Same messages with my sample Java application. This did not happen in Mac OS X versions prior to 10.7.4. I confirmed that this still occurs in the latest developer preview of Mountain Lion and the latest Java SE 7, including OpenJDK 7. Regardless of whether or not this is a Java-related issue, the fact that these messages suddenly appeared with 10.7.4 insinuates that there is an OS bug somewhere or perhaps someone left in some debugging print statements. Posting this topic here to see if anyone else has come across this issue and/or knows of a workaround. Thanks, Sara ----------------------------------------------------------------- Sara M. Burke Ext. 7476 From leonid.romanov at oracle.com Tue Jun 26 10:54:42 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 26 Jun 2012 21:54:42 +0400 Subject: : CGContextGetCTM messages In-Reply-To: <1DB09293-50B5-462F-BD42-6968F40583C3@mathworks.com> References: <1DB09293-50B5-462F-BD42-6968F40583C3@mathworks.com> Message-ID: Yes, I can confirm that I've been seeing these messages as well. I'm also getting quite a lot of "IOSurface: buffer allocation size is zero" errors in the log. No idea about what causes them or what workarounds are, though. On 26.06.2012, at 21:40, Sara Burke wrote: > Hi all, > > I am new on this list, so I do apologize for any format issues. > > I came across a post to this mailing list of which I am having the same issue so I was wondering if anyone has c: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-June/004407.html > > More details: > > My application emits the following messages; for easier reading, MY_APP replaces the actual application name: > > Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextGetCTM: invalid context 0x0 > Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextSetBaseCTM: invalid context 0x0 > Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextGetCTM: invalid context 0x0 > Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextSetBaseCTM: invalid context 0x0 > > Same messages with my sample Java application. > > This did not happen in Mac OS X versions prior to 10.7.4. I confirmed that this still occurs in the latest developer preview of Mountain Lion and the latest Java SE 7, including OpenJDK 7. > Regardless of whether or not this is a Java-related issue, the fact that these messages suddenly appeared with 10.7.4 insinuates that there is an OS bug somewhere or perhaps someone left in some debugging print statements. > Posting this topic here to see if anyone else has come across this issue and/or knows of a workaround. > > Thanks, > Sara > > > > ----------------------------------------------------------------- > Sara M. Burke > Ext. 7476 > From Sara.Burke at mathworks.com Tue Jun 26 11:00:06 2012 From: Sara.Burke at mathworks.com (Sara Burke) Date: Tue, 26 Jun 2012 18:00:06 +0000 Subject: : CGContextGetCTM messages In-Reply-To: References: <1DB09293-50B5-462F-BD42-6968F40583C3@mathworks.com> Message-ID: I'm assuming you see these messages running a Java application with OpenJDK 7? What Mac OS are you on? On Jun 26, 2012, at 1:54 PM, Leonid Romanov wrote: Yes, I can confirm that I've been seeing these messages as well. I'm also getting quite a lot of "IOSurface: buffer allocation size is zero" errors in the log. No idea about what causes them or what workarounds are, though. On 26.06.2012, at 21:40, Sara Burke wrote: Hi all, I am new on this list, so I do apologize for any format issues. I came across a post to this mailing list of which I am having the same issue so I was wondering if anyone has c: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-June/004407.html More details: My application emits the following messages; for easier reading, MY_APP replaces the actual application name: Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextGetCTM: invalid context 0x0 Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextSetBaseCTM: invalid context 0x0 Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextGetCTM: invalid context 0x0 Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextSetBaseCTM: invalid context 0x0 Same messages with my sample Java application. This did not happen in Mac OS X versions prior to 10.7.4. I confirmed that this still occurs in the latest developer preview of Mountain Lion and the latest Java SE 7, including OpenJDK 7. Regardless of whether or not this is a Java-related issue, the fact that these messages suddenly appeared with 10.7.4 insinuates that there is an OS bug somewhere or perhaps someone left in some debugging print statements. Posting this topic here to see if anyone else has come across this issue and/or knows of a workaround. Thanks, Sara ----------------------------------------------------------------- Sara M. Burke Ext. 7476 ----------------------------------------------------------------- Sara M. Burke Ext. 7476 From leonid.romanov at oracle.com Tue Jun 26 11:03:59 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 26 Jun 2012 22:03:59 +0400 Subject: : CGContextGetCTM messages In-Reply-To: References: <1DB09293-50B5-462F-BD42-6968F40583C3@mathworks.com> Message-ID: <9ACC06A9-3C26-492B-97D5-9AC4B92FEECA@oracle.com> Yep. I'm on 10.7.4 and Java app in question is NetBeans. I'm not sure whether CGContext and IOSurface messages are related, but if they always come together, perhaps they are. On 26.06.2012, at 22:00, Sara Burke wrote: > I'm assuming you see these messages running a Java application with OpenJDK 7? What Mac OS are you on? > > On Jun 26, 2012, at 1:54 PM, Leonid Romanov wrote: > >> Yes, I can confirm that I've been seeing these messages as well. I'm also getting quite a lot of "IOSurface: buffer allocation size is zero" errors in the log. No idea about what causes them or what workarounds are, though. >> >> On 26.06.2012, at 21:40, Sara Burke wrote: >> >>> Hi all, >>> >>> I am new on this list, so I do apologize for any format issues. >>> >>> I came across a post to this mailing list of which I am having the same issue so I was wondering if anyone has c: >>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-June/004407.html >>> >>> More details: >>> >>> My application emits the following messages; for easier reading, MY_APP replaces the actual application name: >>> >>> Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextGetCTM: invalid context 0x0 >>> Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextSetBaseCTM: invalid context 0x0 >>> Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextGetCTM: invalid context 0x0 >>> Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextSetBaseCTM: invalid context 0x0 >>> >>> Same messages with my sample Java application. >>> >>> This did not happen in Mac OS X versions prior to 10.7.4. I confirmed that this still occurs in the latest developer preview of Mountain Lion and the latest Java SE 7, including OpenJDK 7. >>> Regardless of whether or not this is a Java-related issue, the fact that these messages suddenly appeared with 10.7.4 insinuates that there is an OS bug somewhere or perhaps someone left in some debugging print statements. >>> Posting this topic here to see if anyone else has come across this issue and/or knows of a workaround. >>> >>> Thanks, >>> Sara >>> >>> >>> >>> ----------------------------------------------------------------- >>> Sara M. Burke >>> Ext. 7476 >>> >> > > > > > > ----------------------------------------------------------------- > Sara M. Burke > Ext. 7476 > From Sara.Burke at mathworks.com Tue Jun 26 11:24:17 2012 From: Sara.Burke at mathworks.com (Sara Burke) Date: Tue, 26 Jun 2012 18:24:17 +0000 Subject: : CGContextGetCTM messages In-Reply-To: <9ACC06A9-3C26-492B-97D5-9AC4B92FEECA@oracle.com> References: <1DB09293-50B5-462F-BD42-6968F40583C3@mathworks.com> <9ACC06A9-3C26-492B-97D5-9AC4B92FEECA@oracle.com> Message-ID: <323A0CBA-7012-49DF-992A-2C61ABE527B8@mathworks.com> I'm pretty sure they are unrelated messages, but I don't know for sure. I thought I had isolated the issue to the Java call setIconImage() which reproduced the CGContext messages, but I'm not 100% sure yet that function call is the only culprit. The "IOSurface" message from the kernel is something I get in the Console all the time, even before 10.7.4. Most of the time these kind of Console messages aren't something to worry about, especially if they are ones you see frequently across OS updates. Anyways, I've been tracking the CGContext message issue all month and haven't yet discovered the real issue and/or workaround. On Jun 26, 2012, at 2:03 PM, Leonid Romanov wrote: Yep. I'm on 10.7.4 and Java app in question is NetBeans. I'm not sure whether CGContext and IOSurface messages are related, but if they always come together, perhaps they are. On 26.06.2012, at 22:00, Sara Burke wrote: I'm assuming you see these messages running a Java application with OpenJDK 7? What Mac OS are you on? On Jun 26, 2012, at 1:54 PM, Leonid Romanov wrote: Yes, I can confirm that I've been seeing these messages as well. I'm also getting quite a lot of "IOSurface: buffer allocation size is zero" errors in the log. No idea about what causes them or what workarounds are, though. On 26.06.2012, at 21:40, Sara Burke wrote: Hi all, I am new on this list, so I do apologize for any format issues. I came across a post to this mailing list of which I am having the same issue so I was wondering if anyone has c: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-June/004407.html More details: My application emits the following messages; for easier reading, MY_APP replaces the actual application name: Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextGetCTM: invalid context 0x0 Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextSetBaseCTM: invalid context 0x0 Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextGetCTM: invalid context 0x0 Jun 1 14:49:12 sburke-maci MY_APP[5611] : CGContextSetBaseCTM: invalid context 0x0 Same messages with my sample Java application. This did not happen in Mac OS X versions prior to 10.7.4. I confirmed that this still occurs in the latest developer preview of Mountain Lion and the latest Java SE 7, including OpenJDK 7. Regardless of whether or not this is a Java-related issue, the fact that these messages suddenly appeared with 10.7.4 insinuates that there is an OS bug somewhere or perhaps someone left in some debugging print statements. Posting this topic here to see if anyone else has come across this issue and/or knows of a workaround. Thanks, Sara ----------------------------------------------------------------- Sara M. Burke Ext. 7476 ----------------------------------------------------------------- Sara M. Burke Ext. 7476 ----------------------------------------------------------------- Sara M. Burke Ext. 7476 From roger.lewis at oracle.com Tue Jun 26 11:27:58 2012 From: roger.lewis at oracle.com (Roger Lewis) Date: Tue, 26 Jun 2012 11:27:58 -0700 Subject: : CGContextGetCTM messages In-Reply-To: <1DB09293-50B5-462F-BD42-6968F40583C3@mathworks.com> References: <1DB09293-50B5-462F-BD42-6968F40583C3@mathworks.com> Message-ID: <4FE9FF2E.1090904@oracle.com> Hi Sara, There is also a posting on the Oracle Forums indicating that the problem is happening on Apples Java as well. No release version is mentioned, though it was posted on June 7th. 10.7.4 was released on, or about, May 9th. At that point the 6u31 seems to be the most current release. https://forums.oracle.com/forums/thread.jspa?threadID=2399029 The likely configuration there is 10.7.4 with 6u31, but just a guess. 6u31 notes (last updated April 13th) https://support.apple.com/kb/HT5242 -Roger On 6/26/12 10:40 AM, Sara Burke wrote: > Hi all, > > I am new on this list, so I do apologize for any format issues. > > I came across a post to this mailing list of which I am having the same issue so I was wondering if anyone has heard of any root causes and/or workarounds: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-June/004407.html > > More details: > > My application emits the following messages; for easier reading, MY_APP replaces the actual application name: > > Jun 1 14:49:12 sburke-maci MY_APP[5611]: CGContextGetCTM: invalid context 0x0 > Jun 1 14:49:12 sburke-maci MY_APP[5611]: CGContextSetBaseCTM: invalid context 0x0 > Jun 1 14:49:12 sburke-maci MY_APP[5611]: CGContextGetCTM: invalid context 0x0 > Jun 1 14:49:12 sburke-maci MY_APP[5611]: CGContextSetBaseCTM: invalid context 0x0 > > Same messages with my sample Java application. > > This did not happen in Mac OS X versions prior to 10.7.4. I confirmed that this still occurs in the latest developer preview of Mountain Lion and the latest Java SE 7, including OpenJDK 7. > Regardless of whether or not this is a Java-related issue, the fact that these messages suddenly appeared with 10.7.4 insinuates that there is an OS bug somewhere or perhaps someone left in some debugging print statements. > Posting this topic here to see if anyone else has come across this issue and/or knows of a workaround. > > Thanks, > Sara > > > > ----------------------------------------------------------------- > Sara M. Burke > Ext. 7476 > From Sara.Burke at mathworks.com Tue Jun 26 11:36:55 2012 From: Sara.Burke at mathworks.com (Sara Burke) Date: Tue, 26 Jun 2012 18:36:55 +0000 Subject: : CGContextGetCTM messages In-Reply-To: <4FE9FF2E.1090904@oracle.com> References: <1DB09293-50B5-462F-BD42-6968F40583C3@mathworks.com> <4FE9FF2E.1090904@oracle.com> Message-ID: Roger, that post to the Oracle forums is indeed the same issue. Yes, this happens to me with the following Java versions: Java SE 6 1.6.0_29 (Apple) Java SE 6 1.6.0_31 (Apple) Java SE 7 1.7.0_04 (Oracle) OpenJDK 7 binary from Oracle >From this I suppose we can conclude this isn't necessarily related to OpenJDK 7, so I won't prolong this on the mailing list :) Thanks everyone! -S On Jun 26, 2012, at 2:27 PM, Roger Lewis wrote: Hi Sara, There is also a posting on the Oracle Forums indicating that the problem is happening on Apples Java as well. No release version is mentioned, though it was posted on June 7th. 10.7.4 was released on, or about, May 9th. At that point the 6u31 seems to be the most current release. https://forums.oracle.com/forums/thread.jspa?threadID=2399029 The likely configuration there is 10.7.4 with 6u31, but just a guess. 6u31 notes (last updated April 13th) https://support.apple.com/kb/HT5242 -Roger On 6/26/12 10:40 AM, Sara Burke wrote: Hi all, I am new on this list, so I do apologize for any format issues. I came across a post to this mailing list of which I am having the same issue so I was wondering if anyone has heard of any root causes and/or workarounds: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-June/004407.html More details: My application emits the following messages; for easier reading, MY_APP replaces the actual application name: Jun 1 14:49:12 sburke-maci MY_APP[5611]: CGContextGetCTM: invalid context 0x0 Jun 1 14:49:12 sburke-maci MY_APP[5611]: CGContextSetBaseCTM: invalid context 0x0 Jun 1 14:49:12 sburke-maci MY_APP[5611]: CGContextGetCTM: invalid context 0x0 Jun 1 14:49:12 sburke-maci MY_APP[5611]: CGContextSetBaseCTM: invalid context 0x0 Same messages with my sample Java application. This did not happen in Mac OS X versions prior to 10.7.4. I confirmed that this still occurs in the latest developer preview of Mountain Lion and the latest Java SE 7, including OpenJDK 7. Regardless of whether or not this is a Java-related issue, the fact that these messages suddenly appeared with 10.7.4 insinuates that there is an OS bug somewhere or perhaps someone left in some debugging print statements. Posting this topic here to see if anyone else has come across this issue and/or knows of a workaround. Thanks, Sara ----------------------------------------------------------------- Sara M. Burke Ext. 7476 ----------------------------------------------------------------- Sara M. Burke Ext. 7476 From gregg at wonderly.org Tue Jun 26 12:24:54 2012 From: gregg at wonderly.org (Gregg Wonderly) Date: Tue, 26 Jun 2012 14:24:54 -0500 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE9CEF3.8080905@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <4FE94F6F.2060002@oracle.com> <4FE94FED.6050406@oracle.com> <4FE9CEF3.8080905@oracle.com> Message-ID: <854ADF35-EC9F-4C3A-B062-39FCCAA47015@wonderly.org> On Jun 26, 2012, at 10:02 AM, Alan Bateman wrote: > > Do the tests assume they are run on HFS? Just wondering if you you need to look at the FileStore name/type to check. TensComplement's ZFS port (ZEVO) to MacOSX may need some consideration if HFS is going to be the only test bed. Gregg Wonderly From xueming.shen at oracle.com Tue Jun 26 20:33:50 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 26 Jun 2012 20:33:50 -0700 Subject: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE9CEF3.8080905@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <4FE94F6F.2060002@oracle.com> <4FE94FED.6050406@oracle.com> <4FE9CEF3.8080905@oracle.com> Message-ID: <4FEA7F1E.4070500@oracle.com> Alan, Webrev has been updated accordingly at http://cr.openjdk.java.net/~sherman/7130915/webrev with changes (1) added a CFStringCreateMutable(...) != null check in both io and nio native, though it is unlikely to fail here because we are passing a NULL and 0 length, like new StringBuilder() invocation, if it fails the system probably goes very wrong. Both FStringAppendCharacters and CFStringNormalize are void return type. (2) The first line of path.toCharArray in normalizeJavaPath is a typo, it is supposed to be deleted. The implementation only goes toCharArray when it needs to go native. Currently it uses >0x80 as the fast path criteria, it is possible to expose some sun.text.normalizer's internal methods to have a "quick nfc" check, but I'm not sure how much the performance gain would be, but might worth some investigation later. (3) Comments have been added for those override-able methods in UnixFileSystem. (4) blank lines have been removed from dispatcher.c (5) I don't think we need to do the HFS check, given we are only doing nfc/nfd stuff now, as long as it is a MacOSX, I believe its nfc/nfd layer will be there. Copyright has been re-copy/ pasted and we now only use only bugid. -Sherman On 6/26/12 8:02 AM, Alan Bateman wrote: > On 26/06/2012 07:00, Xueming Shen wrote: >> On 6/25/12 10:58 PM, Xueming Shen wrote: >>> Hi, >>> >>> While I still believe that case-insensitive is the right choice for >>> File/Path on MacOSX, it is >>> suggested that we might want to be a little conservative in this >>> patch, with the assumption >>> that this patch will be backport to 7u release after being baked in >>> jdk8 for a while (given >>> Apple's JDK6 is case sensitive for File, it might be too much for a >>> update releases to go >>> with two in-compatible changes, case sensitive and hash32). >>> >>> So here is the webrev for a strip-down version from the original >>> patch, in which it only >>> targets the nfd/nfc issue raised in 7130915 and 7168427. The >>> proposed changes for >>> case insensitive compare and hash32 for both java.io.File and >>> java.nio.file.Path are >>> removed. >>> >>> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev >>> >>> (The webrev for the "full" version has been moved to >>> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev_full) >>> >>> Thanks, >>> -Sherman > I had to dig up the File Systems, Unicode, and Normalization > presentation [1] before reviewing this, it's been a while. > > I think the changes for java.io for fine, I just worry that there may > be a few odd cases where it will be different to Apple JDK6. I looked > through the macosx-port/macosx-port/jdk forest and there is one patch > from Apple that does the NFC->NFD conversation. I don't get that patch > because you say that the syscalls handle NFC okay. In your changes > then you normalize when decoding the file names to Strings, which > seems right but that seems to be completely missing from the changes > that Apple brought over. The only minor comment is that we probably > need to check the return from core foundation functions such as > CFStringCreateMutable (this goes for the other native code too). > > Adding the FileSystemProvider for MacOSX is great to see. The approach > is fine for but is somewhat inefficient when ->NFD or ->NFC is needed. > One inefficiency that can be fixed is in sun.nio.fs.MacOSXFileSystem. > normalizeJavaPath then you can eliminate the second call to > toCharArray. I think the new methods on sun.no.fs.UnixFileSystem > should be given comments so that it's clear whether they should be > overridden (the Unix* provider tends to be starting point for most > ports). A minor comment is that MacOSXNativeDispatcher has a bunch of > blank lines at the end, also I think "static final" is more normal > than "final static". At some point I think we should re-write > MacOSXNativeDispatcher.normalizepath so that it deosn't require the > critical section or malloc as in this area we try to keep the native > methods to a bare minimum. > > Do the tests assume they are run on HFS? Just wondering if you you > need to look at the FileStore name/type to check. Some of variable > namesa bit non-standard, very C like. Minor nit is that the copyright > in the header isn't right in the tests. Also the tests list 2 CRs > whereas I assume this is one CR (with the other closed as a dup). > > On case sensitive vs. insensitive then I think it should be > insensitive as per the first round but that would be a significant > change given that Apple's JDK does not appear to have changed > File.equals. Maybe we should think about this again once these changes > are in 8. > > -Alan > > [1] > http://developers.sun.com/global/products_platforms/solaris/reference/presentations/IUC29-FileSystems.pdf From Alan.Bateman at oracle.com Tue Jun 26 23:41:37 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Jun 2012 07:41:37 +0100 Subject: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FEA7F1E.4070500@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <4FE94F6F.2060002@oracle.com> <4FE94FED.6050406@oracle.com> <4FE9CEF3.8080905@oracle.com> <4FEA7F1E.4070500@oracle.com> Message-ID: <4FEAAB21.9050205@oracle.com> On 27/06/2012 04:33, Xueming Shen wrote: > Alan, > > Webrev has been updated accordingly at > > http://cr.openjdk.java.net/~sherman/7130915/webrev > > with changes > > (1) added a CFStringCreateMutable(...) != null check in both io and > nio native, though it is > unlikely to fail here because we are passing a NULL and 0 > length, like new StringBuilder() > invocation, if it fails the system probably goes very wrong. Both > FStringAppendCharacters > and CFStringNormalize are void return type. > > (2) The first line of path.toCharArray in normalizeJavaPath is a typo, > it is supposed to be > deleted. The implementation only goes toCharArray when it needs > to go native. Currently > it uses >0x80 as the fast path criteria, it is possible to expose > some sun.text.normalizer's > internal methods to have a "quick nfc" check, but I'm not sure > how much the performance > gain would be, but might worth some investigation later. > > (3) Comments have been added for those override-able methods in > UnixFileSystem. > > (4) blank lines have been removed from dispatcher.c > > (5) I don't think we need to do the HFS check, given we are only doing > nfc/nfd stuff now, as > long as it is a MacOSX, I believe its nfc/nfd layer will be > there. Copyright has been re-copy/ > pasted and we now only use only bugid. > > -Sherman I'm heading away on vacation now and only quickly scanned the updated webrev. All looks okay to me. On the calls to the CF functions then one thing is that if they fail (and this is unlikely I know) then you won't have an exception pending so may need to add code to call one of the JNU* functions to throw OOME, otherwise it might cause a NPE in the caller rather than throwing an exception as you would expect. -Alan From xueming.shen at oracle.com Wed Jun 27 00:03:13 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 27 Jun 2012 00:03:13 -0700 Subject: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FEAAB21.9050205@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <4FE94F6F.2060002@oracle.com> <4FE94FED.6050406@oracle.com> <4FE9CEF3.8080905@oracle.com> <4FEA7F1E.4070500@oracle.com> <4FEAAB21.9050205@oracle.com> Message-ID: <4FEAB031.4080107@oracle.com> Thanks Alan! The webrev has been updated to throw OOME as your other nio native dispatcher does. http://cr.openjdk.java.net/~sherman/7130915/webrev. I can wait for your back from the vacation:-) -Sherman On 6/26/12 11:41 PM, Alan Bateman wrote: > On 27/06/2012 04:33, Xueming Shen wrote: >> Alan, >> >> Webrev has been updated accordingly at >> >> http://cr.openjdk.java.net/~sherman/7130915/webrev >> >> with changes >> >> (1) added a CFStringCreateMutable(...) != null check in both io and >> nio native, though it is >> unlikely to fail here because we are passing a NULL and 0 >> length, like new StringBuilder() >> invocation, if it fails the system probably goes very wrong. >> Both FStringAppendCharacters >> and CFStringNormalize are void return type. >> >> (2) The first line of path.toCharArray in normalizeJavaPath is a >> typo, it is supposed to be >> deleted. The implementation only goes toCharArray when it needs >> to go native. Currently >> it uses >0x80 as the fast path criteria, it is possible to >> expose some sun.text.normalizer's >> internal methods to have a "quick nfc" check, but I'm not sure >> how much the performance >> gain would be, but might worth some investigation later. >> >> (3) Comments have been added for those override-able methods in >> UnixFileSystem. >> >> (4) blank lines have been removed from dispatcher.c >> >> (5) I don't think we need to do the HFS check, given we are only >> doing nfc/nfd stuff now, as >> long as it is a MacOSX, I believe its nfc/nfd layer will be >> there. Copyright has been re-copy/ >> pasted and we now only use only bugid. >> >> -Sherman > I'm heading away on vacation now and only quickly scanned the updated > webrev. All looks okay to me. On the calls to the CF functions then > one thing is that if they fail (and this is unlikely I know) then you > won't have an exception pending so may need to add code to call one of > the JNU* functions to throw OOME, otherwise it might cause a NPE in > the caller rather than throwing an exception as you would expect. > > -Alan > From henri.gomez at gmail.com Wed Jun 27 00:13:16 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 27 Jun 2012 09:13:16 +0200 Subject: 32 bit version of MacOSX Port (OpenJDK) In-Reply-To: References: Message-ID: > Hi, > > Do we know *yet* whether or not there will be a 32 bit version of the > OpenJDK MacOSX Port ? > > We would need to know as business decisions on present capability may be > impacted. > > Thanks to anyone in the know. Happy to see someone else wondering about a 32bits version of OpenJDK for OSX. For now, there is just no support for 32 bits or Universal mode version of OpenJDK in project. I back ported some old macosx-port patches to reintroduce Universal mode in OpenJDK 7u : http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch I asked for an official review and Scott say it was ok but there is still no decision from OpenJDK management to apply them. You should know there is SIGSEVG problems with Universal (32/64) bits OpenJDK released with such patch on http://openjdk-osx-build.googlecode.com/, problems reported here but without any reply yet. -d32 works in client mode but crash in server mode. This one should be fixed before considering using OpenJDK 7 universal for you own usage and why not have universal mode reintroduce into OpenJDK 7u/8 forests. From dkocher at sudo.ch Wed Jun 27 00:28:50 2012 From: dkocher at sudo.ch (David Kocher) Date: Wed, 27 Jun 2012 09:28:50 +0200 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE74719.8080709@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> Message-ID: <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> I welcome this issue is getting some serious attention then. When will this be backported to 7u? -- David On 24.06.2012, at 18:58, Xueming Shen wrote: > > Yes, I believe the issue described in MACOSX_PORT-165 is the > same issue this patch is trying to solve. > > Btw, it appears there are typos in the note(2), my mini keyboard obviously > is too sticky:-) > > (2) normalize the resulting file name from macosx fs APIs from nfd->nfc before passing > back to java.io.File (File.list() and canonicalize()), so we deal with nfc file name > (as "usual") for java.io classes/APIs. > > -sherman > > On 6/24/12 7:50 AM, David Kocher wrote: >> Will this address issue MACOSX_PORT-165 [1]? >> >> [1] http://java.net/jira/browse/MACOSX_PORT-165 >> >> -- David >> >> On 22.06.2012, at 19:01, Xueming Shen wrote: >> >>> Hi >>> >>> Here is the proposed change to support Unicode nfd/nfc and case insensitive >>> file path on MacOSX file system. >>> >>> 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X >>> 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] >>> >>> While these two bug reports are only against java.io, we have the same issue in javax.nio.file. >>> Here is the webrev >>> >>> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ >>> >>> Here is the brief summary of the changes >>> >>> java.io.File: >>> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means >>> we are now passing nfc/composite characters directly into macosx file system APIs >>> without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses >>> nfd. >>> >>> (2) normalize the resulting file name from macosx fs APIs from nfd->nfd before passing >>> back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name >>> (as "usual") for java.io classes/APIs. >>> >>> (3) fs.compare()/hashCode() was updated to be case insensitive >>> >>> (4) hasCode() was updated to use the new String.hash32(). >>> >>> java.nio.file: >>> >>> (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to >>> update those BsdFile... classes directly to address the macosx specific issues. But given >>> there might be developers over there might work on open jdk BSD port and have dependency >>> on these classes, it might be desirable to have another separate layer of MacOSXFile... >>> classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and >>> MacOSXFileSystem. >>> >>> (6) the "main" changes are in MacOSXFileSystem, in which the corresponding methods >>> were added to handle, case insensitive and nfd<=>nfc normalization, including the >>> pathmatcher. >>> >>> (7) compare is now are case-insensitive >>> >>> (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. >>> >>> >>> Though lots of files have been touched, but the line of changes are actually relatively >>> small. >>> >>> The proposed change only deals with the default case-sensitiveness seting, which is >>> case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the >>> mounted vol to be case-sensitive. A possible approach is to have some extra FileStore >>> attributes, such as a isCaseSensitive and to use case sensitive compare/equal on >>> such fs, but this can be dealt with separately later. >>> >>> Thanks, >>> -Sherman >>> > > From staffan.larsen at oracle.com Wed Jun 27 01:13:16 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 27 Jun 2012 10:13:16 +0200 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: <47E96839-1BDB-42F2-BC45-D1A98559813C@oracle.com> References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> <4FE3C86D.2080008@oracle.com> <47E96839-1BDB-42F2-BC45-D1A98559813C@oracle.com> Message-ID: Can I have a Review for this change, please? The very simple fix is here: http://cr.openjdk.java.net/~sla/7178667/webrev.02/ Thanks, /Staffan On 25 jun 2012, at 10:36, Staffan Larsen wrote: > >>>> So, it sounds like when you rebuilt, everything was built into jre/lib/i386 and jre/lib/amd64, but never combined (or, in this case, just copied) into jre/lib, and therefore not found. >>> >>> Yes. Or rather, only the client jvm was combined, but the client jvm isn't copied into the j2sdk-image on mac, so nothing was copied. >> >> Which begs the question: if we only build 64-bit on OSX then how/why is client being built in the first place? > > I should have said: "only the client jvm was _attempted_ to be combined". In fact, the client does not exist, but the universalize makefiles are written to handle client if it did exist. > > So what happened was: > - the product jvm was built > - it was copied to the import jdk (into jre/lib/amd64/server/) by the generic_export target > - the universalize makefile tried to take the client jvm and universalize it into jre/lib/client/ (notice that there is no amd64 directory level on mac) > - the universalize makefile removes all {amd64,i386} directories > > What should have happened: > - the product jvm was built > - it was copied to the import jdk (into jre/lib/amd64/server/) by the generic_export target > - the universalize makefile makes a universal binary of any existing jvms (client or server) > - the universalize makefile copies these jvms into jre/lib/{server,client} > - the universalize makefile removes all {amd64,i386} directories > > But because the targets weren't .PHONY, the third step above failed. > > I hope that explains the problem in more detail. Who wants to be put down as reviewer? > > Thanks, > /Staffan > From Dmitry.Samersoff at oracle.com Wed Jun 27 03:03:01 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 27 Jun 2012 14:03:01 +0400 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> <4FE3C86D.2080008@oracle.com> <47E96839-1BDB-42F2-BC45-D1A98559813C@oracle.com> Message-ID: <4FEADA55.40701@oracle.com> Looks good for me. -Dmitry On 2012-06-27 12:13, Staffan Larsen wrote: > Can I have a Review for this change, please? > > The very simple fix is > here: http://cr.openjdk.java.net/~sla/7178667/webrev.02/ > > Thanks, > /Staffan > > On 25 jun 2012, at 10:36, Staffan Larsen wrote: > >> >>>>> So, it sounds like when you rebuilt, everything was built into >>>>> jre/lib/i386 and jre/lib/amd64, but never combined (or, in this >>>>> case, just copied) into jre/lib, and therefore not found. >>>> >>>> Yes. Or rather, only the client jvm was combined, but the client jvm >>>> isn't copied into the j2sdk-image on mac, so nothing was copied. >>> >>> Which begs the question: if we only build 64-bit on OSX then how/why >>> is client being built in the first place? >> >> I should have said: "only the client jvm was _attempted_ to be >> combined". In fact, the client does not exist, but the universalize >> makefiles are written to handle client if it did exist. >> >> So what happened was: >> - the product jvm was built >> - it was copied to the import jdk (into jre/lib/amd64/server/) by the >> generic_export target >> - the universalize makefile tried to take the client jvm and >> universalize it into jre/lib/client/ (notice that there is no amd64 >> directory level on mac) >> - the universalize makefile removes all {amd64,i386} directories >> >> What should have happened: >> - the product jvm was built >> - it was copied to the import jdk (into jre/lib/amd64/server/) by the >> generic_export target >> - the universalize makefile makes a universal binary of any existing >> jvms (client or server) >> - the universalize makefile copies these jvms into jre/lib/{server,client} >> - the universalize makefile removes all {amd64,i386} directories >> >> But because the targets weren't .PHONY, the third step above failed. >> >> I hope that explains the problem in more detail. Who wants to be put >> down as reviewer? >> >> Thanks, >> /Staffan >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From david.holmes at oracle.com Wed Jun 27 04:22:27 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jun 2012 21:22:27 +1000 Subject: RFR (S): 7178667: ALT_EXPORT_PATH does not export server jvm on macosx In-Reply-To: References: <0BEEBFB0-B103-418F-BD96-D3C497879A17@oracle.com> <4FE30F94.7030700@oracle.com> <4FE316D5.3020502@oracle.com> <4FE3C86D.2080008@oracle.com> <47E96839-1BDB-42F2-BC45-D1A98559813C@oracle.com> Message-ID: <4FEAECF3.3020408@oracle.com> On 27/06/2012 6:13 PM, Staffan Larsen wrote: > Can I have a Review for this change, please? Ok. :) David > The very simple fix is here: > http://cr.openjdk.java.net/~sla/7178667/webrev.02/ > > Thanks, > /Staffan > > On 25 jun 2012, at 10:36, Staffan Larsen wrote: > >> >>>>> So, it sounds like when you rebuilt, everything was built into >>>>> jre/lib/i386 and jre/lib/amd64, but never combined (or, in this >>>>> case, just copied) into jre/lib, and therefore not found. >>>> >>>> Yes. Or rather, only the client jvm was combined, but the client jvm >>>> isn't copied into the j2sdk-image on mac, so nothing was copied. >>> >>> Which begs the question: if we only build 64-bit on OSX then how/why >>> is client being built in the first place? >> >> I should have said: "only the client jvm was _attempted_ to be >> combined". In fact, the client does not exist, but the universalize >> makefiles are written to handle client if it did exist. >> >> So what happened was: >> - the product jvm was built >> - it was copied to the import jdk (into jre/lib/amd64/server/) by the >> generic_export target >> - the universalize makefile tried to take the client jvm and >> universalize it into jre/lib/client/ (notice that there is no amd64 >> directory level on mac) >> - the universalize makefile removes all {amd64,i386} directories >> >> What should have happened: >> - the product jvm was built >> - it was copied to the import jdk (into jre/lib/amd64/server/) by the >> generic_export target >> - the universalize makefile makes a universal binary of any existing >> jvms (client or server) >> - the universalize makefile copies these jvms into jre/lib/{server,client} >> - the universalize makefile removes all {amd64,i386} directories >> >> But because the targets weren't .PHONY, the third step above failed. >> >> I hope that explains the problem in more detail. Who wants to be put >> down as reviewer? >> >> Thanks, >> /Staffan >> > From hs at tagtraum.com Thu Jun 28 00:23:48 2012 From: hs at tagtraum.com (Hendrik Schreiber) Date: Thu, 28 Jun 2012 09:23:48 +0200 Subject: retina support Message-ID: Hi, starting with the new Retina enabled MacBook Pro Apple has started offering Retina support in regular computers. This is a challenge to Java devs, because as of now, Java's support for Retina is? not so great. Please see the discussion at http://lists.apple.com/archives/java-dev/2012/Jun/msg00094.html Some sort of mechanism is needed that does not rely on NSImage trickery, but still supports correct rendering in HiDPI mode. Do you guys have support for this in the pipeline? Perhaps there is already a bug in the database? Thanks, -hendrik From anthony.petrov at oracle.com Thu Jun 28 05:37:44 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 28 Jun 2012 16:37:44 +0400 Subject: retina support In-Reply-To: References: Message-ID: <4FEC5018.5030602@oracle.com> There's a CR: CR 6486815 RFE: initial Swing support for resolution independence Though there's no progress on it since 2006. -- best regards, Anthony On 06/28/12 11:23, Hendrik Schreiber wrote: > Hi, > > starting with the new Retina enabled MacBook Pro Apple has started offering Retina support in regular computers. This is a challenge to Java devs, because as of now, Java's support for Retina is? not so great. > > Please see the discussion at http://lists.apple.com/archives/java-dev/2012/Jun/msg00094.html > > Some sort of mechanism is needed that does not rely on NSImage trickery, but still supports correct rendering in HiDPI mode. > Do you guys have support for this in the pipeline? Perhaps there is already a bug in the database? > > Thanks, > > -hendrik From anthony.petrov at oracle.com Thu Jun 28 05:40:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 28 Jun 2012 16:40:22 +0400 Subject: retina support In-Reply-To: <4FEC5018.5030602@oracle.com> References: <4FEC5018.5030602@oracle.com> Message-ID: <4FEC50B6.3040804@oracle.com> And also, one more Mac-specific CR: 7124410 [macosx] Lion HiDPI support -- best regards, Anthony On 06/28/12 16:37, Anthony Petrov wrote: > There's a CR: > > CR 6486815 RFE: initial Swing support for resolution independence > > Though there's no progress on it since 2006. > > -- > best regards, > Anthony > > On 06/28/12 11:23, Hendrik Schreiber wrote: >> Hi, >> >> starting with the new Retina enabled MacBook Pro Apple has started >> offering Retina support in regular computers. This is a challenge to >> Java devs, because as of now, Java's support for Retina is? not so great. >> >> Please see the discussion at >> http://lists.apple.com/archives/java-dev/2012/Jun/msg00094.html >> >> Some sort of mechanism is needed that does not rely on NSImage >> trickery, but still supports correct rendering in HiDPI mode. >> Do you guys have support for this in the pipeline? Perhaps there is >> already a bug in the database? >> >> Thanks, >> >> -hendrik From hs at tagtraum.com Thu Jun 28 05:43:27 2012 From: hs at tagtraum.com (Hendrik Schreiber) Date: Thu, 28 Jun 2012 14:43:27 +0200 Subject: retina support In-Reply-To: <4FEC50B6.3040804@oracle.com> References: <4FEC5018.5030602@oracle.com> <4FEC50B6.3040804@oracle.com> Message-ID: I guess the last one you mention is more appropriate for the issue at hand: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124410 Is anybody working on this? I mean - has it hit Oracle's radar at all? -hendrik On Jun 28, 2012, at 2:40 PM, Anthony Petrov wrote: > And also, one more Mac-specific CR: > > 7124410 [macosx] Lion HiDPI support > > -- > best regards, > Anthony > > On 06/28/12 16:37, Anthony Petrov wrote: >> There's a CR: >> >> CR 6486815 RFE: initial Swing support for resolution independence >> >> Though there's no progress on it since 2006. >> >> -- >> best regards, >> Anthony >> >> On 06/28/12 11:23, Hendrik Schreiber wrote: >>> Hi, >>> >>> starting with the new Retina enabled MacBook Pro Apple has started >>> offering Retina support in regular computers. This is a challenge to >>> Java devs, because as of now, Java's support for Retina is? not so great. >>> >>> Please see the discussion at >>> http://lists.apple.com/archives/java-dev/2012/Jun/msg00094.html >>> >>> Some sort of mechanism is needed that does not rely on NSImage >>> trickery, but still supports correct rendering in HiDPI mode. >>> Do you guys have support for this in the pipeline? Perhaps there is >>> already a bug in the database? >>> >>> Thanks, >>> >>> -hendrik From artem.ananiev at oracle.com Thu Jun 28 05:56:48 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 28 Jun 2012 16:56:48 +0400 Subject: retina support In-Reply-To: References: <4FEC5018.5030602@oracle.com> <4FEC50B6.3040804@oracle.com> Message-ID: <4FEC5490.8080002@oracle.com> On 6/28/2012 4:43 PM, Hendrik Schreiber wrote: > I guess the last one you mention is more appropriate for the issue at hand: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124410 > > Is anybody working on this? I mean - has it hit Oracle's radar at all? It's on radar, both AWT/Swing and JavaFX teams are aware of this issue. I can't say for sure what release the fix(es) are targeted to, but very unlikely we'll implement HiDPI support on Mac in 7uX (JDK) and 2.x (JavaFX). Thanks, Artem > -hendrik > > On Jun 28, 2012, at 2:40 PM, Anthony Petrov wrote: > >> And also, one more Mac-specific CR: >> >> 7124410 [macosx] Lion HiDPI support >> >> -- >> best regards, >> Anthony >> >> On 06/28/12 16:37, Anthony Petrov wrote: >>> There's a CR: >>> >>> CR 6486815 RFE: initial Swing support for resolution independence >>> >>> Though there's no progress on it since 2006. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 06/28/12 11:23, Hendrik Schreiber wrote: >>>> Hi, >>>> >>>> starting with the new Retina enabled MacBook Pro Apple has started >>>> offering Retina support in regular computers. This is a challenge to >>>> Java devs, because as of now, Java's support for Retina is? not so great. >>>> >>>> Please see the discussion at >>>> http://lists.apple.com/archives/java-dev/2012/Jun/msg00094.html >>>> >>>> Some sort of mechanism is needed that does not rely on NSImage >>>> trickery, but still supports correct rendering in HiDPI mode. >>>> Do you guys have support for this in the pipeline? Perhaps there is >>>> already a bug in the database? >>>> >>>> Thanks, >>>> >>>> -hendrik > From anthony.petrov at oracle.com Thu Jun 28 05:59:11 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 28 Jun 2012 16:59:11 +0400 Subject: retina support In-Reply-To: References: <4FEC5018.5030602@oracle.com> <4FEC50B6.3040804@oracle.com> Message-ID: <4FEC551F.8030907@oracle.com> The bug is in our database, and it is targeted for JDK 8. So sooner or later there will be a fix. Also, why do you think it is important to hit "Oracle's radar"? OpenJDK is an open source project, and anyone can look at our bugs database and find an interesting task to work on. If you wish, you could develop a fix for this issue yourself, and we'd be happy to review it on this mailing list. -- best regards, Anthony On 06/28/12 16:43, Hendrik Schreiber wrote: > I guess the last one you mention is more appropriate for the issue at hand: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124410 > > Is anybody working on this? I mean - has it hit Oracle's radar at all? > > -hendrik > > On Jun 28, 2012, at 2:40 PM, Anthony Petrov wrote: > >> And also, one more Mac-specific CR: >> >> 7124410 [macosx] Lion HiDPI support >> >> -- >> best regards, >> Anthony >> >> On 06/28/12 16:37, Anthony Petrov wrote: >>> There's a CR: >>> >>> CR 6486815 RFE: initial Swing support for resolution independence >>> >>> Though there's no progress on it since 2006. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 06/28/12 11:23, Hendrik Schreiber wrote: >>>> Hi, >>>> >>>> starting with the new Retina enabled MacBook Pro Apple has started >>>> offering Retina support in regular computers. This is a challenge to >>>> Java devs, because as of now, Java's support for Retina is? not so great. >>>> >>>> Please see the discussion at >>>> http://lists.apple.com/archives/java-dev/2012/Jun/msg00094.html >>>> >>>> Some sort of mechanism is needed that does not rely on NSImage >>>> trickery, but still supports correct rendering in HiDPI mode. >>>> Do you guys have support for this in the pipeline? Perhaps there is >>>> already a bug in the database? >>>> >>>> Thanks, >>>> >>>> -hendrik > From hs at tagtraum.com Thu Jun 28 06:07:29 2012 From: hs at tagtraum.com (Hendrik Schreiber) Date: Thu, 28 Jun 2012 15:07:29 +0200 Subject: retina support In-Reply-To: <4FEC551F.8030907@oracle.com> References: <4FEC5018.5030602@oracle.com> <4FEC50B6.3040804@oracle.com> <4FEC551F.8030907@oracle.com> Message-ID: On Jun 28, 2012, at 2:59 PM, Anthony Petrov wrote: > The bug is in our database, and it is targeted for JDK 8. So sooner or later there will be a fix. > > Also, why do you think it is important to hit "Oracle's radar"? Whether a bug report exists or not, is almost irrelevant. Somebody actually has to think it's important to fix it and put in the necessary hours for it to make a difference. That's what I meant. Who exactly does it, whether it's people paid by Oracle (like, I assume: you), or a volunteer, I don't care. I just wanted to know, whether people working on the JRE are aware of the problem and working on it. > OpenJDK is an open source project, and anyone can look at our bugs database and find an interesting task to work on. If you wish, you could develop a fix for this issue yourself, and we'd be happy to review it on this mailing list. Unfortunately, I neither have the skill nor the time, but am grateful to those of you who do. -hendrik From joe.mcglynn at oracle.com Thu Jun 28 06:35:51 2012 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Thu, 28 Jun 2012 06:35:51 -0700 Subject: retina support In-Reply-To: References: <4FEC5018.5030602@oracle.com> <4FEC50B6.3040804@oracle.com> <4FEC551F.8030907@oracle.com> Message-ID: We're aware of the problem, and intend to address it. We haven't done enough work to be confident of the full impact/scope yet. As we know more we'll share what we can. If anyone has input on this -- whether it is contributing to the implementation of a solution, or just identifying specific scenarios that need to be addressed -- it would be a big help. The existing CR that Mike filed is an umbrella bug, and the first step is to understand the scope of the problem. Where does HiDPI cause rendering issues? Are there non-visual problems like performance or reliability? You can file additional issues for specific cases and link them as related issues under 7124410. Joe McGlynn | Senior Software Manager Phone: +1 4082763383 | Mobile: +1 8312399494 Oracle Java Platform 4220 Network Circle | Santa Clara, CA 95054 Skype: joebmcglynn Oracle is committed to developing practices and products that help protect the environment On Jun 28, 2012, at 6:07 AM, Hendrik Schreiber wrote: > On Jun 28, 2012, at 2:59 PM, Anthony Petrov wrote: > >> The bug is in our database, and it is targeted for JDK 8. So sooner or later there will be a fix. >> >> Also, why do you think it is important to hit "Oracle's radar"? > > Whether a bug report exists or not, is almost irrelevant. > Somebody actually has to think it's important to fix it and put in the necessary hours for it to make a difference. > > That's what I meant. Who exactly does it, whether it's people paid by Oracle (like, I assume: you), or a volunteer, I don't care. I just wanted to know, whether people working on the JRE are aware of the problem and working on it. > >> OpenJDK is an open source project, and anyone can look at our bugs database and find an interesting task to work on. If you wish, you could develop a fix for this issue yourself, and we'd be happy to review it on this mailing list. > > Unfortunately, I neither have the skill nor the time, but am grateful to those of you who do. > > -hendrik From Sergey.Bylokhov at oracle.com Thu Jun 28 08:39:40 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 28 Jun 2012 19:39:40 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FE880D0.3080108@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FD895F1.3040605@oracle.com> <4FE8407C.7060103@oracle.com> <4FE880D0.3080108@oracle.com> Message-ID: <4FEC7ABC.8070302@oracle.com> Hi Artem, Anthony. Updated webrev. http://cr.openjdk.java.net/~serb/7124244/webrev.04/ - CPlatformEmbeddedFrame now use correct backbuffer. - For simplification, creation of the backbuffer was reverted back. 25.06.2012 19:16, Artem Ananiev wrote: > Hi, Sergey, > > a few minor comments: > > 1. CPlatformWindow.java: invalidateShadow() in native is ready to be > called on any thread, so what's the reason behind invokeLater() here? > > 2. RepaintManager.java: the new field should better be named > "volatileBufferType". > > 3. LWComponentPeer.applyShape() is a peer method, which accepts > user-supplied object (right now it's constructed from Shape in AWT > internal code, but nothing prevents users from calling this method > directly), so it should be stored as a copy, not as a reference. > > Thanks, > > Artem > > On 6/25/2012 2:42 PM, Sergey Bylokhov wrote: >> Hi, Artem, Anthony. >> New version of the fix: >> http://cr.openjdk.java.net/~serb/7124244/webrev.01 >> >> 13.06.2012 06:30, Artem Ananiev wrote: >>> Hi, Sergey, >>> >>> a few minor comments: >>> >>> 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in >>> CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are >>> corresponding checks just above. >> done. >>> >>> 2. invalidateShadow() is not used in sun.lwawt, so it can be just a >>> method in CPlatformWindow. BTW, do you have any ideas, why CGLayer >>> holds a reference to LWWindowPeer, not to CPlatformWindow? >> done. >>> >>> 3. As we don't expect isSwingBackbufferTranslucencySupported() to >>> return different values, it would be fine to call it only once to >>> avoid possible perf regressions. >> done. >>> >>> Thanks, >>> >>> Artem >>> >>> On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >>>> Hi Everyone, >>>> Please review the fix. >>>> >>>> Shaped window was implemented as a translucent window with constrained >>>> graphics. Now translucent window doesn't use separate BufferedImage >>>> as a >>>> back buffer. Also alpha value for the swing back buffer was >>>> enabled(Shared code changed). >>>> Note that shaped windows are affected by this bugs: >>>> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >>>> - Shadows disappear. >>>> - Transparent areas aren't transparent to mouse clicks. >>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >>>> - Opacity does not work for non opaque windows. >>>> >>>> Any suggestions are welcome. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >>>> >> >> -- Best regards, Sergey. From swpalmer at gmail.com Thu Jun 28 10:11:01 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 28 Jun 2012 13:11:01 -0400 Subject: retina support In-Reply-To: References: <4FEC5018.5030602@oracle.com> <4FEC50B6.3040804@oracle.com> <4FEC551F.8030907@oracle.com> Message-ID: <22EA2DC5-4F6A-4610-A279-14B7B368D9B6@gmail.com> On 2012-06-28, at 9:35 AM, Joe McGlynn wrote: > We're aware of the problem, and intend to address it. We haven't done enough work to be confident of the full impact/scope yet. As we know more we'll share what we can. > > If anyone has input on this -- whether it is contributing to the implementation of a solution, or just identifying specific scenarios that need to be addressed -- it would be a big help. The existing CR that Mike filed is an umbrella bug, and the first step is to understand the scope of the problem. Where does HiDPI cause rendering issues? Are there non-visual problems like performance or reliability? You can file additional issues for specific cases and link them as related issues under 7124410. Is there a cross-platform mechanism to determine the (approximate) display DPI? I think that would at least allow for workarounds. For example, how far would a single scaling transform on the entire Scene in a JavaFX 2.x application go? I suspect that JavaFX UIs would not be as much of a problem as Swing UIs. Regards, Scott P. From anthony.petrov at oracle.com Fri Jun 29 05:25:44 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 29 Jun 2012 16:25:44 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FEC7ABC.8070302@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FD895F1.3040605@oracle.com> <4FE8407C.7060103@oracle.com> <4FE880D0.3080108@oracle.com> <4FEC7ABC.8070302@oracle.com> Message-ID: <4FED9EC8.3080508@oracle.com> Hi Sergey, The fix looks good. Btw, if you set a shape to a frame, will the Frame.printAll() use the shape correctly? E.g. an ellipse-shaped window must be printed as an ellipse. The parts laying outside of the shape shouldn't be printed. -- best regards, Anthony On 6/28/2012 7:39 PM, Sergey Bylokhov wrote: > Hi Artem, Anthony. > Updated webrev. > http://cr.openjdk.java.net/~serb/7124244/webrev.04/ > - CPlatformEmbeddedFrame now use correct backbuffer. > - For simplification, creation of the backbuffer was reverted back. > > 25.06.2012 19:16, Artem Ananiev wrote: >> Hi, Sergey, >> >> a few minor comments: >> >> 1. CPlatformWindow.java: invalidateShadow() in native is ready to be >> called on any thread, so what's the reason behind invokeLater() here? >> >> 2. RepaintManager.java: the new field should better be named >> "volatileBufferType". >> >> 3. LWComponentPeer.applyShape() is a peer method, which accepts >> user-supplied object (right now it's constructed from Shape in AWT >> internal code, but nothing prevents users from calling this method >> directly), so it should be stored as a copy, not as a reference. >> >> Thanks, >> >> Artem >> >> On 6/25/2012 2:42 PM, Sergey Bylokhov wrote: >>> Hi, Artem, Anthony. >>> New version of the fix: >>> http://cr.openjdk.java.net/~serb/7124244/webrev.01 >>> >>> 13.06.2012 06:30, Artem Ananiev wrote: >>>> Hi, Sergey, >>>> >>>> a few minor comments: >>>> >>>> 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in >>>> CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are >>>> corresponding checks just above. >>> done. >>>> >>>> 2. invalidateShadow() is not used in sun.lwawt, so it can be just a >>>> method in CPlatformWindow. BTW, do you have any ideas, why CGLayer >>>> holds a reference to LWWindowPeer, not to CPlatformWindow? >>> done. >>>> >>>> 3. As we don't expect isSwingBackbufferTranslucencySupported() to >>>> return different values, it would be fine to call it only once to >>>> avoid possible perf regressions. >>> done. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >>>>> Hi Everyone, >>>>> Please review the fix. >>>>> >>>>> Shaped window was implemented as a translucent window with constrained >>>>> graphics. Now translucent window doesn't use separate BufferedImage >>>>> as a >>>>> back buffer. Also alpha value for the swing back buffer was >>>>> enabled(Shared code changed). >>>>> Note that shaped windows are affected by this bugs: >>>>> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >>>>> - Shadows disappear. >>>>> - Transparent areas aren't transparent to mouse clicks. >>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >>>>> - Opacity does not work for non opaque windows. >>>>> >>>>> Any suggestions are welcome. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >>>>> >>> >>> > > From jcpalmer at rochester.rr.com Fri Jun 29 13:55:10 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Fri, 29 Jun 2012 16:55:10 -0400 Subject: "Place Java icon in system tray" Checkbox Message-ID: <74472B6E-780F-4886-838C-385FCD4D9E40@rochester.rr.com> Went through all the Java Control Panel tabs. One area of dubious meaning is the "Place Java icon in system tray" checkbox of the Miscellaneous section of the Advanced Tab. Does this have any meaning on this platform? I played with it, & nothing really happened. Grey it out maybe? See there is an entry in OSX Port Status Page talking about cleanup of control panel. The status page has not been updated in a while, though (and URL changed). The usefulness of listing of things this way may also have passed. Is there some idea of the things that are left? Is the port to the point of just knocking off more bugs? Are there also dependencies in 7u6 that are not Mac related? As an observer, there is no easy way to tell. Anything would be appreciated. Jeff Palmer From scott.kovatch at oracle.com Fri Jun 29 15:02:54 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 29 Jun 2012 15:02:54 -0700 Subject: "Place Java icon in system tray" Checkbox In-Reply-To: <74472B6E-780F-4886-838C-385FCD4D9E40@rochester.rr.com> References: <74472B6E-780F-4886-838C-385FCD4D9E40@rochester.rr.com> Message-ID: <67424F95-6694-47DC-AFAC-BCC73D939CB4@oracle.com> On Jun 29, 2012, at 1:55 PM, Jeff Palmer wrote: > Went through all the Java Control Panel tabs. > > One area of dubious meaning is the "Place Java icon in system tray" checkbox of the Miscellaneous section of the Advanced Tab. Does this have any meaning on this platform? I played with it, & nothing really happened. Grey it out maybe? Depending on which build you are running, this is a known problem. I believe b16 fixes this -- we weren't properly saving the state of that checkbox. When checked, you should see the menu extra/status item for Java appear in the menu bar when running an applet or Web Start app, just as it does in Java 6. It's a small version of the steaming coffee cup. Now that you mention it, though, I do agree that 'system tray' is completely the wrong terminology for Mac OS X, and should be changed. > See there is an entry in OSX Port Status Page talking about cleanup of control panel. This covered picking up most of the UI changes from Java Preferences.app and put them into the Java Control Panel. They should also be in b16. > The status page has not been updated in a while, though (and URL changed). The usefulness of listing of things this way may also have passed. > Is there some idea of the things that are left? Is the port to the point of just knocking off more bugs? Are there also dependencies in 7u6 that are not Mac related? It has been a while since I updated that list. We are down to the point of knocking out the worst bugs, primarily in the AWT, plugin and Web Start. I don't think it's been mentioned on this list, but we plan to move the entire JDK bug database to a JIRA-based system in the near future. That should make it easier to track your bugs of interest. And while I certainly appreciate the desire to be self-sufficient and the value doing your own research, asking about specifics on this list is fine, too. -- Scott ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA