From bradford.wetmore at oracle.com Tue May 1 13:52:37 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 01 May 2012 13:52:37 -0700 Subject: Apple Security Provider. Message-ID: <4FA04D15.2060408@oracle.com> Hi, Can someone who has knowledge of the Apple Java Cryptographic Service Provider for JDK 6 please contact me? There are several services which were available in the Apple provider from JDK6 but not present in the current JDK7u4 port. Just wondering about the history here. i.e. apple.security.AppleProvider Thanks, Brad From scott.kovatch at oracle.com Tue May 1 14:12:30 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 1 May 2012 14:12:30 -0700 Subject: Apple Security Provider. In-Reply-To: <4FA04D15.2060408@oracle.com> References: <4FA04D15.2060408@oracle.com> Message-ID: <8D612089-F140-4B3C-8AE3-9B4390FA92C4@oracle.com> I wrote a lot of that code originally, back in the day. It's possible some of it didn't get contributed to OpenJDK, but Mike Swingler or Alexander Strange would know more about its recent history. -- Scott On May 1, 2012, at 1:52 PM, Brad Wetmore wrote: > > Hi, > > Can someone who has knowledge of the Apple Java Cryptographic Service Provider for JDK 6 please contact me? There are several services which were available in the Apple provider from JDK6 but not present in the current JDK7u4 port. Just wondering about the history here. > > i.e. apple.security.AppleProvider > > Thanks, > > Brad > > From mik3hall at gmail.com Tue May 1 14:17:32 2012 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 1 May 2012 16:17:32 -0500 Subject: Apple Security Provider. In-Reply-To: <4FA04D15.2060408@oracle.com> References: <4FA04D15.2060408@oracle.com> Message-ID: <7C1CF7D5-B2A7-4A0D-B165-9D952800AF2A@gmail.com> On May 1, 2012, at 3:52 PM, Brad Wetmore wrote: > There are several services which were available in the Apple provider from JDK6 but not present in the current JDK7u4 port. Does that include using KeyChain as a keystore? I seem to remember a certain amount of mention concerning usage of that. Back a ways. From swingler at apple.com Tue May 1 14:57:10 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 01 May 2012 14:57:10 -0700 Subject: Apple Security Provider. In-Reply-To: <7C1CF7D5-B2A7-4A0D-B165-9D952800AF2A@gmail.com> References: <4FA04D15.2060408@oracle.com> <7C1CF7D5-B2A7-4A0D-B165-9D952800AF2A@gmail.com> Message-ID: <700AB04E-4E6D-4C68-A350-BBE61B264B7F@apple.com> On May 1, 2012, at 2:17 PM, Michael Hall wrote: > On May 1, 2012, at 3:52 PM, Brad Wetmore wrote: > >> There are several services which were available in the Apple provider from JDK6 but not present in the current JDK7u4 port. > > Does that include using KeyChain as a keystore? I seem to remember a certain amount of mention concerning usage of that. Back a ways. I believe we did port over the KeyChain provider, but not the entirely of the Apple provider (since it was based on deprecated API). Regards, Mike Swingler Apple Inc. From mik3hall at gmail.com Tue May 1 15:10:36 2012 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 1 May 2012 17:10:36 -0500 Subject: Apple Security Provider. In-Reply-To: <700AB04E-4E6D-4C68-A350-BBE61B264B7F@apple.com> References: <4FA04D15.2060408@oracle.com> <7C1CF7D5-B2A7-4A0D-B165-9D952800AF2A@gmail.com> <700AB04E-4E6D-4C68-A350-BBE61B264B7F@apple.com> Message-ID: <169E1E2E-0FEF-4021-A41E-B75D57C680BD@gmail.com> On May 1, 2012, at 4:57 PM, Mike Swingler wrote: > On May 1, 2012, at 2:17 PM, Michael Hall wrote: > >> On May 1, 2012, at 3:52 PM, Brad Wetmore wrote: >> >>> There are several services which were available in the Apple provider from JDK6 but not present in the current JDK7u4 port. >> >> Does that include using KeyChain as a keystore? I seem to remember a certain amount of mention concerning usage of that. Back a ways. > > I believe we did port over the KeyChain provider, but not the entirely of the Apple provider (since it was based on deprecated API). I got to thinking about this and remembered it looked something like this... public KeyStoreHandler(File f) { if (f == null && System.getProperty("os.name").equals("Mac OS X")) { try { ks = KeyStore.getInstance("KeychainStore","Apple"); } catch (Exception ex) { ex.printStackTrace(); } } else ks = load(KeyStore.getDefaultType(),f.getPath(),null); } What would the Provider second parameter to KeyStore getInstance be now? From scott.kovatch at oracle.com Tue May 1 15:28:32 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 1 May 2012 15:28:32 -0700 Subject: Using JDK splash screen from Web Start Message-ID: Hello, Java Web Start supports showing a splash screen based on an image resource in the JNLP file. To do this, we load libsplashscreen.dylib and call SplashInit, SplashLoadFile and SplashClose (no animated image support, sorry.) This used to work in JDK 6, but now it doesn't. I verified that I'm getting the image and passing it into SplashLoadFile, but no window appears with the image. Looking at the implementation in JDK 7 I'm thinking that something is either starting up the AWT, or that there is a dependency of some kind on the AWT. Is this the case? Should libsplashscreen be linked against libawt? Use of AWT code is not an issue here because Web Start starts a new process that shows the splash screen, but right now I'd be happy if it just worked. Any info/help is appreciated. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From swingler at apple.com Tue May 1 16:11:10 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 01 May 2012 16:11:10 -0700 Subject: Using JDK splash screen from Web Start In-Reply-To: References: Message-ID: <25B1F045-94BB-43B9-A0EF-DC747E8EDDAD@apple.com> On May 1, 2012, at 3:28 PM, Scott Kovatch wrote: > Hello, > > Java Web Start supports showing a splash screen based on an image resource in the JNLP file. To do this, we load libsplashscreen.dylib and call SplashInit, SplashLoadFile and SplashClose (no animated image support, sorry.) > > This used to work in JDK 6, but now it doesn't. I verified that I'm getting the image and passing it into SplashLoadFile, but no window appears with the image. > > Looking at the implementation in JDK 7 I'm thinking that something is either starting up the AWT, or that there is a dependency of some kind on the AWT. Is this the case? Should libsplashscreen be linked against libawt? Use of AWT code is not an issue here because Web Start starts a new process that shows the splash screen, but right now I'd be happy if it just worked. > > Any info/help is appreciated. The Java SE 6 splash-screen support was not contributable, because it directly use raw CGS windows (which were conveniently thread-safe from the Java main() thread). In JDK7, I believe the windows are now NSWindow based, and won't show up until AppKit has already started and the event loop in pumping. I'm not sure why it isn't work at all, even with a delay. Regards, Mike Swingler Apple Inc. From scott.kovatch at oracle.com Tue May 1 17:15:04 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 1 May 2012 17:15:04 -0700 Subject: Using JDK splash screen from Web Start In-Reply-To: <25B1F045-94BB-43B9-A0EF-DC747E8EDDAD@apple.com> References: <25B1F045-94BB-43B9-A0EF-DC747E8EDDAD@apple.com> Message-ID: <4BB1DC45-CE4B-4987-A50F-A3622E93B0E0@oracle.com> On May 1, 2012, at 4:11 PM, Mike Swingler wrote: > On May 1, 2012, at 3:28 PM, Scott Kovatch wrote: > >> Hello, >> >> Java Web Start supports showing a splash screen based on an image resource in the JNLP file. To do this, we load libsplashscreen.dylib and call SplashInit, SplashLoadFile and SplashClose (no animated image support, sorry.) >> >> This used to work in JDK 6, but now it doesn't. I verified that I'm getting the image and passing it into SplashLoadFile, but no window appears with the image. >> >> Looking at the implementation in JDK 7 I'm thinking that something is either starting up the AWT, or that there is a dependency of some kind on the AWT. Is this the case? Should libsplashscreen be linked against libawt? Use of AWT code is not an issue here because Web Start starts a new process that shows the splash screen, but right now I'd be happy if it just worked. >> >> Any info/help is appreciated. > > The Java SE 6 splash-screen support was not contributable, because it directly use raw CGS windows (which were conveniently thread-safe from the Java main() thread). > > In JDK7, I believe the windows are now NSWindow based, and won't show up until AppKit has already started and the event loop in pumping. I'm not sure why it isn't work at all, even with a delay. Sigh? That breaks the contract of the splash methods. Looking at SplashPlatformInit, I see two things. One, it assumes that it isn't being called on the main thread, because it attempts to call [NSApplicationAWT sharedApplication] in a main queue dispatch. Two, it assumes that libawt is available. For Web Start neither of these are true. We spawn a process for the splash screen with 'javaws -splash ', which eventually just calls SplashInit, SplashLoadFile and SplashClose when it gets a signal to quit. All of this happens on the main thread. Now I'll have to imitate java_md and spawn a thread that calls all of this stuff. And link against AWT! I would like to be constructive here, but I can't. This is frustrating. :-\ -- Scott From mik3hall at gmail.com Tue May 1 17:34:17 2012 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 1 May 2012 19:34:17 -0500 Subject: Apple Security Provider. In-Reply-To: <169E1E2E-0FEF-4021-A41E-B75D57C680BD@gmail.com> References: <4FA04D15.2060408@oracle.com> <7C1CF7D5-B2A7-4A0D-B165-9D952800AF2A@gmail.com> <700AB04E-4E6D-4C68-A350-BBE61B264B7F@apple.com> <169E1E2E-0FEF-4021-A41E-B75D57C680BD@gmail.com> Message-ID: <21127AA3-221A-4242-A0C0-9A817729FF21@gmail.com> >>> >>> >> >> I believe we did port over the KeyChain provider, but not the entirely of the Apple provider (since it was based on deprecated API). It is there... KeyStore implementors: CaseExactJKS JCEKS KeychainStore PKCS12 JKS But doesn't appear to work the same? As shown in my prior. The original implementation didn't require a load call to initialize it, but now.... import java.security.*; import java.util.Enumeration; public class KeyStoreTester { public static void main(String[] args) { try { KeyStore ks = KeyStore.getInstance("KeychainStore"); System.out.println(ks.getProvider()); Enumeration e = ks.aliases(); while (e.hasMoreElements()) System.out.println(e.nextElement()); } catch (Exception ex) { ex.printStackTrace(); } } } /usr/libexec/java_home -v 1.7 --exec java KeyStoreTester Apple version 1.1 java.security.KeyStoreException: Uninitialized keystore at java.security.KeyStore.aliases(KeyStore.java:1002) at KeyStoreTester.main(KeyStoreTester.java:10) It seems to need you to? I can probably figure out what file to use for the load. Is that actually supposed to be required now? From swingler at apple.com Tue May 1 18:00:48 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 01 May 2012 18:00:48 -0700 Subject: Using JDK splash screen from Web Start In-Reply-To: <4BB1DC45-CE4B-4987-A50F-A3622E93B0E0@oracle.com> References: <25B1F045-94BB-43B9-A0EF-DC747E8EDDAD@apple.com> <4BB1DC45-CE4B-4987-A50F-A3622E93B0E0@oracle.com> Message-ID: <7A197207-D7AE-4599-8757-2CFA6967B7A0@apple.com> On May 1, 2012, at 5:15 PM, Scott Kovatch wrote: > On May 1, 2012, at 4:11 PM, Mike Swingler wrote: > >> On May 1, 2012, at 3:28 PM, Scott Kovatch wrote: >> >>> Hello, >>> >>> Java Web Start supports showing a splash screen based on an image resource in the JNLP file. To do this, we load libsplashscreen.dylib and call SplashInit, SplashLoadFile and SplashClose (no animated image support, sorry.) >>> >>> This used to work in JDK 6, but now it doesn't. I verified that I'm getting the image and passing it into SplashLoadFile, but no window appears with the image. >>> >>> Looking at the implementation in JDK 7 I'm thinking that something is either starting up the AWT, or that there is a dependency of some kind on the AWT. Is this the case? Should libsplashscreen be linked against libawt? Use of AWT code is not an issue here because Web Start starts a new process that shows the splash screen, but right now I'd be happy if it just worked. >>> >>> Any info/help is appreciated. >> >> The Java SE 6 splash-screen support was not contributable, because it directly use raw CGS windows (which were conveniently thread-safe from the Java main() thread). >> >> In JDK7, I believe the windows are now NSWindow based, and won't show up until AppKit has already started and the event loop in pumping. I'm not sure why it isn't work at all, even with a delay. > > Sigh? That breaks the contract of the splash methods. Looking at SplashPlatformInit, I see two things. One, it assumes that it isn't being called on the main thread, because it attempts to call [NSApplicationAWT sharedApplication] in a main queue dispatch. Two, it assumes that libawt is available. > > For Web Start neither of these are true. We spawn a process for the splash screen with 'javaws -splash ', which eventually just calls SplashInit, SplashLoadFile and SplashClose when it gets a signal to quit. All of this happens on the main thread. Now I'll have to imitate java_md and spawn a thread that calls all of this stuff. And link against AWT! > > I would like to be constructive here, but I can't. This is frustrating. :-\ I believe one of my early suggestions when this was first brought up was to create a private "_splash" binary in the JDK bundle who's only job is to show the image in it's own process/event-loop?but the idea was dismissed as too complex. Perhaps it still is?given the payoff, but it's the next logical step I would take if I had the cycles. Regards, Mike Swingler Apple Inc. From henri.gomez at gmail.com Wed May 2 04:19:18 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 2 May 2012 13:19:18 +0200 Subject: Freetype in Mountain Lion and higher Message-ID: Hi to all, We discussed some time about OpenJDK dependencies on Freetype. Support for X11 will be removed in Mountain Lion but Freetype is not stricto-senso related to X11. A quick look on its dependencies on Lion show no deps on X11 (only gzip and bzip). /usr/X11/lib/libfreetype.6.dylib: /usr/X11/lib/libfreetype.6.dylib (compatibility version 14.0.0, current version 14.2.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) Will Freetype dylib be removed on 10.8 or will still be supported (and bundled) ? From anthony.petrov at oracle.com Wed May 2 04:34:32 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 May 2012 15:34:32 +0400 Subject: Using JDK splash screen from Web Start In-Reply-To: <7A197207-D7AE-4599-8757-2CFA6967B7A0@apple.com> References: <25B1F045-94BB-43B9-A0EF-DC747E8EDDAD@apple.com> <4BB1DC45-CE4B-4987-A50F-A3622E93B0E0@oracle.com> <7A197207-D7AE-4599-8757-2CFA6967B7A0@apple.com> Message-ID: <4FA11BC8.7010803@oracle.com> On 5/2/2012 5:00 AM, Mike Swingler wrote: > On May 1, 2012, at 5:15 PM, Scott Kovatch wrote: > >> On May 1, 2012, at 4:11 PM, Mike Swingler wrote: >> >>> On May 1, 2012, at 3:28 PM, Scott Kovatch wrote: >>> >>>> Hello, >>>> >>>> Java Web Start supports showing a splash screen based on an image resource in the JNLP file. To do this, we load libsplashscreen.dylib and call SplashInit, SplashLoadFile and SplashClose (no animated image support, sorry.) >>>> >>>> This used to work in JDK 6, but now it doesn't. I verified that I'm getting the image and passing it into SplashLoadFile, but no window appears with the image. >>>> >>>> Looking at the implementation in JDK 7 I'm thinking that something is either starting up the AWT, or that there is a dependency of some kind on the AWT. Is this the case? Should libsplashscreen be linked against libawt? Use of AWT code is not an issue here because Web Start starts a new process that shows the splash screen, but right now I'd be happy if it just worked. >>>> >>>> Any info/help is appreciated. >>> The Java SE 6 splash-screen support was not contributable, because it directly use raw CGS windows (which were conveniently thread-safe from the Java main() thread). >>> >>> In JDK7, I believe the windows are now NSWindow based, and won't show up until AppKit has already started and the event loop in pumping. I'm not sure why it isn't work at all, even with a delay. >> Sigh? That breaks the contract of the splash methods. Looking at SplashPlatformInit, I see two things. One, it assumes that it isn't being called on the main thread, because it attempts to call [NSApplicationAWT sharedApplication] in a main queue dispatch. Two, it assumes that libawt is available. >> >> For Web Start neither of these are true. We spawn a process for the splash screen with 'javaws -splash ', which eventually just calls SplashInit, SplashLoadFile and SplashClose when it gets a signal to quit. All of this happens on the main thread. Now I'll have to imitate java_md and spawn a thread that calls all of this stuff. And link against AWT! Splash screen doesn't require to link against AWT. All the code needed to start up a NSApp instance for the splash screen has been extracted to the libosxapp dynamic library - that's what the splash screen needs to be linked against. And yes, I think you have to do something similar to what we do in java_md. >> I would like to be constructive here, but I can't. This is frustrating. :-\ > > I believe one of my early suggestions when this was first brought up was to create a private "_splash" binary in the JDK bundle who's only job is to show the image in it's own process/event-loop?but the idea was dismissed as too complex. Perhaps it still is?given the payoff, but it's the next logical step I would take if I had the cycles. We decided to drop this idea because it would involve inter-process communication between the _spalsh and java processes because a java app may want to manipulate the splash screen. I'm not saying that this is impossible to implement, but it looks like too much of an effort for such a toy feature as the splash screen. Besides, I don't see why would such an approach be preferable to what we have already implemented, why would we have to re-implement it. Are there any issues with the current implementation? -- best regards, Anthony From leonid.romanov at oracle.com Wed May 2 04:37:33 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 2 May 2012 15:37:33 +0400 Subject: Request for review: 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In-Reply-To: <4F99520B.4020704@oracle.com> References: <4F8EE086.2090809@oracle.com> <4F900FAF.6070104@oracle.com> <4F953825.20508@oracle.com> <8600BFDB-9091-4F9C-93A9-7F29B42CC5AD@oracle.com> <4F968CF5.4050500@oracle.com> <3836447A-4013-4135-9F80-B80155D86A8B@oracle.com> <4F99520B.4020704@oracle.com> Message-ID: Thanks! I'm OK with the fix. On 26.04.2012, at 17:47, Alexander Scherbatiy wrote: > On 4/25/2012 2:46 PM, Leonid Romanov wrote: >> it is not obvious what isTopmostWindowUnderMouse is supposed to check without reading its source code. >> It would be great if you could add a brief comment describing method's purpose. Otherwise, the fix looks good. > > I have added the following comment: > // checks that this window is under the mouse cursor and this point is not overlapped by others windows > > Here is the updated version: > http://cr.openjdk.java.net/~alexsch/7154048/webrev.03/ > > Thanks, > Alexandr. > >> On 24.04.2012, at 15:22, Alexander Scherbatiy wrote: >> >>> On 4/23/2012 7:39 PM, Leonid Romanov wrote: >>>> Hi, >>>> I can't find where you set initial value of mouseIsOver variable. Does Objective-C guarantee that it gets some defined default value? >>> I really missed this part. >>> >>> Please review the new version: >>> http://cr.openjdk.java.net/~alexsch/7154048/webrev.02/ >>> >>> The only thing that is changed is the initialization of the mouseIsOver variable to false in the -initWithRect: method of the AWTView class. >>> >>> Thanks, >>> Alexandr. >>> >>>> On 23.04.2012, at 15:08, Alexander Scherbatiy wrote: >>>> >>>>> Thank you for the review. >>>>> >>>>> Here is the new version: >>>>> http://cr.openjdk.java.net/~alexsch/7154048/webrev.01/ >>>>> >>>>> 1. The synthesizeMouseEnteredExitedEvents method is added as a native method to the CPlatformWindow class. >>>>> Now it is invoked only in places that programmatically change a window size: >>>>> - nativeSetNSWindowBounds method from the AWTWindow >>>>> - setVisible and setWindowState methods from the CPlatformWindow >>>>> >>>>> 2. The objective-c code is formatted. >>>>> >>>>> 3. I do not think that setting the lastMouseEventPeer after sending the MOUSE_ENTERED event in the LWWindowPeer class can affect some logic in the peer. >>>>> The postEvent method just post the MOUSE_ENTERED events to the queue. It does not use the lastMouseEventPeer variable and there is no a recursion that invokes the dispatchMouseEvent method again. >>>>> >>>>> 4. Dragging a window under a panel should not generate mouse entered/exited events for components. However the events should be generated if the window is moved out of the frame or moved in to the frame. So one more condition that checks is the mouse crosess the frame borders are added to the dispatchMouseEvent method from the LWWindowPeer class. >>>>> The DragWindowOutOfFrameTest test is added that these events are properly generated. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 4/19/2012 5:14 PM, Anthony Petrov wrote: >>>>>> Hi Alexander, >>>>>> >>>>>> 1. I don't think that it's a good idea to add synthesizeMouseEnteredExitedEvents calls to CWrapper methods. These methods are supposed to perform direct calls to Cocoa API w/o any side-effects. They may be used for windows that even aren't AWT windows, and as such sending them the synthesizeMouseEnteredExitedEvents message is useless, and just doesn't seem right from CWrapper's purpose perspective. You may want to introduce CPlatformWindow._synthesizeMouseEnteredExitedEvents() native method that would call this native method, and then add a call to it where needed in Java code. >>>>>> >>>>>> 2. Please follow formatting guidelines and reformat lines like this: >>>>>> >>>>>>> if(id != MouseEvent.MOUSE_DRAGGED){ >>>>>> to read as >>>>>> >>>>>> if (id != MouseEvent.MOUSE_DRAGGED) { >>>>>> >>>>>> instead. I see lots of such mis-formatted if() statements all over your code. >>>>>> >>>>>> 3. In LWWindowPeer.java you are now setting the lastMouseEventPeer after sending the MOUSE_ENTERED event. Before your fix it's been set earlier. Can this change affect some logic in the peer code while processing ENTERED events at a user event handler? >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 04/18/12 19:40, Alexander Scherbatiy wrote: >>>>>>> Please review a fix for CR 7154048. >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154048 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7154048/webrev.00/ >>>>>>> >>>>>>> Let's see the following test case: >>>>>>> - Frame contains two components JLabel and JButton >>>>>>> - The JLabel component has a mouse listener >>>>>>> mousePressed: create a Window under the mouse click >>>>>>> mouseDragged: drag the created window >>>>>>> mouseReleased: close the Window >>>>>>> - A user clicks on the JLabel component, drags the mouse to the JButton >>>>>>> component and releases the mouse button >>>>>>> >>>>>>> The current JDK 8 implementation shows the following events on Mac OS X: >>>>>>> -------------------------------------------------------- >>>>>>> mouse pressed: javax.swing.JLabel >>>>>>> mouse exited: javax.swing.JLabel >>>>>>> mouse entered: javax.swing.JLabel >>>>>>> mouse dragged: javax.swing.JLabel >>>>>>> mouse exited: javax.swing.JLabel >>>>>>> mouse entered: javax.swing.JButton >>>>>>> mouse dragged: javax.swing.JLabel >>>>>>> mouse exited: javax.swing.JButton >>>>>>> mouse entered: Drag Window >>>>>>> mouse exited: Drag Window >>>>>>> mouse entered: javax.swing.JButton >>>>>>> mouse released: javax.swing.JButton >>>>>>> -------------------------------------------------------- >>>>>>> >>>>>>> There are several issues: >>>>>>> 1) The window does not receive the mouse entered event when it is >>>>>>> created under the mouse >>>>>>> 2) There are JLabel exited/JButton entered events during the window >>>>>>> dragging >>>>>>> 3) JLabel does not receive the mouse released event >>>>>>> >>>>>>> The fix synthesizes the mouse entered/exited events manually if they are >>>>>>> not received. >>>>>>> >>>>>>> The entered/exited events synthesizing is added to setFrame, toFront, >>>>>>> toBack, and zoom methods of the AWTWindow and CWrapper classes. >>>>>>> >>>>>>> There is an option to add the events synthesizing to the windowDidResize >>>>>>> notification. However this notification is sent when a window size is >>>>>>> changed in both cases, programmatically and when user is resized the >>>>>>> window. So in a lot of case there is no need for the our use case events >>>>>>> generation. >>>>>>> >>>>>>> The LWWindowPeer class is updated to not generate extra mouse enter/exit >>>>>>> events during the mouse dragging. >>>>>>> >>>>>>> Tho automated tests are added. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. > From anthony.petrov at oracle.com Wed May 2 05:02:59 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 May 2012 16:02:59 +0400 Subject: Freetype in Mountain Lion and higher In-Reply-To: References: Message-ID: <4FA12273.60906@oracle.com> Hi Henri, As Mike mentioned several times, and I agree with him, the best approach would be to build a private copy of the freetype library when OpenJDK is being built, and ship it together with the OpenJDK binaries. In this case we avoid having unnecessary dependencies on optional OS X components, and also get rid of any library versions issues that may arise when e.g. (not) upgrading your operating system. Note that we do that with OpenJDK on MS Windows platform. Please refer to the Windows make files for more details. Patches are always welcome! :) -- best regards, Anthony On 5/2/2012 3:19 PM, Henri Gomez wrote: > Hi to all, > > We discussed some time about OpenJDK dependencies on Freetype. > Support for X11 will be removed in Mountain Lion but Freetype is not > stricto-senso related to X11. > > A quick look on its dependencies on Lion show no deps on X11 (only > gzip and bzip). > > /usr/X11/lib/libfreetype.6.dylib: > /usr/X11/lib/libfreetype.6.dylib (compatibility version 14.0.0, > current version 14.2.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) > /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 159.1.0) > > Will Freetype dylib be removed on 10.8 or will still be supported (and > bundled) ? From Sergey.Bylokhov at oracle.com Wed May 2 05:49:15 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 02 May 2012 16:49:15 +0400 Subject: [8] Request for review: 7124213: [macosx] pack() does ignore size of a component; doesn't on the other platforms. In-Reply-To: <4F8EBF0B.3000100@oracle.com> References: <4F8C31AA.5060900@oracle.com> <4F8EBF0B.3000100@oracle.com> Message-ID: <4FA12D4B.7070701@oracle.com> Hi, Artem. Yes LWTextAreaPeer uses the same approach(60,10). But in the fix I change LWScrollPanePeer. > Hi, Sergey, > > I'm fine with the fix, just curious about "... should work in the same > way as on other platforms". Both on Windows and X11 TextArea peer's > minimum size is calculated as the size of TextArea that consists of 10 > rows by 60 columns. What did you mean then? > > Thanks, > On 4/16/2012 6:50 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> LWScrollPanePeer.getMinimumSize() on macosx should work in the same >> way, as on other platforms. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124213 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7124213/webrev.00/ >> From henri.gomez at gmail.com Wed May 2 06:23:02 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 2 May 2012 15:23:02 +0200 Subject: Freetype in Mountain Lion and higher In-Reply-To: <4FA12273.60906@oracle.com> References: <4FA12273.60906@oracle.com> Message-ID: > Hi Henri, > > As Mike mentioned several times, and I agree with him, the best approach > would be to build a private copy of the freetype library when OpenJDK is > being built, and ship it together with the OpenJDK binaries. In this case we > avoid having unnecessary dependencies on optional OS X components, and also > get rid of any library versions issues that may arise when e.g. (not) > upgrading your operating system. > > Note that we do that with OpenJDK on MS Windows platform. Please refer to > the Windows make files for more details. Patches are always welcome! :) I already do some experiments with it and prepared some hacks around package/build process. And got some questions about jdk/make/sun/font/Makefile : ie: why hardcoding version 6 of dynamic library for freetype. ifeq ($(USING_SYSTEM_FT_LIB), false) FREETYPE_LIB = $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX).6 endif From steve.mcleod at gmail.com Wed May 2 06:51:52 2012 From: steve.mcleod at gmail.com (Steve McLeod) Date: Wed, 2 May 2012 15:51:52 +0200 Subject: segmentedTextured JButtons render poorly on OpenJDK 7 Message-ID: <50E95D2F1D044FFDB79E1BFF323D7BF1@gmail.com> (I originally posted to java-dev at lists.apple.com, but someone suggested this forum would be better) I''m using OpenJDK 1.7.0_04. I'm using the client property "segmentedTextured" on some buttons. The top and bottom of the buttons are not rendered. Here's the simplest reproduction code I've been able to create. import javax.swing.*; import java.awt.*; public class SegmentedTexturedButtonTest { public static void main(String[] args) { Image iconView = Toolkit.getDefaultToolkit().getImage("NSImage://NSIconViewTemplate"); Image listView = Toolkit.getDefaultToolkit().getImage("NSImage://NSListViewTemplate"); JToggleButton leftButton = new JToggleButton("View", new ImageIcon(iconView)); leftButton.putClientProperty("JButton.buttonType", "segmentedTextured"); leftButton.putClientProperty("JButton.segmentPosition", "first"); leftButton.setFocusable(false); JToggleButton rightButton = new JToggleButton("List", new ImageIcon(listView)); rightButton.putClientProperty("JButton.buttonType", "segmentedTextured"); rightButton.putClientProperty("JButton.segmentPosition", "last"); rightButton.setFocusable(false); JPanel contentPane = new JPanel(new FlowLayout(FlowLayout.LEFT, 0, 0)); contentPane.add(leftButton); contentPane.add(rightButton); JFrame frame = new JFrame("Test"); frame.setContentPane(contentPane); frame.pack(); frame.setLocationRelativeTo(null); frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); frame.setVisible(true); } } The same code renders properly on Apple's Java 6. I observe the problem on OS X 10.7 and OS X 10.8. A secondary problem (or perhaps non-problem) is that the code above results in a window with smaller width being shown with OpenJDK 7 Screenshots demonstrating the problem: With Java 6: http://pokercopilot.com/stuff/java6_segmented_texture_buttons.png With OpenJDK 7: http://pokercopilot.com/stuff/java7_segmented_texture_buttons.png Regards, Steve --------------------------------------------------- Steve McLeod Founder, Poker Copilot http://www.pokercopilot.com From scott.kovatch at oracle.com Wed May 2 08:08:59 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 2 May 2012 08:08:59 -0700 Subject: Using JDK splash screen from Web Start In-Reply-To: <4FA11BC8.7010803@oracle.com> References: <25B1F045-94BB-43B9-A0EF-DC747E8EDDAD@apple.com> <4BB1DC45-CE4B-4987-A50F-A3622E93B0E0@oracle.com> <7A197207-D7AE-4599-8757-2CFA6967B7A0@apple.com> <4FA11BC8.7010803@oracle.com> Message-ID: <70B5063F-A305-49C8-A5B6-D4EC94F82C24@oracle.com> On May 2, 2012, at 4:34 AM, Anthony Petrov wrote: >>> Sigh? That breaks the contract of the splash methods. Looking at SplashPlatformInit, I see two things. One, it assumes that it isn't being called on the main thread, because it attempts to call [NSApplicationAWT sharedApplication] in a main queue dispatch. Two, it assumes that libawt is available. >>> >>> For Web Start neither of these are true. We spawn a process for the splash screen with 'javaws -splash ', which eventually just calls SplashInit, SplashLoadFile and SplashClose when it gets a signal to quit. All of this happens on the main thread. Now I'll have to imitate java_md and spawn a thread that calls all of this stuff. And link against AWT! > > Splash screen doesn't require to link against AWT. All the code needed to start up a NSApp instance for the splash screen has been extracted to the libosxapp dynamic library - that's what the splash screen needs to be linked against. That's good to know. I didn't do an 'nm' on libosxapp; it didn't occur to me that it would be in there. > And yes, I think you have to do something similar to what we do in java_md. Okay. I'm not a fan of replicating code like that, but if I have to, I have to. > We decided to drop this idea because it would involve inter-process communication between the _spalsh and java processes because a java app may want to manipulate the splash screen. I'm not saying that this is impossible to implement, but it looks like too much of an effort for such a toy feature as the splash screen. Besides, I don't see why would such an approach be preferable to what we have already implemented, why would we have to re-implement it. Are there any issues with the current implementation? In general, no. I had no problems with using the splash feature in a simple AWT app. It's just that I won't be able to reuse as much code as I thought to implement a small feature, and that leaves me grouchy. :-) Web Start, in fact, does exactly the kind of cross-process communication you describe to hide the splash screen after a short delay. -- Scott From anthony.petrov at oracle.com Wed May 2 08:35:41 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 May 2012 19:35:41 +0400 Subject: Using JDK splash screen from Web Start In-Reply-To: <70B5063F-A305-49C8-A5B6-D4EC94F82C24@oracle.com> References: <25B1F045-94BB-43B9-A0EF-DC747E8EDDAD@apple.com> <4BB1DC45-CE4B-4987-A50F-A3622E93B0E0@oracle.com> <7A197207-D7AE-4599-8757-2CFA6967B7A0@apple.com> <4FA11BC8.7010803@oracle.com> <70B5063F-A305-49C8-A5B6-D4EC94F82C24@oracle.com> Message-ID: <4FA1544D.4070902@oracle.com> On 5/2/2012 7:08 PM, Scott Kovatch wrote: >> And yes, I think you have to do something similar to what we do in java_md. > > Okay. I'm not a fan of replicating code like that, but if I have to, I have to. > >> We decided to drop this idea because it would involve inter-process communication between the _spalsh and java processes because a java app may want to manipulate the splash screen. I'm not saying that this is impossible to implement, but it looks like too much of an effort for such a toy feature as the splash screen. Besides, I don't see why would such an approach be preferable to what we have already implemented, why would we have to re-implement it. Are there any issues with the current implementation? > > In general, no. I had no problems with using the splash feature in a simple AWT app. It's just that I won't be able to reuse as much code as I thought to implement a small feature, and that leaves me grouchy. :-) > > Web Start, in fact, does exactly the kind of cross-process communication you describe to hide the splash screen after a short delay. Well, one thing is to send a simple "hide" signal through the IPC, and the other one is to update the rendered image dynamically, which seems to be slightly more heavyweight than sending a simple signal, eh? :) I investigated this possibility actually, and there exist some memory restrictions for this kind of communication which complicates the matter even further. It just doesn't seem to be worth it. As to the code replication, why not export necessary functions from the Java Launcher dynamic library and call them from the WebStart? After all, the Web Start is actually a kind of a launcher, so there must be some room for code sharing I believe (perhaps in future releases only, but still.) -- best regards, Anthony From anthony.petrov at oracle.com Wed May 2 08:39:23 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 May 2012 19:39:23 +0400 Subject: Freetype in Mountain Lion and higher In-Reply-To: References: <4FA12273.60906@oracle.com> Message-ID: <4FA1552B.90402@oracle.com> On 5/2/2012 5:23 PM, Henri Gomez wrote: >> As Mike mentioned several times, and I agree with him, the best approach >> would be to build a private copy of the freetype library when OpenJDK is >> being built, and ship it together with the OpenJDK binaries. In this case we >> avoid having unnecessary dependencies on optional OS X components, and also >> get rid of any library versions issues that may arise when e.g. (not) >> upgrading your operating system. >> >> Note that we do that with OpenJDK on MS Windows platform. Please refer to >> the Windows make files for more details. Patches are always welcome! :) > > I already do some experiments with it and prepared some hacks around > package/build process. > And got some questions about jdk/make/sun/font/Makefile : > > ie: why hardcoding version 6 of dynamic library for freetype. > > > ifeq ($(USING_SYSTEM_FT_LIB), false) > FREETYPE_LIB = $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX).6 > endif I'd defer the answer to 2D folks. I can only speculate that this must be a minimum required version. Perhaps the makefiles logic might be enhanced in this area. -- best regards, Anthony From alexander.zuev at oracle.com Wed May 2 08:59:20 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 02 May 2012 19:59:20 +0400 Subject: [7u6] Please review my fix for 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame In-Reply-To: <4F9BCBDF.6040709@oracle.com> References: <4F996FD3.9080702@oracle.com> <4F9ACF63.5080406@oracle.com> <4F9BA768.1070404@oracle.com> <4F9BCBDF.6040709@oracle.com> Message-ID: <4FA159D8.8060803@oracle.com> Anthony, finally all the servers are up and i can present the new webrev, it is here: http://cr.openjdk.java.net/~kizune/7148289/webrev.01 I have renamed methods mentioned that they are nested native event loop controllers. With best regards, Alex On 4/28/12 14:52, Anthony Petrov wrote: > Hi Alexander, > > On 4/28/2012 12:16 PM, Alexander Zuev wrote: >> the ToolkitThreadBlockerHandler is an interface that is supposed to >> be used >> when program has to wait for the event pushed to the EDT finish its >> task and >> he calls like this: >> while (!dispatcher.isDone()) { >> >> DataTransferer.getInstance().getToolkitThreadBlockedHandler().enter(); >> } >> and the event handler in its unregisterEvent() method calls for >> handler.exit() >> The method is supposed to make sure that waiting on the EDT doesn't >> create deadlocks. >> The implementation depends on the toolkit architecture - on some >> toolkits it's NoOp since >> they don't care if EDT is waiting, but in LWCToolkit our AWT >> components are backed by Swing >> delegates so there are a lot of calls from native application thread >> to EDT and vice versa so we >> can't afford to stop both threads. Solution is the code that makes >> secondary AppKit event loop >> to handle native events so waiting on EDT will leave at least one >> event loop pumping. > > Thanks! > >> The name is correct because despite the fact that we are in AWT >> code (LWCToolkit) we don't >> create nested EDT loop but running nested native (AppKit) loop - >> hence the name: enter/exitNativeEventLoop() > > Since the main event loop is already spinning, I would still suggest > to rename it to, say, enter/exitNestedNativeEventLoop() to stress that > this event loop is going to be an inner loop, rather than the main > (outer) event loop. > > -- > best regards, > Anthony > >> >> With best regards, >> Alex >> >> On 4/27/12 20:54, Anthony Petrov wrote: >>> Hi Alexander, >>> >>> Could you provide some details about the ToolkitThreadBlockedHandler >>> interface? How is it used by the DnD code? >>> >>> Also, I suggest to replace the word Native with Nested in >>> enter/exitNativeEventLoop() method names. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/26/2012 7:54 PM, Alexander Zuev wrote: >>>> Hello, >>>> >>>> please review my fix for the CR 7148289: [macosx] Deadlock in >>>> sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame >>>> >>>> Bug description is >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7148289 >>>> >>>> Fix can be found at >>>> http://cr.openjdk.java.net/~kizune/7148289/webrev.00 >>>> >>>> With best regards, >>>> Alex >> From henri.gomez at gmail.com Wed May 2 09:01:16 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 2 May 2012 18:01:16 +0200 Subject: Freetype in Mountain Lion and higher In-Reply-To: <4FA1552B.90402@oracle.com> References: <4FA12273.60906@oracle.com> <4FA1552B.90402@oracle.com> Message-ID: >> ? ?ifeq ($(USING_SYSTEM_FT_LIB), false) >> ? ? ?FREETYPE_LIB = >> $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX).6 >> ? ?endif > > > I'd defer the answer to 2D folks. I can only speculate that this must be a > minimum required version. Perhaps the makefiles logic might be enhanced in > this area. Yep, I spent some time on this makefile and it seems incomplete. ie : $(FREETYPE_LIB): $(CP) $(FREETYPE_LIB_PATH)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX) $@ endif This goal make me think copy of Freetype library was planned, but need some more tweaking. ifeq ($(PLATFORM), windows) FREETYPE_LIB = $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX) OTHER_LDLIBS += $(FREETYPE_LIB_PATH)/freetype.lib else ifeq ($(USING_SYSTEM_FT_LIB), false) FREETYPE_LIB = $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX).6 endif OTHER_LDLIBS += -L$(FREETYPE_LIB_PATH) -lfreetype endif ... # # Libraries to link, and other C flags. # ifeq ($(PLATFORM), macosx)) OTHER_INCLUDES += -I$(X11_PATH)/include OTHER_LDLIBS += -lawt $(LIBM) $(LIBCXX) ifeq ($(OS_VENDOR),Apple) # XXXDARWIN Match BSD/Linux behavior -- the mawt.dylib symbols will # be available at runtime. OTHER_LDLIBS += -undefined dynamic_lookup endif else ifeq ($(PLATFORM), solaris) # Note that on Solaris, fontmanager is built against the headless library. LDFLAGS += -L$(LIBDIR)/$(LIBARCH)/headless OTHER_LDLIBS += -lawt -L$(LIBDIR)/$(LIBARCH)/xawt -lmawt -lc $(LIBM) $(LIBCXX) else # PLATFORM is linux OTHER_LDLIBS += -lawt $(LIBM) $(LIBCXX) ifeq ("$(CC_VER_MAJOR)", "3") OTHER_LDLIBS += -Wl,-Bstatic -lgcc_eh -Wl,-Bdynamic endif endif endif Makefile may need some cleanup to split it between using system FT lib and copying (embedding) provided external FT LIB (via ALT_FREETYPE_HEADERS_PATH and ALT_FREETYPE_LIB_PATH) It will be clearer by using 2 vars. One exist, USING_SYSTEM_FT_LIB, new one could be EMBEDDING_EXTERNAL_FT_LIB. My 0.01$ From anthony.petrov at oracle.com Wed May 2 09:11:53 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 02 May 2012 20:11:53 +0400 Subject: [7u6] Please review my fix for 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame In-Reply-To: <4FA159D8.8060803@oracle.com> References: <4F996FD3.9080702@oracle.com> <4F9ACF63.5080406@oracle.com> <4F9BA768.1070404@oracle.com> <4F9BCBDF.6040709@oracle.com> <4FA159D8.8060803@oracle.com> Message-ID: <4FA15CC9.4010209@oracle.com> Looks perfect. Thank you! -- best regards, Anthony On 5/2/2012 7:59 PM, Alexander Zuev wrote: > Anthony, > > finally all the servers are up and i can present the new webrev, it is > here: > http://cr.openjdk.java.net/~kizune/7148289/webrev.01 > > I have renamed methods mentioned that they are nested native event loop > controllers. > > With best regards, > Alex > > On 4/28/12 14:52, Anthony Petrov wrote: >> Hi Alexander, >> >> On 4/28/2012 12:16 PM, Alexander Zuev wrote: >>> the ToolkitThreadBlockerHandler is an interface that is supposed to >>> be used >>> when program has to wait for the event pushed to the EDT finish its >>> task and >>> he calls like this: >>> while (!dispatcher.isDone()) { >>> >>> DataTransferer.getInstance().getToolkitThreadBlockedHandler().enter(); >>> } >>> and the event handler in its unregisterEvent() method calls for >>> handler.exit() >>> The method is supposed to make sure that waiting on the EDT doesn't >>> create deadlocks. >>> The implementation depends on the toolkit architecture - on some >>> toolkits it's NoOp since >>> they don't care if EDT is waiting, but in LWCToolkit our AWT >>> components are backed by Swing >>> delegates so there are a lot of calls from native application thread >>> to EDT and vice versa so we >>> can't afford to stop both threads. Solution is the code that makes >>> secondary AppKit event loop >>> to handle native events so waiting on EDT will leave at least one >>> event loop pumping. >> >> Thanks! >> >>> The name is correct because despite the fact that we are in AWT >>> code (LWCToolkit) we don't >>> create nested EDT loop but running nested native (AppKit) loop - >>> hence the name: enter/exitNativeEventLoop() >> >> Since the main event loop is already spinning, I would still suggest >> to rename it to, say, enter/exitNestedNativeEventLoop() to stress that >> this event loop is going to be an inner loop, rather than the main >> (outer) event loop. >> >> -- >> best regards, >> Anthony >> >>> >>> With best regards, >>> Alex >>> >>> On 4/27/12 20:54, Anthony Petrov wrote: >>>> Hi Alexander, >>>> >>>> Could you provide some details about the ToolkitThreadBlockedHandler >>>> interface? How is it used by the DnD code? >>>> >>>> Also, I suggest to replace the word Native with Nested in >>>> enter/exitNativeEventLoop() method names. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 4/26/2012 7:54 PM, Alexander Zuev wrote: >>>>> Hello, >>>>> >>>>> please review my fix for the CR 7148289: [macosx] Deadlock in >>>>> sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame >>>>> >>>>> Bug description is >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7148289 >>>>> >>>>> Fix can be found at >>>>> http://cr.openjdk.java.net/~kizune/7148289/webrev.00 >>>>> >>>>> With best regards, >>>>> Alex >>> > From philip.race at oracle.com Wed May 2 09:32:22 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 02 May 2012 09:32:22 -0700 Subject: Freetype in Mountain Lion and higher In-Reply-To: References: <4FA12273.60906@oracle.com> <4FA1552B.90402@oracle.com> Message-ID: <4FA16196.3070702@oracle.com> I think .6 probably was to ensure we are getting a version was expect. If it was something else it might be a red flag to check all worked as expected. There's also the infamous freetype_check program which ensured the actual freetype version, not the library version, was what we expected. At the time we did the work platforms which had fonts with embedded bitmaps were *dead* with freetype. Expect an infinite loop on start up. The plan was to have pre-built freetype libs which would be imported and delivered along with JDK, but *allow* Linux distros to set a variable USING_SYSTEM_FT_LIB to say not to do that .. I am not sure I see why we need another variable (EMBEDDING_EXTERNAL_FT_LIB) to say not to not do that ... For OS X including a copy is absolutely the way to go, and I blocked on this a few months ago because I didn't have the cycles to go figure out how to fix the freetype build for OS X, which hardwires into itself the dylib path where it expects to be installed and that code linked against it must use, to be standard location. That seemed to me to be the only issue that seemed to require anything except perhaps very, very minor makefile tweaking. -phil. On 5/2/2012 9:01 AM, Henri Gomez wrote: >>> ifeq ($(USING_SYSTEM_FT_LIB), false) >>> FREETYPE_LIB = >>> $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX).6 >>> endif >> >> I'd defer the answer to 2D folks. I can only speculate that this must be a >> minimum required version. Perhaps the makefiles logic might be enhanced in >> this area. > Yep, I spent some time on this makefile and it seems incomplete. > ie : > > > $(FREETYPE_LIB): > $(CP) $(FREETYPE_LIB_PATH)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX) $@ > endif > > This goal make me think copy of Freetype library was planned, but need > some more tweaking. > > ifeq ($(PLATFORM), windows) > FREETYPE_LIB = $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX) > OTHER_LDLIBS += $(FREETYPE_LIB_PATH)/freetype.lib > else > ifeq ($(USING_SYSTEM_FT_LIB), false) > FREETYPE_LIB = $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX).6 > endif > OTHER_LDLIBS += -L$(FREETYPE_LIB_PATH) -lfreetype > endif > > ... > > # > # Libraries to link, and other C flags. > # > > ifeq ($(PLATFORM), macosx)) > OTHER_INCLUDES += -I$(X11_PATH)/include > OTHER_LDLIBS += -lawt $(LIBM) $(LIBCXX) > ifeq ($(OS_VENDOR),Apple) > # XXXDARWIN Match BSD/Linux behavior -- the mawt.dylib symbols will > # be available at runtime. > OTHER_LDLIBS += -undefined dynamic_lookup > endif > else > ifeq ($(PLATFORM), solaris) > # Note that on Solaris, fontmanager is built against the headless library. > LDFLAGS += -L$(LIBDIR)/$(LIBARCH)/headless > OTHER_LDLIBS += -lawt -L$(LIBDIR)/$(LIBARCH)/xawt -lmawt -lc $(LIBM) $(LIBCXX) > else # PLATFORM is linux > OTHER_LDLIBS += -lawt $(LIBM) $(LIBCXX) > ifeq ("$(CC_VER_MAJOR)", "3") > OTHER_LDLIBS += -Wl,-Bstatic -lgcc_eh -Wl,-Bdynamic > endif > endif > endif > > Makefile may need some cleanup to split it between using system FT lib > and copying (embedding) provided external FT LIB (via > ALT_FREETYPE_HEADERS_PATH and ALT_FREETYPE_LIB_PATH) > > It will be clearer by using 2 vars. > > One exist, USING_SYSTEM_FT_LIB, new one could be EMBEDDING_EXTERNAL_FT_LIB. > > My 0.01$ From scott.kovatch at oracle.com Wed May 2 09:38:26 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 2 May 2012 09:38:26 -0700 Subject: Using JDK splash screen from Web Start In-Reply-To: <4FA1544D.4070902@oracle.com> References: <25B1F045-94BB-43B9-A0EF-DC747E8EDDAD@apple.com> <4BB1DC45-CE4B-4987-A50F-A3622E93B0E0@oracle.com> <7A197207-D7AE-4599-8757-2CFA6967B7A0@apple.com> <4FA11BC8.7010803@oracle.com> <70B5063F-A305-49C8-A5B6-D4EC94F82C24@oracle.com> <4FA1544D.4070902@oracle.com> Message-ID: <3E9ECFAA-47F5-4B1D-9C76-823CBB3D8442@oracle.com> On May 2, 2012, at 8:35 AM, Anthony Petrov wrote: > On 5/2/2012 7:08 PM, Scott Kovatch wrote: >>> And yes, I think you have to do something similar to what we do in java_md. >> Okay. I'm not a fan of replicating code like that, but if I have to, I have to. >>> We decided to drop this idea because it would involve inter-process communication between the _spalsh and java processes because a java app may want to manipulate the splash screen. I'm not saying that this is impossible to implement, but it looks like too much of an effort for such a toy feature as the splash screen. Besides, I don't see why would such an approach be preferable to what we have already implemented, why would we have to re-implement it. Are there any issues with the current implementation? >> In general, no. I had no problems with using the splash feature in a simple AWT app. It's just that I won't be able to reuse as much code as I thought to implement a small feature, and that leaves me grouchy. :-) >> Web Start, in fact, does exactly the kind of cross-process communication you describe to hide the splash screen after a short delay. > > Well, one thing is to send a simple "hide" signal through the IPC, and the other one is to update the rendered image dynamically, which seems to be slightly more heavyweight than sending a simple signal, eh? :) I investigated this possibility actually, and there exist some memory restrictions for this kind of communication which complicates the matter even further. It just doesn't seem to be worth it. > > As to the code replication, why not export necessary functions from the Java Launcher dynamic library and call them from the WebStart? After all, the Web Start is actually a kind of a launcher, so there must be some room for code sharing I believe (perhaps in future releases only, but still.) Web Start itself has no problems starting Java to do its work -- it just calls 'java' with a list of arguments. The issue here is that for the splash screen we don't use the JVM's splash support. Web Start can run JREs back to at least 1.4.2, so we can't assume the JVM handles the splash option. So, we spawn another process and call 'javaws -splash '. This calls the minimum set of splash routines and quits. However, in the Mac implementation I ought to be able to remove that assumption since we won't be supporting older JREs. I tried passing along '-splash:' with the other Web Start arguments and it worked fine. That's okay for AWT-based Web Start apps, but I'm concerned about JavaFX apps. I know libosxapp doesn't actually pull in the AWT, but now I need to test that JavaFX will work okay if it finds an NSApplicationAWT already started when Glass creates its application. -- Scott K. From sean.mullan at oracle.com Wed May 2 11:47:01 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 02 May 2012 14:47:01 -0400 Subject: Apple Security Provider. In-Reply-To: <21127AA3-221A-4242-A0C0-9A817729FF21@gmail.com> References: <4FA04D15.2060408@oracle.com> <7C1CF7D5-B2A7-4A0D-B165-9D952800AF2A@gmail.com> <700AB04E-4E6D-4C68-A350-BBE61B264B7F@apple.com> <169E1E2E-0FEF-4021-A41E-B75D57C680BD@gmail.com> <21127AA3-221A-4242-A0C0-9A817729FF21@gmail.com> Message-ID: <4FA18125.9090904@oracle.com> On 05/01/2012 08:34 PM, Michael Hall wrote: > >>>> >>>> >>> >>> I believe we did port over the KeyChain provider, but not the entirely of the Apple provider (since it was based on deprecated API). > > It is there... > > KeyStore > implementors: > CaseExactJKS > JCEKS > KeychainStore > PKCS12 > JKS > > But doesn't appear to work the same? As shown in my prior. The original implementation didn't require a load call to initialize it, but now.... > > import java.security.*; > import java.util.Enumeration; > > public class KeyStoreTester { > > public static void main(String[] args) { > try { > KeyStore ks = KeyStore.getInstance("KeychainStore"); > System.out.println(ks.getProvider()); > Enumeration e = ks.aliases(); > while (e.hasMoreElements()) > System.out.println(e.nextElement()); > } > catch (Exception ex) { ex.printStackTrace(); } > } > > } > > /usr/libexec/java_home -v 1.7 --exec java KeyStoreTester > Apple version 1.1 > java.security.KeyStoreException: Uninitialized keystore > at java.security.KeyStore.aliases(KeyStore.java:1002) > at KeyStoreTester.main(KeyStoreTester.java:10) > > > It seems to need you to? I can probably figure out what file to use for the load. Is that actually supposed to be required now? > Try specifying null for the InputStream parameter. I am not familiar with the OS X implementation, but it sounds like that may have been a bug - according to the KeyStore API, in order to access a KeyStore, you first have to initialize it by calling the load method. --Sean From leonid.romanov at oracle.com Wed May 2 12:10:38 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 2 May 2012 23:10:38 +0400 Subject: [8] Review request for 7124376: [macosx] Modal dialog lost focus In-Reply-To: <4F9ADFBE.5070909@oracle.com> References: <4F9AD9C7.6020707@oracle.com> <57BD5F10-B0B3-4091-8777-2A084643DC4C@oracle.com> <4F9ADFBE.5070909@oracle.com> Message-ID: <365B8FE6-2E62-4B95-AE56-E474F1FDD4E6@oracle.com> Hi, I've reworked my fix. See http://cr.openjdk.java.net/~leonidr/7124376/webrev.01/ On 27.04.2012, at 22:04, Anthony Petrov wrote: > I've noticed that too. I didn't point this out though, because you're also checking the MODAL_EXCLUDED flag in your modallyBlocked(), so I thought it was OK. But if you can pull this check to the Java code before even calling modallyBLocked(), then I guess the "setEnabled" name would make more sense. > > -- > best regards, > Anthony > > On 4/27/2012 10:02 PM, Leonid Romanov wrote: >> I've looked at 7124395 and the fixes you did for FX and it looks like we need setEnabled method for AWTWindow. I'll redo my fix accordingly. On 27.04.2012, at 21:39, Anthony Petrov wrote: >>> Hi Leonid, >>> >>> I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. >>> >>> Regarding the fix itself: >>> >>> 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? >>> >>> 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 4/27/2012 6:11 PM, Leonid Romanov wrote: >>>> Hi, >>>> Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking "Show Message Dialog" button. Now, click on the "SwingSet2" window title bar and you'll see the window rapidly gaining and loosing focus. >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 >>>> webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ >>>> Thanks, >>>> Leonid. From jcpalmer at rochester.rr.com Wed May 2 12:21:30 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Wed, 2 May 2012 15:21:30 -0400 Subject: JWS Feedback Message-ID: <2D3C4F59-9690-41EB-9927-8DBC06ADEDE7@rochester.rr.com> Tried to create java.net account so this could be posted in the location requested. Never got confirm message. Sent test message from elsewhere & showed up right away. Hit back button & addr was right. Submitted again & email & user name taken. Anyway, here is what would have been posted: - Always trust content from this publisher text is cramped from text above. - Explicitly requesting a 1.6 version gets Unsupported version of Java dialog. Same with 1.6+, 1.7, & 1.7.0_06-ea. Leaving out version tag correctly errors, saying there must be a version. This makes JWS virtually untestable. Prefer 1.6+ to work, so same .jnlp can work for Snow Leopard. This is resources section being used: - The signing checking of comparing Application.jnlp in jar to website's works as before. Refuses to run, when they do not match. From anthony.petrov at oracle.com Thu May 3 05:31:03 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 03 May 2012 16:31:03 +0400 Subject: Using JDK splash screen from Web Start In-Reply-To: <3E9ECFAA-47F5-4B1D-9C76-823CBB3D8442@oracle.com> References: <25B1F045-94BB-43B9-A0EF-DC747E8EDDAD@apple.com> <4BB1DC45-CE4B-4987-A50F-A3622E93B0E0@oracle.com> <7A197207-D7AE-4599-8757-2CFA6967B7A0@apple.com> <4FA11BC8.7010803@oracle.com> <70B5063F-A305-49C8-A5B6-D4EC94F82C24@oracle.com> <4FA1544D.4070902@oracle.com> <3E9ECFAA-47F5-4B1D-9C76-823CBB3D8442@oracle.com> Message-ID: <4FA27A87.9070905@oracle.com> On 05/02/12 20:38, Scott Kovatch wrote: > However, in the Mac implementation I ought to be able to remove that assumption since we won't be supporting older JREs. I tried passing along '-splash:' with the other Web Start arguments and it worked fine. That's okay for AWT-based Web Start apps, but I'm concerned about JavaFX apps. I know libosxapp doesn't actually pull in the AWT, but now I need to test that JavaFX will work okay if it finds an NSApplicationAWT already started when Glass creates its application. Since both the splash screen and FX want its own instance of NSApp, using both is impossible at this moment. Or the FX app must be run in the embedded mode (as if there's full AWT running - but it's really unneeded since it's enough what we've got in libosxapp already for FX to run smoothly). -- best regards, Anthony From anthony.petrov at oracle.com Thu May 3 05:40:47 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 03 May 2012 16:40:47 +0400 Subject: [8] Review request for 7124376: [macosx] Modal dialog lost focus In-Reply-To: <365B8FE6-2E62-4B95-AE56-E474F1FDD4E6@oracle.com> References: <4F9AD9C7.6020707@oracle.com> <57BD5F10-B0B3-4091-8777-2A084643DC4C@oracle.com> <4F9ADFBE.5070909@oracle.com> <365B8FE6-2E62-4B95-AE56-E474F1FDD4E6@oracle.com> Message-ID: <4FA27CCF.2060204@oracle.com> Hi Leonid, The fix looks good to me. Thanks. -- best regards, Anthony On 05/02/12 23:10, Leonid Romanov wrote: > Hi, > I've reworked my fix. See > http://cr.openjdk.java.net/~leonidr/7124376/webrev.01/ > > On 27.04.2012, at 22:04, Anthony Petrov wrote: > >> I've noticed that too. I didn't point this out though, because you're also checking the MODAL_EXCLUDED flag in your modallyBlocked(), so I thought it was OK. But if you can pull this check to the Java code before even calling modallyBLocked(), then I guess the "setEnabled" name would make more sense. >> >> -- >> best regards, >> Anthony >> >> On 4/27/2012 10:02 PM, Leonid Romanov wrote: >>> I've looked at 7124395 and the fixes you did for FX and it looks like we need setEnabled method for AWTWindow. I'll redo my fix accordingly. On 27.04.2012, at 21:39, Anthony Petrov wrote: >>>> Hi Leonid, >>>> >>>> I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. >>>> >>>> Regarding the fix itself: >>>> >>>> 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? >>>> >>>> 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 4/27/2012 6:11 PM, Leonid Romanov wrote: >>>>> Hi, >>>>> Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking "Show Message Dialog" button. Now, click on the "SwingSet2" window title bar and you'll see the window rapidly gaining and loosing focus. >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 >>>>> webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ >>>>> Thanks, >>>>> Leonid. > From Sergey.Bylokhov at oracle.com Thu May 3 08:16:27 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 03 May 2012 19:16:27 +0400 Subject: [7u6] Request for review: 7160623 [macosx] Editable TextArea/TextField are blocking GUI applications from exit Message-ID: <4FA2A14B.8040501@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=7160623 jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c31eeeda3ed1 Webrev can be found at: http://cr.openjdk.java.net/~serb/7160623/webrev.00 Discussion about the same xawt fix: http://mail.openjdk.java.net/pipermail/awt-dev/2012-March/002381.html From Sergey.Bylokhov at oracle.com Thu May 3 08:25:56 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 03 May 2012 19:25:56 +0400 Subject: [8] Request for review: 7147055 [macosx] Cursors are changing over a blocked window; also blinking In-Reply-To: <4F8306DD.1050300@oracle.com> References: <4F8306DD.1050300@oracle.com> Message-ID: <4FA2A384.8020900@oracle.com> Hi Everyone. Does anybody has a chance to review the fix? One more reviewer needed. Thanks. 09.04.2012 19:57, Sergey Bylokhov wrote: > Hi Everyone, > Cursor for blocked window was fixed. Now we use default cursor in this > case. > > 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 > > -- > Best regards, Sergey. > From leonid.romanov at oracle.com Thu May 3 08:51:56 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 3 May 2012 19:51:56 +0400 Subject: [7u6] Review request for 7124376: [macosx] Modal dialog lost focus Message-ID: Hi, This is a backport from JDK 8 to 7u6. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.02/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a420895ee2c3 Thanks, Leonid. From alexander.zuev at oracle.com Thu May 3 10:25:21 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 3 May 2012 21:25:21 +0400 Subject: [7u6] Review request for 7124376: [macosx] Modal dialog lost focus In-Reply-To: References: Message-ID: Looks fine to me. With best regards, Alexander Zuev 03.05.2012, ? 19:51, Leonid Romanov ???????(?): > Hi, > This is a backport from JDK 8 to 7u6. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 > webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.02/ > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a420895ee2c3 > > Thanks, > Leonid. > From alexander.zuev at oracle.com Thu May 3 10:28:57 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 03 May 2012 21:28:57 +0400 Subject: [8] Request for review: 7147055 [macosx] Cursors are changing over a blocked window; also blinking In-Reply-To: <4FA2A384.8020900@oracle.com> References: <4F8306DD.1050300@oracle.com> <4FA2A384.8020900@oracle.com> Message-ID: <4FA2C059.4050106@oracle.com> It looks pretty reasonable to me. With best regards, Alexander Zuev On 5/3/12 19:25, Sergey Bylokhov wrote: > Hi Everyone. > Does anybody has a chance to review the fix? One more reviewer needed. > > Thanks. > > 09.04.2012 19:57, Sergey Bylokhov wrote: >> Hi Everyone, >> Cursor for blocked window was fixed. Now we use default cursor in >> this case. >> >> 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 >> >> -- >> Best regards, Sergey. >> > From scott.kovatch at oracle.com Thu May 3 16:00:22 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 3 May 2012 16:00:22 -0700 Subject: JWS Feedback In-Reply-To: <2D3C4F59-9690-41EB-9927-8DBC06ADEDE7@rochester.rr.com> References: <2D3C4F59-9690-41EB-9927-8DBC06ADEDE7@rochester.rr.com> Message-ID: <51C81FC6-A3DC-4BA7-8710-08C6BE17A09C@oracle.com> On May 2, 2012, at 12:21 PM, Jeff Palmer wrote: > Tried to create java.net account so this could be posted in the location requested. Never got confirm message. Sent test message from elsewhere & showed up right away. Hit back button & addr was right. Submitted again & email & user name taken. Anyway, here is what would have been posted: > > - Always trust content from this publisher text is cramped from text above. Please file a bug. I always said it at Apple, and I'm saying it again at Oracle. :-) > - Explicitly requesting a 1.6 version gets Unsupported version of Java dialog. Same with 1.6+, 1.7, & 1.7.0_06-ea. Leaving out version tag correctly errors, saying there must be a version. This makes JWS virtually untestable. Prefer 1.6+ to work, so same .jnlp can work for Snow Leopard. Can you add 1.6 to the list of JREs in the Java Control Panel? Choose 'Java' -> 'View?' -> 'Find' and then navigate to /Library/Java/JavaVirtualMachines? It should find any 1.6 JDK installed there. Then click OK and 'Apply'. We should then start using 1.6 if the JNLP wants it. While this is not as good as discovering Java 6 automatically, we aren't currently supporting that. We may end up doing it but not guaranteeing compatibility with Java 6. > - The signing checking of comparing Application.jnlp in jar to website's works as before. Refuses to run, when they do not match. I'm not sure what you are describing here. Do you think this is a bug? I believe this is a feature of Web Start in JDK 7, but I'm not as up-to-date on the internals as I used to be. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From scott.kovatch at oracle.com Thu May 3 16:20:55 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 3 May 2012 16:20:55 -0700 Subject: JWS Feedback In-Reply-To: <51C81FC6-A3DC-4BA7-8710-08C6BE17A09C@oracle.com> References: <2D3C4F59-9690-41EB-9927-8DBC06ADEDE7@rochester.rr.com> <51C81FC6-A3DC-4BA7-8710-08C6BE17A09C@oracle.com> Message-ID: <8E20C61B-9E9B-4C25-8689-7EBC3A444064@oracle.com> On May 3, 2012, at 4:00 PM, Scott Kovatch wrote: > > On May 2, 2012, at 12:21 PM, Jeff Palmer wrote: > >> Tried to create java.net account so this could be posted in the location requested. Never got confirm message. Sent test message from elsewhere & showed up right away. Hit back button & addr was right. Submitted again & email & user name taken. Anyway, here is what would have been posted: >> >> - Always trust content from this publisher text is cramped from text above. > > Please file a bug. I always said it at Apple, and I'm saying it again at Oracle. :-) I should have clarified: http://bugreport.sun.com does not require you to sign up for an account. -- Scott K. From mik3hall at gmail.com Thu May 3 17:59:13 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 3 May 2012 19:59:13 -0500 Subject: Apple Security Provider. In-Reply-To: <4FA18125.9090904@oracle.com> References: <4FA04D15.2060408@oracle.com> <7C1CF7D5-B2A7-4A0D-B165-9D952800AF2A@gmail.com> <700AB04E-4E6D-4C68-A350-BBE61B264B7F@apple.com> <169E1E2E-0FEF-4021-A41E-B75D57C680BD@gmail.com> <21127AA3-221A-4242-A0C0-9A817729FF21@gmail.com> <4FA18125.9090904@oracle.com> Message-ID: <84D9F8EA-CE3F-429E-9E22-C60B928FF739@gmail.com> On May 2, 2012, at 1:47 PM, Sean Mullan wrote: > Try specifying null for the InputStream parameter. I am not familiar with the OS X implementation, but it sounds like that may have been a bug - according to the KeyStore API, in order to access a KeyStore, you first have to initialize it by calling the load method. I'd noticed keytool worked ok with it so I wasn't too worried. But yes, you look to be correct, as to 'load' is needed to init, this works... import java.security.*; import java.util.Enumeration; public class KeyStoreTester { public static void main(String[] args) { try { KeyStore ks = KeyStore.getInstance("KeychainStore","Apple"); ks.load(null,"ANY".toCharArray()); System.out.println(ks.getProvider()); Enumeration e = ks.aliases(); while (e.hasMoreElements()) System.out.println(e.nextElement()); } catch (Exception ex) { ex.printStackTrace(); } } } Apparently the example I copied from was buggy itself or the no init worked at some point. It's pretty unnecessary as both parameters are really invalid nonsense. I'd still sort of wonder if you really want to continue calling the Provider Apple as well? But maybe will be addressed a little farther down the road. From mik3hall at gmail.com Thu May 3 18:23:49 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 3 May 2012 20:23:49 -0500 Subject: Apple Security Provider. In-Reply-To: <700AB04E-4E6D-4C68-A350-BBE61B264B7F@apple.com> References: <4FA04D15.2060408@oracle.com> <7C1CF7D5-B2A7-4A0D-B165-9D952800AF2A@gmail.com> <700AB04E-4E6D-4C68-A350-BBE61B264B7F@apple.com> Message-ID: <5D52478C-CA26-41D5-98C8-647D5256BDE0@gmail.com> On May 1, 2012, at 4:57 PM, Mike Swingler wrote: > but not the entirely of the Apple provider (since it was based on deprecated API). One other thing on this. I'm not sure if you mean java deprecated or OS deprecated. If OS deprecated there's probably no reason to continue java support. If java deprecated but still valid OS API's there might be a reason to continue them? As I remember it some of these were java implementations of crypto protocols used elsewhere by Apple. Although there was nothing I made use of in preference to java alternatives that I remember. From marco.dinacci at gmail.com Fri May 4 02:22:36 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 4 May 2012 10:22:36 +0100 Subject: segmentedTextured buttons not rendered correctly Message-ID: Hi, the top and bottom borders of a JToggleButton are not correctly rendered if the client property segmentedTextured has been set. See this screenshot: http://goo.gl/04pfw This code reproduces the problem: import javax.swing.*; import java.awt.*; public class SegmentedTexturedTest { public static void main(String[] args) { JToggleButton leftButton = new JToggleButton("Left Button"); //leftButton.setMargin(new Insets(3,3,3,3)); // workaround leftButton.putClientProperty("JButton.buttonType", "segmentedTextured"); leftButton.putClientProperty("JButton.segmentPosition", "first"); leftButton.setFocusable(false); JToggleButton rightButton = new JToggleButton("Right Button"); //rightButton.setMargin(new Insets(3,3,3,3)); // workaround rightButton.putClientProperty("JButton.buttonType", "segmentedTextured"); rightButton.putClientProperty("JButton.segmentPosition", "last"); rightButton.setFocusable(false); JPanel contentPane = new JPanel(new FlowLayout(FlowLayout.LEFT, 0,0)); contentPane.add(leftButton); contentPane.add(rightButton); JFrame frame = new JFrame("SegmentedTexturedTest"); frame.setContentPane(contentPane); frame.pack(); frame.setLocationRelativeTo(null); frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); frame.setVisible(true); } } The workaround (see the two commented lines above) works fine for this simple test app but not for the more complicated layout I have in my app as the buttons takes too much space. Any ideas what is causing this problem ? Thanks, Marco From anthony.petrov at oracle.com Fri May 4 04:43:17 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 May 2012 15:43:17 +0400 Subject: [8] Review request for 7149062: [macosx] dock menu don't show available frames In-Reply-To: <586FC99C-0C39-49A6-916C-516C568FFB71@oracle.com> References: <4F8EB5A1.6060104@oracle.com> <4F95687A.3000709@oracle.com> <586FC99C-0C39-49A6-916C-516C568FFB71@oracle.com> Message-ID: <4FA3C0D5.5000908@oracle.com> Hi Scott, I'm sorry for the delay with my response. Thank you very much for the review! On 4/23/2012 9:15 PM, Scott Kovatch wrote: > This looks fine to me. Only question is in CPlatformWindow: > > 313 if (Window.Type.UTILITY.equals(target.getType())) { > 314 styleBits = SET(styleBits, UTILITY, true); > 315 } > > Is this new? It looks needed but not necessarily part of this fix. Indeed. I've filed a separate CR 7166437 to address this issue. > It's unfortunate that you have to replicate code in AWTWindow_Normal and AWTWindow_Panel, but I don't see a better way to do it since you want to override methods. Would a category work here? There's not a lot of code here, but it may be harder to maintain over time. I've investigated that, but it looks like a category (or an extension) requires a class name to add methods to. It's impossible to define an anonymous category and then apply it to two different classes. However, for the sake of this fix we do need to have two distinct classes: one inheriting from NSWindow, and another - from NSPanel. I can't find anything Obj-C-wise that could help eliminate the code replication here. Well, we could extract it into a separate file and #include it within the corresponding @implementation sections. But given the really small size of the replicated code this would look a bit weird in my opinion. So I re-generated the webrev w/o the UTILITY thing mentioned above. The final webrev is at: http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.1/ Looks OK to push that? -- best regards, Anthony > > -- Scott > > On Apr 23, 2012, at 7:34 AM, Anthony Petrov wrote: > >> Mike et al., >> >> Could I get a review for this fix please? >> >> -- >> best regards, >> Anthony >> >> On 04/18/12 16:37, Anthony Petrov wrote: >>> Hello, >>> >>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7149062 at: >>> >>> http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.0/ >>> >>> The AWTWindow class now inherits from NSObject and implements the >>> NSWindowDelegate protocol. The real NSWindow object is held in the >>> nsWindow property of the AWTWindow class, and is represented by either >>> an AWTWindow_Normal or AWTWindow_Panel instance. These two classes >>> inherit from NSWindow and NSPanel correspondingly. Note, however, that >>> we still return a reference to the NSWindow/NSPanel instance to Java so >>> that the pointer could be used with CWrapper methods directly. A >>> reference to an associated AWTWindow instance is always available as >>> (AWTWindow*)[nsWindow delegate]. >>> >>> All windows that inherit from NSWindow are added to the windows list in >>> the dock icon menu by default. We use NSPanel-based windows for UTILITY, >>> HUD, NONACTIVATING, and HIDES_ON_DEACTIVATE windows only, because these >>> kinds of windows typically don't represent main application windows, and >>> thus aren't expected to be added to the windows list. Besides, UTILITY >>> (and HUD?) windows just have to be NSPanels. >>> >>> This fix is going to be back-ported to 7u6 later on. >>> >>> -- >>> best regards, >>> Anthony > From anthony.petrov at oracle.com Fri May 4 05:09:16 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 May 2012 16:09:16 +0400 Subject: [7u6] Request for review: 7160623 [macosx] Editable TextArea/TextField are blocking GUI applications from exit In-Reply-To: <4FA2A14B.8040501@oracle.com> References: <4FA2A14B.8040501@oracle.com> Message-ID: <4FA3C6EC.5020205@oracle.com> The fix still looks fine. -- best regards, Anthony On 5/3/2012 7:16 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=7160623 > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c31eeeda3ed1 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7160623/webrev.00 > > Discussion about the same xawt fix: > http://mail.openjdk.java.net/pipermail/awt-dev/2012-March/002381.html From anthony.petrov at oracle.com Fri May 4 05:15:35 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 May 2012 16:15:35 +0400 Subject: [8] Review request for 7166437: [macosx] Support for Window.Type.UTILITY on the Mac Message-ID: <4FA3C867.9000701@oracle.com> Hello, Please review this rather trivial fix for http://bugs.sun.com/view_bug.do?bug_id=7166437 at: http://cr.openjdk.java.net/~anthony/8-31-UTILITY-7166437.0/ -- best regards, Anthony From anthony.petrov at oracle.com Fri May 4 07:53:35 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 May 2012 18:53:35 +0400 Subject: [7u6] Review request for 7144542: [macosx] Crash in liblwawt.dylib setBusy() when exiting an FX app run with j2d pipeline Message-ID: <4FA3ED6F.5010502@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7144542 at: http://cr.openjdk.java.net/~anthony/7u6-6-crashInSetBusy-7144542.0/ Note: in JDK 8 we already load the headless version of the AWT library, and this prevents the crash. Now I'm applying the same logic to JDK 7u6. -- best regards, Anthony From scott.kovatch at oracle.com Fri May 4 09:07:28 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 4 May 2012 09:07:28 -0700 Subject: [8] Review request for 7149062: [macosx] dock menu don't show available frames In-Reply-To: <4FA3C0D5.5000908@oracle.com> References: <4F8EB5A1.6060104@oracle.com> <4F95687A.3000709@oracle.com> <586FC99C-0C39-49A6-916C-516C568FFB71@oracle.com> <4FA3C0D5.5000908@oracle.com> Message-ID: On May 4, 2012, at 4:43 AM, Anthony Petrov wrote: > I've investigated that, but it looks like a category (or an extension) requires a class name to add methods to. It's impossible to define an anonymous category and then apply it to two different classes. However, for the sake of this fix we do need to have two distinct classes: one inheriting from NSWindow, and another - from NSPanel. I can't find anything Obj-C-wise that could help eliminate the code replication here. Well, we could extract it into a separate file and #include it within the corresponding @implementation sections. But given the really small size of the replicated code this would look a bit weird in my opinion. No problem -- it was more a random thought than a concrete suggestion. I doubt we will be changing much in either file over time. > So I re-generated the webrev w/o the UTILITY thing mentioned above. The final webrev is at: > > http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.1/ > > Looks OK to push that? Looks good to me. -- Scott K. From anthony.petrov at oracle.com Fri May 4 09:09:38 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 May 2012 20:09:38 +0400 Subject: [8] Review request for 7149062: [macosx] dock menu don't show available frames In-Reply-To: References: <4F8EB5A1.6060104@oracle.com> <4F95687A.3000709@oracle.com> <586FC99C-0C39-49A6-916C-516C568FFB71@oracle.com> <4FA3C0D5.5000908@oracle.com> Message-ID: <4FA3FF42.9040503@oracle.com> Thanks for the review. -- best regards, Anthony On 5/4/2012 8:07 PM, Scott Kovatch wrote: > On May 4, 2012, at 4:43 AM, Anthony Petrov wrote: > >> I've investigated that, but it looks like a category (or an extension) requires a class name to add methods to. It's impossible to define an anonymous category and then apply it to two different classes. However, for the sake of this fix we do need to have two distinct classes: one inheriting from NSWindow, and another - from NSPanel. I can't find anything Obj-C-wise that could help eliminate the code replication here. Well, we could extract it into a separate file and #include it within the corresponding @implementation sections. But given the really small size of the replicated code this would look a bit weird in my opinion. > > No problem -- it was more a random thought than a concrete suggestion. I doubt we will be changing much in either file over time. > >> So I re-generated the webrev w/o the UTILITY thing mentioned above. The final webrev is at: >> >> http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.1/ >> >> Looks OK to push that? > > Looks good to me. > > -- Scott K. > > From jcpalmer at rochester.rr.com Fri May 4 10:27:48 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Fri, 4 May 2012 13:27:48 -0400 Subject: JWS Feedback In-Reply-To: <8E20C61B-9E9B-4C25-8689-7EBC3A444064@oracle.com> References: <2D3C4F59-9690-41EB-9927-8DBC06ADEDE7@rochester.rr.com> <51C81FC6-A3DC-4BA7-8710-08C6BE17A09C@oracle.com> <8E20C61B-9E9B-4C25-8689-7EBC3A444064@oracle.com> Message-ID: On May 3, 2012, at 7:20 PM, Scott Kovatch wrote: > > On May 3, 2012, at 4:00 PM, Scott Kovatch wrote: > >> >> On May 2, 2012, at 12:21 PM, Jeff Palmer wrote: >> >>> Tried to create java.net account so this could be posted in the location requested. Never got confirm message. Sent test message from elsewhere & showed up right away. Hit back button & addr was right. Submitted again & email & user name taken. Anyway, here is what would have been posted: >>> >>> - Always trust content from this publisher text is cramped from text above. >> >> Please file a bug. I always said it at Apple, and I'm saying it again at Oracle. :-) > > I should have clarified: http://bugreport.sun.com does not require you to sign up for an account. > > -- Scott K. Good one ;-) Turns out the correct answer was just try to log in. It does not like it, but gives a button to resend the confirmation email. Worked second time. As far as the Application.jnlp comment, Yes it is a feature. Doing all the JNLP experiments, I was reminded myself that I cannot just change the jnlp alone. Your page said to list good and bad. Just thought: nobody is going to test that. Maybe should mention it works. Will submit bug on text placement of the check box. I'll reply to the tag thing separately. Your suggestion is not what I want. I have been reading JNLP file syntax very closely, and will reply after tests are complete. From swingler at apple.com Fri May 4 14:50:10 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 04 May 2012 14:50:10 -0700 Subject: [8] Review request for 7149062: [macosx] dock menu don't show available frames In-Reply-To: <4FA3FF42.9040503@oracle.com> References: <4F8EB5A1.6060104@oracle.com> <4F95687A.3000709@oracle.com> <586FC99C-0C39-49A6-916C-516C568FFB71@oracle.com> <4FA3C0D5.5000908@oracle.com> <4FA3FF42.9040503@oracle.com> Message-ID: <7A956413-A1B7-4E4A-8D4C-90B98A6666DF@apple.com> Overall, this looks good, but my one suggestion would be to NOT break out AWTWindow_Normal and AWTWindow_Panel into their own files, but instead to put them side-by-side in the AWTWindow implementation. You could possibly share part of their implementations in a macro to enforce that they don't fall out of sync with each other over time, but that might be overkill - though I think keeping them in the same file will be important for people to see both at the same time. Regards, Mike Swingler Apple Inc. On May 4, 2012, at 9:09 AM, Anthony Petrov wrote: > Thanks for the review. > > -- > best regards, > Anthony > > On 5/4/2012 8:07 PM, Scott Kovatch wrote: >> On May 4, 2012, at 4:43 AM, Anthony Petrov wrote: >>> I've investigated that, but it looks like a category (or an extension) requires a class name to add methods to. It's impossible to define an anonymous category and then apply it to two different classes. However, for the sake of this fix we do need to have two distinct classes: one inheriting from NSWindow, and another - from NSPanel. I can't find anything Obj-C-wise that could help eliminate the code replication here. Well, we could extract it into a separate file and #include it within the corresponding @implementation sections. But given the really small size of the replicated code this would look a bit weird in my opinion. >> No problem -- it was more a random thought than a concrete suggestion. I doubt we will be changing much in either file over time. >>> So I re-generated the webrev w/o the UTILITY thing mentioned above. The final webrev is at: >>> >>> http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.1/ >>> >>> Looks OK to push that? >> Looks good to me. >> -- Scott K. From jcpalmer at rochester.rr.com Fri May 4 15:35:02 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Fri, 4 May 2012 18:35:02 -0400 Subject: JWS Feedback In-Reply-To: <51C81FC6-A3DC-4BA7-8710-08C6BE17A09C@oracle.com> References: <2D3C4F59-9690-41EB-9927-8DBC06ADEDE7@rochester.rr.com> <51C81FC6-A3DC-4BA7-8710-08C6BE17A09C@oracle.com> Message-ID: <38B4F4DA-C5C1-4508-9662-BB0E5920DAC8@rochester.rr.com> On May 3, 2012, at 7:00 PM, Scott Kovatch wrote: > > On May 2, 2012, at 12:21 PM, Jeff Palmer wrote: > >> - Explicitly requesting a 1.6 version gets Unsupported version of Java dialog. Same with 1.6+, 1.7, & 1.7.0_06-ea. Leaving out version tag correctly errors, saying there must be a version. This makes JWS virtually untestable. Prefer 1.6+ to work, so same .jnlp can work for Snow Leopard. > > Can you add 1.6 to the list of JREs in the Java Control Panel? Choose 'Java' -> 'View?' -> 'Find' and then navigate to /Library/Java/JavaVirtualMachines? It should find any 1.6 JDK installed there. Then click OK and 'Apply'. We should then start using 1.6 if the JNLP wants it. > > While this is not as good as discovering Java 6 automatically, we aren't currently supporting that. We may end up doing it but not guaranteeing compatibility with Java 6. > Lets start over by stating what it is I want: - A single JNLP which could be put into production today. - Would start Java 7 to run an application on Windows / linux. - Would start Java 7 to run an application on OSX if available, otherwise start Java 6. Today, Java 6 would get used on all versions of OS X. Once the OS update happens on Lion, and the customer loads it, they should start running using Java 7. Snow leopard continues to start Java 6. Of course, this means code must be build for Java 1.6, but has the upside of having the customer base already using Java 7 when a compelling reason is found to use a Java 7 feature. With a little lead time, Snow Leopard customers can told to upgrade to Mountain Loin in that case. This is not an education product involving school budgets, making it is impossible Snow Leopard under the bus. - - - - - - - How I want to do this is using the ability of specifying multiple versions to use when the os="Mac". The JNLP reference material says multiple versions can be specified in priority order, so all of the above should be accomplishable with: - - - - - - - What is happening is the following message is displayed: One big problem is "WELL WHAT VERSION DOES IT THINK WAS BEING ASKED FOR?" Will submit a bug to show this as well on the message. I tried a whole list of stuff multiple times, but always the same result. Then I remembered I had another JWS application built & signed the same that is not for general use. I made resources match above, and changed the little single for dialog to show the JVM running in the title. Starts just fine on Lion, running 1.7. Have not restarted as SN to absolutely nail down it works there too, but SN does work with a single 1.6+ in the Mac section. So something is different. Can I assume that this must be in the JNLP and not the app? I cannot really submit a bug without better isolation. A couple of other troubling things are: I followed the directions to un-install, then re-installed the plug-in. There is something missing from those directions. Something like file already exists happens on re-install from the terminal commands. After the second re-install, I no longer get a Java icon in Preferences app. Also apart from the very first time run, never get the dialog where it asks whether to trust my CA code signing certificate, even after re-install. From anthony.petrov at oracle.com Sat May 5 05:57:44 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Sat, 05 May 2012 16:57:44 +0400 Subject: [8] Review request for 7149062: [macosx] dock menu don't show available frames In-Reply-To: <7A956413-A1B7-4E4A-8D4C-90B98A6666DF@apple.com> References: <4F8EB5A1.6060104@oracle.com> <4F95687A.3000709@oracle.com> <586FC99C-0C39-49A6-916C-516C568FFB71@oracle.com> <4FA3C0D5.5000908@oracle.com> <4FA3FF42.9040503@oracle.com> <7A956413-A1B7-4E4A-8D4C-90B98A6666DF@apple.com> Message-ID: <4FA523C8.2070508@oracle.com> Thanks for reviewing that. Your suggestion sounds reasonable, so I've published a new webrev at: http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.2/ -- best regards, Anthony On 5/5/2012 1:50 AM, Mike Swingler wrote: > Overall, this looks good, but my one suggestion would be to NOT break out AWTWindow_Normal and AWTWindow_Panel into their own files, but instead to put them side-by-side in the AWTWindow implementation. > > You could possibly share part of their implementations in a macro to enforce that they don't fall out of sync with each other over time, but that might be overkill - though I think keeping them in the same file will be important for people to see both at the same time. > > Regards, > Mike Swingler > Apple Inc. > > On May 4, 2012, at 9:09 AM, Anthony Petrov wrote: > >> Thanks for the review. >> >> -- >> best regards, >> Anthony >> >> On 5/4/2012 8:07 PM, Scott Kovatch wrote: >>> On May 4, 2012, at 4:43 AM, Anthony Petrov wrote: >>>> I've investigated that, but it looks like a category (or an extension) requires a class name to add methods to. It's impossible to define an anonymous category and then apply it to two different classes. However, for the sake of this fix we do need to have two distinct classes: one inheriting from NSWindow, and another - from NSPanel. I can't find anything Obj-C-wise that could help eliminate the code replication here. Well, we could extract it into a separate file and #include it within the corresponding @implementation sections. But given the really small size of the replicated code this would look a bit weird in my opinion. >>> No problem -- it was more a random thought than a concrete suggestion. I doubt we will be changing much in either file over time. >>>> So I re-generated the webrev w/o the UTILITY thing mentioned above. The final webrev is at: >>>> >>>> http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.1/ >>>> >>>> Looks OK to push that? >>> Looks good to me. >>> -- Scott K. > From jcpalmer at rochester.rr.com Sat May 5 13:08:29 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Sat, 5 May 2012 16:08:29 -0400 Subject: JWS Feedback In-Reply-To: <38B4F4DA-C5C1-4508-9662-BB0E5920DAC8@rochester.rr.com> References: <2D3C4F59-9690-41EB-9927-8DBC06ADEDE7@rochester.rr.com> <51C81FC6-A3DC-4BA7-8710-08C6BE17A09C@oracle.com> <38B4F4DA-C5C1-4508-9662-BB0E5920DAC8@rochester.rr.com> Message-ID: Wow! That was painful. Go news is I'm in. I'll walk some of this back in this order: If you change the 2nd command in the install directions to add the force option when creating the link in the preferences, sudo ln -fs ?, the install is repeatable, and got the Java Preferences Dialog back. Once that was is back, you could remove a certificate, which I did and, the permission to run dialog shows again. Not important that certificates do not get removed with un-install as this whole install thing is a temp job. After an exhaustive set of tests, it was determined that this could not be an issue with the JNLP. Another 6 tests later of ripping stuff out of the application, I looked up and saw that the message was MINE! @#*!! A month ago, I put in a Mac only String check that the JVM version was 1.6.0_31, because of that stupid flash thing. Re-worked the test & it comes up! Only a brief look around, but it is operational. Did notice some things as expected. Will submit any bugs including the cramped text discussed earlier. On May 4, 2012, at 6:35 PM, Jeff Palmer wrote: > > On May 3, 2012, at 7:00 PM, Scott Kovatch wrote: > >> >> On May 2, 2012, at 12:21 PM, Jeff Palmer wrote: >> >>> - Explicitly requesting a 1.6 version gets Unsupported version of Java dialog. Same with 1.6+, 1.7, & 1.7.0_06-ea. Leaving out version tag correctly errors, saying there must be a version. This makes JWS virtually untestable. Prefer 1.6+ to work, so same .jnlp can work for Snow Leopard. >> >> Can you add 1.6 to the list of JREs in the Java Control Panel? Choose 'Java' -> 'View?' -> 'Find' and then navigate to /Library/Java/JavaVirtualMachines? It should find any 1.6 JDK installed there. Then click OK and 'Apply'. We should then start using 1.6 if the JNLP wants it. >> >> While this is not as good as discovering Java 6 automatically, we aren't currently supporting that. We may end up doing it but not guaranteeing compatibility with Java 6. >> > > Lets start over by stating what it is I want: > - A single JNLP which could be put into production today. > - Would start Java 7 to run an application on Windows / linux. > - Would start Java 7 to run an application on OSX if available, otherwise start Java 6. > > Today, Java 6 would get used on all versions of OS X. Once the OS update happens on Lion, and the customer loads it, they should start running using Java 7. Snow leopard continues to start Java 6. > > Of course, this means code must be build for Java 1.6, but has the upside of having the customer base already using Java 7 when a compelling reason is found to use a Java 7 feature. With a little lead time, Snow Leopard customers can told to upgrade to Mountain Loin in that case. This is not an education product involving school budgets, making it is impossible Snow Leopard under the bus. > - - - - - - - > How I want to do this is using the ability of specifying multiple versions to use when the os="Mac". The JNLP reference material says multiple versions can be specified in priority order, so all of the above should be accomplishable with: > > > > > > > > version="1.7+" > version="1.6+" > /> > > - - - - - - - > What is happening is the following message is displayed: > > > > > One big problem is "WELL WHAT VERSION DOES IT THINK WAS BEING ASKED FOR?" Will submit a bug to show this as well on the message. > > I tried a whole list of stuff multiple times, but always the same result. Then I remembered I had another JWS application built & signed the same that is not for general use. I made resources match above, and changed the little single for dialog to show the JVM running in the title. Starts just fine on Lion, running 1.7. Have not restarted as SN to absolutely nail down it works there too, but SN does work with a single 1.6+ in the Mac section. > > So something is different. Can I assume that this must be in the JNLP and not the app? I cannot really submit a bug without better isolation. > > A couple of other troubling things are: I followed the directions to un-install, then re-installed the plug-in. There is something missing from those directions. Something like file already exists happens on re-install from the terminal commands. After the second re-install, I no longer get a Java icon in Preferences app. > > Also apart from the very first time run, never get the dialog where it asks whether to trust my CA code signing certificate, even after re-install. > > > > From swingler at apple.com Sun May 6 14:22:24 2012 From: swingler at apple.com (Mike Swingler) Date: Sun, 06 May 2012 14:22:24 -0700 Subject: [8] Review request for 7149062: [macosx] dock menu don't show available frames In-Reply-To: <4FA523C8.2070508@oracle.com> References: <4F8EB5A1.6060104@oracle.com> <4F95687A.3000709@oracle.com> <586FC99C-0C39-49A6-916C-516C568FFB71@oracle.com> <4FA3C0D5.5000908@oracle.com> <4FA3FF42.9040503@oracle.com> <7A956413-A1B7-4E4A-8D4C-90B98A6666DF@apple.com> <4FA523C8.2070508@oracle.com> Message-ID: Looks good to me. Cheers, Mike Swingler Apple Inc. On May 5, 2012, at 5:57 AM, Anthony Petrov wrote: > Thanks for reviewing that. Your suggestion sounds reasonable, so I've published a new webrev at: > > http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.2/ > > -- > best regards, > Anthony > > On 5/5/2012 1:50 AM, Mike Swingler wrote: >> Overall, this looks good, but my one suggestion would be to NOT break out AWTWindow_Normal and AWTWindow_Panel into their own files, but instead to put them side-by-side in the AWTWindow implementation. >> You could possibly share part of their implementations in a macro to enforce that they don't fall out of sync with each other over time, but that might be overkill - though I think keeping them in the same file will be important for people to see both at the same time. >> Regards, >> Mike Swingler >> Apple Inc. >> On May 4, 2012, at 9:09 AM, Anthony Petrov wrote: >>> Thanks for the review. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 5/4/2012 8:07 PM, Scott Kovatch wrote: >>>> On May 4, 2012, at 4:43 AM, Anthony Petrov wrote: >>>>> I've investigated that, but it looks like a category (or an extension) requires a class name to add methods to. It's impossible to define an anonymous category and then apply it to two different classes. However, for the sake of this fix we do need to have two distinct classes: one inheriting from NSWindow, and another - from NSPanel. I can't find anything Obj-C-wise that could help eliminate the code replication here. Well, we could extract it into a separate file and #include it within the corresponding @implementation sections. But given the really small size of the replicated code this would look a bit weird in my opinion. >>>> No problem -- it was more a random thought than a concrete suggestion. I doubt we will be changing much in either file over time. >>>>> So I re-generated the webrev w/o the UTILITY thing mentioned above. The final webrev is at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.1/ >>>>> >>>>> Looks OK to push that? >>>> Looks good to me. >>>> -- Scott K. From henri.gomez at gmail.com Sun May 6 23:49:02 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 7 May 2012 08:49:02 +0200 Subject: Java for OS X 2012-004 and OpenJDK 7 / 8 Message-ID: With Java for OS X 2012-004, I'm wondering if there is an impact in build process of OpenJDK 7 and 8 for OSX. Should this VM, hosted under /Library/Java/JavaVirtualMachines/1.6.0_32-b05-417.jdk/ should be used now as build VM for OpenJDK 7 ? Cheers From swingler at apple.com Mon May 7 08:42:36 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 07 May 2012 08:42:36 -0700 Subject: Java for OS X 2012-004 and OpenJDK 7 / 8 In-Reply-To: References: Message-ID: <0B6346C9-4495-4576-A452-6507EA71E9B1@apple.com> On May 6, 2012, at 11:49 PM, Henri Gomez wrote: > With Java for OS X 2012-004, I'm wondering if there is an impact in > build process of OpenJDK 7 and 8 for OSX. > > Should this VM, hosted under > /Library/Java/JavaVirtualMachines/1.6.0_32-b05-417.jdk/ should be used > now as build VM for OpenJDK 7 ? Ideally, OpenJDK should be building OpenJDK. You shouldn't need to bootstrap with an Apple JVM anymore. Regards, Mike Swingler Apple Inc. From scott.kovatch at oracle.com Mon May 7 09:10:50 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 7 May 2012 09:10:50 -0700 Subject: Heads up: bundle name change integrated today Message-ID: Folks, If you are building from jdk7u you should know that the name of the generated bundles are now: jdk$(JDK_VERSION).jdk jre$(JDK_VERSION).jre or, for 7u6, jdk1.7.0_06.jdk jre1.7.0_06.jre You have to supply JDK_UPDATE_VERSION yourself. This will keep the installer from overwriting a previous JDK, and will let users who have extensions turned off know whether they have a JDK or JRE installed. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From henri.gomez at gmail.com Tue May 8 08:42:57 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 8 May 2012 17:42:57 +0200 Subject: Java for OS X 2012-004 and OpenJDK 7 / 8 In-Reply-To: <0B6346C9-4495-4576-A452-6507EA71E9B1@apple.com> References: <0B6346C9-4495-4576-A452-6507EA71E9B1@apple.com> Message-ID: > Ideally, OpenJDK should be building OpenJDK. You shouldn't need to bootstrap with an Apple JVM anymore. I use OpenJDK 7 to build OpenJDK 8 (various versions) but never tried to build OpenJDK 7 with OpenJDK7 I'll try. From henri.gomez at gmail.com Tue May 8 08:44:29 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 8 May 2012 17:44:29 +0200 Subject: Heads up: bundle name change integrated today In-Reply-To: References: Message-ID: I notice that yesterday. I don't see any problems with previous versions installed since it's packaging works who do such relocation job. 2012/5/7 Scott Kovatch : > Folks, > > If you are building from jdk7u you should know that the name of the generated bundles are now: > > jdk$(JDK_VERSION).jdk > jre$(JDK_VERSION).jre > > or, for 7u6, > > jdk1.7.0_06.jdk > jre1.7.0_06.jre > > You have to supply JDK_UPDATE_VERSION yourself. > > This will keep the installer from overwriting a previous JDK, and will let users who have extensions turned off know whether they have a JDK or JRE installed. > > -- Scott K. > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > > From scott.kovatch at oracle.com Tue May 8 09:03:02 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 8 May 2012 09:03:02 -0700 Subject: Heads up: bundle name change integrated today In-Reply-To: References: Message-ID: <4A5AC073-1D33-4799-AA53-3EBE53DCEDE4@oracle.com> The issue with overwriting will bite you if you are installing with the Oracle JDK installer. If you build it yourself, probably not. I know some people (including myself) just have a symlink to the built JDK bundle in /Library/Java/JavaVirtualMachines, and if you forget to update that link you'll wonder why nothing changes when you make a fix. -- Scott K. On May 8, 2012, at 8:44 AM, Henri Gomez wrote: > I notice that yesterday. > > I don't see any problems with previous versions installed since it's > packaging works who do such relocation job. > > 2012/5/7 Scott Kovatch : >> Folks, >> >> If you are building from jdk7u you should know that the name of the generated bundles are now: >> >> jdk$(JDK_VERSION).jdk >> jre$(JDK_VERSION).jre >> >> or, for 7u6, >> >> jdk1.7.0_06.jdk >> jre1.7.0_06.jre >> >> You have to supply JDK_UPDATE_VERSION yourself. >> >> This will keep the installer from overwriting a previous JDK, and will let users who have extensions turned off know whether they have a JDK or JRE installed. >> >> -- Scott K. >> >> ---------------------------------------- >> Scott Kovatch >> scott.kovatch at oracle.com >> Santa Clara/Pleasanton, CA >> >> From henri.gomez at gmail.com Tue May 8 09:10:25 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 8 May 2012 18:10:25 +0200 Subject: Heads up: bundle name change integrated today In-Reply-To: <4A5AC073-1D33-4799-AA53-3EBE53DCEDE4@oracle.com> References: <4A5AC073-1D33-4799-AA53-3EBE53DCEDE4@oracle.com> Message-ID: > The issue with overwriting will bite you if you are installing with the Oracle JDK installer. If you build it yourself, probably not. I know some people (including myself) just have a symlink to the built JDK bundle in /Library/Java/JavaVirtualMachines, and if you forget to update that link you'll wonder why nothing changes when you make a fix. A symlink between /your/home/build/location/1.7.0.jdk and /Library/Java/JavaVirtualMachines/1.7.0.jdk ? So it will be a new symlink between : /your/home/build/location/jdk1.7.0.jdk and /Library/Java/JavaVirtualMachines/1.7.0.jdk ? From scott.kovatch at oracle.com Tue May 8 09:18:24 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 8 May 2012 09:18:24 -0700 Subject: Heads up: bundle name change integrated today In-Reply-To: References: <4A5AC073-1D33-4799-AA53-3EBE53DCEDE4@oracle.com> Message-ID: <2E2FF916-643B-40FE-924A-25C21D96F102@oracle.com> On May 8, 2012, at 9:10 AM, Henri Gomez wrote: >> The issue with overwriting will bite you if you are installing with the Oracle JDK installer. If you build it yourself, probably not. I know some people (including myself) just have a symlink to the built JDK bundle in /Library/Java/JavaVirtualMachines, and if you forget to update that link you'll wonder why nothing changes when you make a fix. > > A symlink between /your/home/build/location/1.7.0.jdk and > /Library/Java/JavaVirtualMachines/1.7.0.jdk ? > > So it will be a new symlink between : > > /your/home/build/location/jdk1.7.0.jdk and > /Library/Java/JavaVirtualMachines/1.7.0.jdk ? No, just 'ln -s /your/home/build/location/jdk1.7.0_06.jdk' in /Library/Java/JavaVirtualMachines, in my case. I also had one for /your/home/build/location/1.7.0.jdk. -- Scott From henri.gomez at gmail.com Tue May 8 10:35:59 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 8 May 2012 19:35:59 +0200 Subject: Heads up: bundle name change integrated today In-Reply-To: <2E2FF916-643B-40FE-924A-25C21D96F102@oracle.com> References: <4A5AC073-1D33-4799-AA53-3EBE53DCEDE4@oracle.com> <2E2FF916-643B-40FE-924A-25C21D96F102@oracle.com> Message-ID: > No, just 'ln -s /your/home/build/location/jdk1.7.0_06.jdk' in /Library/Java/JavaVirtualMachines, in my case. I also had one for /your/home/build/location/1.7.0.jdk. Ok I don't have such problem. BTW, I updated my OpenJDK 7 and 8 builds. From greg.x.brown at oracle.com Tue May 8 17:06:30 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Tue, 8 May 2012 20:06:30 -0400 Subject: JDK 7 with JavaApplicationStub In-Reply-To: References: <8117A406-9F47-4EB1-8C51-A702D70008CB@ultramixer.com> <3563925A-391C-407A-954C-C56FA16BA029@oracle.com> <066C14EE-9F94-4184-B1E2-BC6C7D338EB7@gmail.com> <8D557568-43D0-45A5-A69A-1DDE819239DD@apple.com> <0FDE1CCB-1EB0-4170-938B-08D4BC6A3659@apple.com> <540D00C0-5F4D-4C7B-B4E4-BEA12AC7FBC9@gmail.com> Message-ID: > There are many parts of the JDK that can be stripped out (or even starting with a base JRE instead). Currently all of the bin/* tools, JObjC, and several other libraries. The AppBundler projects have ways to make this stripping automatic. Right, AppBundler now supports this. See the section on the nested element: http://java.net/downloads/appbundler/appbundler.html From tobi at ultramixer.com Tue May 8 23:11:41 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 9 May 2012 08:11:41 +0200 Subject: JDK 7 with JavaApplicationStub In-Reply-To: <4179A78EBF714C308730D0DE66CCCE7B@marinacci.org> References: <8117A406-9F47-4EB1-8C51-A702D70008CB@ultramixer.com> <421DDE84-9BE6-45CB-AE9C-0C271C65510E@marinacci.org> <5212148C-49AB-4361-93D4-4759ED12DA07@gmail.com> <337950BA-6EC9-4FE1-B13A-0866AD8CE8A2@oracle.com> <97A3E3B4-9F2D-4AFC-81A5-9EF3C65E9EB9@gmail.com> <4179A78EBF714C308730D0DE66CCCE7B@marinacci.org> Message-ID: <0CCE09BF-CDAF-427E-80AF-D065E9D23B7B@ultramixer.com> I tried to make a java app for the mac app store with a bundled JRE. So I used the AppBundler from Oracle, specified the java.library.path with = ./Contents/Java and now it works! Now I'm going to submit the app to the AppStore anew (10th try ;)) Best regards, Tobi Am 09.05.2012 um 05:51 schrieb Josh Marinacci : > Semantically, the working directory is the directory the user was in when they invoked a process from the command shell. If there is no active shell then the concept of a working directory is meaningless. Hence my original question, what are you actually trying to accomplish? > > -- > Josh Marinacci > joshondesign.com > > On Tuesday, May 8, 2012 at 8:43 PM, Scott Palmer wrote: > >> On 2012-05-08, at 8:16 PM, Michael Hall wrote: >> >>> >>> On May 8, 2012, at 7:07 PM, Greg Brown wrote: >>> >>>> and are not allowed to change it programmatically. >>> >>> echo $user.dir >>> /Users/mjh/HalfPipe_work >>> set user.dir /Users/mjh/HalfPipe_work/HalfPipe.app >>> echo $user.dir >>> /Users/mjh/HalfPipe_work/HalfPipe.app >>> exec ls -l $user.dir >>> total 0 >>> drwxr-xr-x 6 mjh staff 204 May 6 08:26 Contents >> >> A shell environment variable and a Java "system property" are not the same thing. >> >> Scott >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Java-dev mailing list (Java-dev at lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/java-dev/joshua%40marinacci.org >> >> This email sent to joshua at marinacci.org > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Java-dev mailing list (Java-dev at lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/java-dev/tobi%40ultramixer.com > > This email sent to tobi at ultramixer.com From tobi at ultramixer.com Wed May 9 00:06:03 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 9 May 2012 09:06:03 +0200 Subject: build AppBundler? Message-ID: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> Hi Greg, how can i build the AppBundler from the source code? I'm missing a ant file or something like that...? Best regards, Tobi From tobi at ultramixer.com Wed May 9 01:29:20 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 9 May 2012 10:29:20 +0200 Subject: Contributing to AppBundler - Merging from JarBundler Message-ID: <78E2280A-3F07-4650-AED9-E06C7C79E215@ultramixer.com> Hi, I customized AppBundler so that I'm able to submit my Java app to the AppStore. Things that are currently missing in AppBundler (IMO) are: 1. field "LSApplicationCategoryType" => It's necessary for the AppStore. 2. option to specify working directory => AppBundler ant task should provide a further attribute like "workingDir" where the user can specify the working directory relative to the app bundle, e.g. workingDir="$APP_BUNDLE/Contents/Java" 3. further nested elements to specify helpbook folder and document types for associating file types to the app I'm a contributor of the JarBundler project which is similar to AppBundler projects but provides many more options like the 3 missing points on top. So if you like I extend the AppBundler project as a contributor. Please take a look at JarBundler: a) http://informagen.com/JarBundler/index.html b) http://informagen.com/JarBundler/DocumentType.html Furthermore I wrote several ant tasks to sign and archive java apps for the AppStore. 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 Fabrizio.Giudici at tidalwave.it Wed May 9 02:07:47 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Wed, 09 May 2012 11:07:47 +0200 Subject: Recapping status of JDK 7u4, OpenJDK 7 and embedding a JRE Message-ID: Folks, perhaps it's just me but I think we need to recap the status of various things as per the subject. I try to resume shortly what I'm aware of and then put some questions: 1. We have JDK 7u4 from Oracle that for what I see works pretty well on Mac OS X, in the sense that NetBeans 7.1.2 and some of my own, simpler apps pass a smoke test. 2. I can technically embed the JRE taken out of JDK 7u4 and it works - not doing that with one of the two AppBundler out there because my apps are based on the NetBeans Platform which requires its own startup, but I'm skipping this particular point now. 3. As far as I understand, JDK 7u4 by Oracle has its own licensing that prevents us from making any change (I'm explicitly referring on trimming some stuff) on the embedded JRE. 4. As far as I understand, JDK 7u4 can't be redistributed in any other way than embedding, which forbids e.g. preparing a Maven tar.gz artifact (even unstripped) with the JRE bits and publishing it to a public Maven repository. 5. As far as I understand, we are allowed to trim the embed JRE from OpenJDK as far as we comply with the GPLv2 + CPE rules. 6. As far as I understand, OpenJDK JRE can be redistributed as a Maven tar.gz artifact provided that I label it with the proper licensing stuff. First, I'd like to have some confirmation of the points above. Second, if they are correct, it seems that the only way I have to embed a JRE into my FLOSS apps is by using OpenJDK, because of that requirement of a Maven public artifact. Thanks. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." fabrizio.giudici at tidalwave.it http://tidalwave.it - http://fabriziogiudici.it From henri.gomez at gmail.com Wed May 9 03:16:33 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 9 May 2012 12:16:33 +0200 Subject: os.arch and universal Message-ID: I'm searching where os.arch is reported on OpenJDK 7 and 8 to complement my patches for universal (32/64bits) in jdk/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java, I could see : public final class JObjCRuntime { static { System.loadLibrary("JObjC"); } public static enum Arch{ ppc, i386, x86_64 }; public static enum Width{ W32, W64 }; public static final Arch ARCH = getArch(); public static final Width WIDTH = getWidth(); private static Arch getArch(){ String arch = System.getProperty("os.arch"); if("ppc".equals(arch)) return Arch.ppc; if("i386".equals(arch)) return Arch.i386; if("x86_64".equals(arch)) return Arch.x86_64; if("amd64".equals(arch)) return Arch.x86_64; if("universal".equals(arch)) return Arch.x86_64; throw new RuntimeException("Did not recognize os.arch system property: '" + arch + "'"); } Should it be : private static Arch getArch(){ String arch = System.getProperty("os.arch"); if("ppc".equals(arch)) return Arch.ppc; if("i386".equals(arch)) return Arch.i386; if("x86_64".equals(arch)) return Arch.x86_64; if("amd64".equals(arch)) return Arch.x86_64; if("universal".equals(arch) && getWidth() == Width.W64) return Arch.x86_64; if("universal".equals(arch) && getWidth() == Width.W32) return Arch.i386; throw new RuntimeException("Did not recognize os.arch system property: '" + arch + "'"); } From henri.gomez at gmail.com Wed May 9 04:56:20 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 9 May 2012 13:56:20 +0200 Subject: os.arch and universal In-Reply-To: References: Message-ID: I also notice some differences in jni part from has been done in macosx-port : jdk7 u /* os properties */ { #ifdef MACOSX setOSNameAndVersion(&sprops); #else struct utsname name; uname(&name); sprops.os_name = strdup(name.sysname); sprops.os_version = strdup(name.release); #endif sprops.os_arch = ARCHPROPNAME; if (getenv("GNOME_DESKTOP_SESSION_ID") != NULL) { sprops.desktop = "gnome"; } else { sprops.desktop = NULL; } } -- macosx-port /* os properties */ { sprops.os_arch = ARCHPROPNAME; #ifdef MACOSX setOSNameAndVersion(&sprops); #ifdef __x86_64__ sprops.os_arch = "x86_64"; #elif defined(__i386__) sprops.os_arch = "i386"; #endif #else struct utsname name; uname(&name); sprops.os_name = strdup(name.sysname); sprops.os_version = strdup(name.release); #endif Wondering if here also os_arch shouldn't be set regarding data model, ie 32/64 bits ? 2012/5/9 Henri Gomez : > I'm searching where os.arch is reported on OpenJDK 7 and 8 to > complement my patches for universal (32/64bits) > > in jdk/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java, > I could see : > > public final class JObjCRuntime { > ? ?static { System.loadLibrary("JObjC"); } > > ? ?public static enum Arch{ ppc, i386, x86_64 }; > ? ?public static enum Width{ W32, W64 }; > > ? ?public static final Arch ARCH = getArch(); > ? ?public static final Width WIDTH = getWidth(); > > ? ?private static Arch getArch(){ > ? ? ? ?String arch = System.getProperty("os.arch"); > ? ? ? ?if("ppc".equals(arch)) return Arch.ppc; > ? ? ? ?if("i386".equals(arch)) return Arch.i386; > ? ? ? ?if("x86_64".equals(arch)) return Arch.x86_64; > ? ? ? ?if("amd64".equals(arch)) return Arch.x86_64; > ? ? ? ?if("universal".equals(arch)) return Arch.x86_64; > ? ? ? ?throw new RuntimeException("Did not recognize os.arch system > property: '" + arch + "'"); > ? ?} > > Should it be : > > > ? ?private static Arch getArch(){ > ? ? ? ?String arch = System.getProperty("os.arch"); > ? ? ? ?if("ppc".equals(arch)) return Arch.ppc; > ? ? ? ?if("i386".equals(arch)) return Arch.i386; > ? ? ? ?if("x86_64".equals(arch)) return Arch.x86_64; > ? ? ? ?if("amd64".equals(arch)) return Arch.x86_64; > ? ? ? ?if("universal".equals(arch) && getWidth() == Width.W64) return > Arch.x86_64; > ? ? ? ?if("universal".equals(arch) && getWidth() == Width.W32) return > Arch.i386; > ? ? ? ?throw new RuntimeException("Did not recognize os.arch system > property: '" + arch + "'"); > ? ?} From henri.gomez at gmail.com Wed May 9 05:24:34 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 9 May 2012 14:24:34 +0200 Subject: os.arch "amd64" or "x86_64"? In-Reply-To: References: <4F305956.2000507@oracle.com> <04472581-D0D8-4DF7-B5F2-0A2713DDAD36@oracle.com> <4F306AC9.1000701@oracle.com> Message-ID: > The JDK 6 "java" command on OS X mentions this value as well, so it technically isn't even restricted to internal developer details (though most non-developers on OS X would never run "java" from the command line). > >>java -? > ? > where options include: > ? ?-d32 ? ? ? ? ?use a 32-bit data model if available > ? ?-d64 ? ? ? ? ?use a 64-bit data model if available (implies -server, only for x86_64) > ? Apple JVM 1.6 report i386 with -d32 and x86_64 with -d64. I guess we should do the same in Universal modes for OpenJDK 7 and higher From greg.x.brown at oracle.com Wed May 9 05:49:35 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 9 May 2012 08:49:35 -0400 Subject: build AppBundler? In-Reply-To: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> Message-ID: The source code is here: https://svn.java.net/svn/appbundler~svn/ You will need Java 7 and Ant 1.8.2 or later to build. Running "ant" from the root project directory will build the AppBundler JAR. "ant test-swingset" will create an app bundle for the SwingSet demo with an embedded JRE. "ant test-swingset-plugin" will create the same app but without the embedded JRE. Make sure you have JAVA_HOME defined, since that's how the script determines which JRE to embed. If you just want to download the latest binary, you can find it here: http://java.net/projects/appbundler/downloads On May 9, 2012, at 3:06 AM, Tobias Bley wrote: > Hi Greg, > > how can i build the AppBundler from the source code? I'm missing a ant file or something like that...? > > Best regards, > Tobi > > > > From marco.dinacci at gmail.com Wed May 9 05:57:06 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Wed, 9 May 2012 13:57:06 +0100 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> Message-ID: Hi, I also needed the LSApplicationCategoryType to be generated so I added support for it. It's in this very small patch against the latest svn: Index: appbundler/src/com/oracle/appbundler/AppBundlerTask.java =================================================================== --- appbundler/src/com/oracle/appbundler/AppBundlerTask.java (revision 20) +++ appbundler/src/com/oracle/appbundler/AppBundlerTask.java (working copy) @@ -65,6 +65,8 @@ private String signature = "????"; private String copyright = ""; + private String applicationCategoryType = ""; + // JVM info properties private String mainClassName = null; private FileSet runtime = null; @@ -121,6 +123,10 @@ this.mainClassName = mainClassName; } + public void setApplicationCategoryType(String applicationCategoryType) { + this.applicationCategoryType = applicationCategoryType; + } + public void addConfiguredRuntime(FileSet runtime) throws BuildException { if (this.runtime != null) { throw new BuildException("Runtime already specified."); @@ -389,6 +395,7 @@ writeProperty(xout, "CFBundleSignature", signature); writeProperty(xout, "CFBundleVersion", "1"); writeProperty(xout, "NSHumanReadableCopyright", copyright); + writeProperty(xout, "LSApplicationCategoryType", applicationCategoryType); // Write runtime if (runtime != null) { Best, Marco, On 9 May 2012 13:49, Greg Brown wrote: > The source code is here: > > https://svn.java.net/svn/appbundler~svn/ > > You will need Java 7 and Ant 1.8.2 or later to build. Running "ant" from the root project directory will build the AppBundler JAR. "ant test-swingset" will create an app bundle for the SwingSet demo with an embedded JRE. "ant test-swingset-plugin" will create the same app but without the embedded JRE. Make sure you have JAVA_HOME defined, since that's how the script determines which JRE to embed. > > If you just want to download the latest binary, you can find it here: > > http://java.net/projects/appbundler/downloads From greg.x.brown at oracle.com Wed May 9 06:02:56 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 9 May 2012 09:02:56 -0400 Subject: Contributing to AppBundler - Merging from JarBundler In-Reply-To: <78E2280A-3F07-4650-AED9-E06C7C79E215@ultramixer.com> References: <78E2280A-3F07-4650-AED9-E06C7C79E215@ultramixer.com> Message-ID: Hi Tobi, > 1. field "LSApplicationCategoryType" => It's necessary for the AppStore. This is good to know. I'll add support for this. > 2. option to specify working directory => AppBundler ant task should provide a further attribute like "workingDir" where the user can specify the working directory relative to the app bundle, e.g. workingDir="$APP_BUNDLE/Contents/Java" As I've mentioned, relying on the working directory is not a good practice. What are you currently using the working directory for? Maybe there is a better (more reliable) way to accomplish it. > 3. further nested elements to specify helpbook folder and document types for associating file types to the app Seems reasonable. Can you provide a little more detail on how you think this might work? Greg From greg.x.brown at oracle.com Wed May 9 06:03:24 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 9 May 2012 09:03:24 -0400 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> Message-ID: Thanks! On May 9, 2012, at 8:57 AM, Marco Dinacci wrote: > Hi, > > I also needed the LSApplicationCategoryType to be generated so I added > support for it. > It's in this very small patch against the latest svn: > > Index: appbundler/src/com/oracle/appbundler/AppBundlerTask.java > =================================================================== > --- appbundler/src/com/oracle/appbundler/AppBundlerTask.java (revision 20) > +++ appbundler/src/com/oracle/appbundler/AppBundlerTask.java (working copy) > @@ -65,6 +65,8 @@ > private String signature = "????"; > private String copyright = ""; > > + private String applicationCategoryType = ""; > + > // JVM info properties > private String mainClassName = null; > private FileSet runtime = null; > @@ -121,6 +123,10 @@ > this.mainClassName = mainClassName; > } > > + public void setApplicationCategoryType(String applicationCategoryType) { > + this.applicationCategoryType = applicationCategoryType; > + } > + > public void addConfiguredRuntime(FileSet runtime) throws BuildException { > if (this.runtime != null) { > throw new BuildException("Runtime already specified."); > @@ -389,6 +395,7 @@ > writeProperty(xout, "CFBundleSignature", signature); > writeProperty(xout, "CFBundleVersion", "1"); > writeProperty(xout, "NSHumanReadableCopyright", copyright); > + writeProperty(xout, "LSApplicationCategoryType", > applicationCategoryType); > > // Write runtime > if (runtime != null) { > > > > Best, > Marco, > > On 9 May 2012 13:49, Greg Brown wrote: >> The source code is here: >> >> https://svn.java.net/svn/appbundler~svn/ >> >> You will need Java 7 and Ant 1.8.2 or later to build. Running "ant" from the root project directory will build the AppBundler JAR. "ant test-swingset" will create an app bundle for the SwingSet demo with an embedded JRE. "ant test-swingset-plugin" will create the same app but without the embedded JRE. Make sure you have JAVA_HOME defined, since that's how the script determines which JRE to embed. >> >> If you just want to download the latest binary, you can find it here: >> >> http://java.net/projects/appbundler/downloads From henri.gomez at gmail.com Wed May 9 07:34:28 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 9 May 2012 16:34:28 +0200 Subject: os.arch and universal In-Reply-To: References: Message-ID: Universal patches updated : http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch Now os.arch is reported as i386 if data.model is 32 and as x86_64 is data.model is 64bits. It should fix problem with JRuby : https://github.com/jruby/jruby/commit/9e05b5f1791917cdc3487b3ddfd78956c4bb92c0#commitcomment-1306674 Cheers. 2012/5/9 Henri Gomez : > I also notice some differences in jni part from has been done in macosx-port : > > jdk7 u > > ? ?/* os properties */ > ? ?{ > #ifdef MACOSX > ? ? ? ?setOSNameAndVersion(&sprops); > #else > ? ? ? ?struct utsname name; > ? ? ? ?uname(&name); > ? ? ? ?sprops.os_name = strdup(name.sysname); > ? ? ? ?sprops.os_version = strdup(name.release); > #endif > > ? ? ? ?sprops.os_arch = ARCHPROPNAME; > > ? ? ? ?if (getenv("GNOME_DESKTOP_SESSION_ID") != NULL) { > ? ? ? ? ? ?sprops.desktop = "gnome"; > ? ? ? ?} > ? ? ? ?else { > ? ? ? ? ? ?sprops.desktop = NULL; > ? ? ? ?} > ? ?} > > -- > > macosx-port > > ? ?/* os properties */ > ? ?{ > ? ? ? ?sprops.os_arch = ARCHPROPNAME; > > #ifdef MACOSX > ? ? ? ?setOSNameAndVersion(&sprops); > #ifdef __x86_64__ > ? ? ? ?sprops.os_arch = "x86_64"; > #elif defined(__i386__) > ? ? ? ?sprops.os_arch = "i386"; > #endif > #else > ? ? ? ?struct utsname name; > ? ? ? ?uname(&name); > ? ? ? ?sprops.os_name = strdup(name.sysname); > ? ? ? ?sprops.os_version = strdup(name.release); > #endif > > Wondering if here also os_arch shouldn't be set regarding data model, > ie 32/64 bits ? > > > 2012/5/9 Henri Gomez : >> I'm searching where os.arch is reported on OpenJDK 7 and 8 to >> complement my patches for universal (32/64bits) >> >> in jdk/src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java, >> I could see : >> >> public final class JObjCRuntime { >> ? ?static { System.loadLibrary("JObjC"); } >> >> ? ?public static enum Arch{ ppc, i386, x86_64 }; >> ? ?public static enum Width{ W32, W64 }; >> >> ? ?public static final Arch ARCH = getArch(); >> ? ?public static final Width WIDTH = getWidth(); >> >> ? ?private static Arch getArch(){ >> ? ? ? ?String arch = System.getProperty("os.arch"); >> ? ? ? ?if("ppc".equals(arch)) return Arch.ppc; >> ? ? ? ?if("i386".equals(arch)) return Arch.i386; >> ? ? ? ?if("x86_64".equals(arch)) return Arch.x86_64; >> ? ? ? ?if("amd64".equals(arch)) return Arch.x86_64; >> ? ? ? ?if("universal".equals(arch)) return Arch.x86_64; >> ? ? ? ?throw new RuntimeException("Did not recognize os.arch system >> property: '" + arch + "'"); >> ? ?} >> >> Should it be : >> >> >> ? ?private static Arch getArch(){ >> ? ? ? ?String arch = System.getProperty("os.arch"); >> ? ? ? ?if("ppc".equals(arch)) return Arch.ppc; >> ? ? ? ?if("i386".equals(arch)) return Arch.i386; >> ? ? ? ?if("x86_64".equals(arch)) return Arch.x86_64; >> ? ? ? ?if("amd64".equals(arch)) return Arch.x86_64; >> ? ? ? ?if("universal".equals(arch) && getWidth() == Width.W64) return >> Arch.x86_64; >> ? ? ? ?if("universal".equals(arch) && getWidth() == Width.W32) return >> Arch.i386; >> ? ? ? ?throw new RuntimeException("Did not recognize os.arch system >> property: '" + arch + "'"); >> ? ?} From scott.kovatch at oracle.com Wed May 9 08:16:41 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 9 May 2012 08:16:41 -0700 Subject: Contributing to AppBundler - Merging from JarBundler In-Reply-To: <78E2280A-3F07-4650-AED9-E06C7C79E215@ultramixer.com> References: <78E2280A-3F07-4650-AED9-E06C7C79E215@ultramixer.com> Message-ID: <55B611AB-5429-4D0F-92DE-91FB82559F31@oracle.com> On May 9, 2012, at 1:29 AM, Tobias Bley wrote: > I'm a contributor of the JarBundler project which is similar to AppBundler projects but provides many more options like the 3 missing points on top. So if you like I extend the AppBundler project as a contributor. > > Please take a look at JarBundler: > > a) http://informagen.com/JarBundler/index.html > b) http://informagen.com/JarBundler/DocumentType.html > > Furthermore I wrote several ant tasks to sign and archive java apps for the AppStore. It would be great if you could contribute to AppBundler. If I can push aside some of the remaining applet and Web Start work I can devote more time to getting this going so we can accept contributions and make progress on it. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From artem.ananiev at oracle.com Thu May 10 03:11:54 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 10 May 2012 14:11:54 +0400 Subject: [7u6] Please review my fix for 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame In-Reply-To: <4F9BA768.1070404@oracle.com> References: <4F996FD3.9080702@oracle.com> <4F9ACF63.5080406@oracle.com> <4F9BA768.1070404@oracle.com> Message-ID: <4FAB946A.30407@oracle.com> Hi, Alex, could you add this information to the bug evaluation, please? Thanks, Artem On 4/28/2012 12:16 PM, Alexander Zuev wrote: > Anthony, > > sure, the details are: > > the ToolkitThreadBlockerHandler is an interface that is supposed to be used > when program has to wait for the event pushed to the EDT finish its task > and > he calls like this: > while (!dispatcher.isDone()) { > DataTransferer.getInstance().getToolkitThreadBlockedHandler().enter(); > } > and the event handler in its unregisterEvent() method calls for > handler.exit() > The method is supposed to make sure that waiting on the EDT doesn't > create deadlocks. > The implementation depends on the toolkit architecture - on some > toolkits it's NoOp since > they don't care if EDT is waiting, but in LWCToolkit our AWT components > are backed by Swing > delegates so there are a lot of calls from native application thread to > EDT and vice versa so we > can't afford to stop both threads. Solution is the code that makes > secondary AppKit event loop > to handle native events so waiting on EDT will leave at least one event > loop pumping. > > The name is correct because despite the fact that we are in AWT code > (LWCToolkit) we don't > create nested EDT loop but running nested native (AppKit) loop - hence > the name: enter/exitNativeEventLoop() > > With best regards, > Alex > > On 4/27/12 20:54, Anthony Petrov wrote: >> Hi Alexander, >> >> Could you provide some details about the ToolkitThreadBlockedHandler >> interface? How is it used by the DnD code? >> >> Also, I suggest to replace the word Native with Nested in >> enter/exitNativeEventLoop() method names. >> >> -- >> best regards, >> Anthony >> >> On 4/26/2012 7:54 PM, Alexander Zuev wrote: >>> Hello, >>> >>> please review my fix for the CR 7148289: [macosx] Deadlock in >>> sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame >>> >>> Bug description is >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7148289 >>> >>> Fix can be found at http://cr.openjdk.java.net/~kizune/7148289/webrev.00 >>> >>> With best regards, >>> Alex > From artem.ananiev at oracle.com Thu May 10 03:16:15 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 10 May 2012 14:16:15 +0400 Subject: [8] Review request for 7124376: [macosx] Modal dialog lost focus In-Reply-To: <365B8FE6-2E62-4B95-AE56-E474F1FDD4E6@oracle.com> References: <4F9AD9C7.6020707@oracle.com> <57BD5F10-B0B3-4091-8777-2A084643DC4C@oracle.com> <4F9ADFBE.5070909@oracle.com> <365B8FE6-2E62-4B95-AE56-E474F1FDD4E6@oracle.com> Message-ID: <4FAB956F.7000600@oracle.com> Hi, Leonid, I wonder why you need this check for *_EXCLUDED in platform code? Whether a window should be blocked or not is determined at the shared level, in java.awt.Window/Dialog, so it's either bug in this shared code, or the check in CPlatformWindow is redundant. Thanks, Artem On 5/2/2012 11:10 PM, Leonid Romanov wrote: > Hi, > I've reworked my fix. See > http://cr.openjdk.java.net/~leonidr/7124376/webrev.01/ > > On 27.04.2012, at 22:04, Anthony Petrov wrote: > >> I've noticed that too. I didn't point this out though, because you're also checking the MODAL_EXCLUDED flag in your modallyBlocked(), so I thought it was OK. But if you can pull this check to the Java code before even calling modallyBLocked(), then I guess the "setEnabled" name would make more sense. >> >> -- >> best regards, >> Anthony >> >> On 4/27/2012 10:02 PM, Leonid Romanov wrote: >>> I've looked at 7124395 and the fixes you did for FX and it looks like we need setEnabled method for AWTWindow. I'll redo my fix accordingly. On 27.04.2012, at 21:39, Anthony Petrov wrote: >>>> Hi Leonid, >>>> >>>> I was thinking of implementing a similar mechanism in order to fix 7124395. Please see the Comments section in that bug for some additional details. >>>> >>>> Regarding the fix itself: >>>> >>>> 1. Even though you return NO from canBecomeMain/KeyWindow, the OS will still bring the window to front of the z-order when you click it. In FX we handle this by always returning YES from canBecome* methods, however, the windowDidBecomeKey: sends a special FOCUS_DISABLED event if the window is blocked. In that case the upper level code re-stacks windows so that the blocker window always appears on the top of the z-order. Have you verified if this works fine for AWT apps with your fix? >>>> >>>> 2. Also, we just don't send mouse events for blocked windows from native code to Java. Is this handled somewhere else for modally blocked windows in lwawt? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 4/27/2012 6:11 PM, Leonid Romanov wrote: >>>>> Hi, >>>>> Please review a fix for 7124376: [macosx] Modal dialog lost focus. One can easily reproduce this bug by launching SwingSet2, choosing JOptionPane demo and then clicking "Show Message Dialog" button. Now, click on the "SwingSet2" window title bar and you'll see the window rapidly gaining and loosing focus. >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124376 >>>>> webrev: http://cr.openjdk.java.net/~leonidr/7124376/webrev.00/ >>>>> Thanks, >>>>> Leonid. > From artem.ananiev at oracle.com Thu May 10 03:23:47 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 10 May 2012 14:23:47 +0400 Subject: [8] Review request for 7166437: [macosx] Support for Window.Type.UTILITY on the Mac In-Reply-To: <4FA3C867.9000701@oracle.com> References: <4FA3C867.9000701@oracle.com> Message-ID: <4FAB9733.3090909@oracle.com> Hi, Anthony, the fix looks fine. Thanks, Artem On 5/4/2012 4:15 PM, Anthony Petrov wrote: > Hello, > > Please review this rather trivial fix for > http://bugs.sun.com/view_bug.do?bug_id=7166437 at: > > http://cr.openjdk.java.net/~anthony/8-31-UTILITY-7166437.0/ > > -- > best regards, > Anthony From artem.ananiev at oracle.com Thu May 10 03:33:39 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 10 May 2012 14:33:39 +0400 Subject: [7u6] Review request for 7144542: [macosx] Crash in liblwawt.dylib setBusy() when exiting an FX app run with j2d pipeline In-Reply-To: <4FA3ED6F.5010502@oracle.com> References: <4FA3ED6F.5010502@oracle.com> Message-ID: <4FAB9983.9030506@oracle.com> On 5/4/2012 6:53 PM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7144542 at: > > http://cr.openjdk.java.net/~anthony/7u6-6-crashInSetBusy-7144542.0/ So what you do is to change headful CToolkit to headless XToolkit, correct? Note that this change will also trigger Java2D pipeline change, which might not be what we want. Have you tried to find out what exactly leads to the crash when CToolkit is used? Thanks, Artem > Note: in JDK 8 we already load the headless version of the AWT library, > and this prevents the crash. Now I'm applying the same logic to JDK 7u6. > > -- > best regards, > Anthony From Alexander.Potochkin at oracle.com Thu May 10 10:20:07 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 10 May 2012 21:20:07 +0400 Subject: [8] request for review: 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. Message-ID: <4FABF8C7.6070506@oracle.com> Hello Please review the forward port to JDK 8 http://cr.openjdk.java.net/~alexp/7149005/webrev.00/ the patch is the same as previously approved for 7u4, I applied it to JDK8 and checked that it works as expected Thanks alexp From alexander.zuev at oracle.com Thu May 10 13:55:38 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 11 May 2012 00:55:38 +0400 Subject: [8] request for review: 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. In-Reply-To: <4FABF8C7.6070506@oracle.com> References: <4FABF8C7.6070506@oracle.com> Message-ID: <7DD0B2AD-964E-421F-BFF1-A4C7C038B380@oracle.com> Looks fine to me. With best regards, Alexander Zuev 10.05.2012, ? 21:20, Alexander Potochkin ???????(?): > Hello > > Please review the forward port to JDK 8 > http://cr.openjdk.java.net/~alexp/7149005/webrev.00/ > > the patch is the same as previously approved for 7u4, > I applied it to JDK8 and checked that it works as expected > > Thanks > alexp From marco.dinacci at gmail.com Fri May 11 03:53:57 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 11 May 2012 11:53:57 +0100 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> Message-ID: Hi Greg, I noticed that you included LSApplicationCategoryType in the source, thanks. However I've found one problems after building my app using the latest code, the icon is not showing. The reason is that in main.m you changed the current directory to NSHomeDirectory before launching the application and since the icon path is relative to the bundlePath the icon can't be found. A solution would be to revert the code like it was in rev 20 and change the directory to NSHomeDirectory after the app has been launched, something like this: Index: appbundler/native/main.m =================================================================== --- appbundler/native/main.m (revision 23) +++ appbundler/native/main.m (working copy) @@ -72,8 +72,11 @@ // Get the main bundle NSBundle *mainBundle = [NSBundle mainBundle]; - // Set the working directory to the user's home directory - chdir([NSHomeDirectory() UTF8String]); + // Set the working directory to the main bundle root + NSString *mainBundlePath = [mainBundle bundlePath]; + if (chdir([mainBundlePath UTF8String]) == -1) { + [NSException raise:@JAVA_LAUNCH_ERROR format:@"Could not set initial working directory."]; + } // Get the main bundle's info dictionary NSDictionary *infoDictionary = [mainBundle infoDictionary]; @@ -111,7 +114,6 @@ } // Set the class path - NSString *mainBundlePath = [mainBundle bundlePath]; NSString *javaPath = [mainBundlePath stringByAppendingString:@"/Contents/Java"]; NSMutableString *classPath = [NSMutableString stringWithFormat:@"-Djava.class.path=%@/Classes", javaPath]; @@ -162,7 +164,7 @@ } // Invoke JLI_Launch() - return jli_LaunchFxnPtr(argc, argv, + int result = jli_LaunchFxnPtr(argc, argv, 0, NULL, 0, NULL, "", @@ -173,4 +175,9 @@ FALSE, FALSE, 0); + + // Set the working directory to the user's home directory + chdir([NSHomeDirectory() UTF8String]); + + return result; } Best, Marco On 9 May 2012 14:03, Greg Brown wrote: > Thanks! > > On May 9, 2012, at 8:57 AM, Marco Dinacci wrote: > >> Hi, >> >> I also needed the LSApplicationCategoryType to be generated so I added >> support for it. >> It's in this very small patch against the latest svn: >> >> Index: appbundler/src/com/oracle/appbundler/AppBundlerTask.java >> =================================================================== >> --- appbundler/src/com/oracle/appbundler/AppBundlerTask.java ?(revision 20) >> +++ appbundler/src/com/oracle/appbundler/AppBundlerTask.java ?(working copy) >> @@ -65,6 +65,8 @@ >> ? ? private String signature = "????"; >> ? ? private String copyright = ""; >> >> + ? ?private String applicationCategoryType = ""; >> + >> ? ? // JVM info properties >> ? ? private String mainClassName = null; >> ? ? private FileSet runtime = null; >> @@ -121,6 +123,10 @@ >> ? ? ? ? this.mainClassName = mainClassName; >> ? ? } >> >> + ? ?public void setApplicationCategoryType(String applicationCategoryType) { >> + ? ? ? ?this.applicationCategoryType = applicationCategoryType; >> + ? ?} >> + >> ? ? public void addConfiguredRuntime(FileSet runtime) throws BuildException { >> ? ? ? ? if (this.runtime != null) { >> ? ? ? ? ? ? throw new BuildException("Runtime already specified."); >> @@ -389,6 +395,7 @@ >> ? ? ? ? ? ? writeProperty(xout, "CFBundleSignature", signature); >> ? ? ? ? ? ? writeProperty(xout, "CFBundleVersion", "1"); >> ? ? ? ? ? ? writeProperty(xout, "NSHumanReadableCopyright", copyright); >> + ? ? ? ? ? ?writeProperty(xout, "LSApplicationCategoryType", >> applicationCategoryType); >> >> ? ? ? ? ? ? // Write runtime >> ? ? ? ? ? ? if (runtime != null) { >> >> >> >> Best, >> Marco, >> From greg.x.brown at oracle.com Fri May 11 05:42:43 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 11 May 2012 08:42:43 -0400 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> Message-ID: <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> > However I've found one problems after building my app using the latest > code, the icon is not showing. > > The reason is that in main.m you changed the current directory to > NSHomeDirectory before launching the application This is probably a red herring. The working directory shouldn't have any effect on the icon - if it did, any app that changed the working directory to something other than the bundle root at startup would break. There does seem to be a problem with the icon and app title, though. For some reason, the icon starts correctly but then quickly changes to the default Java icon. I'm looking into it now. G From leonid.romanov at oracle.com Fri May 11 05:57:50 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 11 May 2012 16:57:50 +0400 Subject: build AppBundler? In-Reply-To: <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> Message-ID: Well, yes, we have a bug for this problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 If you are willing to investigate it more, feel free to assign this bug to yourself. On 11.05.2012, at 16:42, Greg Brown wrote: >> However I've found one problems after building my app using the latest >> code, the icon is not showing. >> >> The reason is that in main.m you changed the current directory to >> NSHomeDirectory before launching the application > > This is probably a red herring. The working directory shouldn't have any effect on the icon - if it did, any app that changed the working directory to something other than the bundle root at startup would break. > > There does seem to be a problem with the icon and app title, though. For some reason, the icon starts correctly but then quickly changes to the default Java icon. I'm looking into it now. > > G > From tobi at ultramixer.com Fri May 11 06:08:47 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 11 May 2012 15:08:47 +0200 Subject: build AppBundler? In-Reply-To: <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> Message-ID: You'll have to use the following option in the ant-task -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com Am 11.05.2012 um 14:42 schrieb Greg Brown : >> However I've found one problems after building my app using the latest >> code, the icon is not showing. >> >> The reason is that in main.m you changed the current directory to >> NSHomeDirectory before launching the application > > This is probably a red herring. The working directory shouldn't have any effect on the icon - if it did, any app that changed the working directory to something other than the bundle root at startup would break. > > There does seem to be a problem with the icon and app title, though. For some reason, the icon starts correctly but then quickly changes to the default Java icon. I'm looking into it now. > > G > From Sergey.Bylokhov at oracle.com Fri May 11 06:12:57 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 May 2012 17:12:57 +0400 Subject: [8] request for review: 7149005: [macosx] Java Control Panel's UI controls are distorted when draging scroll bar. In-Reply-To: <4FABF8C7.6070506@oracle.com> References: <4FABF8C7.6070506@oracle.com> Message-ID: <4FAD1059.5080604@oracle.com> Hi, Alexander. Fix looks good. 10.05.2012 21:20, Alexander Potochkin wrote: > Hello > > Please review the forward port to JDK 8 > http://cr.openjdk.java.net/~alexp/7149005/webrev.00/ > > the patch is the same as previously approved for 7u4, > I applied it to JDK8 and checked that it works as expected > > Thanks > alexp From marco.dinacci at gmail.com Fri May 11 06:18:06 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 11 May 2012 14:18:06 +0100 Subject: build AppBundler? In-Reply-To: <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> Message-ID: Hi, >> However I've found one problems after building my app using the latest >> code, the icon is not showing. >> >> The reason is that in main.m you changed the current directory to >> NSHomeDirectory before launching the application > > This is probably a red herring. The working directory shouldn't have any effect on the icon - if it did, any app that changed the working directory to something other than the bundle root at startup would break. > > There does seem to be a problem with the icon and app title, though. For some reason, the icon starts correctly but then quickly changes to the default Java icon. I'm looking into it now. As Tobias wrote you have to manually add the -Xdock:icon option in the build.xml since all the appbundler do at the moment is copying the icon in the bundle, without adding the aforementioned option. So if you chdir to the user home before launching the program you'll pass the wrong icon path (ex. ../Resources/MyIcon.icns) to the application. Maybe an alternative solution that doesn't involve changing the path to the bundle could be to parse the java options before launching the app and if the -Xdock:icon is present adjust the path accordingly. Marco From greg.x.brown at oracle.com Fri May 11 06:30:04 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 11 May 2012 09:30:04 -0400 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> Message-ID: <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> > Maybe an alternative solution that doesn't involve changing the path > to the bundle could be to parse the java options before launching the > app and if the -Xdock:icon is present adjust the path accordingly. The cleanest workaround would probably be for the launcher stub to get the value of the CFBundleIconFile key and automatically generate the -Xdock:icon option that gets passed to the VM. However, fixing the actual problem with the JRE would be preferable. G From marco.dinacci at gmail.com Fri May 11 06:54:26 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 11 May 2012 14:54:26 +0100 Subject: build AppBundler? In-Reply-To: <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> Message-ID: Hi, On 11 May 2012 14:30, Greg Brown wrote: >> Maybe an alternative solution that doesn't involve changing the path >> to the bundle could be to parse the java options before launching the >> app and if the -Xdock:icon is present adjust the path accordingly. > > The cleanest workaround would probably be for the launcher stub to get the value of the CFBundleIconFile key and automatically generate the -Xdock:icon option that gets passed to the VM. However, fixing the actual problem with the JRE would be preferable. I'm not sure the bug is in the JRE, I think the problem is in the launcher. I can open with openjdk 7 an old version of my app bundled with JavaApplicationStub and it will show the icon but if I bundle my app with the AppBundler it won't unless I set the Xdock:icon option in the build file. Marco From greg.x.brown at oracle.com Fri May 11 06:59:55 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 11 May 2012 09:59:55 -0400 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> Message-ID: > I'm not sure the bug is in the JRE http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 From marco.dinacci at gmail.com Fri May 11 07:05:06 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 11 May 2012 15:05:06 +0100 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> Message-ID: Hi, On 11 May 2012 14:59, Greg Brown wrote: > I'm not sure the bug is in the JRE > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 yes I saw that, at the end it also says: "It looks like this is a Launcher bug in Oracle JDK on the Mac, thus I'm reassigning this issue to xxxxx at xxxxx for further evaluation. " and I agree with that but I can be wrong of course. Marco From greg.x.brown at oracle.com Fri May 11 07:06:52 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 11 May 2012 10:06:52 -0400 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> Message-ID: <413B881D-B1E2-469B-8DCD-55B36F061790@oracle.com> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 > > yes I saw that, at the end it also says: > > "It looks like this is a Launcher bug in Oracle JDK on the Mac, thus > I'm reassigning this issue to xxxxx at xxxxx for further evaluation. I don't believe this refers to the AppBundler launcher. From greg.x.brown at oracle.com Fri May 11 07:12:44 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 11 May 2012 10:12:44 -0400 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> Message-ID: <6D3590B4-7369-4F07-A4D6-94AF5AB2543C@oracle.com> FWIW, I commented out the line in AppBundler's main.m that calls JLI_Launch() and the icon does not change. So I suspect that this bug does occur somewhere within the JRE. On May 11, 2012, at 10:05 AM, Marco Dinacci wrote: > Hi, > > On 11 May 2012 14:59, Greg Brown wrote: >> I'm not sure the bug is in the JRE >> >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 > > yes I saw that, at the end it also says: > > "It looks like this is a Launcher bug in Oracle JDK on the Mac, thus > I'm reassigning this issue to xxxxx at xxxxx for further evaluation. > " > > and I agree with that but I can be wrong of course. > > > Marco From marco.dinacci at gmail.com Fri May 11 07:20:42 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 11 May 2012 15:20:42 +0100 Subject: build AppBundler? In-Reply-To: <6D3590B4-7369-4F07-A4D6-94AF5AB2543C@oracle.com> References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> <6D3590B4-7369-4F07-A4D6-94AF5AB2543C@oracle.com> Message-ID: Hi, On 11 May 2012 15:12, Greg Brown wrote: > FWIW, I commented out the line in AppBundler's main.m that calls JLI_Launch() and the icon does not change. So I suspect that this bug does occur somewhere within the JRE. right, I didn't know much about the other launcher, you are probably right then. I'll have to live with my workaround for the moment. Thanks, Marco From greg.x.brown at oracle.com Fri May 11 07:32:05 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 11 May 2012 10:32:05 -0400 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> <6D3590B4-7369-4F07-A4D6-94AF5AB2543C@oracle.com> Message-ID: <0E037732-4B22-414C-9E9A-E95DD82547C8@oracle.com> > right, I didn't know much about the other launcher, you are probably > right then. I'll have to live with my workaround for the moment. Like I said, we could easily work around this by having the AppBundler launcher create the -Xdock:icon option. I'd prefer to see if the JRE issue can be fixed first, but I'm not opposed to implementing the workaround if necessary. G From tobi at ultramixer.com Fri May 11 07:35:14 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 11 May 2012 16:35:14 +0200 Subject: build AppBundler? In-Reply-To: <0E037732-4B22-414C-9E9A-E95DD82547C8@oracle.com> References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> <6D3590B4-7369-4F07-A4D6-94AF5AB2543C@oracle.com> <0E037732-4B22-414C-9E9A-E95DD82547C8@oracle.com> Message-ID: <2788DC3F-2E9C-4D24-AED5-AB3A10F63FB2@ultramixer.com> +1 -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com Am 11.05.2012 um 16:32 schrieb Greg Brown : >> right, I didn't know much about the other launcher, you are probably >> right then. I'll have to live with my workaround for the moment. > > Like I said, we could easily work around this by having the AppBundler launcher create the -Xdock:icon option. I'd prefer to see if the JRE issue can be fixed first, but I'm not opposed to implementing the workaround if necessary. > > G > From tobi at ultramixer.com Fri May 11 07:48:26 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 11 May 2012 16:48:26 +0200 Subject: build AppBundler? In-Reply-To: <6D3590B4-7369-4F07-A4D6-94AF5AB2543C@oracle.com> References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> <6D3590B4-7369-4F07-A4D6-94AF5AB2543C@oracle.com> Message-ID: Hey, why don't you believe me? I recently created an app with AppBundler and an embedded OpenJDK and my app shows the current name and Icon! NO Bug. Best regards, -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com Am 11.05.2012 um 16:12 schrieb Greg Brown : > FWIW, I commented out the line in AppBundler's main.m that calls JLI_Launch() and the icon does not change. So I suspect that this bug does occur somewhere within the JRE. > > On May 11, 2012, at 10:05 AM, Marco Dinacci wrote: > >> Hi, >> >> On 11 May 2012 14:59, Greg Brown wrote: >>> I'm not sure the bug is in the JRE >>> >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 >> >> yes I saw that, at the end it also says: >> >> "It looks like this is a Launcher bug in Oracle JDK on the Mac, thus >> I'm reassigning this issue to xxxxx at xxxxx for further evaluation. >> " >> >> and I agree with that but I can be wrong of course. >> >> >> Marco > From greg.x.brown at oracle.com Fri May 11 08:06:09 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 11 May 2012 11:06:09 -0400 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> <6D3590B4-7369-4F07-A4D6-94AF5AB2543C@oracle.com> Message-ID: <3B10CAC8-56F9-45B0-B3AE-338F17432A8F@oracle.com> > Hey, why don't you believe me? Not sure what you are referring to. > I recently created an app with AppBundler and an embedded OpenJDK and my app shows the current name and Icon! NO Bug. When I create an app with AppBundler (http://java.net/projects/appbundler) and J7u4, the app name and icon are not correct. Maybe the bug does not appear in an OpenJDK build, but it does seem to be a problem with the Oracle JDK, as noted in the issue report: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 From tobi at ultramixer.com Fri May 11 08:10:44 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 11 May 2012 17:10:44 +0200 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> <6D3590B4-7369-4F07-A4D6-94AF5AB2543C@oracle.com> Message-ID: <3178D6F4-A054-4AFE-8129-DE32B81CF9A2@ultramixer.com> Did you use -Xdock ? -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com Am 11.05.2012 um 16:48 schrieb Tobias Bley : > Hey, why don't you believe me? I recently created an app with AppBundler and an embedded OpenJDK and my app shows the current name and Icon! NO Bug. > > Best regards, > > -- > Tobias Bley > Chief Executive Officer > > -------------------------------------------------------- > > UltraMixer Digital Audio Solutions > Schillerstra?e 29 > D-01326 Dresden > Germany > > -------------------------------------------------------- > bley at ultramixer.com http://www.ultramixer.com > > > > Am 11.05.2012 um 16:12 schrieb Greg Brown : > >> FWIW, I commented out the line in AppBundler's main.m that calls JLI_Launch() and the icon does not change. So I suspect that this bug does occur somewhere within the JRE. >> >> On May 11, 2012, at 10:05 AM, Marco Dinacci wrote: >> >>> Hi, >>> >>> On 11 May 2012 14:59, Greg Brown wrote: >>>> I'm not sure the bug is in the JRE >>>> >>>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 >>> >>> yes I saw that, at the end it also says: >>> >>> "It looks like this is a Launcher bug in Oracle JDK on the Mac, thus >>> I'm reassigning this issue to xxxxx at xxxxx for further evaluation. >>> " >>> >>> and I agree with that but I can be wrong of course. >>> >>> >>> Marco >> > From greg.x.brown at oracle.com Fri May 11 08:11:09 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 11 May 2012 11:11:09 -0400 Subject: build AppBundler? In-Reply-To: <3B10CAC8-56F9-45B0-B3AE-338F17432A8F@oracle.com> References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> <6D3590B4-7369-4F07-A4D6-94AF5AB2543C@oracle.com> <3B10CAC8-56F9-45B0-B3AE-338F17432A8F@oracle.com> Message-ID: <93FEDD63-4ECA-427B-A90B-0C006E101297@oracle.com> BTW, please post any follow-up discussion to commits at appbundler.java.net. Thanks. G On May 11, 2012, at 11:06 AM, Greg Brown wrote: >> Hey, why don't you believe me? > > Not sure what you are referring to. > >> I recently created an app with AppBundler and an embedded OpenJDK and my app shows the current name and Icon! NO Bug. > > When I create an app with AppBundler (http://java.net/projects/appbundler) and J7u4, the app name and icon are not correct. Maybe the bug does not appear in an OpenJDK build, but it does seem to be a problem with the Oracle JDK, as noted in the issue report: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 > From marco.dinacci at gmail.com Fri May 11 08:12:03 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Fri, 11 May 2012 16:12:03 +0100 Subject: build AppBundler? In-Reply-To: References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> <6D3590B4-7369-4F07-A4D6-94AF5AB2543C@oracle.com> Message-ID: Hi Tobias, On 11 May 2012 15:48, Tobias Bley wrote: > Hey, why don't you believe me? I recently created an app with AppBundler and an embedded OpenJDK and my app shows the current name and Icon! NO Bug. > I think everybody believes you, I also have an app with icon and name showing up, however if I remove the Xdock:icon the icon won't show. Also, even with the option enabled if using the latest openjdk build and the latest appbundler the icon won't show up. Best, Marco From anthony.petrov at oracle.com Fri May 11 08:55:59 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 11 May 2012 19:55:59 +0400 Subject: [7u6] Review request for 7166437: [macosx] Support for Window.Type.UTILITY on the Mac Message-ID: <4FAD368F.60509@oracle.com> Hello, This is a backport of exactly the same fix from JDK 8. Bug: http://bugs.sun.com/view_bug.do?bug_id=7166437 Fix: http://cr.openjdk.java.net/~anthony/7u6-8-UTILITY-7166437.0/ -- best regards, Anthony From Sergey.Bylokhov at oracle.com Fri May 11 09:08:58 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 11 May 2012 20:08:58 +0400 Subject: [7u6] Review request for 7166437: [macosx] Support for Window.Type.UTILITY on the Mac In-Reply-To: <4FAD368F.60509@oracle.com> References: <4FAD368F.60509@oracle.com> Message-ID: <4FAD399A.3060307@oracle.com> Hi, Anthony. Fix looks good. 11.05.2012 19:55, Anthony Petrov wrote: > Hello, > > This is a backport of exactly the same fix from JDK 8. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=7166437 > > Fix: http://cr.openjdk.java.net/~anthony/7u6-8-UTILITY-7166437.0/ > > -- > best regards, > Anthony From alexander.zuev at oracle.com Fri May 11 09:32:38 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 11 May 2012 20:32:38 +0400 Subject: [7u6] Review request for 7166437: [macosx] Support for Window.Type.UTILITY on the Mac In-Reply-To: <4FAD368F.60509@oracle.com> References: <4FAD368F.60509@oracle.com> Message-ID: <4FAD3F26.6030500@oracle.com> Pretty straightforward fix. Looks fine. With best regards, Alexander Zuev On 5/11/12 19:55, Anthony Petrov wrote: > Hello, > > This is a backport of exactly the same fix from JDK 8. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=7166437 > > Fix: http://cr.openjdk.java.net/~anthony/7u6-8-UTILITY-7166437.0/ > > -- > best regards, > Anthony From bley at ultramixer.com Fri May 11 05:55:20 2012 From: bley at ultramixer.com (Tobias Bley) Date: Fri, 11 May 2012 14:55:20 +0200 Subject: build AppBundler? In-Reply-To: <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> Message-ID: You'll have to use the following option in the ant-task -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com Am 11.05.2012 um 14:42 schrieb Greg Brown : >> However I've found one problems after building my app using the latest >> code, the icon is not showing. >> >> The reason is that in main.m you changed the current directory to >> NSHomeDirectory before launching the application > > This is probably a red herring. The working directory shouldn't have any effect on the icon - if it did, any app that changed the working directory to something other than the bundle root at startup would break. > > There does seem to be a problem with the icon and app title, though. For some reason, the icon starts correctly but then quickly changes to the default Java icon. I'm looking into it now. > > G > From gk_brown at verizon.net Fri May 11 08:09:36 2012 From: gk_brown at verizon.net (Greg Brown) Date: Fri, 11 May 2012 11:09:36 -0400 Subject: build AppBundler? In-Reply-To: <3B10CAC8-56F9-45B0-B3AE-338F17432A8F@oracle.com> References: <42A424F4-FB09-4402-8FBA-0FFEF1393C28@ultramixer.com> <96020C74-976D-4B50-877C-85A307DD73FA@oracle.com> <4E31A7A7-9545-44CF-87CA-2C9147E53C15@oracle.com> <6D3590B4-7369-4F07-A4D6-94AF5AB2543C@oracle.com> <3B10CAC8-56F9-45B0-B3AE-338F17432A8F@oracle.com> Message-ID: BTW, please post any follow-up discussion to commits at appbundler.java.net. Thanks. G On May 11, 2012, at 11:06 AM, Greg Brown wrote: >> Hey, why don't you believe me? > > Not sure what you are referring to. > >> I recently created an app with AppBundler and an embedded OpenJDK and my app shows the current name and Icon! NO Bug. > > When I create an app with AppBundler (http://java.net/projects/appbundler) and J7u4, the app name and icon are not correct. Maybe the bug does not appear in an OpenJDK build, but it does seem to be a problem with the Oracle JDK, as noted in the issue report: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 > From anthony.petrov at oracle.com Sat May 12 05:20:51 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Sat, 12 May 2012 16:20:51 +0400 Subject: [7u6] Review request for 7149062: [macosx] dock menu don't show available frames Message-ID: <4FAE55A3.5040405@oracle.com> Hello, This is almost a direct back-port of the same fix from JDK 8. Bug: http://bugs.sun.com/view_bug.do?bug_id=7149062 Fix: http://cr.openjdk.java.net/~anthony/7u6-9-windowListInDockMenu-7149062.0/ -- best regards, Anthony From jcpalmer at rochester.rr.com Sat May 12 10:15:02 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Sat, 12 May 2012 13:15:02 -0400 Subject: Shortcut Icon blurry Message-ID: <3A40D6C3-D9DB-49CB-A747-72D439FFD204@rochester.rr.com> I was under the impression short cuts were coming next week, but parts did show up in EA-b09. It still does not work, so thought note would be better than a bug at this point. Wrote a Java program the generates JPG's of different sizes, with matching levels of details. Sizes are 128, 64, & 32. EA-b09 now prompts to save a short cut, & does. Clicking on the short cut does not yet actually do anything as far as I can tell, but the icon detail does not pop like in the one saved from the Apple implementation. I think the 32 bit version is just being stretched. Looking at the http server's request log shows only the 64-bit version being checked for updates every launch. 128 bit should also be checked when it is set as splash, but I do not have that on right now. Maybe the checking for update is right, but then the wrong version ends up used for display. From igor.nekrestyanov at oracle.com Sat May 12 14:02:41 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Sat, 12 May 2012 14:02:41 -0700 Subject: Shortcut Icon blurry In-Reply-To: <3A40D6C3-D9DB-49CB-A747-72D439FFD204@rochester.rr.com> References: <3A40D6C3-D9DB-49CB-A747-72D439FFD204@rochester.rr.com> Message-ID: <4FAECFF1.9000201@oracle.com> Please file a bug. -igor On 5/12/12 10:15 AM, Jeff Palmer wrote: > I was under the impression short cuts were coming next week, but parts did show up in EA-b09. It still does not work, so thought note would be better than a bug at this point. > > Wrote a Java program the generates JPG's of different sizes, with matching levels of details. Sizes are 128, 64,& 32. EA-b09 now prompts to save a short cut,& does. Clicking on the short cut does not yet actually do anything as far as I can tell, but the icon detail does not pop like in the one saved from the Apple implementation. > > I think the 32 bit version is just being stretched. Looking at the http server's request log shows only the 64-bit version being checked for updates every launch. 128 bit should also be checked when it is set as splash, but I do not have that on right now. > > Maybe the checking for update is right, but then the wrong version ends up used for display. From Fabrizio.Giudici at tidalwave.it Sun May 13 09:35:23 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Sun, 13 May 2012 18:35:23 +0200 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? Message-ID: I've just succesfully ported to OpenJDK 7 a small desktop application that was previously running with Apple's JDK 6. The application computes at the maximum speed possible the MD5 fingerprints of files in a directory. The performance with Apple JDK 6 is about 95-100 MB/sec (which is reasonably limited by my disk native I/O speed). The same application with OpenJDK 7 runs under 7 MB/sec. Loading is done by means of MappedByteBuffer: final @Cleanup RandomAccessFile randomAccessFile = new RandomAccessFile(file, "r"); final MappedByteBuffer byteBuffer = randomAccessFile.getChannel().map(READ_ONLY, 0, file.length()); byteBuffer.load(); randomAccessFile.close(); From preliminary measurement, the bottleneck is with I/O. In fact, with JDK 6 the application takes most of the CPU (MD5 is computed in parallel to I/O), while with OpenJDK 7 the CPU is much lower. Of course I've tested the same application bits side by side with Apple JDK 6 and OpenJDK 7 on the same set of files. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." fabrizio.giudici at tidalwave.it http://tidalwave.it - http://fabriziogiudici.it From kirk at kodewerk.com Sun May 13 10:15:49 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Sun, 13 May 2012 19:15:49 +0200 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: References: Message-ID: <5CAE01C5-CA44-4AB3-A9B4-64691F450B5E@kodewerk.com> No idea about the differences in I/O performance. I do know that 7 was abstracted further away from OSX.. so there might be something there. Certainly a calmer CPU is an indication of a problem with I/O. Kirk On 2012-05-13, at 6:35 PM, Fabrizio Giudici wrote: > I've just succesfully ported to OpenJDK 7 a small desktop application that was previously running with Apple's JDK 6. The application computes at the maximum speed possible the MD5 fingerprints of files in a directory. The performance with Apple JDK 6 is about 95-100 MB/sec (which is reasonably limited by my disk native I/O speed). The same application with OpenJDK 7 runs under 7 MB/sec. > > Loading is done by means of MappedByteBuffer: > > final @Cleanup RandomAccessFile randomAccessFile = new RandomAccessFile(file, "r"); > final MappedByteBuffer byteBuffer = randomAccessFile.getChannel().map(READ_ONLY, 0, file.length()); > byteBuffer.load(); > randomAccessFile.close(); > > From preliminary measurement, the bottleneck is with I/O. In fact, with JDK 6 the application takes most of the CPU (MD5 is computed in parallel to I/O), while with OpenJDK 7 the CPU is much lower. > > Of course I've tested the same application bits side by side with Apple JDK 6 and OpenJDK 7 on the same set of files. > > > -- > Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > fabrizio.giudici at tidalwave.it > http://tidalwave.it - http://fabriziogiudici.it From Alan.Bateman at oracle.com Sun May 13 11:22:20 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 May 2012 19:22:20 +0100 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: References: Message-ID: <4FAFFBDC.9020807@oracle.com> On 13/05/2012 17:35, Fabrizio Giudici wrote: > I've just succesfully ported to OpenJDK 7 a small desktop application > that was previously running with Apple's JDK 6. The application > computes at the maximum speed possible the MD5 fingerprints of files > in a directory. The performance with Apple JDK 6 is about 95-100 > MB/sec (which is reasonably limited by my disk native I/O speed). The > same application with OpenJDK 7 runs under 7 MB/sec. > > Loading is done by means of MappedByteBuffer: > > final @Cleanup RandomAccessFile randomAccessFile = new > RandomAccessFile(file, "r"); > final MappedByteBuffer byteBuffer = > randomAccessFile.getChannel().map(READ_ONLY, 0, file.length()); > byteBuffer.load(); > randomAccessFile.close(); > > From preliminary measurement, the bottleneck is with I/O. In fact, > with JDK 6 the application takes most of the CPU (MD5 is computed in > parallel to I/O), while with OpenJDK 7 the CPU is much lower. > > Of course I've tested the same application bits side by side with > Apple JDK 6 and OpenJDK 7 on the same set of files. > The above is essentially open + mmap + madvise and there hasn't been anything of significant between 6 and 7 that comes to mind, unless of course Apple's jdk6 specifies different advice that improves this case. The only thing that comes to mind is the security provider, maybe there is a different MD5 implementation that is being used. -Alan. From Fabrizio.Giudici at tidalwave.it Sun May 13 12:34:38 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Sun, 13 May 2012 21:34:38 +0200 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: <4FAFFBDC.9020807@oracle.com> References: <4FAFFBDC.9020807@oracle.com> Message-ID: On Sun, 13 May 2012 20:22:20 +0200, Alan Bateman wrote: > The above is essentially open + mmap + madvise and there hasn't been > anything of significant between 6 and 7 that comes to mind, unless of > course Apple's jdk6 specifies different advice that improves this case. > The only thing that comes to mind is the security provider, maybe there > is a different MD5 implementation that is being used. I think MD5 would lead to a higher CPU usage. In any case, I'm isolating a test case only focused on I/O. I'm creating 20 files whose size ranges from 10 to 100 MB and run the above code on it. Files are created from scratch at each run to avoid disk caching issues. Performance measures are: * for Apple JDK 6: speed 78-88 MB/sec * for OpenJDK 7: speed 518-716 MB/sec The latter figure is clearly a fake one: in fact the system monitor sees no disk activity. Is it possible that the MapByteBuffer.load() method changed behaviour, postponing the actual data loading? It would be compatible with the specs: **** Loads this buffer's content into physical memory. This method makes a best effort to ensure that, when it returns, this buffer's content is resident in physical memory. Invoking this method may cause some number of page faults and I/O operations to occur. **** Perhaps JDK 6 loads everything with the single load() call, which is more efficient, while OpenJDK 7 postpones it? And perhaps it does it inefficiently due to a scattered data access by means of the MD5 library? (I knew a lot about crypto algorithms time ago, but now I've forgotten all the details). -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." fabrizio.giudici at tidalwave.it http://tidalwave.it - http://fabriziogiudici.it From Alan.Bateman at oracle.com Sun May 13 13:24:04 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 May 2012 21:24:04 +0100 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: References: <4FAFFBDC.9020807@oracle.com> Message-ID: <4FB01864.9020203@oracle.com> On 13/05/2012 20:34, Fabrizio Giudici wrote: > > I think MD5 would lead to a higher CPU usage. In any case, I'm > isolating a test case only focused on I/O. I'm creating 20 files whose > size ranges from 10 to 100 MB and run the above code on it. Files are > created from scratch at each run to avoid disk caching issues. > Performance measures are: > > * for Apple JDK 6: speed 78-88 MB/sec > * for OpenJDK 7: speed 518-716 MB/sec > > The latter figure is clearly a fake one: in fact the system monitor > sees no disk activity. Is it possible that the MapByteBuffer.load() > method changed behaviour, postponing the actual data loading? It would > be compatible with the specs: > > **** > Loads this buffer's content into physical memory. > This method makes a best effort to ensure that, when it returns, this > buffer's content is resident in physical memory. Invoking this method > may cause some number of page faults and I/O operations to occur. > **** > > > Perhaps JDK 6 loads everything with the single load() call, which is > more efficient, while OpenJDK 7 postpones it? And perhaps it does it > inefficiently due to a scattered data access by means of the MD5 > library? (I knew a lot about crypto algorithms time ago, but now I've > forgotten all the details). > The load method working by touching each page to bring it into memory. The only difference in this regard between jdk6 and 7 is that it was done in native code in jdk6 whereas it's in Java code in jdk7 (the reason for this was to be able to recover with mapped files that get truncated). Performance-wise it shouldn't make a difference and most of the time should be paging in the file. From your figures above it would appear that it's not touching all pages but it requires digging into the details to track this down (plus I would point out that we have no idea if anything was changed in this area in Apple's JDK6). In any case, can you submit a bug on this? -Alan From Fabrizio.Giudici at tidalwave.it Sun May 13 14:02:14 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Sun, 13 May 2012 23:02:14 +0200 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: <4FB01864.9020203@oracle.com> References: <4FAFFBDC.9020807@oracle.com> <4FB01864.9020203@oracle.com> Message-ID: On Sun, 13 May 2012 22:24:04 +0200, Alan Bateman wrote: > The load method working by touching each page to bring it into memory. > The only difference in this regard between jdk6 and 7 is that it was > done in native code in jdk6 whereas it's in Java code in jdk7 (the > reason for this was to be able to recover with mapped files that get > truncated). Performance-wise it shouldn't make a difference and most of > the time should be paging in the file. From your figures above it would > appear that it's not touching all pages but it requires digging into the > details to track this down (plus I would point out that we have no idea > if anything was changed in this area in Apple's JDK6). In any case, can > you submit a bug on this? Sure. I'm preparing a minimal test case. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." fabrizio.giudici at tidalwave.it http://tidalwave.it - http://fabriziogiudici.it From Fabrizio.Giudici at tidalwave.it Sun May 13 15:11:33 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Mon, 14 May 2012 00:11:33 +0200 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: References: <4FAFFBDC.9020807@oracle.com> <4FB01864.9020203@oracle.com> Message-ID: On Sun, 13 May 2012 23:02:14 +0200, Fabrizio Giudici wrote: > On Sun, 13 May 2012 22:24:04 +0200, Alan Bateman > wrote: > >> The load method working by touching each page to bring it into memory. >> The only difference in this regard between jdk6 and 7 is that it was >> done in native code in jdk6 whereas it's in Java code in jdk7 (the >> reason for this was to be able to recover with mapped files that get >> truncated). Performance-wise it shouldn't make a difference and most of >> the time should be paging in the file. From your figures above it would >> appear that it's not touching all pages but it requires digging into >> the details to track this down (plus I would point out that we have no >> idea if anything was changed in this area in Apple's JDK6). In any >> case, can you submit a bug on this? > > Sure. I'm preparing a minimal test case. Filed as https://bugs.openjdk.java.net/show_bug.cgi?id=100258 with attached self-contained test case. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." fabrizio.giudici at tidalwave.it http://tidalwave.it - http://fabriziogiudici.it From Fabrizio.Giudici at tidalwave.it Sun May 13 15:25:52 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Mon, 14 May 2012 00:25:52 +0200 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: References: <4FAFFBDC.9020807@oracle.com> <4FB01864.9020203@oracle.com> Message-ID: On Mon, 14 May 2012 00:11:33 +0200, Fabrizio Giudici wrote: > Filed as https://bugs.openjdk.java.net/show_bug.cgi?id=100258 with > attached self-contained test case. Ok, I was told it's the wrong place. But if I try to submit it to bugs.sun.com as Mac OS X (non Oracle) is rejected. I've filed it as Mac OS X (Oracle) even though it's OpenJDK 7. I hope it's correct. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168505 -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." fabrizio.giudici at tidalwave.it http://tidalwave.it - http://fabriziogiudici.it From Alan.Bateman at oracle.com Mon May 14 00:56:45 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 May 2012 08:56:45 +0100 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: References: <4FAFFBDC.9020807@oracle.com> <4FB01864.9020203@oracle.com> Message-ID: <4FB0BABD.9010004@oracle.com> On 13/05/2012 23:25, Fabrizio Giudici wrote: > > Ok, I was told it's the wrong place. But if I try to submit it to > bugs.sun.com as Mac OS X (non Oracle) is rejected. I've filed it as > Mac OS X (Oracle) even though it's OpenJDK 7. I hope it's correct. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168505 > Thanks, I think see what's going on. Can you try on exclude MappedByteBuffer.load from compilation and re-run your tests to see if that "fixes" the problem, ie: cat > .hotspot_compiler << EOF exclude java/nio/MappedByteBuffer load EOF You'll know if you've excluded it if you get a message such ### Excluding compile ... message. -Alan. From dmitry.cherepanov at oracle.com Mon May 14 03:42:33 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 14 May 2012 14:42:33 +0400 Subject: [8] request for review: 7168550 [macosx] duplicate OGL context state changes related to vertex cache Message-ID: <4FB0E199.2050109@oracle.com> Here's a patch for the 'disappearing text' problem reproducible in dual-screen environment. The fix duplicates some context state changes (which aren't shared across contexts) and the fix also enables switching between contexts from SetScratchSurface (switching 'offscreen' contexts from the flusher thread) to make sure that we'll update the state in the proper context. More info - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168550 (the bug report will become visible soon) Webrev - http://cr.openjdk.java.net/~dcherepanov/7168550/webrev.0/ Thanks, Dmitry From Fabrizio.Giudici at tidalwave.it Mon May 14 04:05:21 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Mon, 14 May 2012 13:05:21 +0200 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: <4FB0BABD.9010004@oracle.com> References: <4FAFFBDC.9020807@oracle.com> <4FB01864.9020203@oracle.com> <4FB0BABD.9010004@oracle.com> Message-ID: On Mon, 14 May 2012 09:56:45 +0200, Alan Bateman wrote: > On 13/05/2012 23:25, Fabrizio Giudici wrote: >> >> Ok, I was told it's the wrong place. But if I try to submit it to >> bugs.sun.com as Mac OS X (non Oracle) is rejected. I've filed it as Mac >> OS X (Oracle) even though it's OpenJDK 7. I hope it's correct. >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168505 >> > Thanks, I think see what's going on. Can you try on exclude > MappedByteBuffer.load from compilation and re-run your tests to see if > that "fixes" the problem, ie: > > cat > .hotspot_compiler << EOF > exclude java/nio/MappedByteBuffer load > EOF > > You'll know if you've excluded it if you get a message such ### > Excluding compile ... message. I was going to ask you something similar, as after looking at the sources of MappedByteBuffer I think there could be a over-optimization. But I'm definitely not a HotSpot expert. Bingo. See console log below, in any case I'm getting now a similar performance than Apple JDK 6 and I see disk reads in the system monitor. Since this seems to workaround the problem for my app, how can I reliably set the .hotspot_compiler stuff? I mean, is there any -XX option that can be used as well? Thanks. [Mistral-MacOSX:WorkAreas/SolidBlue/solidblue-src] fritz% java -version CompilerOracle: exclude java/nio/MappedByteBuffer.load java version "1.7.0_04" Java(TM) SE Runtime Environment (build 1.7.0_04-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode) Mistral-MacOSX:WorkAreas/SolidBlue/solidblue-src] fritz% java -cp modules/IntegrityCheckerProvider/target/test-classes/ it.tidalwave.integritychecker.impl.IoPerformanceTest Creating test files... >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile0 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile1 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile2 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile3 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile4 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile5 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile6 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile7 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile8 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile9 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile10 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile11 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile12 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile13 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile14 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile15 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile16 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile17 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile18 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile19 Read 1020 MB, speed 1586 MB/sec [Mistral-MacOSX:WorkAreas/SolidBlue/solidblue-src] fritz% vi .hotspot_compiler [Mistral-MacOSX:WorkAreas/SolidBlue/solidblue-src] fritz% cat .hotspot_compiler exclude java/nio/MappedByteBuffer load [Mistral-MacOSX:WorkAreas/SolidBlue/solidblue-src] fritz% java -cp modules/IntegrityCheckerProvider/target/test-classes/ it.tidalwave.integritychecker.impl.IoPerformanceTest CompilerOracle: exclude java/nio/MappedByteBuffer.load Creating test files... >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile0 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile1 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile2 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile3 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile4 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile5 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile6 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile7 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile8 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile9 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile10 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile11 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile12 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile13 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile14 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile15 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile16 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile17 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile18 >>>> creating /var/folders/7b/y9nv6nss0q5fgjnzxqxc2tr00000z9/T/testfile19 ### Excluding compile: java.nio.MappedByteBuffer::load Read 1020 MB, speed 99 MB/sec -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." fabrizio.giudici at tidalwave.it http://tidalwave.it - http://fabriziogiudici.it From tomas.hurka at googlemail.com Mon May 14 04:29:59 2012 From: tomas.hurka at googlemail.com (Tomas Hurka) Date: Mon, 14 May 2012 13:29:59 +0200 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: References: <4FAFFBDC.9020807@oracle.com> <4FB01864.9020203@oracle.com> <4FB0BABD.9010004@oracle.com> Message-ID: <8CFD654A-EA8F-48DB-ACF8-697C18BEDF5B@googlemail.com> Hi Fabrizio, On 14 May 2012, at 13:05, Fabrizio Giudici wrote: >> Thanks, I think see what's going on. Can you try on exclude MappedByteBuffer.load from compilation and re-run your tests to see if that "fixes" the problem, ie: >> >> cat > .hotspot_compiler << EOF >> exclude java/nio/MappedByteBuffer load >> EOF >> >> You'll know if you've excluded it if you get a message such ### Excluding compile ... message. > > I was going to ask you something similar, as after looking at the sources of MappedByteBuffer I think there could be a over-optimization. But I'm definitely not a HotSpot expert. > > Bingo. See console log below, in any case I'm getting now a similar performance than Apple JDK 6 and I see disk reads in the system monitor. > > Since this seems to workaround the problem for my app, how can I reliably set the .hotspot_compiler stuff? I mean, is there any -XX option that can be used as well? Use -XX:CompileCommand. See for more details. Bye, -- Tomas Hurka NetBeans Profiler http://profiler.netbeans.org VisualVM http://visualvm.java.net Software Developer Oracle, Praha Czech Republic From andrew.brygin at oracle.com Mon May 14 04:33:15 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Mon, 14 May 2012 15:33:15 +0400 Subject: [8] request for review: 7168550 [macosx] duplicate OGL context state changes related to vertex cache In-Reply-To: <4FB0E199.2050109@oracle.com> References: <4FB0E199.2050109@oracle.com> Message-ID: <4FB0ED7B.9020902@oracle.com> The fix looks fine to me. Thanks, Andrew On 14.05.2012 14:42, Dmitry Cherepanov wrote: > Here's a patch for the 'disappearing text' problem reproducible in > dual-screen environment. The fix duplicates some context state changes > (which aren't shared across contexts) and the fix also enables > switching between contexts from SetScratchSurface (switching > 'offscreen' contexts from the flusher thread) to make sure that we'll > update the state in the proper context. > > More info - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168550 > (the bug report will become visible soon) > Webrev - http://cr.openjdk.java.net/~dcherepanov/7168550/webrev.0/ > > Thanks, > Dmitry > From Fabrizio.Giudici at tidalwave.it Mon May 14 05:17:52 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Mon, 14 May 2012 14:17:52 +0200 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: <8CFD654A-EA8F-48DB-ACF8-697C18BEDF5B@googlemail.com> References: <4FAFFBDC.9020807@oracle.com> <4FB01864.9020203@oracle.com> <4FB0BABD.9010004@oracle.com> <8CFD654A-EA8F-48DB-ACF8-697C18BEDF5B@googlemail.com> Message-ID: On Mon, 14 May 2012 13:29:59 +0200, Tomas Hurka wrote: >> option that can be used as well? > Use -XX:CompileCommand. See > > for more details. Thanks. So, I'm trying it with the whole application and I'm seeing again the original performance :-) (actually still a bit lower, but I'm doing this in parallel with other stuff, I need to re-run the tests without other processes in background - in any case it's not 10x slower as previously). In any case, it seems that this confirms the explanation in my previous message, that if load() doesn't pre-load everything in memory (and it's efficient), the MD5 method accesses data in a way that it doesn't load them in an efficient way. Very subtle! -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." fabrizio.giudici at tidalwave.it http://tidalwave.it - http://fabriziogiudici.it From Alan.Bateman at oracle.com Mon May 14 05:22:23 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 May 2012 13:22:23 +0100 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: References: <4FAFFBDC.9020807@oracle.com> <4FB01864.9020203@oracle.com> <4FB0BABD.9010004@oracle.com> Message-ID: <4FB0F8FF.1080106@oracle.com> On 14/05/2012 12:05, Fabrizio Giudici wrote: > > I was going to ask you something similar, as after looking at the > sources of MappedByteBuffer I think there could be a > over-optimization. But I'm definitely not a HotSpot expert. > > Bingo. See console log below, in any case I'm getting now a similar > performance than Apple JDK 6 and I see disk reads in the system monitor. > > > Since this seems to workaround the problem for my app, how can I > reliably set the .hotspot_compiler stuff? I mean, is there any -XX > option that can be used as well? > I see Tomas has replied pointing you to -XX:CompileCommand, that should work too. The issue isn't actually a HotSpot issue, rather it's the loop that touches each page is essentially reduced to nothing when compiled, we will have to change it to prevent the compiler doing that. -Alan. From Fabrizio.Giudici at tidalwave.it Mon May 14 05:28:41 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Mon, 14 May 2012 14:28:41 +0200 Subject: Any major performance change with I/O from JDK 6 that one should be aware of? In-Reply-To: <4FB0F8FF.1080106@oracle.com> References: <4FAFFBDC.9020807@oracle.com> <4FB01864.9020203@oracle.com> <4FB0BABD.9010004@oracle.com> <4FB0F8FF.1080106@oracle.com> Message-ID: On Mon, 14 May 2012 14:22:23 +0200, Alan Bateman wrote: > The issue isn't actually a HotSpot issue, rather it's the loop that > touches each page is essentially reduced to nothing when compiled, we > will have to change it to prevent the compiler doing that. Yes, I understand that HotSpot is just doing well its job. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." fabrizio.giudici at tidalwave.it http://tidalwave.it - http://fabriziogiudici.it From karen.kinnear at oracle.com Mon May 14 06:59:38 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 14 May 2012 09:59:38 -0400 Subject: SIGBUS or SIGSEGV on OSX? In-Reply-To: <0fc7227b-fb94-484c-80c0-ea5839698642@default> References: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> <0fc7227b-fb94-484c-80c0-ea5839698642@default> Message-ID: <2110EEBC-2818-45CA-8437-4C1D99C87ABA@oracle.com> Roland, Yes please. I also think we are seeing a similar problem on stack overflow handling - so let us know if you are also fixing that or if we want to do a separate additional modification for that case as well. thanks, Karen On May 14, 2012, at 8:54 AM, Bob Vandette wrote: > I had to fix the same problem in the signal handler for iOS. I had > problems with implicit null checks and safepoint polling exceptions > when running our JDK7 Embedded build on iPads and iPhones. > > Make sure you check all cases of SIGSEGV. > > Bob. > > > -----Original Message----- > From: Roland Westrelin > Sent: Monday, May 14, 2012 7:31 AM > To: hotspot-runtime-dev at openjdk.java.net; macosx-port-dev at openjdk.java.net > Cc: hotspot compiler > Subject: SIGBUS or SIGSEGV on OSX? > > Hi, > > We (the compiler team) had a couple of bugs reported on OSX where the crash is caused by a SIGBUS in a compiled method: > > siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0x0000000115d4f018 > > The 64 bit VM is running in "compressed oops with base" mode. The base is 0x0000000115d4f000. > The address of the erroneous memory access is 8 byte aligned and falls in the first page of the heap which is used for implicit null checks. So this access is not expected to trigger a SIGBUS but rather a SIGSEGV and should then be handled by hotspot rather than lead to a crash. > > I see in JVM_handle_bsd_signal() that there's a number of places where a test for SIGSEGV was replaced by test for a SIGSEGV or a SIGBUS. In particular, I think this: > > #if defined(__APPLE__) && !defined(AMD64) > // 32-bit Darwin reports a SIGBUS for nearly all memory access exceptions. > // Catching SIGBUS here prevents the implicit SIGBUS NULL check below from > // being called, so only do so if the implicit NULL check is not necessary. > } else if (sig == SIGBUS && MacroAssembler::needs_explicit_null_check((int)info->si_addr)) { #else > } else if (sig == SIGBUS /* && info->si_code == BUS_OBJERR */) { #endif > > would fix the problem on 64 bit as well. > > Should I make this change? > > Roland. From scott.kovatch at oracle.com Mon May 14 08:14:44 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 14 May 2012 08:14:44 -0700 Subject: [8] request for review: 7168550 [macosx] duplicate OGL context state changes related to vertex cache In-Reply-To: <4FB0E199.2050109@oracle.com> References: <4FB0E199.2050109@oracle.com> Message-ID: On May 14, 2012, at 3:42 AM, Dmitry Cherepanov wrote: > Here's a patch for the 'disappearing text' problem reproducible in dual-screen environment. The fix duplicates some context state changes (which aren't shared across contexts) and the fix also enables switching between contexts from SetScratchSurface (switching 'offscreen' contexts from the flusher thread) to make sure that we'll update the state in the proper context. > > More info - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168550 (the bug report will become visible soon) > Webrev - http://cr.openjdk.java.net/~dcherepanov/7168550/webrev.0/ Hooray! I'm hoping this will also fix the crash in NetBeans when I switch from external monitor to laptop screen or vice versa. -- Scott From swingler at apple.com Mon May 14 09:11:21 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 14 May 2012 09:11:21 -0700 Subject: [8] request for review: 7168550 [macosx] duplicate OGL context state changes related to vertex cache In-Reply-To: <4FB0E199.2050109@oracle.com> References: <4FB0E199.2050109@oracle.com> Message-ID: <88DCE547-783B-41FB-BAE8-1989BFA0BD2C@apple.com> On May 14, 2012, at 3:42 AM, Dmitry Cherepanov wrote: > Here's a patch for the 'disappearing text' problem reproducible in dual-screen environment. The fix duplicates some context state changes (which aren't shared across contexts) and the fix also enables switching between contexts from SetScratchSurface (switching 'offscreen' contexts from the flusher thread) to make sure that we'll update the state in the proper context. > > More info - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168550 (the bug report will become visible soon) > Webrev - http://cr.openjdk.java.net/~dcherepanov/7168550/webrev.0/ The fix looks good to me. Great work tracking this down. Cheers, Mike Swingler Apple Inc. From vladimir.kozlov at oracle.com Mon May 14 09:09:45 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 May 2012 09:09:45 -0700 Subject: SIGBUS or SIGSEGV on OSX? In-Reply-To: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> References: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> Message-ID: <4FB12E49.7070005@oracle.com> So we have it in BSD port but not in OSX? That would explain it, I did review of BSD port and thought that OSX will use the same code. Thank you, Roland, for finding it. Vladimir Roland Westrelin wrote: > Hi, > > We (the compiler team) had a couple of bugs reported on OSX where the crash is caused by a SIGBUS in a compiled method: > > siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0x0000000115d4f018 > > The 64 bit VM is running in "compressed oops with base" mode. The base is 0x0000000115d4f000. > The address of the erroneous memory access is 8 byte aligned and falls in the first page of the heap which is used for implicit null checks. So this access is not expected to trigger a SIGBUS but rather a SIGSEGV and should then be handled by hotspot rather than lead to a crash. > > I see in JVM_handle_bsd_signal() that there's a number of places where a test for SIGSEGV was replaced by test for a SIGSEGV or a SIGBUS. In particular, I think this: > > #if defined(__APPLE__) && !defined(AMD64) > // 32-bit Darwin reports a SIGBUS for nearly all memory access exceptions. > // Catching SIGBUS here prevents the implicit SIGBUS NULL check below from > // being called, so only do so if the implicit NULL check is not necessary. > } else if (sig == SIGBUS && MacroAssembler::needs_explicit_null_check((int)info->si_addr)) { > #else > } else if (sig == SIGBUS /* && info->si_code == BUS_OBJERR */) { > #endif > > would fix the problem on 64 bit as well. > > Should I make this change? > > Roland. From jcpalmer at rochester.rr.com Mon May 14 09:14:52 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Mon, 14 May 2012 12:14:52 -0400 Subject: Shortcut Icon blurry In-Reply-To: <4FAECFF1.9000201@oracle.com> References: <3A40D6C3-D9DB-49CB-A747-72D439FFD204@rochester.rr.com> <4FAECFF1.9000201@oracle.com> Message-ID: <37C94294-1D2D-40AA-8508-8438544DAC2F@rochester.rr.com> Done. In bug report mentioned clicking icon did not do anything, but clicked it again and found http requests for updates to jar, jnlp & 64 wide-high jpg in server log. Also found these log entries on Mac (clean up a little): 5/14/12 11:53:19.967 AM My App Name: launch WebStart with arguments: 5/14/12 11:53:19.968 AM My App Name: -J-Xdock:icon=/Users/lion/Desktop/My App Name.app/Contents/Resources/424c7c54-68133ec2.icns 5/14/12 11:53:19.968 AM My App Name: -localfile 5/14/12 11:53:19.968 AM My App Name: -online 5/14/12 11:53:19.969 AM My App Name: -J-Djnlp.application.href=http://www.mydomain.com/my-app.jnlp 5/14/12 11:53:19.969 AM My App Name: /Users/lion/Library/Application Support/Oracle/Java/Deployment/cache/6.0/1/4ce22701-5c68f43d 5/14/12 11:53:20.161 AM Firewall: javaws is listening from 127.0.0.1:59888 proto=6 5/14/12 11:53:20.170 AM Firewall: javaws is listening from 127.0.0.1:59889 proto=6 Very early in program sys out & sys err are redirected to file, but noticed no entries in files & mod times old. Do not think made it all the way to running. Is this supposed to work yet? From another bug, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168441, I have not been clicking the trust button to test behavior. If go again from Safari and click trust, maybe it then works. Do not want to invest time in things known to not work, but have no release notes. Please advise. On May 12, 2012, at 5:02 PM, Igor Nekrestyanov wrote: > Please file a bug. > > -igor > > On 5/12/12 10:15 AM, Jeff Palmer wrote: >> I was under the impression short cuts were coming next week, but parts did show up in EA-b09. It still does not work, so thought note would be better than a bug at this point. >> >> Wrote a Java program the generates JPG's of different sizes, with matching levels of details. Sizes are 128, 64,& 32. EA-b09 now prompts to save a short cut,& does. Clicking on the short cut does not yet actually do anything as far as I can tell, but the icon detail does not pop like in the one saved from the Apple implementation. >> >> I think the 32 bit version is just being stretched. Looking at the http server's request log shows only the 64-bit version being checked for updates every launch. 128 bit should also be checked when it is set as splash, but I do not have that on right now. >> >> Maybe the checking for update is right, but then the wrong version ends up used for display. > From Sergey.Bylokhov at oracle.com Mon May 14 09:44:06 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 14 May 2012 20:44:06 +0400 Subject: [7u6] Request for review: 7160623 [macosx] Editable TextArea/TextField are blocking GUI applications from exit In-Reply-To: <4FA3C6EC.5020205@oracle.com> References: <4FA2A14B.8040501@oracle.com> <4FA3C6EC.5020205@oracle.com> Message-ID: <4FB13656.3000302@oracle.com> Thanks, Anthony. Does anybody has a chance to review the fix? One more reviewer needed. 04.05.2012 16:09, Anthony Petrov wrote: > The fix still looks fine. > > -- > best regards, > Anthony > > On 5/3/2012 7:16 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=7160623 >> jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c31eeeda3ed1 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7160623/webrev.00 >> >> Discussion about the same xawt fix: >> http://mail.openjdk.java.net/pipermail/awt-dev/2012-March/002381.html -- Best regards, Sergey. From swingler at apple.com Mon May 14 09:54:18 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 14 May 2012 09:54:18 -0700 Subject: [7u6] Review request for 7149062: [macosx] dock menu don't show available frames In-Reply-To: <4FAE55A3.5040405@oracle.com> References: <4FAE55A3.5040405@oracle.com> Message-ID: <1740289B-A97E-41E5-84BC-E7B3F520A190@apple.com> On May 12, 2012, at 5:20 AM, Anthony Petrov wrote: > Hello, > > This is almost a direct back-port of the same fix from JDK 8. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=7149062 > > Fix: http://cr.openjdk.java.net/~anthony/7u6-9-windowListInDockMenu-7149062.0/ Looks good, Mike Swingler Apple Inc. From alexander.zuev at oracle.com Mon May 14 10:28:50 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 14 May 2012 21:28:50 +0400 Subject: [7u6] Request for review: 7160623 [macosx] Editable TextArea/TextField are blocking GUI applications from exit In-Reply-To: <4FB13656.3000302@oracle.com> References: <4FA2A14B.8040501@oracle.com> <4FA3C6EC.5020205@oracle.com> <4FB13656.3000302@oracle.com> Message-ID: <4FB140D2.60101@oracle.com> Fix looks fine. WBR, Alex On 5/14/12 20:44, Sergey Bylokhov wrote: > Thanks, Anthony. > Does anybody has a chance to review the fix? One more reviewer needed. > > 04.05.2012 16:09, Anthony Petrov wrote: >> The fix still looks fine. >> >> -- >> best regards, >> Anthony >> >> On 5/3/2012 7:16 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=7160623 >>> jdk8 changeset: >>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c31eeeda3ed1 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7160623/webrev.00 >>> >>> Discussion about the same xawt fix: >>> http://mail.openjdk.java.net/pipermail/awt-dev/2012-March/002381.html > > From jcpalmer at rochester.rr.com Mon May 14 13:51:24 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Mon, 14 May 2012 16:51:24 -0400 Subject: OT: Reason TLS 1.1 & 1.2 off by default Message-ID: There might be a better place to bring this up, but I do not understand why TLS 1.1 & 1.2 are not enabled by default in the Java Control Panel. This is not just the Mac port. After the demo last September that SSL 3.0 might be defeate-able, 1.6.29 or 30 came out which added TLS 1.1 & 1.2 to Java 6, something that was already in Java 7. Browser makers started to work on the newer protocols from the client side. Jetty and possibly others servers started putting out releases which allowed protocols be prioritized or even turned off. No average user is ever going to turn this on themselves. I can fully see not turning SSL 3.0 and TLS 1.0 off (but I have tested this), but not a reason to not turn these on. From mik3hall at gmail.com Mon May 14 14:09:35 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 14 May 2012 16:09:35 -0500 Subject: Shortcut Icon blurry In-Reply-To: <37C94294-1D2D-40AA-8508-8438544DAC2F@rochester.rr.com> References: <3A40D6C3-D9DB-49CB-A747-72D439FFD204@rochester.rr.com> <4FAECFF1.9000201@oracle.com> <37C94294-1D2D-40AA-8508-8438544DAC2F@rochester.rr.com> Message-ID: <9646490A-98E2-434F-AD3B-08DEBAB96E80@gmail.com> On May 14, 2012, at 11:14 AM, Jeff Palmer wrote: > Very early in program sys out & sys err are redirected to file, but noticed no entries in files & mod times old. Do not think made it all the way to running. Is this supposed to work yet? I'm not sure what is what supposed to work yet? Redirected I/O definitely does. My app has done that from initial set up with Java 7. I'm not sure if that's supposed to work differently for some reason JWS? If you figure security is failing you when it shouldn't with JWS then shouldn't there be some exception be thrown or aren't there options to track failures for security reasons? I seem to remember there were but would have to look it up. From jcpalmer at rochester.rr.com Mon May 14 15:00:33 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Mon, 14 May 2012 18:00:33 -0400 Subject: Shortcut Icon blurry In-Reply-To: <9646490A-98E2-434F-AD3B-08DEBAB96E80@gmail.com> References: <3A40D6C3-D9DB-49CB-A747-72D439FFD204@rochester.rr.com> <4FAECFF1.9000201@oracle.com> <37C94294-1D2D-40AA-8508-8438544DAC2F@rochester.rr.com> <9646490A-98E2-434F-AD3B-08DEBAB96E80@gmail.com> Message-ID: <4A3CB283-09B6-4AD0-AB2B-23D6B354B98F@rochester.rr.com> This is related to short cuts being fully operational. Last week on a Apple forum thread Scott Kovatch said "Shortcut support is now in the build and should show up in next week's EA release". Build 9 came out at the same time he said that, and it does ask to save a short cut. It is just a little too vague what the difference between what a build and a release is. Staring closely at that statement again though, it implies whatever this thing was last week, full support should be there. FYI, as far as Redirected I/O, I agree it works. With JWS there is a brief period before the JVM is actually running. Since the redirection occurs so early in the application, I was using it to guess if the process got as far as starting the JVM. I just deleted the application from the cache, which also removed the short-cut. Re-downloaded with safari, and checked the "Always trust" thing this time. Subsequent clicks of the short cut do not do anything more than before, so that was not the problem. Guess I have another bug to file. On May 14, 2012, at 5:09 PM, Michael Hall wrote: > > On May 14, 2012, at 11:14 AM, Jeff Palmer wrote: > >> Very early in program sys out & sys err are redirected to file, but noticed no entries in files & mod times old. Do not think made it all the way to running. Is this supposed to work yet? > > I'm not sure what is what supposed to work yet? > Redirected I/O definitely does. My app has done that from initial set up with Java 7. > I'm not sure if that's supposed to work differently for some reason JWS? > If you figure security is failing you when it shouldn't with JWS then shouldn't there be some exception be thrown or aren't there options to track failures for security reasons? I seem to remember there were but would have to look it up. From jcpalmer at rochester.rr.com Mon May 14 15:49:29 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Mon, 14 May 2012 18:49:29 -0400 Subject: Shortcut Icon blurry In-Reply-To: <4A3CB283-09B6-4AD0-AB2B-23D6B354B98F@rochester.rr.com> References: <3A40D6C3-D9DB-49CB-A747-72D439FFD204@rochester.rr.com> <4FAECFF1.9000201@oracle.com> <37C94294-1D2D-40AA-8508-8438544DAC2F@rochester.rr.com> <9646490A-98E2-434F-AD3B-08DEBAB96E80@gmail.com> <4A3CB283-09B6-4AD0-AB2B-23D6B354B98F@rochester.rr.com> Message-ID: Update, tried another similarly signed JWS app, but this one does not need any local permissions. The short cut of this one relaunches application fine. Bug file as: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168761 On May 14, 2012, at 6:00 PM, Jeff Palmer wrote: > This is related to short cuts being fully operational. Last week on a Apple forum thread Scott Kovatch said "Shortcut support is now in the build and should show up in next week's EA release". > > Build 9 came out at the same time he said that, and it does ask to save a short cut. It is just a little too vague what the difference between what a build and a release is. Staring closely at that statement again though, it implies whatever this thing was last week, full support should be there. > > FYI, as far as Redirected I/O, I agree it works. With JWS there is a brief period before the JVM is actually running. Since the redirection occurs so early in the application, I was using it to guess if the process got as far as starting the JVM. > > I just deleted the application from the cache, which also removed the short-cut. Re-downloaded with safari, and checked the "Always trust" thing this time. Subsequent clicks of the short cut do not do anything more than before, so that was not the problem. Guess I have another bug to file. > > > On May 14, 2012, at 5:09 PM, Michael Hall wrote: > >> >> On May 14, 2012, at 11:14 AM, Jeff Palmer wrote: >> >>> Very early in program sys out & sys err are redirected to file, but noticed no entries in files & mod times old. Do not think made it all the way to running. Is this supposed to work yet? >> >> I'm not sure what is what supposed to work yet? >> Redirected I/O definitely does. My app has done that from initial set up with Java 7. >> I'm not sure if that's supposed to work differently for some reason JWS? >> If you figure security is failing you when it shouldn't with JWS then shouldn't there be some exception be thrown or aren't there options to track failures for security reasons? I seem to remember there were but would have to look it up. > From mik3hall at gmail.com Mon May 14 16:08:59 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 14 May 2012 18:08:59 -0500 Subject: Shortcut Icon blurry In-Reply-To: <4A3CB283-09B6-4AD0-AB2B-23D6B354B98F@rochester.rr.com> References: <3A40D6C3-D9DB-49CB-A747-72D439FFD204@rochester.rr.com> <4FAECFF1.9000201@oracle.com> <37C94294-1D2D-40AA-8508-8438544DAC2F@rochester.rr.com> <9646490A-98E2-434F-AD3B-08DEBAB96E80@gmail.com> <4A3CB283-09B6-4AD0-AB2B-23D6B354B98F@rochester.rr.com> Message-ID: <082C743A-838A-4387-8FBA-5AD393672EEE@gmail.com> On May 14, 2012, at 5:00 PM, Jeff Palmer wrote: > FYI, as far as Redirected I/O, I agree it works. With JWS there is a brief period before the JVM is actually running. Since the redirection occurs so early in the application, I was using it to guess if the process got as far as starting the JVM. Clarifies my question. Thanks. From bradford.wetmore at oracle.com Mon May 14 18:35:17 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 14 May 2012 18:35:17 -0700 Subject: Fwd: OT: Reason TLS 1.1 & 1.2 off by default In-Reply-To: <4FB1AE3C.1030106@oracle.com> References: <4FB1AE3C.1030106@oracle.com> Message-ID: <4FB1B2D5.7050601@oracle.com> > After the demo last September that SSL 3.0 might be defeate-able, > 1.6.29 or 30 came out which added TLS 1.1 & 1.2 to Java 6, You are likely thinking of a different fix which was added to JDK 6u29 to address CVE-2011-3389. Oracle has not backported TLS 1.1/1.2 to Java 6. TLS 1.1/1.2 currently only exists in JDK 7 (and 8). There have been interop issues with existing TLS servers (including some which don't even speak TLS 1.1/1.2, but choke on the 1.1/1.2 requests), which is part of the reason why it hasn't been enabled by default yet. Brad > -------- Original Message -------- > Subject: OT: Reason TLS 1.1 & 1.2 off by default > Date: Mon, 14 May 2012 16:51:24 -0400 > From: Jeff Palmer > To: macosx-port-dev at openjdk.java.net > > There might be a better place to bring this up, but I do not understand > why TLS 1.1 & 1.2 are not enabled by default in the Java Control Panel. > This is not just the Mac port. > > After the demo last September that SSL 3.0 might be defeate-able, 1.6.29 > or 30 came out which added TLS 1.1 & 1.2 to Java 6, something that was > already in Java 7. Browser makers started to work on the newer protocols > from the client side. Jetty and possibly others servers started putting > out releases which allowed protocols be prioritized or even turned off. > > No average user is ever going to turn this on themselves. I can fully > see not turning SSL 3.0 and TLS 1.0 off (but I have tested this), but > not a reason to not turn these on. From anthony.petrov at oracle.com Tue May 15 06:26:30 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 15 May 2012 17:26:30 +0400 Subject: [8] Review request for 7168851: [macosx] Netbeans crashes in CImage.nativeCreateNSImageFromArray Message-ID: <4FB25986.6060908@oracle.com> Hi Dmitry, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7168851 at: http://cr.openjdk.java.net/~anthony/8-32-nativeCreateNSImageFromArrayCrash-7168851.0/ -- best regards, Anthony From dmitry.cherepanov at oracle.com Tue May 15 06:59:17 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Tue, 15 May 2012 17:59:17 +0400 Subject: [8] Review request for 7168851: [macosx] Netbeans crashes in CImage.nativeCreateNSImageFromArray In-Reply-To: <4FB25986.6060908@oracle.com> References: <4FB25986.6060908@oracle.com> Message-ID: <4FB26135.2020107@oracle.com> Hi Anthony, Thanks for fixing this, minor comment: - 166 [reps release]; Looks fine to me as [NSMutableArray arrayWithCapacity:] returns auto-released object. - 117 [imageRep release]; We should probably keep this 'release' as, looks like, it corresponds to "[NSBitmapImageRep alloc] ..." from CImage_CreateImageRep. Thanks, Dmitry Anthony Petrov wrote: > Hi Dmitry, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7168851 > at: > > http://cr.openjdk.java.net/~anthony/8-32-nativeCreateNSImageFromArrayCrash-7168851.0/ > > > -- > best regards, > Anthony From anthony.petrov at oracle.com Tue May 15 07:08:36 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 15 May 2012 18:08:36 +0400 Subject: [8] Review request for 7168851: [macosx] Netbeans crashes in CImage.nativeCreateNSImageFromArray In-Reply-To: <4FB26135.2020107@oracle.com> References: <4FB25986.6060908@oracle.com> <4FB26135.2020107@oracle.com> Message-ID: <4FB26364.1080000@oracle.com> On 5/15/2012 5:59 PM, Dmitry Cherepanov wrote: > Thanks for fixing this, minor comment: > > - 166 [reps release]; > > Looks fine to me as [NSMutableArray arrayWithCapacity:] returns > auto-released object. > > - 117 [imageRep release]; > > We should probably keep this 'release' as, looks like, it corresponds to > "[NSBitmapImageRep alloc] ..." from CImage_CreateImageRep. "I've learned something today!" :) Indeed. A good catch! Thank you. Here's an updated fix: http://cr.openjdk.java.net/~anthony/8-32-nativeCreateNSImageFromArrayCrash-7168851.1/ -- best regards, Anthony > > Thanks, > Dmitry > > > Anthony Petrov wrote: >> Hi Dmitry, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7168851 >> at: >> >> http://cr.openjdk.java.net/~anthony/8-32-nativeCreateNSImageFromArrayCrash-7168851.0/ >> >> >> -- >> best regards, >> Anthony > From dmitry.cherepanov at oracle.com Tue May 15 07:15:28 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Tue, 15 May 2012 18:15:28 +0400 Subject: [8] Review request for 7168851: [macosx] Netbeans crashes in CImage.nativeCreateNSImageFromArray In-Reply-To: <4FB26364.1080000@oracle.com> References: <4FB25986.6060908@oracle.com> <4FB26135.2020107@oracle.com> <4FB26364.1080000@oracle.com> Message-ID: <4FB26500.2030104@oracle.com> Anthony Petrov wrote: > On 5/15/2012 5:59 PM, Dmitry Cherepanov wrote: >> Thanks for fixing this, minor comment: >> >> - 166 [reps release]; >> >> Looks fine to me as [NSMutableArray arrayWithCapacity:] returns >> auto-released object. >> >> - 117 [imageRep release]; >> >> We should probably keep this 'release' as, looks like, it corresponds >> to "[NSBitmapImageRep alloc] ..." from CImage_CreateImageRep. > > "I've learned something today!" :) > > Indeed. A good catch! Thank you. Here's an updated fix: > > http://cr.openjdk.java.net/~anthony/8-32-nativeCreateNSImageFromArrayCrash-7168851.1/ > Looks fine to me, thanks! :) > > -- > best regards, > Anthony > >> >> Thanks, >> Dmitry >> >> >> Anthony Petrov wrote: >>> Hi Dmitry, >>> >>> Please review a fix for >>> http://bugs.sun.com/view_bug.do?bug_id=7168851 at: >>> >>> http://cr.openjdk.java.net/~anthony/8-32-nativeCreateNSImageFromArrayCrash-7168851.0/ >>> >>> >>> -- >>> best regards, >>> Anthony >> From alexandr.scherbatiy at oracle.com Tue May 15 07:47:27 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 15 May 2012 18:47:27 +0400 Subject: [8] Review request for 7158928 [macosx] NLS: Please change the mnemonic assignment system Message-ID: <4FB26C7F.9080009@oracle.com> Hello, Please review a fix for the issue: 7158928 [macosx] NLS: Please change the mnemonic assignment system http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7158928 The webrev is http://cr.openjdk.java.net/~alexsch/7158928/webrev.00 This is a request from the NLS team to use text and mnemonics in one property for the Aqua properties. The fix consists of the following parts: - aqua.properties file is added as a compiled property in the makefiles. There are no localizations of the aqua.properties file in the JDK. - The aqua bundle is always added to the UIdefaults table in the AquaLookAndFeel. It is necessary to register the bundle and clear the table cache. - Text and mnemonic properties are unified in one property for the aqua.properties file in the same way as it was done for the fix 7093156 For example the following properties xxxText=ABC xxxMnemonic=B are unified to one: xxx.textAndMnemonic=A&BC Thanks, Alexandr. From anthony.petrov at oracle.com Tue May 15 09:46:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 15 May 2012 20:46:49 +0400 Subject: [7u6] Review request for 7144542: [macosx] Crash in liblwawt.dylib setBusy() when exiting an FX app run with j2d pipeline In-Reply-To: <4FAB9983.9030506@oracle.com> References: <4FA3ED6F.5010502@oracle.com> <4FAB9983.9030506@oracle.com> Message-ID: <4FB28879.8080502@oracle.com> Hi Artem, On 5/10/2012 2:33 PM, Artem Ananiev wrote: > On 5/4/2012 6:53 PM, Anthony Petrov wrote: >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7144542 >> at: >> >> http://cr.openjdk.java.net/~anthony/7u6-6-crashInSetBusy-7144542.0/ > > So what you do is to change headful CToolkit to headless XToolkit, > correct? Note that this change will also trigger Java2D pipeline change, > which might not be what we want. Actually, while performing more testing I've found one issue with the fix: we must also choose the correct font manager class. Otherwise the MACOSX_PORT-705 is resurrected. An updated fix is here: http://cr.openjdk.java.net/~anthony/7u6-6-crashInSetBusy-7144542.1/ Meanwhile I've performed some performance measurement using the GUIMark2 for FX, and here are some results: BitmapTest: w/o the fix: ~4.22 FPS with the fix: ~4.19 FPS VectorTest: w/o the fix: ~21.0 FPS with the fix: ~21.3 FPS So it looks like there's no any major performance difference between the CToolkit and XToolkit Java2D pipelines. > Have you tried to find out what exactly leads to the crash when CToolkit > is used? Since the crash is actually happening in the HotSpot code, it's being investigated by HotSpot team under 7166725. -- best regards, Anthony > > Thanks, > > Artem > >> Note: in JDK 8 we already load the headless version of the AWT library, >> and this prevents the crash. Now I'm applying the same logic to JDK 7u6. >> >> -- >> best regards, >> Anthony From Sergey.Bylokhov at oracle.com Wed May 16 06:45:27 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 May 2012 17:45:27 +0400 Subject: [8] Review request for 7158928 [macosx] NLS: Please change the mnemonic assignment system In-Reply-To: <4FB26C7F.9080009@oracle.com> References: <4FB26C7F.9080009@oracle.com> Message-ID: <4FB3AF77.1080300@oracle.com> Hi Alexander. Looks good. Thanks. 15.05.2012 18:47, Alexander Scherbatiy wtote: > Hello, > > Please review a fix for the issue: > 7158928 [macosx] NLS: Please change the mnemonic assignment system > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7158928 > > The webrev is http://cr.openjdk.java.net/~alexsch/7158928/webrev.00 > > This is a request from the NLS team to use text and mnemonics in one > property for the Aqua properties. > > The fix consists of the following parts: > - aqua.properties file is added as a compiled property in the makefiles. > There are no localizations of the aqua.properties file in the JDK. > - The aqua bundle is always added to the UIdefaults table in the > AquaLookAndFeel. It is necessary to register the bundle and clear the > table cache. > - Text and mnemonic properties are unified in one property for the > aqua.properties file in the same way as it was done for the fix 7093156 > For example the following properties > xxxText=ABC > xxxMnemonic=B > are unified to one: > xxx.textAndMnemonic=A&BC > > Thanks, > Alexandr. > > -- Best regards, Sergey. From andrew.brygin at oracle.com Wed May 16 07:22:27 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 16 May 2012 18:22:27 +0400 Subject: [8] request for review: 7124400: [macosx] CGraphicsDevice.getConfigurations() returns reference to member (does not copy configs) Message-ID: <4FB3B823.9010302@oracle.com> Hello, there is a fix for7124400: we have to clone a GraphicsConfiguration collection in order to prevent it's modification by an external code. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124400 Webrev: http://cr.openjdk.java.net/~bae/7124400/webrev.00/ Thanks, Andrew From roland.westrelin at oracle.com Mon May 14 04:30:42 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 14 May 2012 13:30:42 +0200 Subject: SIGBUS or SIGSEGV on OSX? Message-ID: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> Hi, We (the compiler team) had a couple of bugs reported on OSX where the crash is caused by a SIGBUS in a compiled method: siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0x0000000115d4f018 The 64 bit VM is running in "compressed oops with base" mode. The base is 0x0000000115d4f000. The address of the erroneous memory access is 8 byte aligned and falls in the first page of the heap which is used for implicit null checks. So this access is not expected to trigger a SIGBUS but rather a SIGSEGV and should then be handled by hotspot rather than lead to a crash. I see in JVM_handle_bsd_signal() that there's a number of places where a test for SIGSEGV was replaced by test for a SIGSEGV or a SIGBUS. In particular, I think this: #if defined(__APPLE__) && !defined(AMD64) // 32-bit Darwin reports a SIGBUS for nearly all memory access exceptions. // Catching SIGBUS here prevents the implicit SIGBUS NULL check below from // being called, so only do so if the implicit NULL check is not necessary. } else if (sig == SIGBUS && MacroAssembler::needs_explicit_null_check((int)info->si_addr)) { #else } else if (sig == SIGBUS /* && info->si_code == BUS_OBJERR */) { #endif would fix the problem on 64 bit as well. Should I make this change? Roland. From bob.vandette at oracle.com Mon May 14 05:54:03 2012 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 14 May 2012 05:54:03 -0700 (PDT) Subject: SIGBUS or SIGSEGV on OSX? In-Reply-To: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> References: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> Message-ID: <0fc7227b-fb94-484c-80c0-ea5839698642@default> I had to fix the same problem in the signal handler for iOS. I had problems with implicit null checks and safepoint polling exceptions when running our JDK7 Embedded build on iPads and iPhones. Make sure you check all cases of SIGSEGV. Bob. -----Original Message----- From: Roland Westrelin Sent: Monday, May 14, 2012 7:31 AM To: hotspot-runtime-dev at openjdk.java.net; macosx-port-dev at openjdk.java.net Cc: hotspot compiler Subject: SIGBUS or SIGSEGV on OSX? Hi, We (the compiler team) had a couple of bugs reported on OSX where the crash is caused by a SIGBUS in a compiled method: siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0x0000000115d4f018 The 64 bit VM is running in "compressed oops with base" mode. The base is 0x0000000115d4f000. The address of the erroneous memory access is 8 byte aligned and falls in the first page of the heap which is used for implicit null checks. So this access is not expected to trigger a SIGBUS but rather a SIGSEGV and should then be handled by hotspot rather than lead to a crash. I see in JVM_handle_bsd_signal() that there's a number of places where a test for SIGSEGV was replaced by test for a SIGSEGV or a SIGBUS. In particular, I think this: #if defined(__APPLE__) && !defined(AMD64) // 32-bit Darwin reports a SIGBUS for nearly all memory access exceptions. // Catching SIGBUS here prevents the implicit SIGBUS NULL check below from // being called, so only do so if the implicit NULL check is not necessary. } else if (sig == SIGBUS && MacroAssembler::needs_explicit_null_check((int)info->si_addr)) { #else } else if (sig == SIGBUS /* && info->si_code == BUS_OBJERR */) { #endif would fix the problem on 64 bit as well. Should I make this change? Roland. From roland.westrelin at oracle.com Mon May 14 09:03:06 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 14 May 2012 18:03:06 +0200 Subject: SIGBUS or SIGSEGV on OSX? In-Reply-To: <2110EEBC-2818-45CA-8437-4C1D99C87ABA@oracle.com> References: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> <0fc7227b-fb94-484c-80c0-ea5839698642@default> <2110EEBC-2818-45CA-8437-4C1D99C87ABA@oracle.com> Message-ID: Hi Karen, > Yes please. I also think we are seeing a similar problem on stack overflow handling - so let us know if > you are also fixing that or if we want to do a separate additional modification for that case as well. Sure, I can make the other fix as well but I don't see where there is something missing for stack overflow handling. Roland. From roland.westrelin at oracle.com Mon May 14 09:24:05 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 14 May 2012 18:24:05 +0200 Subject: SIGBUS or SIGSEGV on OSX? In-Reply-To: <4FB12E49.7070005@oracle.com> References: <679676EE-E328-4D4C-8830-91E3F1F99013@oracle.com> <4FB12E49.7070005@oracle.com> Message-ID: > So we have it in BSD port but not in OSX? That would explain it, I did review of > BSD port and thought that OSX will use the same code. Not exactly: we have it for OSX and not BSD but only on 32 bit. Roland. From pavel.porvatov at oracle.com Wed May 16 04:56:10 2012 From: pavel.porvatov at oracle.com (Pavel Porvatov) Date: Wed, 16 May 2012 15:56:10 +0400 Subject: [8] Review request for 7158928 [macosx] NLS: Please change the mnemonic assignment system In-Reply-To: <4FB26C7F.9080009@oracle.com> References: <4FB26C7F.9080009@oracle.com> Message-ID: <4FB395DA.9010109@oracle.com> Hi Alexander, Looks good for me. > Hello, > > Please review a fix for the issue: > 7158928 [macosx] NLS: Please change the mnemonic assignment system > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7158928 > > The webrev is http://cr.openjdk.java.net/~alexsch/7158928/webrev.00 > > This is a request from the NLS team to use text and mnemonics in one > property for the Aqua properties. > > The fix consists of the following parts: > - aqua.properties file is added as a compiled property in the makefiles. > There are no localizations of the aqua.properties file in the JDK. > - The aqua bundle is always added to the UIdefaults table in the > AquaLookAndFeel. It is necessary to register the bundle and clear the > table cache. > - Text and mnemonic properties are unified in one property for the > aqua.properties file in the same way as it was done for the fix 7093156 > For example the following properties > xxxText=ABC > xxxMnemonic=B > are unified to one: > xxx.textAndMnemonic=A&BC > > Thanks, > Alexandr. > > From anthony.petrov at oracle.com Wed May 16 08:50:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 16 May 2012 19:50:22 +0400 Subject: [8] request for review: 7124400: [macosx] CGraphicsDevice.getConfigurations() returns reference to member (does not copy configs) In-Reply-To: <4FB3B823.9010302@oracle.com> References: <4FB3B823.9010302@oracle.com> Message-ID: <4FB3CCBE.3080104@oracle.com> The fix looks fine to me. -- best regards, Anthony On 5/16/2012 6:22 PM, Andrew Brygin wrote: > Hello, > > there is a fix for7124400: we have to clone a GraphicsConfiguration > collection in order to prevent it's modification by an external code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124400 > Webrev: http://cr.openjdk.java.net/~bae/7124400/webrev.00/ > > Thanks, > Andrew From marco.dinacci at gmail.com Thu May 17 03:27:58 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Thu, 17 May 2012 11:27:58 +0100 Subject: Swing/AWT apps don't work inside a sandbox Message-ID: Hi, because freetype is still not included for osx, any Java app that makes use of AWT/Swing won't work inside a sandbox as sandboxd will refuse loading the freetype system library: I made a simple app with only this line: Toolkit tk = Toolkit.getDefaultToolkit(); and this is the result when I launch it from within a sandbox: 17/05/2012 10:58:24.423 sandboxd: ([9839]) JavaAppLauncher(9839) deny file-read-data /usr/X11/lib/libfreetype.6.dylib 17/05/2012 10:58:24.426 [0x0-0x11eb1ea].SwingTest: Exception in thread "main" 17/05/2012 10:58:24.426 [0x0-0x11eb1ea].SwingTest: java.lang.UnsatisfiedLinkError: /Users/marco/Documents/Projects/appbundlertest/dist/SwingTest.app/Contents/PlugIns/1.7.0_latest.jdk/Contents/Home/jre/lib/libfontmanager.dylib: dlopen(/Users/marco/Documents/Projects/appbundlertest/dist/SwingTest.app/Contents/PlugIns/1.7.0_latest.jdk/Contents/Home/jre/lib/libfontmanager.dylib, 1): Library not loaded: /usr/X11/lib/libfreetype.6.dylib 17/05/2012 10:58:24.426 [0x0-0x11eb1ea].SwingTest: Referenced from: /Users/marco/Documents/Projects/appbundlertest/dist/SwingTest.app/Contents/PlugIns/1.7.0_latest.jdk/Contents/Home/jre/lib/libfontmanager.dylib 17/05/2012 10:58:24.426 [0x0-0x11eb1ea].SwingTest: Reason: no suitable image found. Did find: 17/05/2012 10:58:24.426 [0x0-0x11eb1ea].SwingTest: /usr/X11/lib/libfreetype.6.dylib: open() failed with errno=1 17/05/2012 10:58:24.427 [0x0-0x11eb1ea].SwingTest: at java.lang.ClassLoader$NativeLibrary.load(Native Method) 17/05/2012 10:58:24.427 [0x0-0x11eb1ea].SwingTest: at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1939) 17/05/2012 10:58:24.427 [0x0-0x11eb1ea].SwingTest: at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1864) 17/05/2012 10:58:24.428 [0x0-0x11eb1ea].SwingTest: at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1846) 17/05/2012 10:58:24.428 [0x0-0x11eb1ea].SwingTest: at java.lang.Runtime.loadLibrary0(Runtime.java:845) 17/05/2012 10:58:24.428 [0x0-0x11eb1ea].SwingTest: at java.lang.System.loadLibrary(System.java:1084) 17/05/2012 10:58:24.428 [0x0-0x11eb1ea].SwingTest: at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:77) 17/05/2012 10:58:24.428 [0x0-0x11eb1ea].SwingTest: at java.security.AccessController.doPrivileged(Native Method) 17/05/2012 10:58:24.428 [0x0-0x11eb1ea].SwingTest: at sun.lwawt.macosx.LWCToolkit.(LWCToolkit.java:74) 17/05/2012 10:58:24.428 [0x0-0x11eb1ea].SwingTest: at java.lang.Class.forName0(Native Method) 17/05/2012 10:58:24.428 [0x0-0x11eb1ea].SwingTest: at java.lang.Class.forName(Class.java:186) 17/05/2012 10:58:24.428 [0x0-0x11eb1ea].SwingTest: at java.awt.Toolkit$2.run(Toolkit.java:870) 17/05/2012 10:58:24.428 [0x0-0x11eb1ea].SwingTest: at java.security.AccessController.doPrivileged(Native Method) 17/05/2012 10:58:24.428 [0x0-0x11eb1ea].SwingTest: at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:862) 17/05/2012 10:58:24.429 [0x0-0x11eb1ea].SwingTest: at SwingTest.main(Unknown Source) Note that in less than two weeks all applications submitted to the App Store will have to be sandboxed. Is anybody already working on bundling freetype ? I can provide this simple project including the ant file which build and sign the app (you will still need valid mac developer keys to sign the app though). Otherwise I'll give it a try but I'll probably need some directions on the best way to do it. Best, Marco From andrew.brygin at oracle.com Thu May 17 05:34:07 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Thu, 17 May 2012 16:34:07 +0400 Subject: [8] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() Message-ID: <4FB4F03F.4020606@oracle.com> Hello, could you please review a fix for 7146550? DnD code does not check whether a toolkit image is ready to be painted into a buffer. We have to do this check in order to get correct image dimension. Suggested fix just delegates the conversion of toolkit image into a CImage instance to a helper class CImage.Creator. This helper class provides two ways to convert a toolkit image int CImage: - immediate conversion: returns valid CImage only if toolkit image has valid dimension, and null otherwise. Immediate conversion works fine for toolkit images which are prepared in advance, or are based on memory image source. - normal conversion: a toolkit image is prepared for rendering using a media tracker. We can not use the normal conversion in case of DnD, because broken toolkit image (whose producer never updates the image state for any reasons) can cause a hang in the DnD the code (test in question implements such scenario). If supplied drag image can not be conversed to CImage (either an exception is thrown or it is not ready, i.e. a result of conversion is null for any reasons) the InvalidDnDOperationException is thrown in order to notify user about the problem with drag image. Note that such approach is already used on windows platform, so with this fix, macosx behaves in a uniform way with windows. Beside this, this fix pushes the drag image (an instance of CImage) down to native DnD machinery in order to be able to display drag images. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 Webrev: http://cr.openjdk.java.net/~bae/7146550/webrev.00/ Thanks, Andrew From jfinley at tech4learning.com Thu May 17 14:55:48 2012 From: jfinley at tech4learning.com (Jessica Finley) Date: Thu, 17 May 2012 15:55:48 -0600 Subject: Using JAWT CALayer with QT Message-ID: Hiya folks, It is my understanding that we are to use CALayer based embedding now instead of NSView based embedding. Can someone explain to me how to do so? Primarily, I am interested in playing a QT movie. I've been looking at the JAWTExample project located here: https://developer.apple.com/library/mac/#samplecode/JAWTExample/Introduction/Intro.html#//apple_ref/doc/uid/DTS10000683-Intro-DontLinkElementID_2 Which works beautifully in Java 6, but no so much in Java 7. When run in Java 7 (after some finagling to launch the jar outside of its app bundle so it will run in Java 7), I get the following error when trying to draw the included QT movie: [java] JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM I'm not really sure why this doesn't work in Java 7, since it is using CALayer embedding, as it should? I think. Thanks! -Jess From andrew.brygin at oracle.com Fri May 18 02:30:34 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Fri, 18 May 2012 13:30:34 +0400 Subject: [8] request for review: 7154088: [macosx] Regression: Component.createImage do not inherits component attributes Message-ID: <4FB616BA.7000700@oracle.com> Hello, could you please review a fix for 7154088? This fix just delegates a creation of an appropriate off-screen image to the platform-specific graphics configuration. The change can be verified by a regression test mentioned in the bug description. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154088 Webrev: http://cr.openjdk.java.net/~bae/7154088/webrev.00/ Thanks, Andrew From artem.ananiev at oracle.com Fri May 18 04:41:03 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 18 May 2012 15:41:03 +0400 Subject: [OpenJDK 2D-Dev] [8] request for review: 7154088: [macosx] Regression: Component.createImage do not inherits component attributes In-Reply-To: <4FB616BA.7000700@oracle.com> References: <4FB616BA.7000700@oracle.com> Message-ID: <4FB6354F.5040502@oracle.com> Looks fine. Thanks, Artem On 5/18/2012 1:30 PM, Andrew Brygin wrote: > Hello, > > could you please review a fix for 7154088? > > This fix just delegates a creation of an appropriate off-screen > image to the platform-specific graphics configuration. > > The change can be verified by a regression test mentioned in the > bug description. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154088 > Webrev: http://cr.openjdk.java.net/~bae/7154088/webrev.00/ > > Thanks, > Andrew From artem.ananiev at oracle.com Fri May 18 06:43:14 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 18 May 2012 17:43:14 +0400 Subject: [7u6] Review request for 7144542: [macosx] Crash in liblwawt.dylib setBusy() when exiting an FX app run with j2d pipeline In-Reply-To: <4FB28879.8080502@oracle.com> References: <4FA3ED6F.5010502@oracle.com> <4FAB9983.9030506@oracle.com> <4FB28879.8080502@oracle.com> Message-ID: <4FB651F2.4050706@oracle.com> Looks fine. Thanks for additional testing! Artem On 5/15/2012 8:46 PM, Anthony Petrov wrote: > Hi Artem, > > On 5/10/2012 2:33 PM, Artem Ananiev wrote: >> On 5/4/2012 6:53 PM, Anthony Petrov wrote: >>> Please review a fix for >>> http://bugs.sun.com/view_bug.do?bug_id=7144542 at: >>> >>> http://cr.openjdk.java.net/~anthony/7u6-6-crashInSetBusy-7144542.0/ >> >> So what you do is to change headful CToolkit to headless XToolkit, >> correct? Note that this change will also trigger Java2D pipeline >> change, which might not be what we want. > > Actually, while performing more testing I've found one issue with the > fix: we must also choose the correct font manager class. Otherwise the > MACOSX_PORT-705 is resurrected. An updated fix is here: > > http://cr.openjdk.java.net/~anthony/7u6-6-crashInSetBusy-7144542.1/ > > Meanwhile I've performed some performance measurement using the GUIMark2 > for FX, and here are some results: > > BitmapTest: > w/o the fix: ~4.22 FPS > with the fix: ~4.19 FPS > > VectorTest: > w/o the fix: ~21.0 FPS > with the fix: ~21.3 FPS > > So it looks like there's no any major performance difference between the > CToolkit and XToolkit Java2D pipelines. > >> Have you tried to find out what exactly leads to the crash when >> CToolkit is used? > > Since the crash is actually happening in the HotSpot code, it's being > investigated by HotSpot team under 7166725. > > -- > best regards, > Anthony > > >> >> Thanks, >> >> Artem >> >>> Note: in JDK 8 we already load the headless version of the AWT library, >>> and this prevents the crash. Now I'm applying the same logic to JDK 7u6. >>> >>> -- >>> best regards, >>> Anthony From robert.strout at oracle.com Thu May 17 09:05:19 2012 From: robert.strout at oracle.com (Robert Strout) Date: Thu, 17 May 2012 09:05:19 -0700 Subject: Apple performance contact ? Message-ID: <4FB521BF.2040704@oracle.com> I'm looking for an contact in Apple that I can talk to about the performance monitoring that Apple has done for the Apple JDK releases. I'm not on this alias, so please reply directly. Thanks, Rob Strout Java Platform Group, Oracle From alexander.zuev at oracle.com Fri May 18 08:57:09 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 18 May 2012 19:57:09 +0400 Subject: [8] request for review: 7124400: [macosx] CGraphicsDevice.getConfigurations() returns reference to member (does not copy configs) In-Reply-To: <4FB3B823.9010302@oracle.com> References: <4FB3B823.9010302@oracle.com> Message-ID: <4FB67155.5070806@oracle.com> Andrew, fix looks Ok to me. WBR, Alex On 5/16/12 18:22, Andrew Brygin wrote: > Hello, > > there is a fix for7124400: we have to clone a GraphicsConfiguration > collection in order to prevent it's modification by an external code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124400 > Webrev: http://cr.openjdk.java.net/~bae/7124400/webrev.00/ > > Thanks, > Andrew From alexander.zuev at oracle.com Fri May 18 08:58:30 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 18 May 2012 19:58:30 +0400 Subject: [8] request for review: 7154088: [macosx] Regression: Component.createImage do not inherits component attributes In-Reply-To: <4FB616BA.7000700@oracle.com> References: <4FB616BA.7000700@oracle.com> Message-ID: <4FB671A6.1000907@oracle.com> Andrew, fix looks good. WBR, Alex On 5/18/12 13:30, Andrew Brygin wrote: > Hello, > > could you please review a fix for 7154088? > > This fix just delegates a creation of an appropriate off-screen > image to the platform-specific graphics configuration. > > The change can be verified by a regression test mentioned in the > bug description. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154088 > Webrev: http://cr.openjdk.java.net/~bae/7154088/webrev.00/ > > Thanks, > Andrew From alexander.zuev at oracle.com Fri May 18 08:59:20 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 18 May 2012 19:59:20 +0400 Subject: [8] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() In-Reply-To: <4FB4F03F.4020606@oracle.com> References: <4FB4F03F.4020606@oracle.com> Message-ID: <4FB671D8.3050003@oracle.com> Andrew, fix looks perfect for me. WBR, Alex On 5/17/12 16:34, Andrew Brygin wrote: > Hello, > > could you please review a fix for 7146550? > > DnD code does not check whether a toolkit image is ready to be painted > into a buffer. We have to do this check in order to get correct image > dimension. > > Suggested fix just delegates the conversion of toolkit image into a > CImage instance to a helper class CImage.Creator. This helper class > provides two ways to convert a toolkit image int CImage: > > - immediate conversion: returns valid CImage only if toolkit image > has valid dimension, and null otherwise. > Immediate conversion works fine for toolkit images which are > prepared in advance, or are based on memory image source. > > - normal conversion: a toolkit image is prepared for rendering using > a media tracker. > > We can not use the normal conversion in case of DnD, because broken > toolkit image (whose producer never updates the image state for any > reasons) can cause a hang in the DnD the code (test in question > implements such scenario). > > If supplied drag image can not be conversed to CImage (either an > exception is thrown or it is not ready, i.e. a result of conversion > is null for any reasons) the InvalidDnDOperationException is thrown > in order to notify user about the problem with drag image. > Note that such approach is already used on windows platform, so with > this fix, macosx behaves in a uniform way with windows. > > Beside this, this fix pushes the drag image (an instance of CImage) > down to native DnD machinery in order to be able to display drag > images. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 > Webrev: http://cr.openjdk.java.net/~bae/7146550/webrev.00/ > > Thanks, > Andrew From david.dehaven at oracle.com Sat May 19 09:07:35 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Sat, 19 May 2012 09:07:35 -0700 Subject: Swing/AWT apps don't work inside a sandbox In-Reply-To: References: Message-ID: <53E11DDF-9A99-4ACE-B936-20C8ADF3856E@oracle.com> > because freetype is still not included for osx, any Java app that > makes use of AWT/Swing won't work inside a sandbox as sandboxd will > refuse loading the freetype system library: Are you using your own build of OpenJDK? If you have X11 installed it will pull in libfreetype when you build. The solution is to not build with X11, the process for which escapes me at the moment? -DrD- From mik3hall at gmail.com Sat May 19 14:10:17 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 19 May 2012 16:10:17 -0500 Subject: System properties Message-ID: Are differences between current and Apple builds going to be addressed at some point? Are new values assumed to be what is currently considered correct? Should differences be bug reported? Are these considered differences that are up to whoever is managing the builds? (My java shell app listing system properties - I'm on a slightly older unofficial build yet) e.g. Java 6 set | grep encoding System.in:39:sun.jnu.encoding=MacRoman System.in:40:file.encoding.pkg=sun.io System.in:62:sun.io.unicode.encoding=UnicodeLittle System.in:116:file.encoding=MacRoman Java 7 set | grep encoding System.in:37:sun.jnu.encoding=US-ASCII System.in:38:file.encoding.pkg=sun.io System.in:62:sun.io.unicode.encoding=UnicodeBig System.in:111:file.encoding=US-ASCII From marco.dinacci at gmail.com Sun May 20 01:47:27 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Sun, 20 May 2012 09:47:27 +0100 Subject: Swing/AWT apps don't work inside a sandbox In-Reply-To: <53E11DDF-9A99-4ACE-B936-20C8ADF3856E@oracle.com> References: <53E11DDF-9A99-4ACE-B936-20C8ADF3856E@oracle.com> Message-ID: Yes I've my own build and I also have X11 installed. Without changing the Makefiles it doesn't pull it in and look for it using an absolute path even if you specify ALT_FREETYPE_HEADERS_PATH and ALT_FREETYPE_LIBS_PATH to point to your libfreetype build. I've found quicker for the moment to use install_name_tool as a workaround to change the path of libreetype inside libfontmanager.dylib from /usr/X11/libfreetype.6.dylib to @rpath/libfreetype.6.dylib after having copied in the lib manually. Marco On 19 May 2012 17:07, David DeHaven wrote: > >> because freetype is still not included for osx, any Java app that >> makes use of AWT/Swing won't work inside a sandbox as sandboxd will >> refuse loading the freetype system library: > > Are you using your own build of OpenJDK? If you have X11 installed it will pull in libfreetype when you build. The solution is to not build with X11, the process for which escapes me at the moment? > > -DrD- > From mik3hall at gmail.com Sun May 20 07:50:55 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 20 May 2012 09:50:55 -0500 Subject: System properties In-Reply-To: References: Message-ID: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> On May 20, 2012, at 8:08 AM, Andrew Thompson wrote: > The USASCII change in particular is going to cause spectacular breakage. Switching the UTF16 endianness is probably going to trip up non BOM using code too. I had just been looking at some native in working with OSType's. It used MacRoman in converting. I didn't think it should of. I remembered that MacRoman had been the java file.encoding and wondered if it still was. I have no idea myself what impact changing would have but thought the issue worth raising. From henri.gomez at gmail.com Sun May 20 12:32:04 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sun, 20 May 2012 21:32:04 +0200 Subject: Swing/AWT apps don't work inside a sandbox In-Reply-To: References: <53E11DDF-9A99-4ACE-B936-20C8ADF3856E@oracle.com> Message-ID: > Yes I've my own build and I also have X11 installed. Without changing > the Makefiles it doesn't pull it in and look for it using an absolute > path even if you specify ALT_FREETYPE_HEADERS_PATH and > ALT_FREETYPE_LIBS_PATH to point to your libfreetype build. > > I've found quicker for the moment to use install_name_tool as a > workaround to change the path of libreetype inside > libfontmanager.dylib from /usr/X11/libfreetype.6.dylib to > @rpath/libfreetype.6.dylib after having copied in the lib manually. I experimented the same, compiling freetype on my own. For now, openjdk-osx-build didn't use it but may in a near future From dmitry.cherepanov at oracle.com Mon May 21 04:22:16 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 21 May 2012 15:22:16 +0400 Subject: [8] request for review: 7160293: [macosx] FileDialog appears on secondary display Message-ID: <4FBA2568.7070609@oracle.com> Here's a patch for the problem - dialog appears on the wrong monitor. The minimal patch for this issue would be a one line change in nativeGetScreenNSWindowIsOn_AppKitThread (AWTWindow.m): - return 1; + return index; but the fix also includes some minor cleanup: http://cr.openjdk.java.net/~dcherepanov/7160293/webrev.0/ Thanks, Dmitry From andrew.brygin at oracle.com Mon May 21 04:24:58 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Mon, 21 May 2012 15:24:58 +0400 Subject: [8] request for review: 7160293: [macosx] FileDialog appears on secondary display In-Reply-To: <4FBA2568.7070609@oracle.com> References: <4FBA2568.7070609@oracle.com> Message-ID: <4FBA260A.4020004@oracle.com> The fix looks fine to me. Thanks, Andrew On 21.05.2012 15:22, Dmitry Cherepanov wrote: > Here's a patch for the problem - dialog appears on the wrong monitor. > > The minimal patch for this issue would be a one line change in > nativeGetScreenNSWindowIsOn_AppKitThread (AWTWindow.m): > > - return 1; > + return index; > > but the fix also includes some minor cleanup: > > http://cr.openjdk.java.net/~dcherepanov/7160293/webrev.0/ > > Thanks, > Dmitry > From artem.ananiev at oracle.com Mon May 21 04:50:46 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 21 May 2012 15:50:46 +0400 Subject: [8] request for review: 7160293: [macosx] FileDialog appears on secondary display In-Reply-To: <4FBA2568.7070609@oracle.com> References: <4FBA2568.7070609@oracle.com> Message-ID: <4FBA2C16.4070002@oracle.com> Looks fine. Thanks, Artem On 5/21/2012 3:22 PM, Dmitry Cherepanov wrote: > Here's a patch for the problem - dialog appears on the wrong monitor. > > The minimal patch for this issue would be a one line change in > nativeGetScreenNSWindowIsOn_AppKitThread (AWTWindow.m): > > - return 1; > + return index; > > but the fix also includes some minor cleanup: > > http://cr.openjdk.java.net/~dcherepanov/7160293/webrev.0/ > > Thanks, > Dmitry > From Sergey.Bylokhov at oracle.com Mon May 21 04:55:01 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 May 2012 15:55:01 +0400 Subject: [8] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() In-Reply-To: <4FB4F03F.4020606@oracle.com> References: <4FB4F03F.4020606@oracle.com> Message-ID: <4FBA2D15.50108@oracle.com> Hi, Andrew. Two questions: 1 Probably System.err.println("createFromImage: buffer: " + buffer); should be removed from CImage.createFromImage()? 2 I guess windows implementation uses images with width&height=0 as the correct image. Should we do the same? 17.05.2012 16:34, Andrew Brygin wrote: > Hello, > > could you please review a fix for 7146550? > > DnD code does not check whether a toolkit image is ready to be painted > into a buffer. We have to do this check in order to get correct image > dimension. > > Suggested fix just delegates the conversion of toolkit image into a > CImage instance to a helper class CImage.Creator. This helper class > provides two ways to convert a toolkit image int CImage: > > - immediate conversion: returns valid CImage only if toolkit image > has valid dimension, and null otherwise. > Immediate conversion works fine for toolkit images which are > prepared in advance, or are based on memory image source. > > - normal conversion: a toolkit image is prepared for rendering using > a media tracker. > > We can not use the normal conversion in case of DnD, because broken > toolkit image (whose producer never updates the image state for any > reasons) can cause a hang in the DnD the code (test in question > implements such scenario). > > If supplied drag image can not be conversed to CImage (either an > exception is thrown or it is not ready, i.e. a result of conversion > is null for any reasons) the InvalidDnDOperationException is thrown > in order to notify user about the problem with drag image. > Note that such approach is already used on windows platform, so with > this fix, macosx behaves in a uniform way with windows. > > Beside this, this fix pushes the drag image (an instance of CImage) > down to native DnD machinery in order to be able to display drag > images. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 > Webrev: http://cr.openjdk.java.net/~bae/7146550/webrev.00/ > > Thanks, > Andrew -- Best regards, Sergey. From andrew.brygin at oracle.com Mon May 21 05:07:19 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Mon, 21 May 2012 16:07:19 +0400 Subject: [8] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() In-Reply-To: <4FBA2D15.50108@oracle.com> References: <4FB4F03F.4020606@oracle.com> <4FBA2D15.50108@oracle.com> Message-ID: <4FBA2FF7.9040301@oracle.com> Hi Sergey, thanks for the review! I have updated the fix according to your comments: - debug output is removed, - image with zero dimension is accepted. Please take a look to updated webrev: http://cr.openjdk.java.net/~bae/7146550/webrev.01/ Thanks, Andrew On 21.05.2012 15:55, Sergey Bylokhov wrote: > Hi, Andrew. > Two questions: > 1 Probably System.err.println("createFromImage: buffer: " + buffer); > should be removed from CImage.createFromImage()? > 2 I guess windows implementation uses images with width&height=0 as > the correct image. Should we do the same? > > 17.05.2012 16:34, Andrew Brygin wrote: >> Hello, >> >> could you please review a fix for 7146550? >> >> DnD code does not check whether a toolkit image is ready to be painted >> into a buffer. We have to do this check in order to get correct image >> dimension. >> >> Suggested fix just delegates the conversion of toolkit image into a >> CImage instance to a helper class CImage.Creator. This helper class >> provides two ways to convert a toolkit image int CImage: >> >> - immediate conversion: returns valid CImage only if toolkit image >> has valid dimension, and null otherwise. >> Immediate conversion works fine for toolkit images which are >> prepared in advance, or are based on memory image source. >> >> - normal conversion: a toolkit image is prepared for rendering using >> a media tracker. >> >> We can not use the normal conversion in case of DnD, because broken >> toolkit image (whose producer never updates the image state for any >> reasons) can cause a hang in the DnD the code (test in question >> implements such scenario). >> >> If supplied drag image can not be conversed to CImage (either an >> exception is thrown or it is not ready, i.e. a result of conversion >> is null for any reasons) the InvalidDnDOperationException is thrown >> in order to notify user about the problem with drag image. >> Note that such approach is already used on windows platform, so with >> this fix, macosx behaves in a uniform way with windows. >> >> Beside this, this fix pushes the drag image (an instance of CImage) >> down to native DnD machinery in order to be able to display drag >> images. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 >> Webrev: http://cr.openjdk.java.net/~bae/7146550/webrev.00/ >> >> Thanks, >> Andrew > > From Sergey.Bylokhov at oracle.com Mon May 21 05:28:27 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 May 2012 16:28:27 +0400 Subject: [8] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() In-Reply-To: <4FBA2FF7.9040301@oracle.com> References: <4FB4F03F.4020606@oracle.com> <4FBA2D15.50108@oracle.com> <4FBA2FF7.9040301@oracle.com> Message-ID: <4FBA34EB.5020200@oracle.com> Hi. Andrew. Fix looks good. But I have another 2 question. 1 Is it possible to leak Graphics object in the CImage.imageToArray()? probably g2.dispose(); should be called in the finally block? 2 In the windows implementation ex.getMessage() added to "drag image creation problem:". Also exception text a bit different(dot and colon). 21.05.2012 16:07, Andrew Brygin wrote: > Hi Sergey, > > thanks for the review! > > I have updated the fix according to your comments: > - debug output is removed, > - image with zero dimension is accepted. > > Please take a look to updated webrev: > http://cr.openjdk.java.net/~bae/7146550/webrev.01/ > > Thanks, > Andrew > > On 21.05.2012 15:55, Sergey Bylokhov wrote: >> Hi, Andrew. >> Two questions: >> 1 Probably System.err.println("createFromImage: buffer: " + buffer); >> should be removed from CImage.createFromImage()? >> 2 I guess windows implementation uses images with width&height=0 as >> the correct image. Should we do the same? >> >> 17.05.2012 16:34, Andrew Brygin wrote: >>> Hello, >>> >>> could you please review a fix for 7146550? >>> >>> DnD code does not check whether a toolkit image is ready to be painted >>> into a buffer. We have to do this check in order to get correct image >>> dimension. >>> >>> Suggested fix just delegates the conversion of toolkit image into a >>> CImage instance to a helper class CImage.Creator. This helper class >>> provides two ways to convert a toolkit image int CImage: >>> >>> - immediate conversion: returns valid CImage only if toolkit image >>> has valid dimension, and null otherwise. >>> Immediate conversion works fine for toolkit images which are >>> prepared in advance, or are based on memory image source. >>> >>> - normal conversion: a toolkit image is prepared for rendering using >>> a media tracker. >>> >>> We can not use the normal conversion in case of DnD, because broken >>> toolkit image (whose producer never updates the image state for any >>> reasons) can cause a hang in the DnD the code (test in question >>> implements such scenario). >>> >>> If supplied drag image can not be conversed to CImage (either an >>> exception is thrown or it is not ready, i.e. a result of conversion >>> is null for any reasons) the InvalidDnDOperationException is thrown >>> in order to notify user about the problem with drag image. >>> Note that such approach is already used on windows platform, so with >>> this fix, macosx behaves in a uniform way with windows. >>> >>> Beside this, this fix pushes the drag image (an instance of CImage) >>> down to native DnD machinery in order to be able to display drag >>> images. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 >>> Webrev: http://cr.openjdk.java.net/~bae/7146550/webrev.00/ >>> >>> Thanks, >>> Andrew >> >> > -- Best regards, Sergey. From swingler at apple.com Mon May 21 07:34:38 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 21 May 2012 07:34:38 -0700 Subject: System properties In-Reply-To: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> Message-ID: <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> On May 20, 2012, at 7:50 AM, Michael Hall wrote: > On May 20, 2012, at 8:08 AM, Andrew Thompson wrote: > >> The USASCII change in particular is going to cause spectacular breakage. Switching the UTF16 endianness is probably going to trip up non BOM using code too. > > I had just been looking at some native in working with OSType's. It used MacRoman in converting. I didn't think it should of. I remembered that MacRoman had been the java file.encoding and wondered if it still was. I have no idea myself what impact changing would have but thought the issue worth raising. What I don't understand is why the encoding is US-ASCII instead of UTF-8. We should definitely not be trying to resurrect MacRoman, because the rest of OS X has basically moved on to UTF-8 or UTF-16. Anyone know why US-ASCII? This is probably worth a bug. Regards, Mike Swingler Apple Inc. From scott.kovatch at oracle.com Mon May 21 09:28:00 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 21 May 2012 20:28:00 +0400 Subject: System properties In-Reply-To: <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> Message-ID: <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> On May 21, 2012, at 6:34 PM, Mike Swingler wrote: > On May 20, 2012, at 7:50 AM, Michael Hall wrote: > >> On May 20, 2012, at 8:08 AM, Andrew Thompson wrote: >> >>> The USASCII change in particular is going to cause spectacular breakage. Switching the UTF16 endianness is probably going to trip up non BOM using code too. >> >> I had just been looking at some native in working with OSType's. It used MacRoman in converting. I didn't think it should of. I remembered that MacRoman had been the java file.encoding and wondered if it still was. I have no idea myself what impact changing would have but thought the issue worth raising. > > What I don't understand is why the encoding is US-ASCII instead of UTF-8. We should definitely not be trying to resurrect MacRoman, because the rest of OS X has basically moved on to UTF-8 or UTF-16. > > Anyone know why US-ASCII? This is probably worth a bug. I thought this looked fishy, too. I would have expected UTF-8 for file names, and the default format of text files. Please file a bug. -- Scott ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From lordpixel at mac.com Sun May 20 06:08:51 2012 From: lordpixel at mac.com (Andrew Thompson) Date: Sun, 20 May 2012 14:08:51 +0100 Subject: System properties In-Reply-To: References: Message-ID: The USASCII change in particular is going to cause spectacular breakage. Switching the UTF16 endianness is probably going to trip up non BOM using code too. On May 19, 2012, at 10:10 PM, Michael Hall wrote: > Are differences between current and Apple builds going to be addressed at some point? > Are new values assumed to be what is currently considered correct? > Should differences be bug reported? > Are these considered differences that are up to whoever is managing the builds? > (My java shell app listing system properties - I'm on a slightly older unofficial build yet) > > e.g. > Java 6 > set | grep encoding > System.in:39:sun.jnu.encoding=MacRoman > System.in:40:file.encoding.pkg=sun.io > System.in:62:sun.io.unicode.encoding=UnicodeLittle > System.in:116:file.encoding=MacRoman > > Java 7 > set | grep encoding > System.in:37:sun.jnu.encoding=US-ASCII > System.in:38:file.encoding.pkg=sun.io > System.in:62:sun.io.unicode.encoding=UnicodeBig > System.in:111:file.encoding=US-ASCII From jfinley at tech4learning.com Mon May 21 12:41:10 2012 From: jfinley at tech4learning.com (Jessica Finley) Date: Mon, 21 May 2012 13:41:10 -0600 Subject: Using JAWT CALayer with QT In-Reply-To: References: Message-ID: So, I've modified the project to not use the JavaVM framework, and to instead point to jdk1.7.0_06.jdk/Contents/Home/jre/include headers and associated libraries (libawt.dylib, libjawt.dylib). I left out the NativeDrawnCanvas.java and DrawingCanvas.m classes, since they use deprecated NSView based drawing. Additionally, I modified the awt.version in LayerCanvas.m to be awt.version = JAWT_VERSION_1_7 | JAWT_MACOSX_USE_CALAYER; // opt into the CALayer model Now, when I run the application, I no longer get the error ([java] JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM), but instead the canvas doesn't draw anything at all. I get no warnings about loading the resources for the layers or anything like that, so I'm assuming it's finding them (I made changes so instead of referencing the resources from the app bundle, they are referenced absolutely on the file system). Any ideas as to why nothing is being drawn at all? Let me know if you want my modified example project to take a look at. Has anyone gotten any sort of CALayer drawing working with Java 7? At this point, I'm not as much interested in QT specifics as much as just getting _something_ working. Thanks, Jess On May 17, 2012, at 3:55 PM, Jessica Finley wrote: > Hiya folks, > > It is my understanding that we are to use CALayer based embedding now instead of NSView based embedding. Can someone explain to me how to do so? Primarily, I am interested in playing a QT movie. I've been looking at the JAWTExample project located here: > > https://developer.apple.com/library/mac/#samplecode/JAWTExample/Introduction/Intro.html#//apple_ref/doc/uid/DTS10000683-Intro-DontLinkElementID_2 > > Which works beautifully in Java 6, but no so much in Java 7. When run in Java 7 (after some finagling to launch the jar outside of its app bundle so it will run in Java 7), I get the following error when trying to draw the included QT movie: > [java] JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM > > I'm not really sure why this doesn't work in Java 7, since it is using CALayer embedding, as it should? I think. > > Thanks! > -Jess From bley at ultramixer.com Mon May 21 12:15:20 2012 From: bley at ultramixer.com (Tobias Bley) Date: Mon, 21 May 2012 21:15:20 +0200 Subject: apple.awt.brushMetalLook client property not honoured in OpenJDK 1.7.0_04 In-Reply-To: <89F29BA3CEB748E2BA11F69C182A744B@gmail.com> References: <89F29BA3CEB748E2BA11F69C182A744B@gmail.com> Message-ID: Is there any solution available? -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com Am 20.04.2012 um 19:36 schrieb Steve McLeod : > (Sorry for the cross-post; I accidentally posted originally to the wrong list) > > I have this self-contained code example: > > import javax.swing.*; > import java.awt.*; > > public class ScratchSpace { > > public static void main(String[] args) { > System.out.println("javaVersion = " + System.getProperty("java.version")); > JToolBar toolBar = new JToolBar(); > toolBar.setFloatable(false); > toolBar.add(new JButton("Dummy")); > > JPanel contentPane = new JPanel(new BorderLayout()); > contentPane.add(toolBar, BorderLayout.NORTH); > contentPane.add(new JTextArea(20, 20), BorderLayout.CENTER); > > JFrame frame = new JFrame(); > frame.getRootPane().putClientProperty("apple.awt.brushMetalLook", Boolean.TRUE); > frame.setContentPane(contentPane); > frame.pack(); > frame.setLocationRelativeTo(null); > frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); > frame.setVisible(true); > } > > } > > In Apple's Java 6 on Lion, this gives me a "unified tool bar" appearance. > > On OpenJDK 1.7.0_04, I don't get the unified tool bar appearance. Instead the toolbar is a distinct different colour from the window title bar. > > > Regards, > > > > > > > Steve > > > --------------------------------------------------- > > > Steve McLeod > > > Founder, Poker Copilot > > > http://www.pokercopilot.com > > > > From mik3hall at gmail.com Mon May 21 14:21:52 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 21 May 2012 16:21:52 -0500 Subject: System properties In-Reply-To: <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> Message-ID: <6F38D236-1492-4A84-81A4-2B6B6A02C955@gmail.com> On May 21, 2012, at 11:28 AM, Scott Kovatch wrote: > On May 21, 2012, at 6:34 PM, Mike Swingler wrote: > >> On May 20, 2012, at 7:50 AM, Michael Hall wrote: >> >>> On May 20, 2012, at 8:08 AM, Andrew Thompson wrote: >>> >>>> The USASCII change in particular is going to cause spectacular breakage. Switching the UTF16 endianness is probably going to trip up non BOM using code too. >>> >>> I had just been looking at some native in working with OSType's. It used MacRoman in converting. I didn't think it should of. I remembered that MacRoman had been the java file.encoding and wondered if it still was. I have no idea myself what impact changing would have but thought the issue worth raising. >> >> What I don't understand is why the encoding is US-ASCII instead of UTF-8. We should definitely not be trying to resurrect MacRoman, because the rest of OS X has basically moved on to UTF-8 or UTF-16. >> >> Anyone know why US-ASCII? This is probably worth a bug. > > I thought this looked fishy, too. I would have expected UTF-8 for file names, and the default format of text files. > > Please file a bug. I can certainly file a bug report. To the more general question. Differences in System properties are then to be considered the Oracle/openjdk jvm changing to more current or more general options and are not a concern? Or it is reasonable to ask about them on a case by case basis? From mik3hall at gmail.com Mon May 21 14:39:09 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 21 May 2012 16:39:09 -0500 Subject: System properties In-Reply-To: <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> Message-ID: On May 21, 2012, at 11:28 AM, Scott Kovatch wrote: > I thought this looked fishy, too. I would have expected UTF-8 for file names, and the default format of text files. > > Please file a bug. And Mike Swingler earlier > What I don't understand is why the encoding is US-ASCII instead of UTF-8. We should definitely not be trying to resurrect MacRoman, because the rest of OS X has basically moved on to UTF-8 or UTF-16. > > Anyone know why US-ASCII? This is probably worth a bug. Just to be sure I"m understanding what is a bug about this. I am not filing a bug for what I was thinking which was that this is a change from prior jvm's that may cause broken or incorrect file reading where MacRoman differed from US-ASCII. But that UTF-8 or UTF-16 would be more appropriate replacements for the essentially deprecated MacRoman? My main question was if differences in System properties in general were subject to verification and testing along the same lines as coding changes or might something change that would have side effects and slip under the radar (No pun intended I assure you). From jfinley at tech4learning.com Mon May 21 14:55:19 2012 From: jfinley at tech4learning.com (Jessica Finley) Date: Mon, 21 May 2012 15:55:19 -0600 Subject: Using JAWT CALayer with QT In-Reply-To: References: Message-ID: Update for posterity: So, I changed the awt.version back to JAWT_VERSION_1_4 and referenced the instead of the JDK7 jawt_md.h (while continuing to link to the Java7 libs instead of the JavaVM framework) and it works! That seems odd to "mix and match" like that, but I suppose it makes sense. I need Apple's header to define some stuff for me, yet I need JDK 7's libraries to do the execution. Thanks, Jess On May 21, 2012, at 1:41 PM, Jessica Finley wrote: > So, I've modified the project to not use the JavaVM framework, and to instead point to jdk1.7.0_06.jdk/Contents/Home/jre/include headers and associated libraries (libawt.dylib, libjawt.dylib). I left out the NativeDrawnCanvas.java and DrawingCanvas.m classes, since they use deprecated NSView based drawing. Additionally, I modified the awt.version in LayerCanvas.m to be > awt.version = JAWT_VERSION_1_7 | JAWT_MACOSX_USE_CALAYER; // opt into the CALayer model > > Now, when I run the application, I no longer get the error ([java] JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM), but instead the canvas doesn't draw anything at all. I get no warnings about loading the resources for the layers or anything like that, so I'm assuming it's finding them (I made changes so instead of referencing the resources from the app bundle, they are referenced absolutely on the file system). > > Any ideas as to why nothing is being drawn at all? Let me know if you want my modified example project to take a look at. > > Has anyone gotten any sort of CALayer drawing working with Java 7? At this point, I'm not as much interested in QT specifics as much as just getting _something_ working. > > Thanks, > Jess > > > On May 17, 2012, at 3:55 PM, Jessica Finley wrote: > >> Hiya folks, >> >> It is my understanding that we are to use CALayer based embedding now instead of NSView based embedding. Can someone explain to me how to do so? Primarily, I am interested in playing a QT movie. I've been looking at the JAWTExample project located here: >> >> https://developer.apple.com/library/mac/#samplecode/JAWTExample/Introduction/Intro.html#//apple_ref/doc/uid/DTS10000683-Intro-DontLinkElementID_2 >> >> Which works beautifully in Java 6, but no so much in Java 7. When run in Java 7 (after some finagling to launch the jar outside of its app bundle so it will run in Java 7), I get the following error when trying to draw the included QT movie: >> [java] JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM >> >> I'm not really sure why this doesn't work in Java 7, since it is using CALayer embedding, as it should? I think. >> >> Thanks! >> -Jess > From xueming.shen at oracle.com Mon May 21 15:13:11 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 21 May 2012 15:13:11 -0700 Subject: System properties In-Reply-To: References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> Message-ID: <4FBABDF7.2050507@oracle.com> Whether or not this is a bug depends on your locale setting. If your locale is set to C locale, then the US-ASCII is the correct pick, if your locale is using UTF-8 as its encoding (I would assume this should be the default setting), then this property should be UTF-8. Command "locale" tells you your current locale setting and "locale -a" tells you all the choices. I'm still setting/upgrading my leopard, so I can't verify what JDK7 is doing with various locale settings, but I don't see any thing special in prop_md.c... -Sherman On 5/21/2012 2:39 PM, Michael Hall wrote: > On May 21, 2012, at 11:28 AM, Scott Kovatch wrote: > >> I thought this looked fishy, too. I would have expected UTF-8 for file names, and the default format of text files. >> >> Please file a bug. > > And Mike Swingler earlier > >> What I don't understand is why the encoding is US-ASCII instead of UTF-8. We should definitely not be trying to resurrect MacRoman, because the rest of OS X has basically moved on to UTF-8 or UTF-16. >> >> Anyone know why US-ASCII? This is probably worth a bug. > Just to be sure I"m understanding what is a bug about this. > I am not filing a bug for what I was thinking which was that this is a change from prior jvm's that may cause broken or incorrect file reading where MacRoman differed from US-ASCII. > But that UTF-8 or UTF-16 would be more appropriate replacements for the essentially deprecated MacRoman? > My main question was if differences in System properties in general were subject to verification and testing along the same lines as coding changes or might something change that would have side effects and slip under the radar (No pun intended I assure you). > > From mik3hall at gmail.com Mon May 21 15:35:37 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 21 May 2012 17:35:37 -0500 Subject: System properties In-Reply-To: <4FBABDF7.2050507@oracle.com> References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> <4FBABDF7.2050507@oracle.com> Message-ID: <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> On May 21, 2012, at 5:13 PM, Xueming Shen wrote: > Whether or not this is a bug depends on your locale setting. If your locale is set to C locale, > then the US-ASCII is the correct pick, if your locale is using UTF-8 as its encoding (I would > assume this should be the default setting), then this property should be UTF-8. Command > "locale" tells you your current locale setting and "locale -a" tells you all the choices. I'm > still setting/upgrading my leopard, so I can't verify what JDK7 is doing with various locale > settings, but I don't see any thing special in prop_md.c... locale LANG="en_US.UTF-8" and a number of LC_ attributes(?) also set to en_US.UTF-8. So file.encoding=US-ASCII would be right. So this change is a feature not a bug, it now uses the more appropriate locale setting rather than a hardcoded MacRoman? From mik3hall at gmail.com Mon May 21 16:02:06 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 21 May 2012 18:02:06 -0500 Subject: System properties In-Reply-To: References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> <4FBABDF7.2050507@oracle.com> <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> Message-ID: On May 21, 2012, at 5:55 PM, Andrew Thompson wrote: > A lot of time has now passed, so UTF8 is probably a better default. But really, does Apple's Java 6 report MacRoman for the default encoding on a US English system even today? If so changing it in 7 will break some existing apps. Yes, it is the encoding to this day on Java 6 set java.version java.version=1.6.0_31 set file.encoding file.encoding=MacRoman From xueming.shen at oracle.com Mon May 21 17:26:45 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 21 May 2012 17:26:45 -0700 Subject: System properties In-Reply-To: <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> <4FBABDF7.2050507@oracle.com> <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> Message-ID: <4FBADD45.3000600@oracle.com> I tried both 7u4 and 7u6 on my Leopard (I would not expect any difference if on Lion), in en_US.UTF-8 locale, both report the file.encoding as UTF-8, which I think is correct. (it reports US-ASCII if run in C/PROSIX). I don't see a problem here. Yes, Apple's jdk6 does report MacRoman when run in en_US.UTF-8 locale, which I would assume is problematic. -Sherman On 5/21/12 3:35 PM, Michael Hall wrote: > On May 21, 2012, at 5:13 PM, Xueming Shen wrote: > >> Whether or not this is a bug depends on your locale setting. If your locale is set to C locale, >> then the US-ASCII is the correct pick, if your locale is using UTF-8 as its encoding (I would >> assume this should be the default setting), then this property should be UTF-8. Command >> "locale" tells you your current locale setting and "locale -a" tells you all the choices. I'm >> still setting/upgrading my leopard, so I can't verify what JDK7 is doing with various locale >> settings, but I don't see any thing special in prop_md.c... > locale > LANG="en_US.UTF-8" > > and a number of LC_ attributes(?) also set to en_US.UTF-8. > So file.encoding=US-ASCII would be right. > So this change is a feature not a bug, it now uses the more appropriate locale setting rather than a hardcoded MacRoman? > > From mik3hall at gmail.com Mon May 21 18:14:48 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 21 May 2012 20:14:48 -0500 Subject: System properties In-Reply-To: <4FBADD45.3000600@oracle.com> References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> <4FBABDF7.2050507@oracle.com> <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> <4FBADD45.3000600@oracle.com> Message-ID: On May 21, 2012, at 7:26 PM, Xueming Shen wrote: > (it reports US-ASCII if run in C/PROSIX). I don't see a problem here. I'm not sure what 'run in C/PROSIX' is but maybe thats the difference here. Otherwise it's most likely my build versus yours/Oracle's. From what you're saying I don't see the need for a bug report yet. Unless somehow I'm picking up US-ASCII in a situation where I shouldn't be. The setting probably isn't going to be changed back to MacRoman although this may have isolated problems. So point in a 'not MacRoman' bug report. Once I have a official Oracle build installed, which should be this week sometime, I'll see if I switch to UTF-8 as my file.encoding setting otherwise if I remain US-ASCII and am not supposed to be C/PROSIX I'll bug report. So the only thing I'm not entirely clear on yet is when should I or shouldn't I be C/PROSIX? From xueming.shen at oracle.com Mon May 21 18:59:45 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 21 May 2012 18:59:45 -0700 Subject: System properties In-Reply-To: References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> <4FBABDF7.2050507@oracle.com> <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> <4FBADD45.3000600@oracle.com> Message-ID: <4FBAF311.70609@oracle.com> My apology, I mean if run jvm in C or POSIX locale, the file.encoding is set to US-ASCII by Oracle 7u4/7u6, which is expected. -Sherman On 5/21/2012 6:14 PM, Michael Hall wrote: > > On May 21, 2012, at 7:26 PM, Xueming Shen wrote: > >> (it reports US-ASCII if run in C/PROSIX). I don't see a problem here. > > I'm not sure what 'run in C/PROSIX' is but maybe thats the difference > here. Otherwise it's most likely my build versus yours/Oracle's. > From what you're saying I don't see the need for a bug report yet. > Unless somehow I'm picking up US-ASCII in a situation where I > shouldn't be. > The setting probably isn't going to be changed back to MacRoman > although this may have isolated problems. So point in a 'not MacRoman' > bug report. > Once I have a official Oracle build installed, which should be this > week sometime, I'll see if I switch to UTF-8 as my file.encoding > setting otherwise if I remain US-ASCII and am not supposed to be > C/PROSIX I'll bug report. > So the only thing I'm not entirely clear on yet is when should I or > shouldn't I be C/PROSIX? From mik3hall at gmail.com Mon May 21 19:29:10 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 21 May 2012 21:29:10 -0500 Subject: System properties In-Reply-To: <4FBAF311.70609@oracle.com> References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> <4FBABDF7.2050507@oracle.com> <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> <4FBADD45.3000600@oracle.com> <4FBAF311.70609@oracle.com> Message-ID: On May 21, 2012, at 8:59 PM, Xueming Shen wrote: > My apology, I mean if run jvm in C or POSIX locale, the file.encoding is set to US-ASCII by Oracle 7u4/7u6, which > is expected. OK, I'm finding some information on this. I will have to do some more follow up reading up on this to determine what locale applies to my running of the jvm unless someone happens to know? I guess as you say it still comes down to whether or not this should be in effect. That is the jvm is run with the C locale, then no bug report for file.encoding US-ASCII. If not, my locale should not be C/POSIX, then there should be a bug report as I should be UTF-8. Again, MacRoman no longer applies, period, which was what I originally questioned. But the rationale for the change pertaining to locale is interesting. From andrew.brygin at oracle.com Tue May 22 01:14:07 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Tue, 22 May 2012 12:14:07 +0400 Subject: [8] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() In-Reply-To: <4FBA34EB.5020200@oracle.com> References: <4FB4F03F.4020606@oracle.com> <4FBA2D15.50108@oracle.com> <4FBA2FF7.9040301@oracle.com> <4FBA34EB.5020200@oracle.com> Message-ID: <4FBB4ACF.2050103@oracle.com> Hi Sergey, please see my comments inline. On 21.05.2012 16:28, Sergey Bylokhov wrote: > Hi. Andrew. > Fix looks good. > But I have another 2 question. > 1 Is it possible to leak Graphics object in the CImage.imageToArray()? > probably g2.dispose(); should be called in the finally block? I do not think so: the toolkit image which we are going to draw is already prepared and has a good state, so I do not see why do we need a finally block here. Could you please explain in more details what scenario do you have in mind? It is not a bug deal to add a finally block here, but we have be able to prevent a leak even if dispose() method was not invoked, because the spec does not make such claims. If we strongly need it to be called, I think we are in trouble... > 2 In the windows implementation ex.getMessage() added to "drag image > creation problem:". Also exception text a bit different(dot and colon). It is a statement. What is the question? Would you like to see the exception message to be exactly same as on windows? Looking for two next questions :) Thanks, Andrew > > > 21.05.2012 16:07, Andrew Brygin wrote: >> Hi Sergey, >> >> thanks for the review! >> >> I have updated the fix according to your comments: >> - debug output is removed, >> - image with zero dimension is accepted. >> >> Please take a look to updated webrev: >> http://cr.openjdk.java.net/~bae/7146550/webrev.01/ >> >> Thanks, >> Andrew >> >> On 21.05.2012 15:55, Sergey Bylokhov wrote: >>> Hi, Andrew. >>> Two questions: >>> 1 Probably System.err.println("createFromImage: buffer: " + >>> buffer); should be removed from CImage.createFromImage()? >>> 2 I guess windows implementation uses images with width&height=0 as >>> the correct image. Should we do the same? >>> >>> 17.05.2012 16:34, Andrew Brygin wrote: >>>> Hello, >>>> >>>> could you please review a fix for 7146550? >>>> >>>> DnD code does not check whether a toolkit image is ready to be >>>> painted >>>> into a buffer. We have to do this check in order to get correct image >>>> dimension. >>>> >>>> Suggested fix just delegates the conversion of toolkit image into a >>>> CImage instance to a helper class CImage.Creator. This helper class >>>> provides two ways to convert a toolkit image int CImage: >>>> >>>> - immediate conversion: returns valid CImage only if toolkit image >>>> has valid dimension, and null otherwise. >>>> Immediate conversion works fine for toolkit images which are >>>> prepared in advance, or are based on memory image source. >>>> >>>> - normal conversion: a toolkit image is prepared for rendering >>>> using >>>> a media tracker. >>>> >>>> We can not use the normal conversion in case of DnD, because broken >>>> toolkit image (whose producer never updates the image state for any >>>> reasons) can cause a hang in the DnD the code (test in question >>>> implements such scenario). >>>> >>>> If supplied drag image can not be conversed to CImage (either an >>>> exception is thrown or it is not ready, i.e. a result of conversion >>>> is null for any reasons) the InvalidDnDOperationException is thrown >>>> in order to notify user about the problem with drag image. >>>> Note that such approach is already used on windows platform, so with >>>> this fix, macosx behaves in a uniform way with windows. >>>> >>>> Beside this, this fix pushes the drag image (an instance of CImage) >>>> down to native DnD machinery in order to be able to display drag >>>> images. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 >>>> Webrev: http://cr.openjdk.java.net/~bae/7146550/webrev.00/ >>>> >>>> Thanks, >>>> Andrew >>> >>> >> > > From lordpixel at mac.com Mon May 21 15:55:34 2012 From: lordpixel at mac.com (Andrew Thompson) Date: Mon, 21 May 2012 23:55:34 +0100 Subject: System properties In-Reply-To: <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> <4FBABDF7.2050507@oracle.com> <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> Message-ID: At one point I recall Apple stating they picked the default encodings for the JVM on the basis of what was most likely to work. Around the time of the transition to OSX most plaintext files coming from English os9 machines would have been MacRoman. So unless my memory fails me MacRoman was the default at some point, because that would work best for those files, but whether MacRoman was ever the default on OSX or just on 9 I don't recall. A lot of time has now passed, so UTF8 is probably a better default. But really, does Apple's Java 6 report MacRoman for the default encoding on a US English system even today? If so changing it in 7 will break some existing apps. On May 21, 2012, at 11:35 PM, Michael Hall wrote: > > On May 21, 2012, at 5:13 PM, Xueming Shen wrote: > >> Whether or not this is a bug depends on your locale setting. If your locale is set to C locale, >> then the US-ASCII is the correct pick, if your locale is using UTF-8 as its encoding (I would >> assume this should be the default setting), then this property should be UTF-8. Command >> "locale" tells you your current locale setting and "locale -a" tells you all the choices. I'm >> still setting/upgrading my leopard, so I can't verify what JDK7 is doing with various locale >> settings, but I don't see any thing special in prop_md.c... > > locale > LANG="en_US.UTF-8" > > and a number of LC_ attributes(?) also set to en_US.UTF-8. > So file.encoding=US-ASCII would be right. > So this change is a feature not a bug, it now uses the more appropriate locale setting rather than a hardcoded MacRoman? > > From Sergey.Bylokhov at oracle.com Tue May 22 05:48:45 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 May 2012 16:48:45 +0400 Subject: [8] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() In-Reply-To: <4FBB4ACF.2050103@oracle.com> References: <4FB4F03F.4020606@oracle.com> <4FBA2D15.50108@oracle.com> <4FBA2FF7.9040301@oracle.com> <4FBA34EB.5020200@oracle.com> <4FBB4ACF.2050103@oracle.com> Message-ID: <4FBB8B2D.7080200@oracle.com> 22.05.2012 12:14, Andrew Brygin wrote: > Hi Sergey, > > please see my comments inline. > On 21.05.2012 16:28, Sergey Bylokhov wrote: >> Hi. Andrew. >> Fix looks good. >> But I have another 2 question. >> 1 Is it possible to leak Graphics object in the >> CImage.imageToArray()? probably g2.dispose(); should be called in the >> finally block? > I do not think so: the toolkit image which we are going to draw is > already prepared and has a good state, > so I do not see why do we need a finally block here. Could you please > explain in more details what scenario > do you have in mind? > > It is not a bug deal to add a finally block here, but we have be able > to prevent a leak even if dispose() method > was not invoked, because the spec does not make such claims. If we > strongly need it to be called, I think we > are in trouble... > >> 2 In the windows implementation ex.getMessage() added to "drag image >> creation problem:". Also exception text a bit different(dot and colon). > It is a statement. What is the question? Would you like to see the > exception message to be exactly same as on windows? yes, if there is no reason to have different messages. > > Looking for two next questions :) > > Thanks, > Andrew >> >> >> 21.05.2012 16:07, Andrew Brygin wrote: >>> Hi Sergey, >>> >>> thanks for the review! >>> >>> I have updated the fix according to your comments: >>> - debug output is removed, >>> - image with zero dimension is accepted. >>> >>> Please take a look to updated webrev: >>> http://cr.openjdk.java.net/~bae/7146550/webrev.01/ >>> >>> Thanks, >>> Andrew >>> >>> On 21.05.2012 15:55, Sergey Bylokhov wrote: >>>> Hi, Andrew. >>>> Two questions: >>>> 1 Probably System.err.println("createFromImage: buffer: " + >>>> buffer); should be removed from CImage.createFromImage()? >>>> 2 I guess windows implementation uses images with width&height=0 as >>>> the correct image. Should we do the same? >>>> >>>> 17.05.2012 16:34, Andrew Brygin wrote: >>>>> Hello, >>>>> >>>>> could you please review a fix for 7146550? >>>>> >>>>> DnD code does not check whether a toolkit image is ready to be >>>>> painted >>>>> into a buffer. We have to do this check in order to get correct >>>>> image >>>>> dimension. >>>>> >>>>> Suggested fix just delegates the conversion of toolkit image into a >>>>> CImage instance to a helper class CImage.Creator. This helper class >>>>> provides two ways to convert a toolkit image int CImage: >>>>> >>>>> - immediate conversion: returns valid CImage only if toolkit image >>>>> has valid dimension, and null otherwise. >>>>> Immediate conversion works fine for toolkit images which are >>>>> prepared in advance, or are based on memory image source. >>>>> >>>>> - normal conversion: a toolkit image is prepared for rendering >>>>> using >>>>> a media tracker. >>>>> >>>>> We can not use the normal conversion in case of DnD, because broken >>>>> toolkit image (whose producer never updates the image state for any >>>>> reasons) can cause a hang in the DnD the code (test in question >>>>> implements such scenario). >>>>> >>>>> If supplied drag image can not be conversed to CImage (either an >>>>> exception is thrown or it is not ready, i.e. a result of conversion >>>>> is null for any reasons) the InvalidDnDOperationException is thrown >>>>> in order to notify user about the problem with drag image. >>>>> Note that such approach is already used on windows platform, so with >>>>> this fix, macosx behaves in a uniform way with windows. >>>>> >>>>> Beside this, this fix pushes the drag image (an instance of CImage) >>>>> down to native DnD machinery in order to be able to display drag >>>>> images. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 >>>>> Webrev: http://cr.openjdk.java.net/~bae/7146550/webrev.00/ >>>>> >>>>> Thanks, >>>>> Andrew >>>> >>>> >>> >> >> > -- Best regards, Sergey. From marco.dinacci at gmail.com Tue May 22 06:22:17 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Tue, 22 May 2012 14:22:17 +0100 Subject: Crash in OSXAPP_SetApplicationDelegate Message-ID: Hi, I've a Swing application that I packaged as a Mac bundle (.app). If I open the .app the application by dbl-clicking on its icon it works perfectly fine but if I open it by clicking on a registered file or from a terminal by writing: $ open -a myapp file the jvm crash in OSXAPP_SetApplicationDelegate. I just submitted a bug, which will be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170716 The problem is not in my app as I can reproduce it with a simple test case with just one line of AWT code. I paste here some debug informations from the log: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff8d05ece2 __pthread_kill + 10 1 libsystem_c.dylib 0x00007fff86daf7d2 pthread_kill + 95 2 libsystem_c.dylib 0x00007fff86da0a7a abort + 143 3 libjvm.dylib 0x000000010c795439 os::abort(bool) + 25 4 libjvm.dylib 0x000000010c881690 VMError::report_and_die() + 2306 5 libjvm.dylib 0x000000010c796b15 JVM_handle_bsd_signal + 1047 6 libsystem_c.dylib 0x00007fff86e01cfa _sigtramp + 26 7 ??? 0x000000010c11de00 0 + 4497464832 8 libosxapp.dylib 0x0000000115ca25fc OSXAPP_SetApplicationDelegate + 153 9 liblwawt.dylib 0x0000000115bff02b __+[AWTStarter start:swtMode:swtModeForWebStart:]_block_invoke_1 + 111 10 JavaNativeFoundation 0x00000001153c1545 +[JNFRunLoop _performDirectBlock:] + 12 Any informations on how to fix this problem are very welcome. Thanks, Marco From Sergey.Bylokhov at oracle.com Tue May 22 06:37:20 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 22 May 2012 17:37:20 +0400 Subject: apple.awt.brushMetalLook client property not honoured in OpenJDK 1.7.0_04 In-Reply-To: References: <89F29BA3CEB748E2BA11F69C182A744B@gmail.com> Message-ID: <4FBB9690.1030200@oracle.com> Hi, Tobias. Current plan is to fix it in jdk7u6. 21.05.2012 23:15, Tobias Bley wrote > Is there any solution available? > -- Best regards, Sergey. From anthony.petrov at oracle.com Tue May 22 06:50:17 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 May 2012 17:50:17 +0400 Subject: Crash in OSXAPP_SetApplicationDelegate In-Reply-To: References: Message-ID: <4FBB9999.3070002@oracle.com> Hi Marco, Thanks for the heads-up. This actually looks like a bug in AWT code. We'll look into it. -- best regards, Anthony On 5/22/2012 5:22 PM, Marco Dinacci wrote: > Hi, > > I've a Swing application that I packaged as a Mac bundle (.app). If I > open the .app the application by dbl-clicking on its icon it works > perfectly fine but if I open it by clicking on a registered file or > from a terminal by writing: > > $ open -a myapp file > > the jvm crash in OSXAPP_SetApplicationDelegate. > > I just submitted a bug, which will be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170716 > The problem is not in my app as I can reproduce it with a simple test > case with just one line of AWT code. > > I paste here some debug informations from the log: > > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 libsystem_kernel.dylib 0x00007fff8d05ece2 __pthread_kill + 10 > 1 libsystem_c.dylib 0x00007fff86daf7d2 pthread_kill + 95 > 2 libsystem_c.dylib 0x00007fff86da0a7a abort + 143 > 3 libjvm.dylib 0x000000010c795439 os::abort(bool) + 25 > 4 libjvm.dylib 0x000000010c881690 > VMError::report_and_die() + 2306 > 5 libjvm.dylib 0x000000010c796b15 > JVM_handle_bsd_signal + 1047 > 6 libsystem_c.dylib 0x00007fff86e01cfa _sigtramp + 26 > 7 ??? 0x000000010c11de00 0 + 4497464832 > 8 libosxapp.dylib 0x0000000115ca25fc > OSXAPP_SetApplicationDelegate + 153 > 9 liblwawt.dylib 0x0000000115bff02b __+[AWTStarter > start:swtMode:swtModeForWebStart:]_block_invoke_1 + 111 > 10 JavaNativeFoundation 0x00000001153c1545 +[JNFRunLoop > _performDirectBlock:] + 12 > > > Any informations on how to fix this problem are very welcome. > > Thanks, > Marco From anthony.petrov at oracle.com Tue May 22 06:55:06 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 May 2012 17:55:06 +0400 Subject: Crash in OSXAPP_SetApplicationDelegate In-Reply-To: <4FBB9999.3070002@oracle.com> References: <4FBB9999.3070002@oracle.com> Message-ID: <4FBB9ABA.7080904@oracle.com> I hit the Send button too soon. Just wanted to ask you: could you provide the shortest possible test code and exact instructions on how to bundle it, so that we could try and reproduce this issue locally? Thanks in advance! -- best regards, Anthony On 5/22/2012 5:50 PM, Anthony Petrov wrote: > Hi Marco, > > Thanks for the heads-up. This actually looks like a bug in AWT code. > We'll look into it. > > -- > best regards, > Anthony > > On 5/22/2012 5:22 PM, Marco Dinacci wrote: >> Hi, >> >> I've a Swing application that I packaged as a Mac bundle (.app). If I >> open the .app the application by dbl-clicking on its icon it works >> perfectly fine but if I open it by clicking on a registered file or >> from a terminal by writing: >> >> $ open -a myapp file >> >> the jvm crash in OSXAPP_SetApplicationDelegate. >> >> I just submitted a bug, which will be found here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170716 >> The problem is not in my app as I can reproduce it with a simple test >> case with just one line of AWT code. >> >> I paste here some debug informations from the log: >> >> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >> 0 libsystem_kernel.dylib 0x00007fff8d05ece2 >> __pthread_kill + 10 >> 1 libsystem_c.dylib 0x00007fff86daf7d2 pthread_kill >> + 95 >> 2 libsystem_c.dylib 0x00007fff86da0a7a abort + 143 >> 3 libjvm.dylib 0x000000010c795439 >> os::abort(bool) + 25 >> 4 libjvm.dylib 0x000000010c881690 >> VMError::report_and_die() + 2306 >> 5 libjvm.dylib 0x000000010c796b15 >> JVM_handle_bsd_signal + 1047 >> 6 libsystem_c.dylib 0x00007fff86e01cfa _sigtramp + 26 >> 7 ??? 0x000000010c11de00 0 + 4497464832 >> 8 libosxapp.dylib 0x0000000115ca25fc >> OSXAPP_SetApplicationDelegate + 153 >> 9 liblwawt.dylib 0x0000000115bff02b __+[AWTStarter >> start:swtMode:swtModeForWebStart:]_block_invoke_1 + 111 >> 10 JavaNativeFoundation 0x00000001153c1545 +[JNFRunLoop >> _performDirectBlock:] + 12 >> >> >> Any informations on how to fix this problem are very welcome. >> >> Thanks, >> Marco From marco.dinacci at gmail.com Tue May 22 07:24:15 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Tue, 22 May 2012 15:24:15 +0100 Subject: Crash in OSXAPP_SetApplicationDelegate In-Reply-To: <4FBB9ABA.7080904@oracle.com> References: <4FBB9999.3070002@oracle.com> <4FBB9ABA.7080904@oracle.com> Message-ID: Hi Anthony, > Just wanted to ask you: could you provide the shortest possible test code > and exact instructions on how to bundle it, so that we could try and > reproduce this issue locally? Thanks in advance! Here below the shortest possible test code I could do. You need appbundler to build the .app and you need to set the ${runtime} property in the ant file to point to your OpenJDK build. Then in a terminal just type "ant" and after a few seconds you should have SwingTest.app in the same dir. Then create a test file say test.zzz and open the app by typing: $ open -a SwingTest.app test.zzz Alternatively, you can specify the app to register with all zzz files and then just type open test.zzz or double click on any zzz file. To do it, attach this XML inside the plist file in SwingTest.app/Contents/Info.plist CFBundleDocumentTypes CFBundleTypeExtensions zzz CFBundleTypeName ZZZ Data CFBundleTypeRole Viewer === SwingTest.java === public class SwingTest { public static void main(String[] args) { Toolkit t = Toolkit.getDefaultToolkit(); } } === build.xml === == MANIFEST.TXT == Main-Class: SwingTest Thanks for looking into this, let me know if I can do anything else to help. Best, Marco From leonid.romanov at oracle.com Wed May 23 06:26:21 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 23 May 2012 17:26:21 +0400 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons Message-ID: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> Hi, Please review a fix for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons. This is about using new Oracle Java branded icon as the default icon for Java apps instead of the Apple supplied icon found in /System/Library/Frameworks/JavaVM.framework. I've discussed this bug with Artem Ananiev and we decided that the best way to do it is to convert icon file to .h file with icon data as an array of bytes and then include this .h file where icon data is needed. So, we basically compile in icon data into the binaries. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168062 Webrev: http://cr.openjdk.java.net/~leonidr/7168062/webrev.00/ Thanks, Leonid. From leonid.romanov at oracle.com Wed May 23 06:35:37 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 23 May 2012 17:35:37 +0400 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> Message-ID: <51783A11-AA0E-477E-89F1-5F7953C70DF2@oracle.com> A little followup: the icon file itself is located at jdk/src/macosx/native/sun/osxapp/resource/icons On 23.05.2012, at 17:26, Leonid Romanov wrote: > Hi, > Please review a fix for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons. This is about using new Oracle Java branded icon as the default icon for Java apps instead of the Apple supplied icon found in /System/Library/Frameworks/JavaVM.framework. > I've discussed this bug with Artem Ananiev and we decided that the best way to do it is to convert icon file to .h file with icon data as an array of bytes and then include this .h file where icon data is needed. So, we basically compile in icon data into the binaries. > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168062 > Webrev: http://cr.openjdk.java.net/~leonidr/7168062/webrev.00/ > > Thanks, > Leonid. > From scott.kovatch at oracle.com Wed May 23 07:39:58 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 23 May 2012 18:39:58 +0400 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> Message-ID: On May 23, 2012, at 5:26 PM, Leonid Romanov wrote: > Hi, > Please review a fix for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons. This is about using new Oracle Java branded icon as the default icon for Java apps instead of the Apple supplied icon found in /System/Library/Frameworks/JavaVM.framework. > I've discussed this bug with Artem Ananiev and we decided that the best way to do it is to convert icon file to .h file with icon data as an array of bytes and then include this .h file where icon data is needed. So, we basically compile in icon data into the binaries. That seems like overkill to me. Can't we just put the .icns in the JRE (Contents/Home/jre/lib/images) and load it from there? What are we guarding against by putting it into a .h file? -- Scott ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From henri.gomez at gmail.com Wed May 23 08:25:10 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 23 May 2012 08:25:10 -0700 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> Message-ID: > That seems like overkill to me. Can't we just put the .icns in the JRE (Contents/Home/jre/lib/images) and load it from there? What are we guarding against by putting it into a .h file? OpenJDK will use Oracle icons ? Even for the community version ? From scott.kovatch at oracle.com Wed May 23 08:29:21 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 23 May 2012 19:29:21 +0400 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> Message-ID: On May 23, 2012, at 7:25 PM, Henri Gomez wrote: >> That seems like overkill to me. Can't we just put the .icns in the JRE (Contents/Home/jre/lib/images) and load it from there? What are we guarding against by putting it into a .h file? > > OpenJDK will use Oracle icons ? Even for the community version ? We don't want to use the Apple java icons. It doesn't have 'Oracle' or anything like that on it -- it's just the generic steaming coffee cup in orange and blue. In fact, I believe it is already in use as the bundle icon for the JDK. -- Scott From henri.gomez at gmail.com Wed May 23 08:36:19 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 23 May 2012 08:36:19 -0700 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> Message-ID: > We don't want to use the Apple java icons. It doesn't have 'Oracle' or anything like that on it -- it's just the generic steaming coffee cup in orange and blue. In fact, I believe it is already in use as the bundle icon for the JDK. Ok Scott. Didn't see any icon (.icns) under Contents/Home/jre/lib/images (OpenJDK / Oracle JDK). Only notice an icon for visualvm in Oracle JDK. From philip.race at oracle.com Wed May 23 08:41:33 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 23 May 2012 08:41:33 -0700 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> Message-ID: <4FBD052D.7080101@oracle.com> On 5/23/2012 8:25 AM, Henri Gomez wrote: >> That seems like overkill to me. Can't we just put the .icns in the JRE (Contents/Home/jre/lib/images) and load it from there? What are we guarding against by putting it into a .h file? > OpenJDK will use Oracle icons ? Even for the community version ? I was wondering about this too. It seems wrong. The icon, and/or the header file should be in "closed". We do not put branded images in the open tree, no matter how its encoded since they aren't open source. The openjdk should use something like the open source duke icon. I am not sure I see how/where that works. BTW good luck seeing > Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168062 its marked for internal consumption only (for some reason I can't fathom). -phil. From philip.race at oracle.com Wed May 23 08:45:17 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 23 May 2012 08:45:17 -0700 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> Message-ID: <4FBD060D.5090604@oracle.com> We shouldn't use the Apple one obviously. We can use the steaming coffee cup for the Oracle JDK but *not* for the openjdk. Duke was open sourced for use by open jdk but not the coffee cup one .. -phil. On 5/23/2012 8:29 AM, Scott Kovatch wrote: > On May 23, 2012, at 7:25 PM, Henri Gomez wrote: > >>> That seems like overkill to me. Can't we just put the .icns in the JRE (Contents/Home/jre/lib/images) and load it from there? What are we guarding against by putting it into a .h file? >> OpenJDK will use Oracle icons ? Even for the community version ? > We don't want to use the Apple java icons. It doesn't have 'Oracle' or anything like that on it -- it's just the generic steaming coffee cup in orange and blue. In fact, I believe it is already in use as the bundle icon for the JDK. > > -- Scott > From alexander.zuev at oracle.com Wed May 23 09:51:54 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 23 May 2012 20:51:54 +0400 Subject: [7u6] Please review my fix for 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock Message-ID: <4FBD15AA.7060206@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/webrev.00/ With best regards, Alexander Zuev From steve.x.northover at oracle.com Wed May 23 10:21:44 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 23 May 2012 13:21:44 -0400 Subject: [7u6] Please review my fix for 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock In-Reply-To: <4FBD15AA.7060206@oracle.com> References: <4FBD15AA.7060206@oracle.com> Message-ID: <4FBD1CA8.8080703@oracle.com> The implementation matches how these methods are used by drag and drop but the naming makes no sense. Who else calls these methods? I'm assuming nobody (or that they are all called with the same implementation in mind). startNativeNestedEventLoop is really "read and dispatch an event without blocking". Steve On 23/05/2012 12:51 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/webrev.00/ > > With best regards, > Alexander Zuev From alexander.zuev at oracle.com Wed May 23 11:11:37 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 23 May 2012 22:11:37 +0400 Subject: [7u6] Please review my fix for 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock In-Reply-To: <4FBD1CA8.8080703@oracle.com> References: <4FBD15AA.7060206@oracle.com> <4FBD1CA8.8080703@oracle.com> Message-ID: <4FBD2859.9010000@oracle.com> Steve, you are absolutely right - this native method is used only by our implementation of the DnD so i may just rename it and the only reason i have not done it is to minimize the scope of the change. So if you think renaming the method is required i will gladly do it. With best regards, Alex On 5/23/12 21:21, steve.x.northover at oracle.com wrote: > The implementation matches how these methods are used by drag and drop > but the naming makes no sense. Who else calls these methods? I'm > assuming nobody (or that they are all called with the same > implementation in mind). > > startNativeNestedEventLoop is really "read and dispatch an event > without blocking". > > Steve > > On 23/05/2012 12:51 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/webrev.00/ >> >> With best regards, >> Alexander Zuev From steve.x.northover at oracle.com Wed May 23 11:26:27 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 23 May 2012 14:26:27 -0400 Subject: [7u6] Please review my fix for 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock In-Reply-To: <4FBD2859.9010000@oracle.com> References: <4FBD15AA.7060206@oracle.com> <4FBD1CA8.8080703@oracle.com> <4FBD2859.9010000@oracle.com> Message-ID: <4FBD2BD3.7080706@oracle.com> ToolkitThreadBlockedHandler seems to be shared code and it follows the enter / exit naming that is wrong. It seems that a lot of changes will be needed in shared code so I'm not sure the renaming is worth it. You could add update the comments to indicate how this is used and save the renaming for another day. Steve On 23/05/2012 2:11 PM, Alexander Zuev wrote: > Steve, > > you are absolutely right - this native method is used only by our > implementation of the DnD so > i may just rename it and the only reason i have not done it is to > minimize the scope of the change. > So if you think renaming the method is required i will gladly do it. > > With best regards, > Alex > > On 5/23/12 21:21, steve.x.northover at oracle.com wrote: >> The implementation matches how these methods are used by drag and >> drop but the naming makes no sense. Who else calls these methods? >> I'm assuming nobody (or that they are all called with the same >> implementation in mind). >> >> startNativeNestedEventLoop is really "read and dispatch an event >> without blocking". >> >> Steve >> >> On 23/05/2012 12:51 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/webrev.00/ >>> >>> With best regards, >>> Alexander Zuev > From alexander.zuev at oracle.com Thu May 24 02:26:21 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 24 May 2012 13:26:21 +0400 Subject: [8] Please review fix for 7144064: [macosx] "Could not find class" error in JTree's ctor when called in headless mode Message-ID: <4FBDFEBD.1090202@oracle.com> Hello, could you please take a look at this forward-port of the fix that did not make it from jdk7 to jdk8. Bug description can be seen here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144064 Webrev can be found here: http://cr.openjdk.java.net/~kizune/7144064/webrev/ With best regards, Alex From alexander.zuev at oracle.com Thu May 24 02:35:29 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 24 May 2012 13:35:29 +0400 Subject: [7u6] Please review my fix for 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock In-Reply-To: <4FBD2BD3.7080706@oracle.com> References: <4FBD15AA.7060206@oracle.com> <4FBD1CA8.8080703@oracle.com> <4FBD2859.9010000@oracle.com> <4FBD2BD3.7080706@oracle.com> Message-ID: <4FBE00E1.1040600@oracle.com> Steve, i've updated comments anywhere i can to reflect specific design of this feature on Mac. Also i have removed the unneeded call to the native function from the exit() method to save us some cycles on Java<->JNI call. Updated webrev can be found here: http://cr.openjdk.java.net/~kizune/7171163/webrev.01/ I also will send the formal request to approve the same change in jdk8 since we have to push change there before we can push it into the jdk7u6. With best regards, Alex On 5/23/12 22:26, steve.x.northover at oracle.com wrote: > ToolkitThreadBlockedHandler seems to be shared code and it follows the > enter / exit naming that is wrong. It seems that a lot of changes > will be needed in shared code so I'm not sure the renaming is worth it. > > You could add update the comments to indicate how this is used and > save the renaming for another day. > > Steve > > On 23/05/2012 2:11 PM, Alexander Zuev wrote: >> Steve, >> >> you are absolutely right - this native method is used only by our >> implementation of the DnD so >> i may just rename it and the only reason i have not done it is to >> minimize the scope of the change. >> So if you think renaming the method is required i will gladly do it. >> >> With best regards, >> Alex >> >> On 5/23/12 21:21, steve.x.northover at oracle.com wrote: >>> The implementation matches how these methods are used by drag and >>> drop but the naming makes no sense. Who else calls these methods? >>> I'm assuming nobody (or that they are all called with the same >>> implementation in mind). >>> >>> startNativeNestedEventLoop is really "read and dispatch an event >>> without blocking". >>> >>> Steve >>> >>> On 23/05/2012 12:51 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/webrev.00/ >>>> >>>> With best regards, >>>> Alexander Zuev >> From alexander.zuev at oracle.com Thu May 24 02:36:12 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 24 May 2012 13:36:12 +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: <4FBE010C.4000405@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/webrev.01/ With best regards, Alexander Zuev From leonid.romanov at oracle.com Thu May 24 02:37:35 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 24 May 2012 13:37:35 +0400 Subject: [8] Please review fix for 7144064: [macosx] "Could not find class" error in JTree's ctor when called in headless mode In-Reply-To: <4FBDFEBD.1090202@oracle.com> References: <4FBDFEBD.1090202@oracle.com> Message-ID: Looks good. On 24.05.2012, at 13:26, Alexander Zuev wrote: > Hello, > > could you please take a look at this forward-port of the fix that did not make it from jdk7 to jdk8. > > Bug description can be seen here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144064 > Webrev can be found here: http://cr.openjdk.java.net/~kizune/7144064/webrev/ > > With best regards, > Alex From artem.ananiev at oracle.com Thu May 24 03:26:10 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 24 May 2012 14:26:10 +0400 Subject: [8] Please review fix for 7144064: [macosx] "Could not find class" error in JTree's ctor when called in headless mode In-Reply-To: <4FBDFEBD.1090202@oracle.com> References: <4FBDFEBD.1090202@oracle.com> Message-ID: <4FBE0CC2.7070409@oracle.com> Looks fine. Thanks, Artem On 5/24/2012 1:26 PM, Alexander Zuev wrote: > Hello, > > could you please take a look at this forward-port of the fix that did > not make it from jdk7 to jdk8. > > Bug description can be seen here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144064 > Webrev can be found here: > http://cr.openjdk.java.net/~kizune/7144064/webrev/ > > With best regards, > Alex From leonid.romanov at oracle.com Thu May 24 05:22:00 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 24 May 2012 16:22:00 +0400 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: <4FBD052D.7080101@oracle.com> References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> <4FBD052D.7080101@oracle.com> Message-ID: <14564BAB-38B9-45C5-B921-C6CBCB568685@oracle.com> I'm not sure whether Jeff Hoffman, who filed 7168062, is on the list, so I'm adding him to CC. Perhaps he would be able to comment on what repo the branded icon should go and what icon to use for the open tree. As for 7168062 not being visible to the outside world, there isn't much to see. It basically states "we should use branded icon instead what we use now" and that is. On 23.05.2012, at 19:41, Phil Race wrote: > > On 5/23/2012 8:25 AM, Henri Gomez wrote: >>> That seems like overkill to me. Can't we just put the .icns in the JRE (Contents/Home/jre/lib/images) and load it from there? What are we guarding against by putting it into a .h file? >> OpenJDK will use Oracle icons ? Even for the community version ? > > I was wondering about this too. It seems wrong. The icon, and/or the header file > should be in "closed". We do not put branded images in the open tree, no > matter how its encoded since they aren't open source. > The openjdk should use something like the open source duke icon. > I am not sure I see how/where that works. > > BTW good luck seeing > >> Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168062 > > its marked for internal consumption only (for some reason I can't fathom). > > -phil. > > > From leonid.romanov at oracle.com Thu May 24 06:23:14 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 24 May 2012 17:23:14 +0400 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category Message-ID: 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 scott.kovatch at oracle.com Thu May 24 06:39:19 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 24 May 2012 17:39:19 +0400 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: References: Message-ID: Looks good to me. Ripping out code for a fix is a good thing. -- Scott On May 24, 2012, at 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 steve.x.northover at oracle.com Thu May 24 06:48:38 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 24 May 2012 09:48:38 -0400 Subject: [7u6] Please review my fix for 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock In-Reply-To: <4FBE00E1.1040600@oracle.com> References: <4FBD15AA.7060206@oracle.com> <4FBD1CA8.8080703@oracle.com> <4FBD2859.9010000@oracle.com> <4FBD2BD3.7080706@oracle.com> <4FBE00E1.1040600@oracle.com> Message-ID: <4FBE3C36.7030808@oracle.com> Thanks for commenting this for the next guy. Nit pick: // Despite the naming this method on MacOS only making one event from // the native loop to be executed so this call is not blocking Is not great English. How about "Despite the naming of this method, on MacOS only one event is read and dispatched before this method returns. This call is non-blocking and does not wait for an event" Thanks, Steve On 24/05/2012 5:35 AM, Alexander Zuev wrote: > Steve, > > i've updated comments anywhere i can to reflect specific design of > this feature on Mac. > Also i have removed the unneeded call to the native function from the > exit() method to save > us some cycles on Java<->JNI call. > > Updated webrev can be found here: > http://cr.openjdk.java.net/~kizune/7171163/webrev.01/ > > I also will send the formal request to approve the same change in > jdk8 since we have to push change > there before we can push it into the jdk7u6. > > With best regards, > Alex > > On 5/23/12 22:26, steve.x.northover at oracle.com wrote: >> ToolkitThreadBlockedHandler seems to be shared code and it follows >> the enter / exit naming that is wrong. It seems that a lot of >> changes will be needed in shared code so I'm not sure the renaming is >> worth it. >> >> You could add update the comments to indicate how this is used and >> save the renaming for another day. >> >> Steve >> >> On 23/05/2012 2:11 PM, Alexander Zuev wrote: >>> Steve, >>> >>> you are absolutely right - this native method is used only by our >>> implementation of the DnD so >>> i may just rename it and the only reason i have not done it is to >>> minimize the scope of the change. >>> So if you think renaming the method is required i will gladly do it. >>> >>> With best regards, >>> Alex >>> >>> On 5/23/12 21:21, steve.x.northover at oracle.com wrote: >>>> The implementation matches how these methods are used by drag and >>>> drop but the naming makes no sense. Who else calls these methods? >>>> I'm assuming nobody (or that they are all called with the same >>>> implementation in mind). >>>> >>>> startNativeNestedEventLoop is really "read and dispatch an event >>>> without blocking". >>>> >>>> Steve >>>> >>>> On 23/05/2012 12:51 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/webrev.00/ >>>>> >>>>> With best regards, >>>>> Alexander Zuev >>> > From alexander.zuev at oracle.com Thu May 24 07:33:04 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Thu, 24 May 2012 18:33:04 +0400 Subject: [7u6] Please review my fix for 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock In-Reply-To: <4FBE3C36.7030808@oracle.com> References: <4FBD15AA.7060206@oracle.com> <4FBD1CA8.8080703@oracle.com> <4FBD2859.9010000@oracle.com> <4FBD2BD3.7080706@oracle.com> <4FBE00E1.1040600@oracle.com> <4FBE3C36.7030808@oracle.com> Message-ID: <4FBE46A0.20702@oracle.com> Steve, i guess you are right and i gladly borrow your version of comment to use. This and two other typos caught by Scott Palmer leads us to the fourth version of the webrev which can be found here: http://cr.openjdk.java.net/~kizune/7171163/webrev.03 With best regards, Alex On 5/24/12 17:48, steve.x.northover at oracle.com wrote: > Thanks for commenting this for the next guy. > > Nit pick: > > // Despite the naming this method on MacOS only making one event from > // the native loop to be executed so this call is not blocking > > Is not great English. How about "Despite the naming of this method, > on MacOS only one event is read and dispatched before this method > returns. This call is non-blocking and does not wait for an event" > > Thanks, > Steve > > On 24/05/2012 5:35 AM, Alexander Zuev wrote: >> Steve, >> >> i've updated comments anywhere i can to reflect specific design of >> this feature on Mac. >> Also i have removed the unneeded call to the native function from the >> exit() method to save >> us some cycles on Java<->JNI call. >> >> Updated webrev can be found here: >> http://cr.openjdk.java.net/~kizune/7171163/webrev.01/ >> >> I also will send the formal request to approve the same change in >> jdk8 since we have to push change >> there before we can push it into the jdk7u6. >> >> With best regards, >> Alex >> >> On 5/23/12 22:26, steve.x.northover at oracle.com wrote: >>> ToolkitThreadBlockedHandler seems to be shared code and it follows >>> the enter / exit naming that is wrong. It seems that a lot of >>> changes will be needed in shared code so I'm not sure the renaming >>> is worth it. >>> >>> You could add update the comments to indicate how this is used and >>> save the renaming for another day. >>> >>> Steve >>> >>> On 23/05/2012 2:11 PM, Alexander Zuev wrote: >>>> Steve, >>>> >>>> you are absolutely right - this native method is used only by our >>>> implementation of the DnD so >>>> i may just rename it and the only reason i have not done it is to >>>> minimize the scope of the change. >>>> So if you think renaming the method is required i will gladly do it. >>>> >>>> With best regards, >>>> Alex >>>> >>>> On 5/23/12 21:21, steve.x.northover at oracle.com wrote: >>>>> The implementation matches how these methods are used by drag and >>>>> drop but the naming makes no sense. Who else calls these >>>>> methods? I'm assuming nobody (or that they are all called with >>>>> the same implementation in mind). >>>>> >>>>> startNativeNestedEventLoop is really "read and dispatch an event >>>>> without blocking". >>>>> >>>>> Steve >>>>> >>>>> On 23/05/2012 12:51 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/webrev.00/ >>>>>> >>>>>> With best regards, >>>>>> Alexander Zuev >>>> >> From andrew.brygin at oracle.com Thu May 24 08:02:28 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Thu, 24 May 2012 19:02:28 +0400 Subject: [7u6] request for review: 7154088: [macosx] Regression: Component.createImage do not inherits component attributes Message-ID: <4FBE4D84.10404@oracle.com> Hello, could you please review a backport of the fix for 7154088 to 7u6? This fix just delegates a creation of an appropriate off-screen image to the platform-specific graphics configuration. The change can be verified by a regression test mentioned in the bug description. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154088 jdk8 changeset: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/416b3a498e71 Webrev: http://cr.openjdk.java.net/~bae/7154088/7u6/webrev.00/ Thanks, Andrew From steve.x.northover at oracle.com Thu May 24 08:26:34 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 24 May 2012 11:26:34 -0400 Subject: [7u6] Please review my fix for 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock In-Reply-To: <4FBE46A0.20702@oracle.com> References: <4FBD15AA.7060206@oracle.com> <4FBD1CA8.8080703@oracle.com> <4FBD2859.9010000@oracle.com> <4FBD2BD3.7080706@oracle.com> <4FBE00E1.1040600@oracle.com> <4FBE3C36.7030808@oracle.com> <4FBE46A0.20702@oracle.com> Message-ID: <4FBE532A.2020609@oracle.com> Thanks so much for finding and fixing this critical issue. Steve On 24/05/2012 10:33 AM, Alexander Zuev wrote: > Steve, > > i guess you are right and i gladly borrow your version of comment to > use. > This and two other typos caught by Scott Palmer leads us to the fourth > version of > the webrev which can be found here: > http://cr.openjdk.java.net/~kizune/7171163/webrev.03 > > With best regards, > Alex > > On 5/24/12 17:48, steve.x.northover at oracle.com wrote: >> Thanks for commenting this for the next guy. >> >> Nit pick: >> >> // Despite the naming this method on MacOS only making one event from >> // the native loop to be executed so this call is not blocking >> >> Is not great English. How about "Despite the naming of this method, >> on MacOS only one event is read and dispatched before this method >> returns. This call is non-blocking and does not wait for an event" >> >> Thanks, >> Steve >> >> On 24/05/2012 5:35 AM, Alexander Zuev wrote: >>> Steve, >>> >>> i've updated comments anywhere i can to reflect specific design of >>> this feature on Mac. >>> Also i have removed the unneeded call to the native function from >>> the exit() method to save >>> us some cycles on Java<->JNI call. >>> >>> Updated webrev can be found here: >>> http://cr.openjdk.java.net/~kizune/7171163/webrev.01/ >>> >>> I also will send the formal request to approve the same change in >>> jdk8 since we have to push change >>> there before we can push it into the jdk7u6. >>> >>> With best regards, >>> Alex >>> >>> On 5/23/12 22:26, steve.x.northover at oracle.com wrote: >>>> ToolkitThreadBlockedHandler seems to be shared code and it follows >>>> the enter / exit naming that is wrong. It seems that a lot of >>>> changes will be needed in shared code so I'm not sure the renaming >>>> is worth it. >>>> >>>> You could add update the comments to indicate how this is used and >>>> save the renaming for another day. >>>> >>>> Steve >>>> >>>> On 23/05/2012 2:11 PM, Alexander Zuev wrote: >>>>> Steve, >>>>> >>>>> you are absolutely right - this native method is used only by >>>>> our implementation of the DnD so >>>>> i may just rename it and the only reason i have not done it is to >>>>> minimize the scope of the change. >>>>> So if you think renaming the method is required i will gladly do it. >>>>> >>>>> With best regards, >>>>> Alex >>>>> >>>>> On 5/23/12 21:21, steve.x.northover at oracle.com wrote: >>>>>> The implementation matches how these methods are used by drag and >>>>>> drop but the naming makes no sense. Who else calls these >>>>>> methods? I'm assuming nobody (or that they are all called with >>>>>> the same implementation in mind). >>>>>> >>>>>> startNativeNestedEventLoop is really "read and dispatch an event >>>>>> without blocking". >>>>>> >>>>>> Steve >>>>>> >>>>>> On 23/05/2012 12:51 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/webrev.00/ >>>>>>> >>>>>>> With best regards, >>>>>>> Alexander Zuev >>>>> >>> > From artem.ananiev at oracle.com Thu May 24 09:12:14 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 24 May 2012 20:12:14 +0400 Subject: [7u6] Please review my fix for 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock In-Reply-To: <4FBE46A0.20702@oracle.com> References: <4FBD15AA.7060206@oracle.com> <4FBD1CA8.8080703@oracle.com> <4FBD2859.9010000@oracle.com> <4FBD2BD3.7080706@oracle.com> <4FBE00E1.1040600@oracle.com> <4FBE3C36.7030808@oracle.com> <4FBE46A0.20702@oracle.com> Message-ID: <4FBE5DDE.4090901@oracle.com> Hi, Alex, the fix looks fine for 7u6. In JDK8 version of the fix, I would rename startNativeNestedEventLoop() in LWCToolkit to something like runOneEvent(). Thanks, Artem On 5/24/2012 6:33 PM, Alexander Zuev wrote: > Steve, > > i guess you are right and i gladly borrow your version of comment to use. > This and two other typos caught by Scott Palmer leads us to the fourth > version of > the webrev which can be found here: > http://cr.openjdk.java.net/~kizune/7171163/webrev.03 > > With best regards, > Alex > > On 5/24/12 17:48, steve.x.northover at oracle.com wrote: >> Thanks for commenting this for the next guy. >> >> Nit pick: >> >> // Despite the naming this method on MacOS only making one event from >> // the native loop to be executed so this call is not blocking >> >> Is not great English. How about "Despite the naming of this method, on >> MacOS only one event is read and dispatched before this method >> returns. This call is non-blocking and does not wait for an event" >> >> Thanks, >> Steve >> >> On 24/05/2012 5:35 AM, Alexander Zuev wrote: >>> Steve, >>> >>> i've updated comments anywhere i can to reflect specific design of >>> this feature on Mac. >>> Also i have removed the unneeded call to the native function from the >>> exit() method to save >>> us some cycles on Java<->JNI call. >>> >>> Updated webrev can be found here: >>> http://cr.openjdk.java.net/~kizune/7171163/webrev.01/ >>> >>> I also will send the formal request to approve the same change in >>> jdk8 since we have to push change >>> there before we can push it into the jdk7u6. >>> >>> With best regards, >>> Alex >>> >>> On 5/23/12 22:26, steve.x.northover at oracle.com wrote: >>>> ToolkitThreadBlockedHandler seems to be shared code and it follows >>>> the enter / exit naming that is wrong. It seems that a lot of >>>> changes will be needed in shared code so I'm not sure the renaming >>>> is worth it. >>>> >>>> You could add update the comments to indicate how this is used and >>>> save the renaming for another day. >>>> >>>> Steve >>>> >>>> On 23/05/2012 2:11 PM, Alexander Zuev wrote: >>>>> Steve, >>>>> >>>>> you are absolutely right - this native method is used only by our >>>>> implementation of the DnD so >>>>> i may just rename it and the only reason i have not done it is to >>>>> minimize the scope of the change. >>>>> So if you think renaming the method is required i will gladly do it. >>>>> >>>>> With best regards, >>>>> Alex >>>>> >>>>> On 5/23/12 21:21, steve.x.northover at oracle.com wrote: >>>>>> The implementation matches how these methods are used by drag and >>>>>> drop but the naming makes no sense. Who else calls these methods? >>>>>> I'm assuming nobody (or that they are all called with the same >>>>>> implementation in mind). >>>>>> >>>>>> startNativeNestedEventLoop is really "read and dispatch an event >>>>>> without blocking". >>>>>> >>>>>> Steve >>>>>> >>>>>> On 23/05/2012 12:51 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/webrev.00/ >>>>>>> >>>>>>> With best regards, >>>>>>> Alexander Zuev >>>>> >>> > From leonid.romanov at oracle.com Thu May 24 11:33:29 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 24 May 2012 22:33:29 +0400 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: <4FBE7C26.9050609@oracle.com> References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> <4FBD052D.7080101@oracle.com> <14564BAB-38B9-45C5-B921-C6CBCB568685@oracle.com> <4FBE7C26.9050609@oracle.com> Message-ID: Yep, we do need a generic icon file for the OpenJDK distribution. It would be great if you could provide me with one. On 24.05.2012, at 22:21, Jeff Hoffman wrote: > I need to do some research on this question... We should follow what has been done before. It makes sense that we don't put Oracle branded images in the OpenJDK distribution -- but I'm not exactly sure what we have been putting in there up until now... If we need a "generic" icns file for the Mac port, I can supply one. > > -jeff > > On 5/24/12 5:22 AM, Leonid Romanov wrote: >> I'm not sure whether Jeff Hoffman, who filed 7168062, is on the list, so I'm adding him to CC. Perhaps he would be able to comment on what repo the branded icon should go and what icon to use for the open tree. >> As for 7168062 not being visible to the outside world, there isn't much to see. It basically states "we should use branded icon instead what we use now" and that is. >> >> On 23.05.2012, at 19:41, Phil Race wrote: >> >>> On 5/23/2012 8:25 AM, Henri Gomez wrote: >>>>> That seems like overkill to me. Can't we just put the .icns in the JRE (Contents/Home/jre/lib/images) and load it from there? What are we guarding against by putting it into a .h file? >>>> OpenJDK will use Oracle icons ? Even for the community version ? >>> I was wondering about this too. It seems wrong. The icon, and/or the header file >>> should be in "closed". We do not put branded images in the open tree, no >>> matter how its encoded since they aren't open source. >>> The openjdk should use something like the open source duke icon. >>> I am not sure I see how/where that works. >>> >>> BTW good luck seeing >>> >>>> Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168062 >>> its marked for internal consumption only (for some reason I can't fathom). >>> >>> -phil. >>> >>> >>> From dalibor.topic at oracle.com Thu May 24 16:12:06 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 25 May 2012 01:12:06 +0200 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: <4FBD052D.7080101@oracle.com> References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> <4FBD052D.7080101@oracle.com> Message-ID: <4FBEC046.8090309@oracle.com> On 5/23/12 5:41 PM, Phil Race wrote: > > On 5/23/2012 8:25 AM, Henri Gomez wrote: >>> That seems like overkill to me. Can't we just put the .icns in the JRE (Contents/Home/jre/lib/images) and load it from there? What are we guarding against by putting it into a .h file? >> OpenJDK will use Oracle icons ? Even for the community version ? > > I was wondering about this too. It seems wrong. The icon, and/or the header file > should be in "closed". Correct. > We do not put branded images in the open tree, no > matter how its encoded since they aren't open source. Correct. > The openjdk should use something like the open source duke icon. Or even better, no image by default in OpenJDK, with an ALT_ICON_DATA that can be supplied to point to the icon to use. That way we don't have to bikeshed about say following the annual Duke fashion trends, and yet people who want to add some open source icon to their builds can do so. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From scott.kovatch at oracle.com Thu May 24 19:49:49 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 25 May 2012 06:49:49 +0400 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: <4FBEC046.8090309@oracle.com> References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> <4FBD052D.7080101@oracle.com> <4FBEC046.8090309@oracle.com> Message-ID: <5C3B17A4-7005-424C-9FB5-3DC5CBFCD498@oracle.com> On May 25, 2012, at 3:12 AM, Dalibor Topic wrote: > On 5/23/12 5:41 PM, Phil Race wrote: >> >> On 5/23/2012 8:25 AM, Henri Gomez wrote: >>>> That seems like overkill to me. Can't we just put the .icns in the JRE (Contents/Home/jre/lib/images) and load it from there? What are we guarding against by putting it into a .h file? >>> OpenJDK will use Oracle icons ? Even for the community version ? >> >> I was wondering about this too. It seems wrong. The icon, and/or the header file >> should be in "closed". > > Correct. > >> We do not put branded images in the open tree, no >> matter how its encoded since they aren't open source. > > Correct. > >> The openjdk should use something like the open source duke icon. > > Or even better, no image by default in OpenJDK, with an ALT_ICON_DATA that can be supplied to point > to the icon to use. That way we don't have to bikeshed about say following the annual Duke fashion > trends, and yet people who want to add some open source icon to their builds can do so. Okay, let's get the facts out before we do anything crazy. Java applications should have a Dock icon when running, so we don't use the default application icon. Currently the AWT uses /System/Library/Frameworks/JavaVM.framework/Resources/GenericApp.icns, which means it's Apple's icon right now. Oracle would like to use its own icon. OpenJDK (IMO) shouldn't rely on an icon in a framework that could disappear in the next year or two, so it should use its own icon. The AWT will need to change for that to happen. If Apple would like to donate this icon I think it would be great, and would solve that problem nicely. It's then up to Leonid to decide how to best use it. Next, Oracle would like to override the default icon so it can use its own icon. If OpenJDK would like to specify the path with a make variable that can be overridden, I think that would solve that part of the problem as well. Does this sound like a plan? Mike S., what do you think? Leonid, does this work for you? - Scott K. From philip.race at oracle.com Thu May 24 21:40:36 2012 From: philip.race at oracle.com (Phil Race) Date: Thu, 24 May 2012 21:40:36 -0700 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: <5C3B17A4-7005-424C-9FB5-3DC5CBFCD498@oracle.com> References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> <4FBD052D.7080101@oracle.com> <4FBEC046.8090309@oracle.com> <5C3B17A4-7005-424C-9FB5-3DC5CBFCD498@oracle.com> Message-ID: <4FBF0D44.3060709@oracle.com> We don't need Apple to donate an Icon .. we can simply provide one for OpenJDK (open) AND one for Oracle JDK (closed). Jeff Hoffman is concocting a Duke one for OpenJDK The build process can then simply determine which one to used based on which build its doing (Oracle or Open) as happens in a number of places. No need for a new make variable. -phil. On 5/24/2012 7:49 PM, Scott Kovatch wrote: > On May 25, 2012, at 3:12 AM, Dalibor Topic wrote: > >> On 5/23/12 5:41 PM, Phil Race wrote: >>> On 5/23/2012 8:25 AM, Henri Gomez wrote: >>>>> That seems like overkill to me. Can't we just put the .icns in the JRE (Contents/Home/jre/lib/images) and load it from there? What are we guarding against by putting it into a .h file? >>>> OpenJDK will use Oracle icons ? Even for the community version ? >>> I was wondering about this too. It seems wrong. The icon, and/or the header file >>> should be in "closed". >> Correct. >> >>> We do not put branded images in the open tree, no >>> matter how its encoded since they aren't open source. >> Correct. >> >>> The openjdk should use something like the open source duke icon. >> Or even better, no image by default in OpenJDK, with an ALT_ICON_DATA that can be supplied to point >> to the icon to use. That way we don't have to bikeshed about say following the annual Duke fashion >> trends, and yet people who want to add some open source icon to their builds can do so. > Okay, let's get the facts out before we do anything crazy. > > Java applications should have a Dock icon when running, so we don't use the default application icon. Currently the AWT uses /System/Library/Frameworks/JavaVM.framework/Resources/GenericApp.icns, which means it's Apple's icon right now. Oracle would like to use its own icon. > > OpenJDK (IMO) shouldn't rely on an icon in a framework that could disappear in the next year or two, so it should use its own icon. The AWT will need to change for that to happen. If Apple would like to donate this icon I think it would be great, and would solve that problem nicely. It's then up to Leonid to decide how to best use it. > > Next, Oracle would like to override the default icon so it can use its own icon. If OpenJDK would like to specify the path with a make variable that can be overridden, I think that would solve that part of the problem as well. > > Does this sound like a plan? Mike S., what do you think? Leonid, does this work for you? > > - Scott K. > From andrew.brygin at oracle.com Fri May 25 01:28:17 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Fri, 25 May 2012 12:28:17 +0400 Subject: [7u6] request for review: 7124400: [macosx] CGraphicsDevice.getConfigurations() returns reference to member (does not copy configs) Message-ID: <4FBF42A1.5060303@oracle.com> Hello, could you please review a backport of fix for CR 7124400 to 7u6? The fix is exactly same as for jdk8: it clones a GraphicsConfiguration collection in order to prevent it's modification by an external code. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124400 Jdk8 changeset: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7c4eed4b6c19 Webrev: http://cr.openjdk.java.net/~bae/7124400/7u6/webrev.00/ Thanks, Andrew From leonid.romanov at oracle.com Fri May 25 03:10:28 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 25 May 2012 14:10:28 +0400 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: <4FBF0D44.3060709@oracle.com> References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> <4FBD052D.7080101@oracle.com> <4FBEC046.8090309@oracle.com> <5C3B17A4-7005-424C-9FB5-3DC5CBFCD498@oracle.com> <4FBF0D44.3060709@oracle.com> Message-ID: <844C61F1-23F8-46E6-8134-A071A1ED4382@oracle.com> I've looked at what icon is used in OpenJDK for Windows and X11, and they both use Duke icon. So, I guess, it makes sense for OS X to use Duke image as well. On 25.05.2012, at 8:40, Phil Race wrote: > We don't need Apple to donate an Icon .. we can simply provide one for OpenJDK (open) AND one for Oracle JDK (closed). > Jeff Hoffman is concocting a Duke one for OpenJDK > The build process can then simply determine which one to used based on which build its doing > (Oracle or Open) as happens in a number of places. No need for a new make variable. > > -phil. > > On 5/24/2012 7:49 PM, Scott Kovatch wrote: >> On May 25, 2012, at 3:12 AM, Dalibor Topic wrote: >> >>> On 5/23/12 5:41 PM, Phil Race wrote: >>>> On 5/23/2012 8:25 AM, Henri Gomez wrote: >>>>>> That seems like overkill to me. Can't we just put the .icns in the JRE (Contents/Home/jre/lib/images) and load it from there? What are we guarding against by putting it into a .h file? >>>>> OpenJDK will use Oracle icons ? Even for the community version ? >>>> I was wondering about this too. It seems wrong. The icon, and/or the header file >>>> should be in "closed". >>> Correct. >>> >>>> We do not put branded images in the open tree, no >>>> matter how its encoded since they aren't open source. >>> Correct. >>> >>>> The openjdk should use something like the open source duke icon. >>> Or even better, no image by default in OpenJDK, with an ALT_ICON_DATA that can be supplied to point >>> to the icon to use. That way we don't have to bikeshed about say following the annual Duke fashion >>> trends, and yet people who want to add some open source icon to their builds can do so. >> Okay, let's get the facts out before we do anything crazy. >> >> Java applications should have a Dock icon when running, so we don't use the default application icon. Currently the AWT uses /System/Library/Frameworks/JavaVM.framework/Resources/GenericApp.icns, which means it's Apple's icon right now. Oracle would like to use its own icon. >> >> OpenJDK (IMO) shouldn't rely on an icon in a framework that could disappear in the next year or two, so it should use its own icon. The AWT will need to change for that to happen. If Apple would like to donate this icon I think it would be great, and would solve that problem nicely. It's then up to Leonid to decide how to best use it. >> >> Next, Oracle would like to override the default icon so it can use its own icon. If OpenJDK would like to specify the path with a make variable that can be overridden, I think that would solve that part of the problem as well. >> >> Does this sound like a plan? Mike S., what do you think? Leonid, does this work for you? >> >> - Scott K. >> > From andrew.brygin at oracle.com Fri May 25 03:23:50 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Fri, 25 May 2012 14:23:50 +0400 Subject: [7u6] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() Message-ID: <4FBF5DB6.2050506@oracle.com> Hello, could you please review a backport of the fix for 7146550 to 7u6? The fix is almost the same as for jdk8, it just adds helper method imageToArray to CImage class. This method was introduced in jdk8 as a part of the fix for 7148275 ([macosx] setIconImages() not working correctly (distorted icon when minimized)). Note that 7148275 was fixed in 7u4 and 7u6 in a different manner, there seems to be no need for complete backport of the jdk8 revision of the fix for 7148275. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 Jdk8 changeset: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a2d12ca36eb3 Webrev: http://cr.openjdk.java.net/~bae/7146550/7u6/webrev.00/ Thanks, Andrew From anthony.petrov at oracle.com Fri May 25 03:38:11 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 May 2012 14:38:11 +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: <4FBE010C.4000405@oracle.com> References: <4FBE010C.4000405@oracle.com> Message-ID: <4FBF6113.6050601@oracle.com> Hi Alexander, I guess I'm a bit late with the review, but my comment also concerns the fix for 7u6. You're changing the shared file SunDropTargetContextPeer.java and reverting a boolean argument when calling postDropTargetEvent. Can this change affect other platforms? Have you run some tests for DnD area on Win and X11 to verify nothing is broken? -- best regards, Anthony On 5/24/2012 1:36 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/webrev.01/ > > With best regards, > Alexander Zuev From dmitry.cherepanov at oracle.com Fri May 25 04:08:15 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 25 May 2012 15:08:15 +0400 Subject: [7u6] Review request for 7168550: [macosx] duplicate OGL context state changes related to vertex cache Message-ID: <4FBF681F.20306@oracle.com> This is a direct back port (and reverting the change for 7154505) of the fix to jdk7u6. Bug: http://bugs.sun.com/view_bug.do?bug_id=7168550 Webrev: http://cr.openjdk.java.net/~dcherepanov/7168550/7u6/webrev.0/ Thanks, Dmitry From dmitry.cherepanov at oracle.com Fri May 25 04:10:32 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 25 May 2012 15:10:32 +0400 Subject: [7u6] Review request for 7160293 [macosx] FileDialog appears on secondary display Message-ID: <4FBF68A8.5040500@oracle.com> This is a direct back port of the fix to jdk7u6. Bug: http://bugs.sun.com/view_bug.do?bug_id=7160293 Webrev: http://cr.openjdk.java.net/~dcherepanov/7160293/7u6/webrev.0/ Thanks, Dmitry From anthony.petrov at oracle.com Fri May 25 04:08:13 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 May 2012 15:08:13 +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: References: <4FBE010C.4000405@oracle.com> <4FBF6113.6050601@oracle.com> Message-ID: <4FBF681D.5080607@oracle.com> Thanks for the confirmation. The fix looks fine to me then. -- best regards, Anthony On 5/25/2012 3:04 PM, Alexander Zuev wrote: > Anthony, I have checked it on Windows and Ubuntu - seems like there's no regressions caused by this fix. > > With best regards, > Alexander Zuev > > 25.05.2012, ? 14:38, Anthony Petrov ???????(?): > >> Hi Alexander, >> >> I guess I'm a bit late with the review, but my comment also concerns the fix for 7u6. You're changing the shared file SunDropTargetContextPeer.java and reverting a boolean argument when calling postDropTargetEvent. Can this change affect other platforms? Have you run some tests for DnD area on Win and X11 to verify nothing is broken? >> >> -- >> best regards, >> Anthony >> >> On 5/24/2012 1:36 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/webrev.01/ >>> With best regards, >>> Alexander Zuev From alexander.zuev at oracle.com Fri May 25 04:06:30 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 25 May 2012 15:06:30 +0400 Subject: [7u6] Review request for 7160293 [macosx] FileDialog appears on secondary display In-Reply-To: <4FBF68A8.5040500@oracle.com> References: <4FBF68A8.5040500@oracle.com> Message-ID: <1ABFF12D-A073-4BFD-827A-AAB594298315@oracle.com> Dmitry, Fix looks fine to me. With best regards, Alexander Zuev 25.05.2012, ? 15:10, Dmitry Cherepanov ???????(?): > This is a direct back port of the fix to jdk7u6. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=7160293 > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7160293/7u6/webrev.0/ > > Thanks, > Dmitry From andrew.brygin at oracle.com Fri May 25 04:22:51 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Fri, 25 May 2012 15:22:51 +0400 Subject: [7u6] Review request for 7168550: [macosx] duplicate OGL context state changes related to vertex cache In-Reply-To: <4FBF681F.20306@oracle.com> References: <4FBF681F.20306@oracle.com> Message-ID: <4FBF6B8B.3050203@oracle.com> Hi Dmitry, the fix looks fine to me. Thanks, Andrew. On 25.05.2012 15:08, Dmitry Cherepanov wrote: > This is a direct back port (and reverting the change for 7154505) of > the fix to jdk7u6. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=7168550 > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7168550/7u6/webrev.0/ > > Thanks, > Dmitry From anthony.petrov at oracle.com Fri May 25 05:17:31 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 May 2012 16:17:31 +0400 Subject: [7u6] Review request for 7160293 [macosx] FileDialog appears on secondary display In-Reply-To: <4FBF68A8.5040500@oracle.com> References: <4FBF68A8.5040500@oracle.com> Message-ID: <4FBF785B.1050001@oracle.com> Looks good to me. -- best regards, Anthony On 5/25/2012 3:10 PM, Dmitry Cherepanov wrote: > This is a direct back port of the fix to jdk7u6. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=7160293 > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7160293/7u6/webrev.0/ > > Thanks, > Dmitry From artem.ananiev at oracle.com Fri May 25 06:06:38 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 25 May 2012 17:06:38 +0400 Subject: [7u6] request for review: 7124400: [macosx] CGraphicsDevice.getConfigurations() returns reference to member (does not copy configs) In-Reply-To: <4FBF42A1.5060303@oracle.com> References: <4FBF42A1.5060303@oracle.com> Message-ID: <4FBF83DE.9070505@oracle.com> Looks fine. Thanks, Artem On 5/25/2012 12:28 PM, Andrew Brygin wrote: > Hello, > > could you please review a backport of fix for CR 7124400 to 7u6? > The fix is exactly same as for jdk8: it clones a GraphicsConfiguration > collection in order to prevent it's modification by an external code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124400 > Jdk8 changeset: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7c4eed4b6c19 > Webrev: http://cr.openjdk.java.net/~bae/7124400/7u6/webrev.00/ > > Thanks, > Andrew From artem.ananiev at oracle.com Fri May 25 06:18:20 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 25 May 2012 17:18:20 +0400 Subject: [7u6] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() In-Reply-To: <4FBF5DB6.2050506@oracle.com> References: <4FBF5DB6.2050506@oracle.com> Message-ID: <4FBF869C.3040909@oracle.com> Hi, Andrew, I didn't participate in the fix review for JDK8, so could you explain the purpose of that createFromImageImmediately() method in CImage, please? Why having createFromImage(), which always waits until the image is ready, and additional checks for w > 0 and h > 0 is not enough? Thanks, Artem On 5/25/2012 2:23 PM, Andrew Brygin wrote: > Hello, > > could you please review a backport of the fix for 7146550 to 7u6? > > The fix is almost the same as for jdk8, it just adds helper method > imageToArray to CImage class. This method was introduced in jdk8 as > a part of the fix for 7148275 ([macosx] setIconImages() not working > correctly (distorted icon when minimized)). Note that 7148275 was > fixed in 7u4 and 7u6 in a different manner, there seems to be no > need for complete backport of the jdk8 revision of the fix for 7148275. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 > Jdk8 changeset: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a2d12ca36eb3 > Webrev: http://cr.openjdk.java.net/~bae/7146550/7u6/webrev.00/ > > Thanks, > Andrew From anthony.petrov at oracle.com Fri May 25 06:22:43 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 May 2012 17:22:43 +0400 Subject: [7u6] request for review: 7124400: [macosx] CGraphicsDevice.getConfigurations() returns reference to member (does not copy configs) In-Reply-To: <4FBF42A1.5060303@oracle.com> References: <4FBF42A1.5060303@oracle.com> Message-ID: <4FBF87A3.6000507@oracle.com> The fix looks good to me. -- best regards, Anthony On 5/25/2012 12:28 PM, Andrew Brygin wrote: > Hello, > > could you please review a backport of fix for CR 7124400 to 7u6? > The fix is exactly same as for jdk8: it clones a GraphicsConfiguration > collection in order to prevent it's modification by an external code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124400 > Jdk8 changeset: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/7c4eed4b6c19 > Webrev: http://cr.openjdk.java.net/~bae/7124400/7u6/webrev.00/ > > Thanks, > Andrew From anthony.petrov at oracle.com Fri May 25 06:51:57 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 May 2012 17:51:57 +0400 Subject: [7u6] request for review: 7154088: [macosx] Regression: Component.createImage do not inherits component attributes In-Reply-To: <4FBE4D84.10404@oracle.com> References: <4FBE4D84.10404@oracle.com> Message-ID: <4FBF8E7D.50005@oracle.com> Looks fine. -- best regards, Anthony On 5/24/2012 7:02 PM, Andrew Brygin wrote: > Hello, > > could you please review a backport of the fix for 7154088 to 7u6? > > This fix just delegates a creation of an appropriate off-screen > image to the platform-specific graphics configuration. > > The change can be verified by a regression test mentioned in the > bug description. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154088 > jdk8 changeset: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/416b3a498e71 > Webrev: http://cr.openjdk.java.net/~bae/7154088/7u6/webrev.00/ > > Thanks, > Andrew From andrew.brygin at oracle.com Fri May 25 07:22:12 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Fri, 25 May 2012 18:22:12 +0400 Subject: [7u6] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() In-Reply-To: <4FBF869C.3040909@oracle.com> References: <4FBF5DB6.2050506@oracle.com> <4FBF869C.3040909@oracle.com> Message-ID: <4FBF9594.9090202@oracle.com> Hi Artem, the spec does not defines how we should handle the drag image. We probably can not delay startDrag() operation in order to prepare the image, because it may take noticeable time (or hangs infinitely as a corner case, and the test implements this scenario). At least, we do behave in such manner on windows. Also, it seems to be logical to put all methods related to CImage production to CImage.Creator class. So, there we need to have two ways to convert a toolkit image to CImage: * 'immediate': returns null if toolkit image is not ready * 'normal': prepare toolkit image before conversion We likely need some kind of spec clarification for startDrag(), in order to define how should we handle toolkit images which are not ready: wait and prepare, silently ignore, or throw an exception. At the moment, this fix just makes our behavior on different platforms a bit more consistent. Thanks, Andrew On 25.05.2012 17:18, Artem Ananiev wrote: > Hi, Andrew, > > I didn't participate in the fix review for JDK8, so could you explain > the purpose of that createFromImageImmediately() method in CImage, > please? Why having createFromImage(), which always waits until the > image is ready, and additional checks for w > 0 and h > 0 is not enough? > > Thanks, > > Artem > > On 5/25/2012 2:23 PM, Andrew Brygin wrote: >> Hello, >> >> could you please review a backport of the fix for 7146550 to 7u6? >> >> The fix is almost the same as for jdk8, it just adds helper method >> imageToArray to CImage class. This method was introduced in jdk8 as >> a part of the fix for 7148275 ([macosx] setIconImages() not working >> correctly (distorted icon when minimized)). Note that 7148275 was >> fixed in 7u4 and 7u6 in a different manner, there seems to be no >> need for complete backport of the jdk8 revision of the fix for 7148275. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 >> Jdk8 changeset: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a2d12ca36eb3 >> Webrev: http://cr.openjdk.java.net/~bae/7146550/7u6/webrev.00/ >> >> Thanks, >> Andrew From tobi at ultramixer.com Fri May 25 07:54:53 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 25 May 2012 16:54:53 +0200 Subject: Java Preferences.app doesn't open anymore Message-ID: Hi, I don't know what I made wrong, but I removed Java6 and now the JavaPreferences.app doesn't start anymore :( Any suggestions? Even reinstall Java6 doen't work. 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 swingler at apple.com Fri May 25 08:55:10 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 25 May 2012 08:55:10 -0700 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: <5C3B17A4-7005-424C-9FB5-3DC5CBFCD498@oracle.com> References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> <4FBD052D.7080101@oracle.com> <4FBEC046.8090309@oracle.com> <5C3B17A4-7005-424C-9FB5-3DC5CBFCD498@oracle.com> Message-ID: <9B4E36FF-A1C4-4B03-94C6-3E4FDACCD0E1@apple.com> On May 24, 2012, at 7:49 PM, Scott Kovatch wrote: > OpenJDK (IMO) shouldn't rely on an icon in a framework that could disappear in the next year or two, so it should use its own icon. The AWT will need to change for that to happen. If Apple would like to donate this icon I think it would be great, and would solve that problem nicely. It's then up to Leonid to decide how to best use it. Just my 2? here: * It is not accurate to imply that any Apple framework or resource therein is going to "go away in the next year or two". * The Apple GenericApp.icns will be around as long as JavaRuntimeSupport and JavaNativeFoundation. * The Apple GenericApp.icns will stay as is (it will not be up-res'd or improved). The GA'd versions of 7u4 have effectively locked the filesystem location of this icon in stone for their supported lifetimes, in addition to all of Apple's Java SE 6 versions. I wouldn't suggest using the Apple icon if there is better or more accurate iconography available, but there is no risk in having a runtime dependency on it, as there is already today. Regards, Mike Swingler Apple Inc. From artem.ananiev at oracle.com Fri May 25 08:59:23 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 25 May 2012 19:59:23 +0400 Subject: [7u6] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() In-Reply-To: <4FBF9594.9090202@oracle.com> References: <4FBF5DB6.2050506@oracle.com> <4FBF869C.3040909@oracle.com> <4FBF9594.9090202@oracle.com> Message-ID: <4FBFAC5B.9040906@oracle.com> Hi, Andrew, thanks for this clarification. I'm fine with the fix then as it makes AWT behave consistently on all the platforms. Could you file a new (likely low priority) bug about startDrag() specification against AWT, please? Thanks, Artem On 5/25/2012 6:22 PM, Andrew Brygin wrote: > Hi Artem, > > the spec does not defines how we should handle the drag image. We > probably can not delay > startDrag() operation in order to prepare the image, because it may take > noticeable time (or > hangs infinitely as a corner case, and the test implements this > scenario). At least, we do > behave in such manner on windows. > > Also, it seems to be logical to put all methods related to CImage > production to CImage.Creator > class. So, there we need to have two ways to convert a toolkit image to > CImage: > * 'immediate': returns null if toolkit image is not ready > * 'normal': prepare toolkit image before conversion > > We likely need some kind of spec clarification for startDrag(), in order > to define how should we > handle toolkit images which are not ready: wait and prepare, silently > ignore, or throw an exception. > > At the moment, this fix just makes our behavior on different platforms a > bit more consistent. > > Thanks, > Andrew > > > On 25.05.2012 17:18, Artem Ananiev wrote: >> Hi, Andrew, >> >> I didn't participate in the fix review for JDK8, so could you explain >> the purpose of that createFromImageImmediately() method in CImage, >> please? Why having createFromImage(), which always waits until the >> image is ready, and additional checks for w > 0 and h > 0 is not enough? >> >> Thanks, >> >> Artem >> >> On 5/25/2012 2:23 PM, Andrew Brygin wrote: >>> Hello, >>> >>> could you please review a backport of the fix for 7146550 to 7u6? >>> >>> The fix is almost the same as for jdk8, it just adds helper method >>> imageToArray to CImage class. This method was introduced in jdk8 as >>> a part of the fix for 7148275 ([macosx] setIconImages() not working >>> correctly (distorted icon when minimized)). Note that 7148275 was >>> fixed in 7u4 and 7u6 in a different manner, there seems to be no >>> need for complete backport of the jdk8 revision of the fix for 7148275. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 >>> Jdk8 changeset: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a2d12ca36eb3 >>> Webrev: http://cr.openjdk.java.net/~bae/7146550/7u6/webrev.00/ >>> >>> Thanks, >>> Andrew > From swingler at apple.com Fri May 25 08:59:20 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 25 May 2012 08:59:20 -0700 Subject: Java Preferences.app doesn't open anymore In-Reply-To: References: Message-ID: On May 25, 2012, at 7:54 AM, Tobias Bley wrote: > Hi, > > I don't know what I made wrong, but I removed Java6 and now the JavaPreferences.app doesn't start anymore :( Any suggestions? Even reinstall Java6 doen't work. > > Best regards, > Tobi If re-installing does not resolve the issue, I suppose the most relevant question to ask is: "how did you 'uninstall' Java SE 6"? Regards, Mike Swingler Apple Inc. From tobi at ultramixer.com Fri May 25 09:12:22 2012 From: tobi at ultramixer.com (Tobias Bley (UltraMixer)) Date: Fri, 25 May 2012 18:12:22 +0200 Subject: Java Preferences.app doesn't open anymore In-Reply-To: References: Message-ID: Yes, it simply delete Java SE 6 from /Library/Frameworks/Java.... So now when I try to start a Java application, Mac OS X brings up a the "java needed dialog" and tries to download Java. But it fails with the message that "... this software is currently not available"... So reinstalling doesn't resolve the issue :( Regards -- Tobias Bley Gesch?ftsf?hrer/ Managing Director ------------------------------------------------------------------------ Tel +49 351 - 264 49 86 Fax +49 180 - 366 50 05 ------------------------------------------------------------------------ UltraMixer Digital Audio Solutions Schillerstrasse 29 01326 Dresden ------------------------------------------------------------------------- info at ultramixer.com http://www.ultramixer.com Am 25.05.2012 um 17:59 schrieb Mike Swingler: > On May 25, 2012, at 7:54 AM, Tobias Bley wrote: > >> Hi, >> >> I don't know what I made wrong, but I removed Java6 and now the JavaPreferences.app doesn't start anymore :( Any suggestions? Even reinstall Java6 doen't work. >> >> Best regards, >> Tobi > > If re-installing does not resolve the issue, I suppose the most relevant question to ask is: "how did you 'uninstall' Java SE 6"? > > Regards, > Mike Swingler > Apple Inc. > From swingler at apple.com Fri May 25 09:20:09 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 25 May 2012 09:20:09 -0700 Subject: Java Preferences.app doesn't open anymore In-Reply-To: References: Message-ID: <99E85032-5E01-4FED-ADA7-0B3C996A6E63@apple.com> That path you provided is not accurate. I think you meant /System/Library/Java/JavaVirtualMachines, or /Library/Java/JavaVirtualMachines. We highly discourage you from tinkering with the contents of /System. If you run this manual installer, it should put your system back in a coherent state: . Regards, Mike Swingler Apple Inc. On May 25, 2012, at 9:12 AM, Tobias Bley (UltraMixer) wrote: > Yes, it simply delete Java SE 6 from /Library/Frameworks/Java.... > > So now when I try to start a Java application, Mac OS X brings up a the "java needed dialog" and tries to download Java. But it fails with the message that "... this software is currently not available"... > > So reinstalling doesn't resolve the issue :( > > Regards > > -- > Tobias Bley > Gesch?ftsf?hrer/ Managing Director > > ------------------------------------------------------------------------ > Tel +49 351 - 264 49 86 Fax +49 180 - 366 50 05 > ------------------------------------------------------------------------ > > UltraMixer Digital Audio Solutions > Schillerstrasse 29 > 01326 Dresden > > ------------------------------------------------------------------------- > info at ultramixer.com http://www.ultramixer.com > > Am 25.05.2012 um 17:59 schrieb Mike Swingler: > >> On May 25, 2012, at 7:54 AM, Tobias Bley wrote: >> >>> Hi, >>> >>> I don't know what I made wrong, but I removed Java6 and now the JavaPreferences.app doesn't start anymore :( Any suggestions? Even reinstall Java6 doen't work. >>> >>> Best regards, >>> Tobi >> >> If re-installing does not resolve the issue, I suppose the most relevant question to ask is: "how did you 'uninstall' Java SE 6"? >> >> Regards, >> Mike Swingler >> Apple Inc. >> > From tobi at ultramixer.com Fri May 25 09:52:34 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 25 May 2012 18:52:34 +0200 Subject: Java Preferences.app doesn't open anymore In-Reply-To: <99E85032-5E01-4FED-ADA7-0B3C996A6E63@apple.com> References: <99E85032-5E01-4FED-ADA7-0B3C996A6E63@apple.com> Message-ID: <047BEE4D-00F9-4429-B7F4-651934F85CB1@ultramixer.com> When I try to start the PKG file a dialogs appears and tells me that the "JavaLaunching.framework" is broken. How can I reinstall this private framework Mike? Best regards, -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com Am 25.05.2012 um 18:20 schrieb Mike Swingler : > That path you provided is not accurate. I think you meant /System/Library/Java/JavaVirtualMachines, or /Library/Java/JavaVirtualMachines. We highly discourage you from tinkering with the contents of /System. > > If you run this manual installer, it should put your system back in a coherent state: . > > Regards, > Mike Swingler > Apple Inc. > > On May 25, 2012, at 9:12 AM, Tobias Bley (UltraMixer) wrote: > >> Yes, it simply delete Java SE 6 from /Library/Frameworks/Java.... >> >> So now when I try to start a Java application, Mac OS X brings up a the "java needed dialog" and tries to download Java. But it fails with the message that "... this software is currently not available"... >> >> So reinstalling doesn't resolve the issue :( >> >> Regards >> >> -- >> Tobias Bley >> Gesch?ftsf?hrer/ Managing Director >> >> ------------------------------------------------------------------------ >> Tel +49 351 - 264 49 86 Fax +49 180 - 366 50 05 >> ------------------------------------------------------------------------ >> >> UltraMixer Digital Audio Solutions >> Schillerstrasse 29 >> 01326 Dresden >> >> ------------------------------------------------------------------------- >> info at ultramixer.com http://www.ultramixer.com >> >> Am 25.05.2012 um 17:59 schrieb Mike Swingler: >> >>> On May 25, 2012, at 7:54 AM, Tobias Bley wrote: >>> >>>> Hi, >>>> >>>> I don't know what I made wrong, but I removed Java6 and now the JavaPreferences.app doesn't start anymore :( Any suggestions? Even reinstall Java6 doen't work. >>>> >>>> Best regards, >>>> Tobi >>> >>> If re-installing does not resolve the issue, I suppose the most relevant question to ask is: "how did you 'uninstall' Java SE 6"? >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> >> > From Sergey.Bylokhov at oracle.com Fri May 25 12:07:05 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 May 2012 23:07:05 +0400 Subject: [7u6] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() In-Reply-To: <4FBF5DB6.2050506@oracle.com> References: <4FBF5DB6.2050506@oracle.com> Message-ID: <4FBFD859.7090608@oracle.com> Hi, Andrew. Fix looks good. 25.05.2012 14:23, Andrew Brygin wrote: > Hello, > > could you please review a backport of the fix for 7146550 to 7u6? > > The fix is almost the same as for jdk8, it just adds helper method > imageToArray to CImage class. This method was introduced in jdk8 as > a part of the fix for 7148275 ([macosx] setIconImages() not working > correctly (distorted icon when minimized)). Note that 7148275 was > fixed in 7u4 and 7u6 in a different manner, there seems to be no > need for complete backport of the jdk8 revision of the fix for 7148275. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 > Jdk8 changeset: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a2d12ca36eb3 > Webrev: http://cr.openjdk.java.net/~bae/7146550/7u6/webrev.00/ > > Thanks, > Andrew -- Best regards, Sergey. From swingler at apple.com Fri May 25 12:22:40 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 25 May 2012 12:22:40 -0700 Subject: Java Preferences.app doesn't open anymore In-Reply-To: <047BEE4D-00F9-4429-B7F4-651934F85CB1@ultramixer.com> References: <99E85032-5E01-4FED-ADA7-0B3C996A6E63@apple.com> <047BEE4D-00F9-4429-B7F4-651934F85CB1@ultramixer.com> Message-ID: JavaLaunching is included in that manual .pkg, and should overwrite the existing one on your disk. If you can't even get though the installer, I don't know how to rescue your system. You have probably made enough accidental changes that even installing the full set of all Java frameworks and the runtime .jdk itself probably won't undo the damage. My suggestion is a clean system install. And don't mess with /System. Really. Regards, Mike Swingler Apple Inc. On May 25, 2012, at 9:52 AM, Tobias Bley wrote: > When I try to start the PKG file a dialogs appears and tells me that the "JavaLaunching.framework" is broken. How can I reinstall this private framework Mike? > > Best regards, > > -- > Tobias Bley > Chief Executive Officer > > -------------------------------------------------------- > > UltraMixer Digital Audio Solutions > Schillerstra?e 29 > D-01326 Dresden > Germany > > -------------------------------------------------------- > bley at ultramixer.com http://www.ultramixer.com > > > > Am 25.05.2012 um 18:20 schrieb Mike Swingler : > >> That path you provided is not accurate. I think you meant /System/Library/Java/JavaVirtualMachines, or /Library/Java/JavaVirtualMachines. We highly discourage you from tinkering with the contents of /System. >> >> If you run this manual installer, it should put your system back in a coherent state: . >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On May 25, 2012, at 9:12 AM, Tobias Bley (UltraMixer) wrote: >> >>> Yes, it simply delete Java SE 6 from /Library/Frameworks/Java.... >>> >>> So now when I try to start a Java application, Mac OS X brings up a the "java needed dialog" and tries to download Java. But it fails with the message that "... this software is currently not available"... >>> >>> So reinstalling doesn't resolve the issue :( >>> >>> Regards >>> >>> -- >>> Tobias Bley >>> Gesch?ftsf?hrer/ Managing Director >>> >>> ------------------------------------------------------------------------ >>> Tel +49 351 - 264 49 86 Fax +49 180 - 366 50 05 >>> ------------------------------------------------------------------------ >>> >>> UltraMixer Digital Audio Solutions >>> Schillerstrasse 29 >>> 01326 Dresden >>> >>> ------------------------------------------------------------------------- >>> info at ultramixer.com http://www.ultramixer.com >>> >>> Am 25.05.2012 um 17:59 schrieb Mike Swingler: >>> >>>> On May 25, 2012, at 7:54 AM, Tobias Bley wrote: >>>> >>>>> Hi, >>>>> >>>>> I don't know what I made wrong, but I removed Java6 and now the JavaPreferences.app doesn't start anymore :( Any suggestions? Even reinstall Java6 doen't work. >>>>> >>>>> Best regards, >>>>> Tobi >>>> >>>> If re-installing does not resolve the issue, I suppose the most relevant question to ask is: "how did you 'uninstall' Java SE 6"? >>>> >>>> Regards, >>>> Mike Swingler >>>> Apple Inc. >>>> >>> >> > From lordpixel at me.com Sat May 26 07:36:37 2012 From: lordpixel at me.com (Andrew Thompson) Date: Sat, 26 May 2012 10:36:37 -0400 Subject: System properties In-Reply-To: References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> <4FBABDF7.2050507@oracle.com> <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> <4FBADD45.3000600@oracle.com> <4FBAF311.70609@oracle.com> Message-ID: Apologies if this is already obvious to everyone reading, but let me state clearly why I think changing this may be a problem. The JVM's default encoding is used whenever one converts bytes to text without explicitly specifying an encoding. To be honest, that's a bad practice, but sometimes unavoidable. Consider this problem statement: Given an arbitrary 'plain text file' correctly determine its encoding and read its contents into a Java String. Now, in many domains there exists information to help you e.g: - if the file came from a web server, the web server may have set an HTTP header which specifies the encoding (maybe it is even the right one!) - if you wrote the file originally, hopefully you know the encoding [but see below] - if the file is in some known format, e.g. its an XML file, then the file itself contains the encoding on the first line (again, maybe it is even correct!) But in general the problem is a hard one. Given an _arbitrary_ file there is no good way to know the right answer. The web browser vendors implemented some sophisticated heuristic sniffers (universal charset detectors) which would work OK some percentage of the time but often get it wrong. As I recall, Apple originally gave a rationale for using MacRoman as the default on US English systems... from 1984 thru 2001 when OS X came out, pretty much every text file created on a US or UK English Macintosh computer would have been encoded in MacRoman. So, statistically, assuming users would mostly open more files from their own machine than not, Mac Roman made sense and would continue to do so for a while as many people took years to move for OS 9 to OS X and continued to use older software that created Mac Roman files. Its now 2012 and most text editors default to UTF8 on OS X systems. Windows 7 is much more likely to use utf8 whereas previous versions used codepage 1252. One can argue the balance has shifted and utf8 is a universally good choice. Here's the thing though... if I have a program that uses the default encoding which I use today on Java 6 on a US Mac system, and I have saved a bunch of files on my computer, then when I launch the same program on Java 7 on the same computer and open the same files, some of the characters are going to be corrupted. One can argue the author of the program is at fault for not specifying the encoding explicitly, and indeed for allowing the program to use an ancient obsolete encoding like Mac Roman, but the user is stuck with a broken program either way. Of course, everything I've said probably applies to non-English systems to, just with some other old Mac text encoding. And it probably also applies to programs that read text over the network and are sloppy about encodings there too. Honestly, I think we probably are at a point where this change makes sense. More than a decade has passed. But at the very least it should *never* *ever* be US ASCII in any shipping build (which would be going backwards from MacRoman) and it really *should* be in the release notes, because this is not a small change, though it is a subtle one. Its fair to make an explicit choice to do this, its not a good idea to do it by accident. On May 21, 2012, at 10:29 PM, Michael Hall wrote: > > On May 21, 2012, at 8:59 PM, Xueming Shen wrote: > >> My apology, I mean if run jvm in C or POSIX locale, the file.encoding is set to US-ASCII by Oracle 7u4/7u6, which >> is expected. > > OK, I'm finding some information on this. I will have to do some more follow up reading up on this to determine what locale applies to my running of the jvm unless someone happens to know? > I guess as you say it still comes down to whether or not this should be in effect. That is the jvm is run with the C locale, then no bug report for file.encoding US-ASCII. > If not, my locale should not be C/POSIX, then there should be a bug report as I should be UTF-8. > Again, MacRoman no longer applies, period, which was what I originally questioned. But the rationale for the change pertaining to locale is interesting. 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 mik3hall at gmail.com Sat May 26 15:17:44 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 26 May 2012 17:17:44 -0500 Subject: System properties In-Reply-To: References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> <4FBABDF7.2050507@oracle.com> <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> <4FBADD45.3000600@oracle.com> <4FBAF311.70609@oracle.com> Message-ID: On May 26, 2012, at 9:34 AM, Andrew Thompson wrote: > Honestly, I think we probably are at a point where this change makes sense. More than a decade has passed. But at the very least it should *never* *ever* be US ASCII in any shipping build (which would be going backwards from MacRoman) and it really *should* be in the release notes, because this is not a small change, though it is a subtle one. Its fair to make an explicit choice to do this, its not a good idea to do it by accident. Not sure why you're cross-posting back to java-dev. Hasn't been MRJ for a while has it? Fwiw, I downloaded the Oracle JDK . This property, file.encoding, remains the same, that is set as US-ASCII. Somewhat interestingly maybe, if I do a locale in Terminal I get? locale LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" ?for a bunch of other LC_ If I do it from my application?. exec locale LANG= LC_COLLATE="C" ?and again a bunch of other LC_ set the same. I think it was said earlier that if you were using the C/POSIX locale then the US-ASCII setting is right? The following I think confirms that I"m picking up the Oracle JRE. The openjdk build, Is that what your build is Henri?, that build has been set os.arch=universal set os.arch os.arch=x86_64 From lordpixel at me.com Sat May 26 15:56:15 2012 From: lordpixel at me.com (Andrew Thompson) Date: Sat, 26 May 2012 18:56:15 -0400 Subject: System properties In-Reply-To: References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> <4FBABDF7.2050507@oracle.com> <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> <4FBADD45.3000600@oracle.com> <4FBAF311.70609@oracle.com> Message-ID: <79E3033E-DAFD-43BE-ACB3-F16F1E30158C@me.com> On May 26, 2012, at 6:17 PM, Michael Hall wrote: > > On May 26, 2012, at 9:34 AM, Andrew Thompson wrote: > >> Honestly, I think we probably are at a point where this change makes sense. More than a decade has passed. But at the very least it should *never* *ever* be US ASCII in any shipping build (which would be going backwards from MacRoman) and it really *should* be in the release notes, because this is not a small change, though it is a subtle one. Its fair to make an explicit choice to do this, its not a good idea to do it by accident. > > Not sure why you're cross-posting back to java-dev. Hasn't been MRJ for a while has it? Well, yes, I have been around for a while. I never updated the local name for the java-dev mailing list. To be honest I was hoping Mike Swingler might confirm or correct what I had to say. Speaking of which, I realized I didn't read your original post closely enough. Running this public static void main(String[] args) { System.out.println(Charset.defaultCharset()); Properties p = System.getProperties(); for (Object key : p.keySet()) { if ( key.toString().contains(".io") || key.toString().contains("file") || key.toString().contains("encoding")) { System.out.println(key + ": " + p.get(key)); } } } On Apple's Java 6 on a US system yields file.encoding.pkg: sun.io java.io.tmpdir: /var/folders/7m/7mim+FSkH-OUDOW+xuAhk++++TM/-Tmp-/ sun.jnu.encoding: MacRoman file.encoding: UTF-8 file.separator: / sun.io.unicode.encoding: UnicodeLittle I had been assuming you were referring to file.encoding changing from MacRoman to UTF-8, but clearly it has been UTF-8 for a while. Googling around sun.jnu.encoding ... it turns out to be an undocumented property that influences things like parsing the command line. Clearly a much less important thing to change. Basically, nothing to see here. Apologies for all the noise. AndyT From mik3hall at gmail.com Sat May 26 16:09:28 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 26 May 2012 18:09:28 -0500 Subject: System properties In-Reply-To: <79E3033E-DAFD-43BE-ACB3-F16F1E30158C@me.com> References: <540739C6-5364-45EC-BEAE-079C40A11C8A@gmail.com> <94EAA236-F9F7-4E49-8040-5F78113C67A7@apple.com> <39B42CE8-B141-4DAC-AE12-9ECDD14784BA@oracle.com> <4FBABDF7.2050507@oracle.com> <37C46F45-90F4-4E14-B3D2-13C15928F984@gmail.com> <4FBADD45.3000600@oracle.com> <4FBAF311.70609@oracle.com> <79E3033E-DAFD-43BE-ACB3-F16F1E30158C@me.com> Message-ID: <6AB8A208-CF1F-4FDE-8C11-CFB7671BD1C5@gmail.com> On May 26, 2012, at 5:56 PM, Andrew Thompson wrote: > I had been assuming you were referring to file.encoding changing from MacRoman to UTF-8, but clearly it has been UTF-8 for a while. > Googling around sun.jnu.encoding ... it turns out to be an undocumented property that influences things like parsing the command line. > Clearly a much less important thing to change. Basically, nothing to see here. Apologies for all the noise. Dropping java-dev? In the interest of accuracy. There still seems to be some differences in our respective properties. For me as I think I already said Java 6 gives file.encoding = MacRoman. No where is it UTF-8. Including Java 7 where it is US-ASCII for both openjdk and Oracle builds as I just said. As far as I know, it isn't breaking anything for me so I guess I still don't plan to file a bug report. Sorry for the additional noise but I think the information should at least be accurate and java 6 for me is not UTF-8 file.encoding. From wmoore40 at gmail.com Sun May 27 13:49:42 2012 From: wmoore40 at gmail.com (William Moore) Date: Sun, 27 May 2012 22:49:42 +0200 Subject: System properties In-Reply-To: References: Message-ID: Hi I ran this on my system and got the following: Apple Java 6: Default character set: MacRoman file.encoding.pkg: sun.io java.io.tmpdir: /var/folders/q6/q4kmcx3114z41thjlh_0x9f00000gn/T/ sun.jnu.encoding: MacRoman file.encoding: MacRoman file.separator: / sun.io.unicode.encoding: UnicodeLittle OpenJDK 7 Update 2: Default character set: UTF-8 file.encoding.pkg: sun.io java.io.tmpdir: /var/folders/q6/q4kmcx3114z41thjlh_0x9f00000gn/T/ sun.jnu.encoding: UTF-8 file.encoding: UTF-8 file.separator: / sun.io.unicode.encoding: UnicodeBig I'm not clear what you mean by "a US system", but it does not seem to me that "it has been UTF-8 for a while". Are there setting somewhere to control these values? William On 26 May 2012, at 8:56pm, Andrew Thompson wrote: > On May 26, 2012, at 6:17 PM, Michael Hall wrote: > >> >> On May 26, 2012, at 9:34 AM, Andrew Thompson wrote: >> >>> Honestly, I think we probably are at a point where this change makes sense. More than a decade has passed. But at the very least it should *never* *ever* be US ASCII in any shipping build (which would be going backwards from MacRoman) and it really *should* be in the release notes, because this is not a small change, though it is a subtle one. Its fair to make an explicit choice to do this, its not a good idea to do it by accident. >> >> Not sure why you're cross-posting back to java-dev. Hasn't been MRJ for a while has it? > > Well, yes, I have been around for a while. I never updated the local name for the java-dev mailing list. To be honest I was hoping Mike Swingler might confirm or correct what I had to say. > > Speaking of which, I realized I didn't read your original post closely enough. Running this > > public static void main(String[] args) { > System.out.println(Charset.defaultCharset()); > Properties p = System.getProperties(); > for (Object key : p.keySet()) { > if ( key.toString().contains(".io") || key.toString().contains("file") || key.toString().contains("encoding")) { > System.out.println(key + ": " + p.get(key)); > } > } > } > > > On Apple's Java 6 on a US system yields > > file.encoding.pkg: sun.io > java.io.tmpdir: /var/folders/7m/7mim+FSkH-OUDOW+xuAhk++++TM/-Tmp-/ > sun.jnu.encoding: MacRoman > file.encoding: UTF-8 > file.separator: / > sun.io.unicode.encoding: UnicodeLittle > > I had been assuming you were referring to file.encoding changing from MacRoman to UTF-8, but clearly it has been UTF-8 for a while. > Googling around sun.jnu.encoding ... it turns out to be an undocumented property that influences things like parsing the command line. > Clearly a much less important thing to change. Basically, nothing to see here. Apologies for all the noise. > > AndyT From mik3hall at gmail.com Sun May 27 15:46:53 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 27 May 2012 17:46:53 -0500 Subject: System properties In-Reply-To: References: Message-ID: > I mean if run jvm in C or POSIX locale, the file.encoding is set to US-ASCII by Oracle 7u4/7u6, which > is expected. > > -Sherman OK, since locale has been indicated as the determiner. Consider?. public class LocaleTester { public static void main(String[] args) { System.out.println("java.version="+System.getProperty("java.version")); System.out.println("file.encoding="+System.getProperty("file.encoding")); System.out.println(rtexec(new String[] { "locale" })); } private static String rtexec(String[] args) { try { StringBuilder execout = new StringBuilder(); Process proc = Runtime.getRuntime().exec(args); proc.waitFor(); java.io.InputStream inout = proc.getInputStream(); java.io.InputStream inerr = proc.getErrorStream(); byte []buffer = new byte[256]; while (true) { int stderrLen = inerr.read(buffer, 0, buffer.length); if (stderrLen > 0) { execout.append(new String(buffer,0,stderrLen)); } int stdoutLen = inout.read(buffer, 0, buffer.length); if (stdoutLen > 0) { execout.append(new String(buffer,0,stdoutLen)); } if (stderrLen < 0 && stdoutLen < 0) break; } return execout.toString(); } catch(Throwable tossed) { tossed.printStackTrace(); } return "-"; } } Run Terminal 1..7 (Should be an Oracle build at the moment) /usr/libexec/java_home -v 1.7 --exec java LocaleTester java.version=1.7.0_04 file.encoding=UTF-8 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= Run Terminal 1.6 /usr/libexec/java_home -v 1.6 --exec java LocaleTester java.version=1.6.0_31 file.encoding=MacRoman 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= Run using built-in functionality from my application (Again for this should be a Oracle 1.7 build) set java.version java.version=1.7.0_04 set file.encoding file.encoding=US-ASCII exec locale LANG= LC_COLLATE="C" LC_CTYPE="C" LC_MESSAGES="C" LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_ALL= 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. 1.7 gives UTF-8 or US-ASCII depending on how it is run. From Terminal command line you get UTF-8. From an application for some reason you get the C/POSIX locale and get US-ASCII for the encoding. According to Xueming Shen who I'm guessing has some Java responsibility involving these things, all of this is correct for the given locale's except as I recall he agreed the prior MacRoman might be problematic. To which Andrew Thompson's other points may of course be valid and worth being addressed. I still have no problems or issues but a little curiosity as to why command line java and application java are run differently involving different locale's and ending up with different properties? From xueming.shen at oracle.com Sun May 27 18:29:17 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 27 May 2012 18:29:17 -0700 Subject: System properties In-Reply-To: References: Message-ID: <4FC2D4ED.2000403@oracle.com> On 5/27/2012 3:46 PM, Michael Hall wrote: >> I mean if run jvm in C or POSIX locale, the file.encoding is set to US-ASCII by Oracle 7u4/7u6, which >> is expected. >> >> -Sherman > OK, since locale has been indicated as the determiner. > > Consider?. > > public class LocaleTester { > > public static void main(String[] args) { > System.out.println("java.version="+System.getProperty("java.version")); > System.out.println("file.encoding="+System.getProperty("file.encoding")); > System.out.println(rtexec(new String[] { "locale" })); > } > > private static String rtexec(String[] args) { > try { > StringBuilder execout = new StringBuilder(); > Process proc = Runtime.getRuntime().exec(args); > proc.waitFor(); > java.io.InputStream inout = proc.getInputStream(); > java.io.InputStream inerr = proc.getErrorStream(); > byte []buffer = new byte[256]; > while (true) { > int stderrLen = inerr.read(buffer, 0, buffer.length); > if (stderrLen> 0) { > execout.append(new String(buffer,0,stderrLen)); > } > int stdoutLen = inout.read(buffer, 0, buffer.length); > if (stdoutLen> 0) { > execout.append(new String(buffer,0,stdoutLen)); > } > if (stderrLen< 0&& stdoutLen< 0) > break; > } > return execout.toString(); > } > catch(Throwable tossed) { tossed.printStackTrace(); } > return "-"; > } > } > > Run Terminal 1..7 (Should be an Oracle build at the moment) > /usr/libexec/java_home -v 1.7 --exec java LocaleTester > java.version=1.7.0_04 > file.encoding=UTF-8 > 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= > > Run Terminal 1.6 > /usr/libexec/java_home -v 1.6 --exec java LocaleTester > java.version=1.6.0_31 > file.encoding=MacRoman > 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= > > Run using built-in functionality from my application (Again for this should be a Oracle 1.7 build) > set java.version > java.version=1.7.0_04 > set file.encoding > file.encoding=US-ASCII > exec locale > LANG= > LC_COLLATE="C" > LC_CTYPE="C" > LC_MESSAGES="C" > LC_MONETARY="C" > LC_NUMERIC="C" > LC_TIME="C" > LC_ALL= > > 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. > > 1.7 gives UTF-8 or US-ASCII depending on how it is run. From Terminal command line you get UTF-8. > From an application for some reason you get the C/POSIX locale and get US-ASCII for the encoding. > > According to Xueming Shen who I'm guessing has some Java responsibility involving these things, all of this is correct for the given locale's except as I recall he agreed the prior MacRoman might be problematic. To which Andrew Thompson's other points may of course be valid and worth being addressed. > I still have no problems or issues but a little curiosity as to why command line java and application java are run differently involving different locale's and ending up with different properties? > Yes, file.encoding is set based on the locale that the jvm is running on, and if you run your java vm in xxxx.UTF-8 locale, the file.encoding should be UTF-8, set to MacRoman will be problematic. So I believe Oracle/OpenJDK7 behaves correctly. That said, as Andrew Thompson pointed out, if all previous Apple JDK releases use MacRoman as the file.encoding for english/UTF-8 locale, there is a "compatibility" concern here, it might worth putting something in the release note to give Oracle/OpenJDK MacOS user a heads up. sun.jnu.encoding should be the same as the file.encoding on Unix-like platform. That "internal" encoding is introduced in jdk6(? if I remember correctly) to address the different system locale and user locale setting problem on Windows platform, in which the system locale and user locale are set to different one, so the encoding for file "content" is not the same as the encoding used by Windows' "A" version APIs (ansi version, vs the "W"/unicode version). Again, this is an internal property/implementation detail, never ever try to use it in your app:-) I don't know how your "application java" works, but normally on a Unix platform, it is NOT unusual to run those system scripts in C locale, actually I think most of them run in C locale, this is something "configurable" (default system locale). My guess is that either your "application" is configured to run in C locale or your system has configured to have the C locale as its default system locale and your "application" runs in this default locale (again, it's USUAL, if your "application" is some "service provider" kind of app, such as a httpd, for example). Therefor any process (including the Java) started from your "application" inherits the C as its running locale. -Sherman From andrew.brygin at oracle.com Mon May 28 02:00:35 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Mon, 28 May 2012 13:00:35 +0400 Subject: [7u6] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() In-Reply-To: <4FBFAC5B.9040906@oracle.com> References: <4FBF5DB6.2050506@oracle.com> <4FBF869C.3040909@oracle.com> <4FBF9594.9090202@oracle.com> <4FBFAC5B.9040906@oracle.com> Message-ID: <4FC33EB3.1060403@oracle.com> Hi Artem, I have submitted bug 7172180 against AWT in order to track discussed clarification for the spec. Thanks, Andrew On 25.05.2012 19:59, Artem Ananiev wrote: > Hi, Andrew, > > thanks for this clarification. I'm fine with the fix then as it makes > AWT behave consistently on all the platforms. > > Could you file a new (likely low priority) bug about startDrag() > specification against AWT, please? > > Thanks, > > Artem > > On 5/25/2012 6:22 PM, Andrew Brygin wrote: >> Hi Artem, >> >> the spec does not defines how we should handle the drag image. We >> probably can not delay >> startDrag() operation in order to prepare the image, because it may take >> noticeable time (or >> hangs infinitely as a corner case, and the test implements this >> scenario). At least, we do >> behave in such manner on windows. >> >> Also, it seems to be logical to put all methods related to CImage >> production to CImage.Creator >> class. So, there we need to have two ways to convert a toolkit image to >> CImage: >> * 'immediate': returns null if toolkit image is not ready >> * 'normal': prepare toolkit image before conversion >> >> We likely need some kind of spec clarification for startDrag(), in order >> to define how should we >> handle toolkit images which are not ready: wait and prepare, silently >> ignore, or throw an exception. >> >> At the moment, this fix just makes our behavior on different platforms a >> bit more consistent. >> >> Thanks, >> Andrew >> >> >> On 25.05.2012 17:18, Artem Ananiev wrote: >>> Hi, Andrew, >>> >>> I didn't participate in the fix review for JDK8, so could you explain >>> the purpose of that createFromImageImmediately() method in CImage, >>> please? Why having createFromImage(), which always waits until the >>> image is ready, and additional checks for w > 0 and h > 0 is not >>> enough? >>> >>> Thanks, >>> >>> Artem >>> >>> On 5/25/2012 2:23 PM, Andrew Brygin wrote: >>>> Hello, >>>> >>>> could you please review a backport of the fix for 7146550 to 7u6? >>>> >>>> The fix is almost the same as for jdk8, it just adds helper method >>>> imageToArray to CImage class. This method was introduced in jdk8 as >>>> a part of the fix for 7148275 ([macosx] setIconImages() not working >>>> correctly (distorted icon when minimized)). Note that 7148275 was >>>> fixed in 7u4 and 7u6 in a different manner, there seems to be no >>>> need for complete backport of the jdk8 revision of the fix for >>>> 7148275. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 >>>> Jdk8 changeset: >>>> http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a2d12ca36eb3 >>>> Webrev: http://cr.openjdk.java.net/~bae/7146550/7u6/webrev.00/ >>>> >>>> Thanks, >>>> Andrew >> From artem.ananiev at oracle.com Mon May 28 03:09:51 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 28 May 2012 14:09:51 +0400 Subject: [7u6] request for review: 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() In-Reply-To: <4FC33EB3.1060403@oracle.com> References: <4FBF5DB6.2050506@oracle.com> <4FBF869C.3040909@oracle.com> <4FBF9594.9090202@oracle.com> <4FBFAC5B.9040906@oracle.com> <4FC33EB3.1060403@oracle.com> Message-ID: <4FC34EEF.8070209@oracle.com> On 5/28/2012 1:00 PM, Andrew Brygin wrote: > Hi Artem, > > I have submitted bug 7172180 against AWT in order to track discussed > clarification for the spec. Thanks. Artem > Thanks, > Andrew > > On 25.05.2012 19:59, Artem Ananiev wrote: >> Hi, Andrew, >> >> thanks for this clarification. I'm fine with the fix then as it makes >> AWT behave consistently on all the platforms. >> >> Could you file a new (likely low priority) bug about startDrag() >> specification against AWT, please? >> >> Thanks, >> >> Artem >> >> On 5/25/2012 6:22 PM, Andrew Brygin wrote: >>> Hi Artem, >>> >>> the spec does not defines how we should handle the drag image. We >>> probably can not delay >>> startDrag() operation in order to prepare the image, because it may take >>> noticeable time (or >>> hangs infinitely as a corner case, and the test implements this >>> scenario). At least, we do >>> behave in such manner on windows. >>> >>> Also, it seems to be logical to put all methods related to CImage >>> production to CImage.Creator >>> class. So, there we need to have two ways to convert a toolkit image to >>> CImage: >>> * 'immediate': returns null if toolkit image is not ready >>> * 'normal': prepare toolkit image before conversion >>> >>> We likely need some kind of spec clarification for startDrag(), in order >>> to define how should we >>> handle toolkit images which are not ready: wait and prepare, silently >>> ignore, or throw an exception. >>> >>> At the moment, this fix just makes our behavior on different platforms a >>> bit more consistent. >>> >>> Thanks, >>> Andrew >>> >>> >>> On 25.05.2012 17:18, Artem Ananiev wrote: >>>> Hi, Andrew, >>>> >>>> I didn't participate in the fix review for JDK8, so could you explain >>>> the purpose of that createFromImageImmediately() method in CImage, >>>> please? Why having createFromImage(), which always waits until the >>>> image is ready, and additional checks for w > 0 and h > 0 is not >>>> enough? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 5/25/2012 2:23 PM, Andrew Brygin wrote: >>>>> Hello, >>>>> >>>>> could you please review a backport of the fix for 7146550 to 7u6? >>>>> >>>>> The fix is almost the same as for jdk8, it just adds helper method >>>>> imageToArray to CImage class. This method was introduced in jdk8 as >>>>> a part of the fix for 7148275 ([macosx] setIconImages() not working >>>>> correctly (distorted icon when minimized)). Note that 7148275 was >>>>> fixed in 7u4 and 7u6 in a different manner, there seems to be no >>>>> need for complete backport of the jdk8 revision of the fix for >>>>> 7148275. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7146550 >>>>> Jdk8 changeset: >>>>> http://hg.openjdk.java.net/jdk8/2d/jdk/rev/a2d12ca36eb3 >>>>> Webrev: http://cr.openjdk.java.net/~bae/7146550/7u6/webrev.00/ >>>>> >>>>> Thanks, >>>>> Andrew >>> > From artem.ananiev at oracle.com Mon May 28 05:46:29 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 28 May 2012 16:46:29 +0400 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: References: Message-ID: <4FC373A5.9030508@oracle.com> 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 Mon May 28 07:06:38 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 28 May 2012 18:06:38 +0400 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: <4FC373A5.9030508@oracle.com> References: <4FC373A5.9030508@oracle.com> Message-ID: <89803632-78F2-410F-B66B-09AEFC8CAB11@oracle.com> 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. 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 marco.dinacci at gmail.com Mon May 28 07:36:31 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Mon, 28 May 2012 15:36:31 +0100 Subject: apple.awt.fileDialogForDirectories property not working. Message-ID: Hi, the apple.awt.fileDialogForDirectories property is not honoured neither with OpenJDK nor with Oracle JDK 7u4. The following program will work with Java 6 but not with the above mentioned distributions: import java.awt.FileDialog; import java.io.File; import javax.swing.JFrame; public class FileDialogTest extends JFrame { public String selectFolder() { FileDialog fd = new FileDialog(this, "Select Folder Test", FileDialog.LOAD); fd.setDirectory(System.getProperty("user.home")); fd.setLocation(50,50); fd.setVisible(true); return fd.getFile(); } public static void main(String[] args) { System.setProperty("apple.awt.fileDialogForDirectories", "true"); FileDialogTest fdt = new FileDialogTest(); String selectedFolder = fdt.selectFolder(); System.out.println("The selected file was: " + selectedFolder); System.setProperty("apple.awt.fileDialogForDirectories", "false"); System.exit(0); } } The expected result is to be able to select a directory, the actual result is that the file chooser enter the directory. The Apple documentation states: By default, the AWT File Dialog lets you choose a file. Under certain circumstances, however, it may be proper for you to choose a directory instead. If that is the case, set this property to allow for directory selection in a file dialog. The default value is false. Shall I file a bug ? Best, Marco From niagarasoft20-macosxportdev at yahoo.com Mon May 28 08:03:06 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Mon, 28 May 2012 08:03:06 -0700 (PDT) Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: References: Message-ID: <1338217386.58223.YahooMailNeo@web126004.mail.ne1.yahoo.com> Hello Marco, I did file a bug for this and it was placed on the back burner. See here. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 I personally feel this is a mistake, as it does not take into consideration the special mac FileDialog features that would be left out, creating an obvious platform specific UI hole. Aside from personally hacking the awt.FileDialog file, I see no other recourse but to use the JFileChooser as a work-around which frankly does not work as well on the mac as is quite lame. Regards, Mike >________________________________ > From: Marco Dinacci >To: macosx-port-dev Port OS X >Sent: Monday, May 28, 2012 10:36 AM >Subject: apple.awt.fileDialogForDirectories property not working. > >Hi, > >the apple.awt.fileDialogForDirectories property is not honoured >neither with OpenJDK nor with Oracle JDK 7u4. >The following program will work with Java 6 but not with the above >mentioned distributions: > >import java.awt.FileDialog; >import java.io.File; >import javax.swing.JFrame; > >public class FileDialogTest extends JFrame { > >? ? public String selectFolder() { >? ? ? ? FileDialog fd = new FileDialog(this, "Select Folder Test", >FileDialog.LOAD); >? ? ? ? fd.setDirectory(System.getProperty("user.home")); >? ? ? ? fd.setLocation(50,50); >? ? ? ? fd.setVisible(true); > >? ? ? ? return fd.getFile(); >? ? } > >? ? public static void main(String[] args) { >? ? ? ? System.setProperty("apple.awt.fileDialogForDirectories", "true"); > >? ? ? ? FileDialogTest fdt = new FileDialogTest(); >? ? ? ? String selectedFolder = fdt.selectFolder(); > >? ? ? ? System.out.println("The selected file was: " + selectedFolder); > >? ? ? ? System.setProperty("apple.awt.fileDialogForDirectories", "false"); >? ? ? ? System.exit(0); >? ? } > >} > >The expected result is to be able to select a directory, the actual >result is that the file chooser enter the directory. > >The Apple documentation states: > >By default, the AWT File Dialog lets you choose a file. Under certain >circumstances, however, it may be proper for you to choose a directory >instead. If that is the case, set this property to allow for directory >selection in a file dialog. > >The default value is false. > > >Shall I file a bug ? > >Best, >Marco > > > From anthony.petrov at oracle.com Mon May 28 08:07:26 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 28 May 2012 19:07:26 +0400 Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: References: Message-ID: <4FC394AE.4050306@oracle.com> Hi Marco, This is a known issue: 7161437. Although it is closed as a duplicate of a more general AWT RFE 6927978 that proposes to add public API for DirectoryDialogs to AWT. -- best regards, Anthony On 05/28/12 18:36, Marco Dinacci wrote: > Hi, > > the apple.awt.fileDialogForDirectories property is not honoured > neither with OpenJDK nor with Oracle JDK 7u4. > The following program will work with Java 6 but not with the above > mentioned distributions: > > import java.awt.FileDialog; > import java.io.File; > import javax.swing.JFrame; > > public class FileDialogTest extends JFrame { > > public String selectFolder() { > FileDialog fd = new FileDialog(this, "Select Folder Test", > FileDialog.LOAD); > fd.setDirectory(System.getProperty("user.home")); > fd.setLocation(50,50); > fd.setVisible(true); > > return fd.getFile(); > } > > public static void main(String[] args) { > System.setProperty("apple.awt.fileDialogForDirectories", "true"); > > FileDialogTest fdt = new FileDialogTest(); > String selectedFolder = fdt.selectFolder(); > > System.out.println("The selected file was: " + selectedFolder); > > System.setProperty("apple.awt.fileDialogForDirectories", "false"); > System.exit(0); > } > > } > > The expected result is to be able to select a directory, the actual > result is that the file chooser enter the directory. > > The Apple documentation states: > > By default, the AWT File Dialog lets you choose a file. Under certain > circumstances, however, it may be proper for you to choose a directory > instead. If that is the case, set this property to allow for directory > selection in a file dialog. > > The default value is false. > > > Shall I file a bug ? > > Best, > Marco From marco.dinacci at gmail.com Mon May 28 08:11:23 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Mon, 28 May 2012 16:11:23 +0100 Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: <1338217386.58223.YahooMailNeo@web126004.mail.ne1.yahoo.com> References: <1338217386.58223.YahooMailNeo@web126004.mail.ne1.yahoo.com> Message-ID: Hi, > I did file a bug for this and it was placed on the back burner. See here. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 thanks. > Aside from personally hacking the awt.FileDialog file, I see no other recourse but to use the JFileChooser as a work-around which frankly does not work as well on the mac as is quite lame. It's worse than that, the JFileChooser won't work if the application is in a sandbox so I can't use it. Which leaves as only solution hacking the awt.FileDialog... Best, Marco From niagarasoft20-macosxportdev at yahoo.com Mon May 28 08:23:48 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Mon, 28 May 2012 08:23:48 -0700 (PDT) Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: References: <1338217386.58223.YahooMailNeo@web126004.mail.ne1.yahoo.com> Message-ID: <1338218628.65962.YahooMailNeo@web126003.mail.ne1.yahoo.com> Hi Marco, Can you clarify the sandbox issue? Mike It's worse than that, the JFileChooser won't work if the application >is in a sandbox so I can't use it. > >Which leaves as only solution hacking the awt.FileDialog... > > From artem.ananiev at oracle.com Mon May 28 08:35:11 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 28 May 2012 19:35:11 +0400 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: <89803632-78F2-410F-B66B-09AEFC8CAB11@oracle.com> References: <4FC373A5.9030508@oracle.com> <89803632-78F2-410F-B66B-09AEFC8CAB11@oracle.com> Message-ID: <4FC39B2F.6070805@oracle.com> 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 marco.dinacci at gmail.com Mon May 28 08:39:36 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Mon, 28 May 2012 16:39:36 +0100 Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: <1338218628.65962.YahooMailNeo@web126003.mail.ne1.yahoo.com> References: <1338217386.58223.YahooMailNeo@web126004.mail.ne1.yahoo.com> <1338218628.65962.YahooMailNeo@web126003.mail.ne1.yahoo.com> Message-ID: Hi, JFileChooser doesn't use a native dialog so it won't be able to list any directory except I guess for the container (~/Library/Containers/myapp/Data) and any special directories listed in the entitlements file. I just bundled and signed an app with the code below the result is a JFileChooser listing my home directory and not showing any icon: mport javax.swing.JFrame; import java.io.File; import javax.swing.JFileChooser; public class FileChooserTest extends JFrame { public String selectFolder() { JFileChooser chooser = new JFileChooser(System.getProperty("user.home")); chooser.showOpenDialog(this); //chooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY); return chooser.getSelectedFile().getAbsolutePath(); } public static void main(String[] args) { System.setProperty("apple.awt.fileDialogForDirectories", "true"); FileChooserTest fdt = new FileChooserTest(); String selectedFolder = fdt.selectFolder(); System.out.println("The selected file was: " + selectedFolder); System.setProperty("apple.awt.fileDialogForDirectories", "false"); System.exit(0); } } Best, Marco On 28 May 2012 16:23, niagarasoft20-macosxportdev at yahoo.com wrote: > Hi Marco, > > Can you clarify the sandbox issue? > > Mike > > It's worse than that, the JFileChooser won't work if the application > is in a sandbox so I can't use it. > > Which leaves as only solution hacking the awt.FileDialog... > From niagarasoft20-macosxportdev at yahoo.com Mon May 28 09:52:16 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Mon, 28 May 2012 09:52:16 -0700 (PDT) Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: <4FC394AE.4050306@oracle.com> References: <4FC394AE.4050306@oracle.com> Message-ID: <1338223936.78830.YahooMailNeo@web126004.mail.ne1.yahoo.com> Anthony, this is fine, however, would it be possible to raise the level of importance of the request given the sandbox issue on the Mac and the larger number of users that it would affect resulting from the new mac platform requirements? Right now the level is set to 4-Low. The bug 6927978 was initially submitted on 19-FEB-2010. Is there any hope that this will be implemented by Mac 10.8 release this summer? Mike >________________________________ > From: Anthony Petrov >To: Marco Dinacci >Cc: macosx-port-dev Port OS X >Sent: Monday, May 28, 2012 11:07 AM >Subject: Re: apple.awt.fileDialogForDirectories property not working. > >Hi Marco, > >This is a known issue: 7161437. Although it is closed as a duplicate of >a more general AWT RFE 6927978 that proposes to add public API for >DirectoryDialogs to AWT. > >-- >best regards, >Anthony > >On 05/28/12 18:36, Marco Dinacci wrote: >> Hi, >> >> the apple.awt.fileDialogForDirectories property is not honoured >> neither with OpenJDK nor with Oracle JDK 7u4. >> The following program will work with Java 6 but not with the above >> mentioned distributions: >> >> import java.awt.FileDialog; >> import java.io.File; >> import javax.swing.JFrame; >> >> public class FileDialogTest extends JFrame { >> >>? ? ? public String selectFolder() { >>? ? ? ? ? FileDialog fd = new FileDialog(this, "Select Folder Test", >> FileDialog.LOAD); >>? ? ? ? ? fd.setDirectory(System.getProperty("user.home")); >>? ? ? ? ? fd.setLocation(50,50); >>? ? ? ? ? fd.setVisible(true); >> >>? ? ? ? ? return fd.getFile(); >>? ? ? } >> >>? ? ? public static void main(String[] args) { >>? ? ? ? ? System.setProperty("apple.awt.fileDialogForDirectories", "true"); >> >>? ? ? ? ? FileDialogTest fdt = new FileDialogTest(); >>? ? ? ? ? String selectedFolder = fdt.selectFolder(); >> >>? ? ? ? ? System.out.println("The selected file was: " + selectedFolder); >> >>? ? ? ? ? System.setProperty("apple.awt.fileDialogForDirectories", "false"); >>? ? ? ? ? System.exit(0); >>? ? ? } >> >> } >> >> The expected result is to be able to select a directory, the actual >> result is that the file chooser enter the directory. >> >> The Apple documentation states: >> >> By default, the AWT File Dialog lets you choose a file. Under certain >> circumstances, however, it may be proper for you to choose a directory >> instead. If that is the case, set this property to allow for directory >> selection in a file dialog. >> >> The default value is false. >> >> >> Shall I file a bug ? >> >> Best, >> Marco > > > From tobi at ultramixer.com Mon May 28 23:49:10 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 29 May 2012 08:49:10 +0200 Subject: Java Preferences.app doesn't open anymore In-Reply-To: References: <99E85032-5E01-4FED-ADA7-0B3C996A6E63@apple.com> <047BEE4D-00F9-4429-B7F4-651934F85CB1@ultramixer.com> Message-ID: <3C4C9A65-34E4-4F7D-BF6B-DA0F194CB223@ultramixer.com> Hi Mike, thanks for your help. I could resolve the problem by reinstalling Mac 10.8... Best regards, Tobi Am 25.05.2012 um 21:22 schrieb Mike Swingler : > JavaLaunching is included in that manual .pkg, and should overwrite the existing one on your disk. If you can't even get though the installer, I don't know how to rescue your system. You have probably made enough accidental changes that even installing the full set of all Java frameworks and the runtime .jdk itself probably won't undo the damage. > > My suggestion is a clean system install. And don't mess with /System. Really. > > Regards, > Mike Swingler > Apple Inc. > > On May 25, 2012, at 9:52 AM, Tobias Bley wrote: > >> When I try to start the PKG file a dialogs appears and tells me that the "JavaLaunching.framework" is broken. How can I reinstall this private framework Mike? >> >> Best regards, >> >> -- >> Tobias Bley >> Chief Executive Officer >> >> -------------------------------------------------------- >> >> UltraMixer Digital Audio Solutions >> Schillerstra?e 29 >> D-01326 Dresden >> Germany >> >> -------------------------------------------------------- >> bley at ultramixer.com http://www.ultramixer.com >> >> >> >> Am 25.05.2012 um 18:20 schrieb Mike Swingler : >> >>> That path you provided is not accurate. I think you meant /System/Library/Java/JavaVirtualMachines, or /Library/Java/JavaVirtualMachines. We highly discourage you from tinkering with the contents of /System. >>> >>> If you run this manual installer, it should put your system back in a coherent state: . >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> >>> On May 25, 2012, at 9:12 AM, Tobias Bley (UltraMixer) wrote: >>> >>>> Yes, it simply delete Java SE 6 from /Library/Frameworks/Java.... >>>> >>>> So now when I try to start a Java application, Mac OS X brings up a the "java needed dialog" and tries to download Java. But it fails with the message that "... this software is currently not available"... >>>> >>>> So reinstalling doesn't resolve the issue :( >>>> >>>> Regards >>>> >>>> -- >>>> Tobias Bley >>>> Gesch?ftsf?hrer/ Managing Director >>>> >>>> ------------------------------------------------------------------------ >>>> Tel +49 351 - 264 49 86 Fax +49 180 - 366 50 05 >>>> ------------------------------------------------------------------------ >>>> >>>> UltraMixer Digital Audio Solutions >>>> Schillerstrasse 29 >>>> 01326 Dresden >>>> >>>> ------------------------------------------------------------------------- >>>> info at ultramixer.com http://www.ultramixer.com >>>> >>>> Am 25.05.2012 um 17:59 schrieb Mike Swingler: >>>> >>>>> On May 25, 2012, at 7:54 AM, Tobias Bley wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I don't know what I made wrong, but I removed Java6 and now the JavaPreferences.app doesn't start anymore :( Any suggestions? Even reinstall Java6 doen't work. >>>>>> >>>>>> Best regards, >>>>>> Tobi >>>>> >>>>> If re-installing does not resolve the issue, I suppose the most relevant question to ask is: "how did you 'uninstall' Java SE 6"? >>>>> >>>>> Regards, >>>>> Mike Swingler >>>>> Apple Inc. >>>>> >>>> >>> >> > From niagarasoft20-macosxportdev at yahoo.com Tue May 29 06:52:10 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Tue, 29 May 2012 06:52:10 -0700 (PDT) Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: References: <1338217386.58223.YahooMailNeo@web126004.mail.ne1.yahoo.com> <1338218628.65962.YahooMailNeo@web126003.mail.ne1.yahoo.com> Message-ID: <1338299530.78078.YahooMailNeo@web126005.mail.ne1.yahoo.com> Marco, Please file this as a? bug . The user should be able to choose their own directory on a mac when using the JFileChooser. If this is the case, it's pretty serious problem. Regards Mike >________________________________ > From: Marco Dinacci >To: "niagarasoft20-macosxportdev at yahoo.com" >Cc: macosx-port-dev Port OS X >Sent: Monday, May 28, 2012 11:39 AM >Subject: Re: apple.awt.fileDialogForDirectories property not working. > >Hi, > >JFileChooser doesn't use a native dialog so it won't be able to list >any directory except I guess for the container >(~/Library/Containers/myapp/Data) and any special directories listed >in the entitlements file. > >I just bundled and signed an app with the code below? the result is a >JFileChooser listing my home directory and not showing any icon: > >mport javax.swing.JFrame; >import java.io.File; >import javax.swing.JFileChooser; > >public? class FileChooserTest extends JFrame { > >? ? public String selectFolder() { >? ? ? JFileChooser chooser = new JFileChooser(System.getProperty("user.home")); >? ? ? chooser.showOpenDialog(this); >? ? ? //chooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY); >? ? ? return chooser.getSelectedFile().getAbsolutePath(); > >? ? } > >? ? public static void main(String[] args) { >? ? ? ? System.setProperty("apple.awt.fileDialogForDirectories", "true"); > >? ? ? ? FileChooserTest fdt = new FileChooserTest(); >? ? ? ? String selectedFolder = fdt.selectFolder(); > >? ? ? ? System.out.println("The selected file was: " + selectedFolder); > >? ? ? ? System.setProperty("apple.awt.fileDialogForDirectories", "false"); >? ? ? ? System.exit(0); >? ? } > >} > > >Best, >Marco > > >On 28 May 2012 16:23, niagarasoft20-macosxportdev at yahoo.com > wrote: >> Hi Marco, >> >> Can you clarify the sandbox issue? >> >> Mike >> >> It's worse than that, the JFileChooser won't work if the application >> is in a sandbox so I can't use it. >> >> Which leaves as only solution hacking the awt.FileDialog... >> > > > From scott.kovatch at oracle.com Tue May 29 07:20:49 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 29 May 2012 07:20:49 -0700 Subject: About JObjC... Message-ID: <7E4F8804-E99D-4270-834E-4511C5C8D313@oracle.com> Folks, A question this morning about JObjC reminded me of something I want to propose to the list. Given that JObjC is a Mac OS X-only technology, it's not clear to me that it belongs in the full JDK. Nothing in the JDK itself uses it, and it contributes about 500k to the overall runtime. That's not a lot, compared to the 62 MB for all of rt.jar, but every little bit helps. With Java 8 coming, JObjC looks like a good candidate for modularization. It has no dependencies of its own, and isn't used enough to warrant putting it into the core. That way, if you want it you can include it in your applications, and you won't have to pay the cost of including it if you don't. I'm inclined to say we shouldn't be building it into 7uX's rt.jar, but given the size it may not be worth the effort. Any opinions? -- Scott From michael.x.mcmahon at oracle.com Tue May 29 07:45:48 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 29 May 2012 15:45:48 +0100 Subject: About JObjC... In-Reply-To: <7E4F8804-E99D-4270-834E-4511C5C8D313@oracle.com> References: <7E4F8804-E99D-4270-834E-4511C5C8D313@oracle.com> Message-ID: <4FC4E11C.2030906@oracle.com> On 29/05/12 15:20, Scott Kovatch wrote: > Folks, > > A question this morning about JObjC reminded me of something I want to propose to the list. Given that JObjC is a Mac OS X-only technology, it's not clear to me that it belongs in the full JDK. Nothing in the JDK itself uses it, and it contributes about 500k to the overall runtime. That's not a lot, compared to the 62 MB for all of rt.jar, but every little bit helps. > > With Java 8 coming, JObjC looks like a good candidate for modularization. It has no dependencies of its own, and isn't used enough to warrant putting it into the core. That way, if you want it you can include it in your applications, and you won't have to pay the cost of including it if you don't. > > I'm inclined to say we shouldn't be building it into 7uX's rt.jar, but given the size it may not be worth the effort. > > Any opinions? > > -- Scott > Is it not building into a separate jar file? jobjc.jar (or something similar) ... I agree though it is a good candidate for inclusion in its own module in 8. - Michael. From greg.x.brown at oracle.com Tue May 29 07:52:59 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Tue, 29 May 2012 10:52:59 -0400 Subject: About JObjC... In-Reply-To: <7E4F8804-E99D-4270-834E-4511C5C8D313@oracle.com> References: <7E4F8804-E99D-4270-834E-4511C5C8D313@oracle.com> Message-ID: <6239E398-0304-473C-BDBA-4F2F1D95ECB4@oracle.com> > A question this morning about JObjC reminded me of something I want to propose to the list. Given that JObjC is a Mac OS X-only technology, it's not clear to me that it belongs in the full JDK. Nothing in the JDK itself uses it, and it contributes about 500k to the overall runtime. That's not a lot, compared to the 62 MB for all of rt.jar, but every little bit helps. I think this makes a lot of sense. On my system, JObjC.jar is actually about 2.5MB (though that is uncompressed - maybe you are referring to the download size). G From scott.kovatch at oracle.com Tue May 29 08:38:09 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 29 May 2012 08:38:09 -0700 Subject: About JObjC... In-Reply-To: <4FC4E11C.2030906@oracle.com> References: <7E4F8804-E99D-4270-834E-4511C5C8D313@oracle.com> <4FC4E11C.2030906@oracle.com> Message-ID: <32698268-CC7B-46ED-96F5-663A2A4FF6A0@oracle.com> On May 29, 2012, at 7:45 AM, Michael McMahon wrote: > On 29/05/12 15:20, Scott Kovatch wrote: >> Folks, >> >> A question this morning about JObjC reminded me of something I want to propose to the list. Given that JObjC is a Mac OS X-only technology, it's not clear to me that it belongs in the full JDK. Nothing in the JDK itself uses it, and it contributes about 500k to the overall runtime. That's not a lot, compared to the 62 MB for all of rt.jar, but every little bit helps. >> >> With Java 8 coming, JObjC looks like a good candidate for modularization. It has no dependencies of its own, and isn't used enough to warrant putting it into the core. That way, if you want it you can include it in your applications, and you won't have to pay the cost of including it if you don't. >> >> I'm inclined to say we shouldn't be building it into 7uX's rt.jar, but given the size it may not be worth the effort. >> >> Any opinions? >> >> -- Scott >> > Is it not building into a separate jar file? jobjc.jar (or something similar) ... > > I agree though it is a good candidate for inclusion in its own module in 8. Oh, I take it back -- yes, it is currently being built into JObjC.jar. I missed it at first because it's capitalized, and doesn't show up with the rest of the JAR files. It's about 2.4 MB. And come to think of it, I've been advising people to leave it out of their bundles and had Greg leave it out of the default JRE set in appbundler, so clearly I knew this already. :-\ Maybe I'm not feeling as well as I thought. I'm still jet-lagged from a long trip and not 100% this morning. Modularizing JObjC needs a bug so it gets done in time for 8. -- Scott K. From marco.dinacci at gmail.com Tue May 29 08:50:22 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Tue, 29 May 2012 16:50:22 +0100 Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: <1338299530.78078.YahooMailNeo@web126005.mail.ne1.yahoo.com> References: <1338217386.58223.YahooMailNeo@web126004.mail.ne1.yahoo.com> <1338218628.65962.YahooMailNeo@web126003.mail.ne1.yahoo.com> <1338299530.78078.YahooMailNeo@web126005.mail.ne1.yahoo.com> Message-ID: Hi Mike, > Please file this as a? bug . The user should be able to choose their own > directory on a mac when using the JFileChooser. If this is the case, it's > pretty serious problem. I can certainly file a bug but I wonder if there is a solution. AFAIK the only way to make the JFileChooser sandbox-proof would be to use internally an NSOpenPanel but the whole point of the JFileChooser is to be a lightweight component, as opposed to FileDialog. I wish too that the priority of the FileDialog RFE could be elevated or that at least 7161437 could be fixed first. Best, Marco From leonid.romanov at oracle.com Tue May 29 09:59:57 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 29 May 2012 20:59:57 +0400 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: <4FC39B2F.6070805@oracle.com> References: <4FC373A5.9030508@oracle.com> <89803632-78F2-410F-B66B-09AEFC8CAB11@oracle.com> <4FC39B2F.6070805@oracle.com> Message-ID: <32533319-5E00-483F-AE69-6E79419C3757@oracle.com> 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 marco.dinacci at gmail.com Tue May 29 10:03:27 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Tue, 29 May 2012 18:03:27 +0100 Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: <4FC394AE.4050306@oracle.com> References: <4FC394AE.4050306@oracle.com> Message-ID: Hi Anthony, > This is a known issue: 7161437. Although it is closed as a duplicate of a > more general AWT RFE 6927978 that proposes to add public API for > DirectoryDialogs to AWT. I understand that 7161437 is closed but since it's more than two years that the RFE has been submitted and all I need really is just the fix for the 7161437, here's a patch that actually fixes it. I don't know if it's the best way to do it but this is certainly good enough for my application. After the diff there's a test case. I hope it can be useful. diff -r 6432464ffec2 src/macosx/classes/sun/lwawt/macosx/CFileDialog.java --- a/src/macosx/classes/sun/lwawt/macosx/CFileDialog.java Sat May 26 08:01:40 2012 -0700 +++ b/src/macosx/classes/sun/lwawt/macosx/CFileDialog.java Tue May 29 17:56:51 2012 +0100 @@ -49,20 +49,28 @@ class CFileDialog implements FileDialogP navigateApps = true; String title = target.getTitle(); if (title == null) { title = " "; } + String chooseDirectoriesValue = System.getProperty("apple.awt.fileDialogForDirectories"); + boolean chooseDirectories = false; + if(chooseDirectoriesValue != null && + chooseDirectoriesValue.equalsIgnoreCase("true")) { + chooseDirectories = true; + } + String[] userFileNames = nativeRunFileDialog(title, dialogMode, target.isMultipleMode(), navigateApps, + chooseDirectories, target.getFilenameFilter() != null, target.getDirectory(), target.getFile()); String directory = null; String file = null; File[] files = null; @@ -137,18 +145,18 @@ class CFileDialog implements FileDialogP File directoryObj = new File(fileObj.getParent()); String nameOnly = fileObj.getName(); ret = ff.accept(directoryObj, nameOnly); } return ret; } private native String[] nativeRunFileDialog(String title, int mode, - boolean multipleMode, boolean shouldNavigateApps, boolean hasFilenameFilter, - String directory, String file); + boolean multipleMode, boolean shouldNavigateApps, boolean canChooseDirectories, + boolean hasFilenameFilter, String directory, String file); @Override public void setDirectory(String dir) { } @Override public void setFile(String file) { } diff -r 6432464ffec2 src/macosx/native/sun/awt/CFileDialog.h --- a/src/macosx/native/sun/awt/CFileDialog.h Sat May 26 08:01:40 2012 -0700 +++ b/src/macosx/native/sun/awt/CFileDialog.h Tue May 29 17:56:51 2012 +0100 @@ -47,16 +47,19 @@ jint fMode; // Indicates whether the user can select multiple files BOOL fMultipleMode; // Should we navigate into apps? BOOL fNavigateApps; + // Can the dialog choose directories ? + BOOL fChooseDirectories; + // Contains the absolute paths of the selected files as URLs NSArray *fURLs; } // Allocator - (id) initWithFilter:(jboolean)inHasFilter fileDialog:(jobject)inDialog title:(NSString *)inTitle diff -r 6432464ffec2 src/macosx/native/sun/awt/CFileDialog.m --- a/src/macosx/native/sun/awt/CFileDialog.m Sat May 26 08:01:40 2012 -0700 +++ b/src/macosx/native/sun/awt/CFileDialog.m Tue May 29 17:56:51 2012 +0100 @@ -38,30 +38,32 @@ - (id)initWithFilter:(jboolean)inHasFilter fileDialog:(jobject)inDialog title:(NSString *)inTitle directory:(NSString *)inPath file:(NSString *)inFile mode:(jint)inMode multipleMode:(BOOL)inMultipleMode shouldNavigate:(BOOL)inNavigateApps +canChooseDirectories:(BOOL)inChooseDirectories withEnv:(JNIEnv*)env; { if (self == [super init]) { fHasFileFilter = inHasFilter; fFileDialog = JNFNewGlobalRef(env, inDialog); fDirectory = inPath; [fDirectory retain]; fFile = inFile; [fFile retain]; fTitle = inTitle; [fTitle retain]; fMode = inMode; fMultipleMode = inMultipleMode; fNavigateApps = inNavigateApps; + fChooseDirectories = inChooseDirectories; fPanelResult = NSCancelButton; } return self; } -(void) disposer { if (fFileDialog != NULL) { @@ -104,17 +106,17 @@ if (fNavigateApps) { [thePanel setTreatsFilePackagesAsDirectories:YES]; } if (fMode == java_awt_FileDialog_LOAD) { NSOpenPanel *openPanel = (NSOpenPanel *)thePanel; [openPanel setAllowsMultipleSelection:fMultipleMode]; [openPanel setCanChooseFiles:YES]; - [openPanel setCanChooseDirectories:NO]; + [openPanel setCanChooseDirectories:fChooseDirectories]; [openPanel setCanCreateDirectories:YES]; } [thePanel setDelegate:self]; fPanelResult = [thePanel runModalForDirectory:fDirectory file:fFile]; [thePanel setDelegate:nil]; if ([self userClickedOK]) { @@ -177,17 +179,17 @@ * Class: sun_lwawt_macosx_CFileDialog * Method: nativeRunFileDialog * Signature: (Ljava/lang/String;ILjava/io/FilenameFilter; * Ljava/lang/String;Ljava/lang/String;)[Ljava/lang/String; */ JNIEXPORT jobjectArray JNICALL Java_sun_lwawt_macosx_CFileDialog_nativeRunFileDialog (JNIEnv *env, jobject peer, jstring title, jint mode, jboolean multipleMode, - jboolean navigateApps, jboolean hasFilter, jstring directory, jstring file) + jboolean navigateApps, jboolean chooseDirectories, jboolean hasFilter, jstring directory, jstring file) { jobjectArray returnValue = NULL; JNF_COCOA_ENTER(env); NSString *dialogTitle = JNFJavaToNSString(env, title); if ([dialogTitle length] == 0) { dialogTitle = @" "; } @@ -195,16 +197,17 @@ JNF_COCOA_ENTER(env); CFileDialog *dialogDelegate = [[CFileDialog alloc] initWithFilter:hasFilter fileDialog:peer title:dialogTitle directory:JNFJavaToNSString(env, directory) file:JNFJavaToNSString(env, file) mode:mode multipleMode:multipleMode shouldNavigate:navigateApps + canChooseDirectories:chooseDirectories withEnv:env]; [JNFRunLoop performOnMainThread:@selector(safeSaveOrLoad) on:dialogDelegate withObject:nil waitUntilDone:YES]; if ([dialogDelegate userClickedOK]) { Test case: import java.awt.FileDialog; import java.io.File; import javax.swing.JFrame; public class FileDialogTest extends JFrame { public String selectFolder() { FileDialog fd = new FileDialog(this, "Select Folder Test", FileDialog.LOAD); fd.setDirectory(System.getProperty("user.home")); fd.setLocation(50,50); fd.setVisible(true); return fd.getFile(); } public static void main(String[] args) { System.setProperty("apple.awt.fileDialogForDirectories", "true"); FileDialogTest fdt = new FileDialogTest(); String selectedFolder = fdt.selectFolder(); System.out.println("The selected file was: " + selectedFolder); System.setProperty("apple.awt.fileDialogForDirectories", "false"); System.exit(0); } } Best, Marco From Sergey.Bylokhov at oracle.com Tue May 29 10:19:37 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 May 2012 21:19:37 +0400 Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: <1338223936.78830.YahooMailNeo@web126004.mail.ne1.yahoo.com> References: <4FC394AE.4050306@oracle.com> <1338223936.78830.YahooMailNeo@web126004.mail.ne1.yahoo.com> Message-ID: <4FC50529.10808@oracle.com> Hi, Mike. I guess that there is no chance to implement it in 7u6 which should be released this summer. Probably we can implement some functionality for mac in 7u8. Priority was raised. 28.05.2012 20:52, niagarasoft20-macosxportdev at yahoo.com wrote: > Anthony, this is fine, however, would it be possible to raise the level of importance of the request given the sandbox issue on the Mac and the larger number of users that it would affect resulting from the new mac platform requirements? > > Right now the level is set to 4-Low. The bug 6927978 was initially submitted on 19-FEB-2010. Is there any hope that this will be implemented by Mac 10.8 release this summer? > > > Mike > > > > >> ________________________________ >> From: Anthony Petrov >> To: Marco Dinacci >> Cc: macosx-port-dev Port OS X >> Sent: Monday, May 28, 2012 11:07 AM >> Subject: Re: apple.awt.fileDialogForDirectories property not working. >> >> Hi Marco, >> >> This is a known issue: 7161437. Although it is closed as a duplicate of >> a more general AWT RFE 6927978 that proposes to add public API for >> DirectoryDialogs to AWT. >> >> -- >> best regards, >> Anthony >> >> On 05/28/12 18:36, Marco Dinacci wrote: >>> Hi, >>> >>> the apple.awt.fileDialogForDirectories property is not honoured >>> neither with OpenJDK nor with Oracle JDK 7u4. >>> The following program will work with Java 6 but not with the above >>> mentioned distributions: >>> >>> import java.awt.FileDialog; >>> import java.io.File; >>> import javax.swing.JFrame; >>> >>> public class FileDialogTest extends JFrame { >>> >>> public String selectFolder() { >>> FileDialog fd = new FileDialog(this, "Select Folder Test", >>> FileDialog.LOAD); >>> fd.setDirectory(System.getProperty("user.home")); >>> fd.setLocation(50,50); >>> fd.setVisible(true); >>> >>> return fd.getFile(); >>> } >>> >>> public static void main(String[] args) { >>> System.setProperty("apple.awt.fileDialogForDirectories", "true"); >>> >>> FileDialogTest fdt = new FileDialogTest(); >>> String selectedFolder = fdt.selectFolder(); >>> >>> System.out.println("The selected file was: " + selectedFolder); >>> >>> System.setProperty("apple.awt.fileDialogForDirectories", "false"); >>> System.exit(0); >>> } >>> >>> } >>> >>> The expected result is to be able to select a directory, the actual >>> result is that the file chooser enter the directory. >>> >>> The Apple documentation states: >>> >>> By default, the AWT File Dialog lets you choose a file. Under certain >>> circumstances, however, it may be proper for you to choose a directory >>> instead. If that is the case, set this property to allow for directory >>> selection in a file dialog. >>> >>> The default value is false. >>> >>> >>> Shall I file a bug ? >>> >>> Best, >>> Marco >> >> -- Best regards, Sergey. From swingler at apple.com Tue May 29 10:00:22 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 29 May 2012 10:00:22 -0700 Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: <1338299530.78078.YahooMailNeo@web126005.mail.ne1.yahoo.com> References: <1338217386.58223.YahooMailNeo@web126004.mail.ne1.yahoo.com> <1338218628.65962.YahooMailNeo@web126003.mail.ne1.yahoo.com> <1338299530.78078.YahooMailNeo@web126005.mail.ne1.yahoo.com> Message-ID: Sandboxing, by it's nature, prevents access to the user's general home directory. It restricts access to all but a very narrow per-app directory hidden within the user's home directory. The viable alternative for the Swing API is to simply delegate to the AWT dialog (or a customized native dialog which better implements the Swing JFileChooser features) when run under sandboxing. A truly TCK compliant JFileChooser is simply not possible in the sandboxed environment - or at least in a form that will go anywhere interesting on the file system. Regards, Mike Swingler Apple Inc. On May 29, 2012, at 6:52 AM, niagarasoft20-macosxportdev at yahoo.com wrote: > Marco, > > Please file this as a bug . The user should be able to choose their own directory on a mac when using the JFileChooser. If this is the case, it's pretty serious problem. > > > Regards > Mike > > > > >> ________________________________ >> From: Marco Dinacci >> To: "niagarasoft20-macosxportdev at yahoo.com" >> Cc: macosx-port-dev Port OS X >> Sent: Monday, May 28, 2012 11:39 AM >> Subject: Re: apple.awt.fileDialogForDirectories property not working. >> >> Hi, >> >> JFileChooser doesn't use a native dialog so it won't be able to list >> any directory except I guess for the container >> (~/Library/Containers/myapp/Data) and any special directories listed >> in the entitlements file. >> >> I just bundled and signed an app with the code below the result is a >> JFileChooser listing my home directory and not showing any icon: >> >> mport javax.swing.JFrame; >> import java.io.File; >> import javax.swing.JFileChooser; >> >> public class FileChooserTest extends JFrame { >> >> public String selectFolder() { >> JFileChooser chooser = new JFileChooser(System.getProperty("user.home")); >> chooser.showOpenDialog(this); >> //chooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY); >> return chooser.getSelectedFile().getAbsolutePath(); >> >> } >> >> public static void main(String[] args) { >> System.setProperty("apple.awt.fileDialogForDirectories", "true"); >> >> FileChooserTest fdt = new FileChooserTest(); >> String selectedFolder = fdt.selectFolder(); >> >> System.out.println("The selected file was: " + selectedFolder); >> >> System.setProperty("apple.awt.fileDialogForDirectories", "false"); >> System.exit(0); >> } >> >> } >> >> >> Best, >> Marco >> >> >> On 28 May 2012 16:23, niagarasoft20-macosxportdev at yahoo.com >> wrote: >>> Hi Marco, >>> >>> Can you clarify the sandbox issue? >>> >>> Mike >>> >>> It's worse than that, the JFileChooser won't work if the application >>> is in a sandbox so I can't use it. >>> >>> Which leaves as only solution hacking the awt.FileDialog... >>> >> >> >> From swingler at apple.com Tue May 29 10:22:38 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 29 May 2012 10:22:38 -0700 Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: References: <4FC394AE.4050306@oracle.com> Message-ID: Looks good to me...it's basically what was stripped out of our original contribution. Regards, Mike Swingler Apple Inc. On May 29, 2012, at 10:03 AM, Marco Dinacci wrote: > Hi Anthony, > >> This is a known issue: 7161437. Although it is closed as a duplicate of a >> more general AWT RFE 6927978 that proposes to add public API for >> DirectoryDialogs to AWT. > > I understand that 7161437 is closed but since it's more than two years > that the RFE has been submitted and all I need really is just the fix > for the 7161437, here's a patch that actually fixes it. I don't know > if it's the best way to do it but this is certainly good enough for my > application. After the diff there's a test case. I hope it can be > useful. > > diff -r 6432464ffec2 src/macosx/classes/sun/lwawt/macosx/CFileDialog.java > --- a/src/macosx/classes/sun/lwawt/macosx/CFileDialog.java Sat May 26 > 08:01:40 2012 -0700 > +++ b/src/macosx/classes/sun/lwawt/macosx/CFileDialog.java Tue May 29 > 17:56:51 2012 +0100 > @@ -49,20 +49,28 @@ class CFileDialog implements FileDialogP > > navigateApps = true; > > String title = target.getTitle(); > if (title == null) { > title = " "; > } > > + String chooseDirectoriesValue = > System.getProperty("apple.awt.fileDialogForDirectories"); > + boolean chooseDirectories = false; > + if(chooseDirectoriesValue != null && > + chooseDirectoriesValue.equalsIgnoreCase("true")) { > + chooseDirectories = true; > + } > + > String[] userFileNames = nativeRunFileDialog(title, > dialogMode, > target.isMultipleMode(), > navigateApps, > + chooseDirectories, > target.getFilenameFilter() != null, > target.getDirectory(), > target.getFile()); > > String directory = null; > String file = null; > File[] files = null; > > @@ -137,18 +145,18 @@ class CFileDialog implements FileDialogP > File directoryObj = new File(fileObj.getParent()); > String nameOnly = fileObj.getName(); > ret = ff.accept(directoryObj, nameOnly); > } > return ret; > } > > private native String[] nativeRunFileDialog(String title, int mode, > - boolean multipleMode, boolean shouldNavigateApps, boolean > hasFilenameFilter, > - String directory, String file); > + boolean multipleMode, boolean shouldNavigateApps, boolean > canChooseDirectories, > + boolean hasFilenameFilter, String directory, String file); > > @Override > public void setDirectory(String dir) { > } > > @Override > public void setFile(String file) { > } > diff -r 6432464ffec2 src/macosx/native/sun/awt/CFileDialog.h > --- a/src/macosx/native/sun/awt/CFileDialog.h Sat May 26 08:01:40 2012 -0700 > +++ b/src/macosx/native/sun/awt/CFileDialog.h Tue May 29 17:56:51 2012 +0100 > @@ -47,16 +47,19 @@ > jint fMode; > > // Indicates whether the user can select multiple files > BOOL fMultipleMode; > > // Should we navigate into apps? > BOOL fNavigateApps; > > + // Can the dialog choose directories ? > + BOOL fChooseDirectories; > + > // Contains the absolute paths of the selected files as URLs > NSArray *fURLs; > } > > // Allocator > - (id) initWithFilter:(jboolean)inHasFilter > fileDialog:(jobject)inDialog > title:(NSString *)inTitle > diff -r 6432464ffec2 src/macosx/native/sun/awt/CFileDialog.m > --- a/src/macosx/native/sun/awt/CFileDialog.m Sat May 26 08:01:40 2012 -0700 > +++ b/src/macosx/native/sun/awt/CFileDialog.m Tue May 29 17:56:51 2012 +0100 > @@ -38,30 +38,32 @@ > - (id)initWithFilter:(jboolean)inHasFilter > fileDialog:(jobject)inDialog > title:(NSString *)inTitle > directory:(NSString *)inPath > file:(NSString *)inFile > mode:(jint)inMode > multipleMode:(BOOL)inMultipleMode > shouldNavigate:(BOOL)inNavigateApps > +canChooseDirectories:(BOOL)inChooseDirectories > withEnv:(JNIEnv*)env; > { > if (self == [super init]) { > fHasFileFilter = inHasFilter; > fFileDialog = JNFNewGlobalRef(env, inDialog); > fDirectory = inPath; > [fDirectory retain]; > fFile = inFile; > [fFile retain]; > fTitle = inTitle; > [fTitle retain]; > fMode = inMode; > fMultipleMode = inMultipleMode; > fNavigateApps = inNavigateApps; > + fChooseDirectories = inChooseDirectories; > fPanelResult = NSCancelButton; > } > > return self; > } > > -(void) disposer { > if (fFileDialog != NULL) { > @@ -104,17 +106,17 @@ > if (fNavigateApps) { > [thePanel setTreatsFilePackagesAsDirectories:YES]; > } > > if (fMode == java_awt_FileDialog_LOAD) { > NSOpenPanel *openPanel = (NSOpenPanel *)thePanel; > [openPanel setAllowsMultipleSelection:fMultipleMode]; > [openPanel setCanChooseFiles:YES]; > - [openPanel setCanChooseDirectories:NO]; > + [openPanel setCanChooseDirectories:fChooseDirectories]; > [openPanel setCanCreateDirectories:YES]; > } > > [thePanel setDelegate:self]; > fPanelResult = [thePanel runModalForDirectory:fDirectory file:fFile]; > [thePanel setDelegate:nil]; > > if ([self userClickedOK]) { > @@ -177,17 +179,17 @@ > * Class: sun_lwawt_macosx_CFileDialog > * Method: nativeRunFileDialog > * Signature: (Ljava/lang/String;ILjava/io/FilenameFilter; > * Ljava/lang/String;Ljava/lang/String;)[Ljava/lang/String; > */ > JNIEXPORT jobjectArray JNICALL > Java_sun_lwawt_macosx_CFileDialog_nativeRunFileDialog > (JNIEnv *env, jobject peer, jstring title, jint mode, jboolean multipleMode, > - jboolean navigateApps, jboolean hasFilter, jstring directory, jstring file) > + jboolean navigateApps, jboolean chooseDirectories, jboolean > hasFilter, jstring directory, jstring file) > { > jobjectArray returnValue = NULL; > > JNF_COCOA_ENTER(env); > NSString *dialogTitle = JNFJavaToNSString(env, title); > if ([dialogTitle length] == 0) { > dialogTitle = @" "; > } > @@ -195,16 +197,17 @@ JNF_COCOA_ENTER(env); > CFileDialog *dialogDelegate = [[CFileDialog alloc] initWithFilter:hasFilter > fileDialog:peer > > title:dialogTitle > > directory:JNFJavaToNSString(env, directory) > > file:JNFJavaToNSString(env, file) > mode:mode > > multipleMode:multipleMode > > shouldNavigate:navigateApps > + > canChooseDirectories:chooseDirectories > withEnv:env]; > > [JNFRunLoop performOnMainThread:@selector(safeSaveOrLoad) > on:dialogDelegate > withObject:nil > waitUntilDone:YES]; > > if ([dialogDelegate userClickedOK]) { > > > > Test case: > > import java.awt.FileDialog; > import java.io.File; > import javax.swing.JFrame; > > public class FileDialogTest extends JFrame { > > public String selectFolder() { > FileDialog fd = new FileDialog(this, "Select Folder Test", > FileDialog.LOAD); > fd.setDirectory(System.getProperty("user.home")); > fd.setLocation(50,50); > fd.setVisible(true); > > return fd.getFile(); > } > > public static void main(String[] args) { > System.setProperty("apple.awt.fileDialogForDirectories", "true"); > > FileDialogTest fdt = new FileDialogTest(); > String selectedFolder = fdt.selectFolder(); > > System.out.println("The selected file was: " + selectedFolder); > > System.setProperty("apple.awt.fileDialogForDirectories", "false"); > System.exit(0); > } > > } > > > Best, > Marco From dmclean at stsci.edu Tue May 29 13:56:07 2012 From: dmclean at stsci.edu (Donald McLean) Date: Tue, 29 May 2012 16:56:07 -0400 Subject: Location of ThaiInputMethod in JDK7 Message-ID: <4FC537E7.2050608@stsci.edu> For years I have experienced a problem where, when I run Java on a Mac, it wants the Thai input method. In the past, it was no problem - thaiim.jar was easy enough to find and move into the "lib/ext" directory. Where do I get thaiim.jar for JDK7 - it appears to have been moved, but I haven't been able to find out where and I'm still getting an error running a Swing app: java.util.ServiceConfigurationError So, where would I find thaiim.jar (or the source files, if necessary)? Thank you, Donald From naoto.sato at oracle.com Tue May 29 15:08:05 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 29 May 2012 15:08:05 -0700 Subject: Location of ThaiInputMethod in JDK7 In-Reply-To: <4FC537E7.2050608@stsci.edu> References: <4FC537E7.2050608@stsci.edu> Message-ID: <4FC548C5.40008@oracle.com> Thai IM was removed from the JRE with the following bug id: http://bugs.sun.com/view_bug.do?bug_id=6909002 Although I haven't seen the error myself, it sounds like a bug to me as the input method should not be required for just launching a Swing app. Can you elaborate your error more? Naoto On 12/05/29 13:56, Donald McLean wrote: > For years I have experienced a problem where, when I run Java on a Mac, > it wants the Thai input method. In the past, it was no problem - > thaiim.jar was easy enough to find and move into the "lib/ext" directory. > > Where do I get thaiim.jar for JDK7 - it appears to have been moved, but > I haven't been able to find out where and I'm still getting an error > running a Swing app: java.util.ServiceConfigurationError > > So, where would I find thaiim.jar (or the source files, if necessary)? > > Thank you, > > Donald > From dmclean at stsci.edu Tue May 29 15:26:13 2012 From: dmclean at stsci.edu (Donald McLean) Date: Tue, 29 May 2012 18:26:13 -0400 Subject: Location of ThaiInputMethod in JDK7 In-Reply-To: <4FC548C5.40008@oracle.com> References: <4FC537E7.2050608@stsci.edu> <4FC548C5.40008@oracle.com> Message-ID: <4FC54D05.1010709@stsci.edu> This is a problem that has been plaguing me for years. It has affected me on 5 different Macs (2 Mac Pros, 1 MacBook Pro, 1 iMac, 1 Mac Mini), Leopard, Snow Leopard and now Lion. I don't know the cause, but the symptom is that running a Swing app, the app suffers from all kinds of odd behaviors (keyboard shortcuts not working, windows not responding to mouse events) and I was finally able to isolate the problem to something that causes the app to want the Thai input method and throwing an exception when it doesn't find it. So in the past, I just install the Thai input method and forget about it. Well, I'm still having the problem (tried 7.0u4 and the 7.0u6 preview) except that now there's no Thai input method to be found. The IT department at my office was never able to find the root of the problem either. Thank you, Donald On 5/29/12 6:08 PM, Naoto Sato wrote: > Thai IM was removed from the JRE with the following bug id: > > http://bugs.sun.com/view_bug.do?bug_id=6909002 > > Although I haven't seen the error myself, it sounds like a bug to me as > the input method should not be required for just launching a Swing app. > Can you elaborate your error more? > > Naoto > > On 12/05/29 13:56, Donald McLean wrote: >> For years I have experienced a problem where, when I run Java on a Mac, >> it wants the Thai input method. In the past, it was no problem - >> thaiim.jar was easy enough to find and move into the "lib/ext" directory. >> >> Where do I get thaiim.jar for JDK7 - it appears to have been moved, but >> I haven't been able to find out where and I'm still getting an error >> running a Swing app: java.util.ServiceConfigurationError >> >> So, where would I find thaiim.jar (or the source files, if necessary)? From victor.dyakov at oracle.com Wed May 30 00:51:30 2012 From: victor.dyakov at oracle.com (Victor Dyakov) Date: Wed, 30 May 2012 11:51:30 +0400 Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: References: <4FC394AE.4050306@oracle.com> Message-ID: <4FC5D182.8040908@oracle.com> I've created the sub-CR targeted to 7u8 Thanks, Victor On 29.05.2012 21:22, Mike Swingler wrote: > Looks good to me...it's basically what was stripped out of our original contribution. > > Regards, > Mike Swingler > Apple Inc. > > On May 29, 2012, at 10:03 AM, Marco Dinacci wrote: > >> Hi Anthony, >> >>> This is a known issue: 7161437. Although it is closed as a duplicate of a >>> more general AWT RFE 6927978 that proposes to add public API for >>> DirectoryDialogs to AWT. >> I understand that 7161437 is closed but since it's more than two years >> that the RFE has been submitted and all I need really is just the fix >> for the 7161437, here's a patch that actually fixes it. I don't know >> if it's the best way to do it but this is certainly good enough for my >> application. After the diff there's a test case. I hope it can be >> useful. >> >> diff -r 6432464ffec2 src/macosx/classes/sun/lwawt/macosx/CFileDialog.java >> --- a/src/macosx/classes/sun/lwawt/macosx/CFileDialog.java Sat May 26 >> 08:01:40 2012 -0700 >> +++ b/src/macosx/classes/sun/lwawt/macosx/CFileDialog.java Tue May 29 >> 17:56:51 2012 +0100 >> @@ -49,20 +49,28 @@ class CFileDialog implements FileDialogP >> >> navigateApps = true; >> >> String title = target.getTitle(); >> if (title == null) { >> title = " "; >> } >> >> + String chooseDirectoriesValue = >> System.getProperty("apple.awt.fileDialogForDirectories"); >> + boolean chooseDirectories = false; >> + if(chooseDirectoriesValue != null&& >> + chooseDirectoriesValue.equalsIgnoreCase("true")) { >> + chooseDirectories = true; >> + } >> + >> String[] userFileNames = nativeRunFileDialog(title, >> dialogMode, >> target.isMultipleMode(), >> navigateApps, >> + chooseDirectories, >> target.getFilenameFilter() != null, >> target.getDirectory(), >> target.getFile()); >> >> String directory = null; >> String file = null; >> File[] files = null; >> >> @@ -137,18 +145,18 @@ class CFileDialog implements FileDialogP >> File directoryObj = new File(fileObj.getParent()); >> String nameOnly = fileObj.getName(); >> ret = ff.accept(directoryObj, nameOnly); >> } >> return ret; >> } >> >> private native String[] nativeRunFileDialog(String title, int mode, >> - boolean multipleMode, boolean shouldNavigateApps, boolean >> hasFilenameFilter, >> - String directory, String file); >> + boolean multipleMode, boolean shouldNavigateApps, boolean >> canChooseDirectories, >> + boolean hasFilenameFilter, String directory, String file); >> >> @Override >> public void setDirectory(String dir) { >> } >> >> @Override >> public void setFile(String file) { >> } >> diff -r 6432464ffec2 src/macosx/native/sun/awt/CFileDialog.h >> --- a/src/macosx/native/sun/awt/CFileDialog.h Sat May 26 08:01:40 2012 -0700 >> +++ b/src/macosx/native/sun/awt/CFileDialog.h Tue May 29 17:56:51 2012 +0100 >> @@ -47,16 +47,19 @@ >> jint fMode; >> >> // Indicates whether the user can select multiple files >> BOOL fMultipleMode; >> >> // Should we navigate into apps? >> BOOL fNavigateApps; >> >> + // Can the dialog choose directories ? >> + BOOL fChooseDirectories; >> + >> // Contains the absolute paths of the selected files as URLs >> NSArray *fURLs; >> } >> >> // Allocator >> - (id) initWithFilter:(jboolean)inHasFilter >> fileDialog:(jobject)inDialog >> title:(NSString *)inTitle >> diff -r 6432464ffec2 src/macosx/native/sun/awt/CFileDialog.m >> --- a/src/macosx/native/sun/awt/CFileDialog.m Sat May 26 08:01:40 2012 -0700 >> +++ b/src/macosx/native/sun/awt/CFileDialog.m Tue May 29 17:56:51 2012 +0100 >> @@ -38,30 +38,32 @@ >> - (id)initWithFilter:(jboolean)inHasFilter >> fileDialog:(jobject)inDialog >> title:(NSString *)inTitle >> directory:(NSString *)inPath >> file:(NSString *)inFile >> mode:(jint)inMode >> multipleMode:(BOOL)inMultipleMode >> shouldNavigate:(BOOL)inNavigateApps >> +canChooseDirectories:(BOOL)inChooseDirectories >> withEnv:(JNIEnv*)env; >> { >> if (self == [super init]) { >> fHasFileFilter = inHasFilter; >> fFileDialog = JNFNewGlobalRef(env, inDialog); >> fDirectory = inPath; >> [fDirectory retain]; >> fFile = inFile; >> [fFile retain]; >> fTitle = inTitle; >> [fTitle retain]; >> fMode = inMode; >> fMultipleMode = inMultipleMode; >> fNavigateApps = inNavigateApps; >> + fChooseDirectories = inChooseDirectories; >> fPanelResult = NSCancelButton; >> } >> >> return self; >> } >> >> -(void) disposer { >> if (fFileDialog != NULL) { >> @@ -104,17 +106,17 @@ >> if (fNavigateApps) { >> [thePanel setTreatsFilePackagesAsDirectories:YES]; >> } >> >> if (fMode == java_awt_FileDialog_LOAD) { >> NSOpenPanel *openPanel = (NSOpenPanel *)thePanel; >> [openPanel setAllowsMultipleSelection:fMultipleMode]; >> [openPanel setCanChooseFiles:YES]; >> - [openPanel setCanChooseDirectories:NO]; >> + [openPanel setCanChooseDirectories:fChooseDirectories]; >> [openPanel setCanCreateDirectories:YES]; >> } >> >> [thePanel setDelegate:self]; >> fPanelResult = [thePanel runModalForDirectory:fDirectory file:fFile]; >> [thePanel setDelegate:nil]; >> >> if ([self userClickedOK]) { >> @@ -177,17 +179,17 @@ >> * Class: sun_lwawt_macosx_CFileDialog >> * Method: nativeRunFileDialog >> * Signature: (Ljava/lang/String;ILjava/io/FilenameFilter; >> * Ljava/lang/String;Ljava/lang/String;)[Ljava/lang/String; >> */ >> JNIEXPORT jobjectArray JNICALL >> Java_sun_lwawt_macosx_CFileDialog_nativeRunFileDialog >> (JNIEnv *env, jobject peer, jstring title, jint mode, jboolean multipleMode, >> - jboolean navigateApps, jboolean hasFilter, jstring directory, jstring file) >> + jboolean navigateApps, jboolean chooseDirectories, jboolean >> hasFilter, jstring directory, jstring file) >> { >> jobjectArray returnValue = NULL; >> >> JNF_COCOA_ENTER(env); >> NSString *dialogTitle = JNFJavaToNSString(env, title); >> if ([dialogTitle length] == 0) { >> dialogTitle = @" "; >> } >> @@ -195,16 +197,17 @@ JNF_COCOA_ENTER(env); >> CFileDialog *dialogDelegate = [[CFileDialog alloc] initWithFilter:hasFilter >> fileDialog:peer >> >> title:dialogTitle >> >> directory:JNFJavaToNSString(env, directory) >> >> file:JNFJavaToNSString(env, file) >> mode:mode >> >> multipleMode:multipleMode >> >> shouldNavigate:navigateApps >> + >> canChooseDirectories:chooseDirectories >> withEnv:env]; >> >> [JNFRunLoop performOnMainThread:@selector(safeSaveOrLoad) >> on:dialogDelegate >> withObject:nil >> waitUntilDone:YES]; >> >> if ([dialogDelegate userClickedOK]) { >> >> >> >> Test case: >> >> import java.awt.FileDialog; >> import java.io.File; >> import javax.swing.JFrame; >> >> public class FileDialogTest extends JFrame { >> >> public String selectFolder() { >> FileDialog fd = new FileDialog(this, "Select Folder Test", >> FileDialog.LOAD); >> fd.setDirectory(System.getProperty("user.home")); >> fd.setLocation(50,50); >> fd.setVisible(true); >> >> return fd.getFile(); >> } >> >> public static void main(String[] args) { >> System.setProperty("apple.awt.fileDialogForDirectories", "true"); >> >> FileDialogTest fdt = new FileDialogTest(); >> String selectedFolder = fdt.selectFolder(); >> >> System.out.println("The selected file was: " + selectedFolder); >> >> System.setProperty("apple.awt.fileDialogForDirectories", "false"); >> System.exit(0); >> } >> >> } >> >> >> Best, >> Marco From artem.ananiev at oracle.com Wed May 30 04:29:08 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 30 May 2012 15:29:08 +0400 Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: References: Message-ID: <4FC60484.3060109@oracle.com> Hi, Marco, although the bug (7161437) is now targeted to 7u8, please, bear in mind that the property will not become officially supported anyway. For example, it may or may not be removed in later JDK versions after we have provided public API for directory choosers (6927978). 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. Thanks, Artem On 5/28/2012 6:36 PM, Marco Dinacci wrote: > Hi, > > the apple.awt.fileDialogForDirectories property is not honoured > neither with OpenJDK nor with Oracle JDK 7u4. > The following program will work with Java 6 but not with the above > mentioned distributions: > > import java.awt.FileDialog; > import java.io.File; > import javax.swing.JFrame; > > public class FileDialogTest extends JFrame { > > public String selectFolder() { > FileDialog fd = new FileDialog(this, "Select Folder Test", > FileDialog.LOAD); > fd.setDirectory(System.getProperty("user.home")); > fd.setLocation(50,50); > fd.setVisible(true); > > return fd.getFile(); > } > > public static void main(String[] args) { > System.setProperty("apple.awt.fileDialogForDirectories", "true"); > > FileDialogTest fdt = new FileDialogTest(); > String selectedFolder = fdt.selectFolder(); > > System.out.println("The selected file was: " + selectedFolder); > > System.setProperty("apple.awt.fileDialogForDirectories", "false"); > System.exit(0); > } > > } > > The expected result is to be able to select a directory, the actual > result is that the file chooser enter the directory. > > The Apple documentation states: > > By default, the AWT File Dialog lets you choose a file. Under certain > circumstances, however, it may be proper for you to choose a directory > instead. If that is the case, set this property to allow for directory > selection in a file dialog. > > The default value is false. > > > Shall I file a bug ? > > Best, > Marco From anthony.petrov at oracle.com Wed May 30 05:13:18 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 30 May 2012 16:13:18 +0400 Subject: [8] Review request for: 7172722: Latest jdk7u from OSX broke universal build Message-ID: <4FC60EDE.4020805@oracle.com> 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 marco.dinacci at gmail.com Wed May 30 06:11:27 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Wed, 30 May 2012 14:11:27 +0100 Subject: apple.awt.fileDialogForDirectories property not working. In-Reply-To: <4FC60484.3060109@oracle.com> References: <4FC60484.3060109@oracle.com> Message-ID: Hi Artem, > although the bug (7161437) is now targeted to 7u8, please, bear in mind that > the property will not become officially supported anyway. For example, it > may or may not be removed in later JDK versions after we have provided > public API for directory choosers (6927978). I understand that the patch is not a definitive solution and I appreciate that the bug resolution has been scheduled to 7u8. > 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. sure. BTW, I filed the JFileChooser bug, it will be available here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172752 Thanks. Best, Marco From jeff.hoffman at oracle.com Thu May 24 11:21:26 2012 From: jeff.hoffman at oracle.com (Jeff Hoffman) Date: Thu, 24 May 2012 11:21:26 -0700 Subject: [7u6] Review request for 7168062: [macosx] Java processes on Mac should use Oracle Java branded icons In-Reply-To: <14564BAB-38B9-45C5-B921-C6CBCB568685@oracle.com> References: <6D5F1922-CA7C-4B08-A630-405A8920142F@oracle.com> <4FBD052D.7080101@oracle.com> <14564BAB-38B9-45C5-B921-C6CBCB568685@oracle.com> Message-ID: <4FBE7C26.9050609@oracle.com> I need to do some research on this question... We should follow what has been done before. It makes sense that we don't put Oracle branded images in the OpenJDK distribution -- but I'm not exactly sure what we have been putting in there up until now... If we need a "generic" icns file for the Mac port, I can supply one. -jeff On 5/24/12 5:22 AM, Leonid Romanov wrote: > I'm not sure whether Jeff Hoffman, who filed 7168062, is on the list, so I'm adding him to CC. Perhaps he would be able to comment on what repo the branded icon should go and what icon to use for the open tree. > As for 7168062 not being visible to the outside world, there isn't much to see. It basically states "we should use branded icon instead what we use now" and that is. > > On 23.05.2012, at 19:41, Phil Race wrote: > >> On 5/23/2012 8:25 AM, Henri Gomez wrote: >>>> That seems like overkill to me. Can't we just put the .icns in the JRE (Contents/Home/jre/lib/images) and load it from there? What are we guarding against by putting it into a .h file? >>> OpenJDK will use Oracle icons ? Even for the community version ? >> I was wondering about this too. It seems wrong. The icon, and/or the header file >> should be in "closed". We do not put branded images in the open tree, no >> matter how its encoded since they aren't open source. >> The openjdk should use something like the open source duke icon. >> I am not sure I see how/where that works. >> >> BTW good luck seeing >> >>> Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7168062 >> its marked for internal consumption only (for some reason I can't fathom). >> >> -phil. >> >> >> From Sergey.Bylokhov at oracle.com Thu May 31 06:43:46 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 31 May 2012 17:43:46 +0400 Subject: [8] Review request for 7142091: [macosx] RFE: Refactoring of peer initialization/disposing Message-ID: <4FC77592.7020900@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. 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 artem.ananiev at oracle.com Thu May 31 08:30:10 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 31 May 2012 19:30:10 +0400 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: <32533319-5E00-483F-AE69-6E79419C3757@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> Message-ID: <4FC78E82.1030500@oracle.com> 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 scott.kovatch at oracle.com Thu May 31 09:20:31 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 31 May 2012 09:20:31 -0700 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: <4FC78E82.1030500@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> Message-ID: <99A4EEA8-726B-4319-AEDE-DC84E9F9D32F@oracle.com> 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 scott.kovatch at oracle.com Thu May 31 09:32:34 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 31 May 2012 09:32:34 -0700 Subject: [7u6] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: References: Message-ID: <11ECC2F5-E492-46BC-8837-BCD28314A6C5@oracle.com> On May 24, 2012, at 6:23 AM, 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/ I re-read the change after seeing the discussion about the app name, and I see that we are now separating the decision of which icon to use from the decision of which name to use, and that's definitely correct. However, it looks like we will now override the application icon if an icon was specified via property name or if -Xdock:name was used. Is that intentional? If so I think it's worth a comment or two. I _think_ this is the right way to go. In my opinion, it's a developer error if the application was bundled and the developer used CFBundleIconFile, but then also set apple.awt.application.icon or "-Xdock:icon=" in the Info.plist or in code. What did Apple's JDK 6 do? I can't remember now. I think we should follow the rules set there, and document them one way or the other. Any thoughts? -- Scott K. From artem.ananiev at oracle.com Thu May 31 09:44:10 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 31 May 2012 20:44:10 +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: <4FC79FDA.3010809@oracle.com> On 5/31/2012 8:20 PM, 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. :-) Yes, exactly, thanks for clear wording, Scott :) > We're straying away from the original review, though. Since we touch that code anyway, we may want to extend the fix to make JAVA_MAIN_CLASS_ of lower priority instead of filing a new bug for that. Thanks, Artem > -- 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 Thu May 31 14:55:28 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 01 Jun 2012 01:55:28 +0400 Subject: [8] Review request for: 7172722: Latest jdk7u from OSX broke universal build In-Reply-To: References: <4FC77E3A.4060408@oracle.com> Message-ID: <4FC7E8D0.4070100@oracle.com> All: please review the fix (a link to the webrev is below) Hi Henri, On 5/31/2012 11:41 PM, Henri Gomez wrote: > Not subscribed to this mailing list. This is not a problem at all! You may just hit the Reply All button on the original review request email that I've sent (I've included your address in the To: section so you should have received a copy). The message will simply go through a moderator of the mailing list, and once approved will hit the mailing list as usual. Anyway, I'm CC'ing the original aliases right now so that this conversation could contribute to the code review. > + NSWindow *nsWindow; > > BTW, your patch should do the work (it was my first attempt before Thanks for verifying that. > friends told me that _nsWindow is a convention to follow in ObjC/Cocoa > land. I realize that this may be a convention in the ObjC world. However, in JDK we tend to establish a pattern and then follow it everywhere to simplify maintenance of the code. Since other properties are defined this way, I decided to do the same with this one too. -- best regards, Anthony > 2012/5/31 Anthony Petrov : >> Hi Henri, >> >> Have you had a chance to give this patch a try? Please reply to the mailing >> list with your testing results. >> >> -- >> best regards, >> Anthony >> >> >> -------- Original Message -------- >> Subject: [8] Review request for: 7172722: Latest jdk7u from OSX >> broke universal build >> Date: Wed, 30 May 2012 16:13:18 +0400 >> From: Anthony Petrov >> To: macosx-port-dev , >> "awt-dev at openjdk.java.net" , Henri Gomez >> >> >> 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 >> From harshman+javadev at gmail.com Thu May 31 15:19:52 2012 From: harshman+javadev at gmail.com (Chris Harshman) Date: Thu, 31 May 2012 15:19:52 -0700 Subject: Transitioning from Apple extensions Message-ID: 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+?) Thanks, Chris