From jcpalmer at rochester.rr.com Wed Jan 2 10:51:18 2013 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Wed, 2 Jan 2013 13:51:18 -0500 Subject: Code Signing per 1.7u2 Message-ID: <86A9D852-4966-460E-949D-BED271ABB7F0@rochester.rr.com> I know I saw somewhere that changes were introduced in release 2 to code signing, which reduced the size of the output jar file. Has anyone been doing this? Is there a link which documents what you need to do differently somewhere? Thanks, Jeff Palmer WhatIf Squared LLC From jcpalmer at rochester.rr.com Wed Jan 2 11:02:16 2013 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Wed, 2 Jan 2013 14:02:16 -0500 Subject: Code Signing per 1.7u2 In-Reply-To: <86A9D852-4966-460E-949D-BED271ABB7F0@rochester.rr.com> References: <86A9D852-4966-460E-949D-BED271ABB7F0@rochester.rr.com> Message-ID: <013892B5-A08C-411D-B5AF-3E048198A0EF@rochester.rr.com> Found it. Ant task . Hope it can be used without being an fx app. On Jan 2, 2013, at 1:51 PM, Jeff Palmer wrote: > I know I saw somewhere that changes were introduced in release 2 to code signing, which reduced the size of the output jar file. Has anyone been doing this? Is there a link which documents what you need to do differently somewhere? > > Thanks, > > Jeff Palmer > WhatIf Squared LLC From brent.christian at oracle.com Thu Jan 3 09:44:24 2013 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 03 Jan 2013 09:44:24 -0800 Subject: RFR : 8003228 : (props) sun.jnu.encoding should be set to UTF-8 [macosx] In-Reply-To: <50D4EC2A.2020905@oracle.com> References: <50D35E6C.8060205@oracle.com> <50D38F14.5050100@oracle.com> <50D4EC2A.2020905@oracle.com> Message-ID: <50E5C378.7080008@oracle.com> Thanks, Naoto. If there are no other comments, I'll need someone to push this for me. Thanks, -Brent On 12/21/12 3:09 PM, Naoto Sato wrote: > Hi Brent, > > The change looks good to me. Sorry for the delay, as I was taking a half > day off. > > Naoto > > On 12/20/12 2:20 PM, Brent Christian wrote: >> Forgot a regtest - now included w/ v.01: >> >> http://cr.openjdk.java.net/~bchristi/8003228/webrev.01/ >> >> Thanks, >> -Brent >> >> On 12/20/12 10:52 AM, Brent Christian wrote: >>> Hi, >>> >>> I've prepared a JDK 8 fix for 8003228 [1]. The webrev is here: >>> http://cr.openjdk.java.net/~bchristi/8003228/webrev.00/ >>> >>> JPRT passes on all platforms (with the exception of two known bugs[2]). >>> >>> There was some recent discussion related to this - see [3]. >>> >>> Thanks, >>> -Brent >>> >>> [1] http://bugs.sun.com/view_bug.do?bug_id=8003228 >>> >>> [2] 8005195 (Doclint tests on Windows), 8004544 >>> (FDSeparateCompilationTest timeout) >>> >>> [3] >>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-November/005124.html >>> >>> >>> >>> > From krueger at lesspain.de Fri Jan 4 07:51:34 2013 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Fri, 4 Jan 2013 16:51:34 +0100 Subject: Retina state of affairs? Message-ID: Hi, I just wanted to be a nuisance from time to time and ask if anyone knows if someone is working on solving or providing a workaround for the retina display issue or is everyone waiting to see whether Oracle is going to rethink this? To be clear, I am not necessarily talking about a clean solution. I realize this is anything but trivial. A workaround that will help me not to be forced into porting the UI code of years of development to a new UI technology in a few months just to have a UI experience that is not doomed compared to the native competition would be great. A few platform-dependent conditionals in our application buying us some time would be something that would be a lot better than rushing into a decision. Just wanted to know if anyone has heard anything? Thanks in advance, Robert From hs at tagtraum.com Fri Jan 4 08:17:34 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Fri, 4 Jan 2013 17:17:34 +0100 Subject: Retina state of affairs? In-Reply-To: References: Message-ID: <47C6498A-63B2-4F0F-AA21-B78AE6AB6791@tagtraum.com> On 04.01.2013, at 16:51, Robert Kr?ger wrote: > Just wanted to know if anyone has heard anything? No, but I'd also be interested in the same kind of information and workaround. Thanks, -hendrik From jcpalmer at rochester.rr.com Fri Jan 4 13:20:17 2013 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Fri, 4 Jan 2013 16:20:17 -0500 Subject: Directions for Non-bundled App Message-ID: <911F94B6-B0D2-48E9-841F-EE70991166BA@rochester.rr.com> I have refactored my application to perform the update functionality of Java Webstart internally, then launching the entry point of the downloaded implementation jar via reflection. I am sorry but I wasn't paying a lot of attention to the app generation threads last year. Looking through the archives, I did not see anything that did not involve bundling. I would like an OS X application, .app?, that could be dragged from Safari which would use the common JRE. I thought I would just get off JWS but without bundling for now, since the Mac port is still a little rough, and Java 8 going to be much more modular for smaller file sizes. That just leaves 7u12 in April for regression risk. Have built the windows EXE port using Launch4J 3.1. You put in your Java version requirements during EXE creation. If they are not met when the app is started it brings up a browser pointing to http://java.com/download. It works good. There were 2 Mac distributables of Launch4J, but they are just trying to build an EXE on a mac. Is there a tool to embed a jar in an app, or directions on how to make one? I have not done any non-webstart development on Mac, since a Basic program in 1983, and I do not think that is going to help. Have used various Unix machines for decades though. Any links would be appreciated! Jeff Palmer WhatIf Squared LLC From harshman+javadev at gmail.com Fri Jan 4 13:48:26 2013 From: harshman+javadev at gmail.com (Chris Harshman) Date: Fri, 4 Jan 2013 13:48:26 -0800 Subject: Directions for Non-bundled App In-Reply-To: <911F94B6-B0D2-48E9-841F-EE70991166BA@rochester.rr.com> References: <911F94B6-B0D2-48E9-841F-EE70991166BA@rochester.rr.com> Message-ID: You were doing Basic development on the Mac before it was released? Awesome! How was Raskin to work with? ;) On Fri, Jan 4, 2013 at 1:20 PM, Jeff Palmer wrote: > I have not done any non-webstart development on Mac, since a Basic > program in 1983 From Sergey.Bylokhov at oracle.com Fri Jan 4 14:54:35 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 05 Jan 2013 02:54:35 +0400 Subject: Retina state of affairs? In-Reply-To: References: Message-ID: <50E75DAB.7070702@oracle.com> Hi, Robert. The fix is in progress. And it will be fixed in jdk 8 for sure. In what update of jdk 7 it will be ported, right now is unclear. You can track this CR: http://bugs.sun.com/view_bug.do?bug_id=8000629 04.01.2013 19:51, Robert Kr?ger wrote: > Hi, > > I just wanted to be a nuisance from time to time and ask if anyone knows if > someone is working on solving or providing a workaround for the retina > display issue or is everyone waiting to see whether Oracle is going to > rethink this? > > To be clear, I am not necessarily talking about a clean solution. I realize > this is anything but trivial. A workaround that will help me not to be > forced into porting the UI code of years of development to a new UI > technology in a few months just to have a UI experience that is not doomed > compared to the native competition would be great. A few platform-dependent > conditionals in our application buying us some time would be something that > would be a lot better than rushing into a decision. > > Just wanted to know if anyone has heard anything? > > Thanks in advance, > > Robert -- Best regards, Sergey. From krueger at lesspain.de Sat Jan 5 06:07:11 2013 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Sat, 5 Jan 2013 15:07:11 +0100 Subject: Fwd: Retina state of affairs? In-Reply-To: References: <50E75DAB.7070702@oracle.com> Message-ID: sorry, apparently I didn't reply to the list. ---------- Forwarded message ---------- From: Robert Kr?ger Date: Sat, Jan 5, 2013 at 11:37 AM Subject: Re: Retina state of affairs? To: Sergey Bylokhov Hi Sergey, On Fri, Jan 4, 2013 at 11:54 PM, Sergey Bylokhov wrote: > Hi, Robert. > The fix is in progress. And it will be fixed in jdk 8 for sure. In what > update of jdk 7 it will be ported, right now is unclear. > You can track this CR: > http://bugs.sun.com/view_bug.**do?bug_id=8000629 > > that's brilliant news! Thanks for the update! From a licensing point of view I am also allowed to bundle JRE8 with my application, right? If a fix is in progress can you already say something about the properties/limitations of the fix? What will be required by the application developer? Or is it more or less equivalent with the way Apple's JDK6 handles that from the app developer's/distributor's perspective? Thanks again, Robert From swpalmer at gmail.com Sat Jan 5 09:09:19 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 5 Jan 2013 12:09:19 -0500 Subject: Retina state of affairs? In-Reply-To: References: <50E75DAB.7070702@oracle.com> Message-ID: As I understand it, you can't bundle Oracle's JRE 8 until it is officially released, but once it is release you are allowed to bundle according to the rules in the license agreement (which i suppose is subject to change and all that). OpenJDK8 may be more flexible. Scott On 2013-01-05, at 9:07 AM, Robert Kr?ger wrote: > sorry, apparently I didn't reply to the list. > > ---------- Forwarded message ---------- > From: Robert Kr?ger > Date: Sat, Jan 5, 2013 at 11:37 AM > Subject: Re: Retina state of affairs? > To: Sergey Bylokhov > > > Hi Sergey, > > On Fri, Jan 4, 2013 at 11:54 PM, Sergey Bylokhov > wrote: > >> Hi, Robert. >> The fix is in progress. And it will be fixed in jdk 8 for sure. In what >> update of jdk 7 it will be ported, right now is unclear. >> You can track this CR: >> http://bugs.sun.com/view_bug.**do?bug_id=8000629 >> >> > that's brilliant news! Thanks for the update! From a licensing point of > view I am also allowed to bundle JRE8 with my application, right? > > If a fix is in progress can you already say something about the > properties/limitations of the fix? What will be required by the application > developer? Or is it more or less equivalent with the way Apple's JDK6 > handles that from the app developer's/distributor's perspective? > > Thanks again, > > Robert From jcpalmer at rochester.rr.com Sat Jan 5 12:46:36 2013 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Sat, 5 Jan 2013 15:46:36 -0500 Subject: Directions for Non-bundled App In-Reply-To: References: Message-ID: <50D2A925-9626-4A40-9628-B721BE617E0A@rochester.rr.com> Need to correct myself. This was the Apple II, g something I think. The Lisa did come out before the Mac & was available around this time. Saw one once. It looked like a Mac, but never programmed it. The one I programmed was a keyboard / computer one piece, with a monitor which sat on top. I wrote a program to play sounds / music. Had the little 5" floppies, instead of the 8"s. Being a second generation programmer, I had my head in data center computer rooms on Saturdays when Johnson was president, though I never knew who he was. On Jan 5, 2013, at 3:00 PM, macosx-port-dev-request at openjdk.java.net wrote: > From: Chris Harshman > Subject: Re: Directions for Non-bundled App > Date: January 4, 2013 4:48:26 PM EST > To: macosx-port-dev at openjdk.java.net > > > You were doing Basic development on the Mac before it was released? > Awesome! How was Raskin to work with? ;) > > > On Fri, Jan 4, 2013 at 1:20 PM, Jeff Palmer wrote: > >> I have not done any non-webstart development on Mac, since a Basic >> program in 1983 > From mik3hall at gmail.com Sat Jan 5 14:42:28 2013 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 5 Jan 2013 16:42:28 -0600 Subject: Directions for Non-bundled App In-Reply-To: <50D2A925-9626-4A40-9628-B721BE617E0A@rochester.rr.com> References: <50D2A925-9626-4A40-9628-B721BE617E0A@rochester.rr.com> Message-ID: On Jan 5, 2013, at 2:46 PM, Jeff Palmer wrote: > Need to correct myself. This was the Apple II, g something I think. The Lisa did come out before the Mac & was available around this time. Saw one once. It looked like a Mac, but never programmed it. The one I programmed was a keyboard / computer one piece, with a monitor which sat on top. I wrote a program to play sounds / music. Had the little 5" floppies, instead of the 8"s. The original Mac 128K's had pretty much no development environment. Pascal was on the Lisa which was pricier. You had to be able to read a little Pascal anyhow to follow the Inside Macintosh series. About the first Basic was a Microsoft one that I think had no real toolbox access. I had it but ended up mostly going with MacForth. I never did get going on Pascal although I think Borland probably had a Turbo one. Jumped late into C coding when Code Warrior and the one I finally used was what was the one I think Symantec ended up picking up? Lightening or something like that? Apple II's I did a little 6502 assembler. peek and poke and all that good stuff. Someone posted a peek address recently. Thought they must have a better memory than me, I don't remember any specific addresses. trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From hs at tagtraum.com Sun Jan 6 03:26:31 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Sun, 6 Jan 2013 12:26:31 +0100 Subject: Toolkit.getDefaultToolkit() hangs after com.apple.eio.FileManager call Message-ID: Hi, just because I spent some "quality" time with this: Calling Toolkit.getDefaultToolkit() after a call to FileManager.findFolder(FileManager.kUserDomain, 0x61737570) will cause Toolkit.getDefaultToolkit() to hang. So, if you intend to use com.apple.eio.FileManager, make sure to call Toolkit.getDefaultToolkit() *before* you call the FileManager. -hendrik PS: Bug is filed at Oracle. java version "1.7.0_10" Java(TM) SE Runtime Environment (build 1.7.0_10-b18) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode) import com.apple.eio.FileManager; import java.awt.*; import java.io.FileNotFoundException; public class ToolkitHang { private static final int kApplicationSupportFolder = 0x61737570;// asup public static void main(String[] args) throws FileNotFoundException { final String appSupportFolder = FileManager.findFolder(FileManager.kUserDomain, kApplicationSupportFolder); System.out.println("App Support Folder: " + appSupportFolder); Toolkit.getDefaultToolkit(); System.out.println("Is never reached."); } } Where it hangs: "main at 1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:-1) at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1939) - locked <0x99> (a java.util.Vector) - locked <0x9a> (a java.util.Vector) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1864) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1825) at java.lang.Runtime.load0(Runtime.java:792) - locked <0x54> (a java.lang.Runtime) at java.lang.System.load(System.java:1059) at java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:-1) at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1939) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1864) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1846) at java.lang.Runtime.loadLibrary0(Runtime.java:845) at java.lang.System.loadLibrary(System.java:1084) at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67) at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47) at java.security.AccessController.doPrivileged(AccessController.java:-1) at java.awt.Toolkit.loadLibraries(Toolkit.java:1648) at java.awt.Toolkit.(Toolkit.java:1670) From hs at tagtraum.com Sun Jan 6 04:11:59 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Sun, 6 Jan 2013 13:11:59 +0100 Subject: apple.awt.brushMetalLook not respected in full screen mode Message-ID: Hi, just to put it on the radar: when using apple.awt.brushMetalLook, the title bar should have the same color in full screen mode as in regular mode. Right now that's not the case - it becomes lighter, like it should when apple.awt.brushMetalLook is off. I filed a bug report with Oracle - however - this seems to be a bug in com.apple.eawt.. Who is maintaining it and who should I file bug reports to? Thanks guys, -hendrik To illustrate: import javax.swing.*; import java.awt.*; public class FullScreenTitleBarBug { public static void main(String[] args) { final JFrame jFrame = new JFrame(); com.apple.eawt.FullScreenUtilities.setWindowCanFullScreen(jFrame, true); jFrame.getRootPane().putClientProperty("apple.awt.brushMetalLook", true); jFrame.getRootPane().setLayout(new BorderLayout()); final JPanel blackPanel = new JPanel(); blackPanel.setBackground(new Color(0xe1e1e1)); jFrame.getRootPane().add(blackPanel, BorderLayout.CENTER); jFrame.setBounds(100, 100, 100, 100); jFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); jFrame.setVisible(true); } } From Sergey.Bylokhov at oracle.com Sun Jan 6 15:17:43 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 07 Jan 2013 03:17:43 +0400 Subject: apple.awt.brushMetalLook not respected in full screen mode In-Reply-To: References: Message-ID: <50EA0617.2030304@oracle.com> Hi, Hendrik. Looks like this is the same issue. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003173 Most probably this will be fixed in 7u12. 06.01.2013 16:11, Hendrik Schreiber wrote: > Hi, > > just to put it on the radar: > > when using apple.awt.brushMetalLook, the title bar should have the same color in full screen mode as in regular mode. Right now that's not the case - it becomes lighter, like it should when apple.awt.brushMetalLook is off. > > I filed a bug report with Oracle - however - this seems to be a bug in com.apple.eawt.. Who is maintaining it and who should I file bug reports to? > > Thanks guys, > > -hendrik > > > To illustrate: > > import javax.swing.*; > import java.awt.*; > > public class FullScreenTitleBarBug { > > public static void main(String[] args) { > > final JFrame jFrame = new JFrame(); > com.apple.eawt.FullScreenUtilities.setWindowCanFullScreen(jFrame, true); > jFrame.getRootPane().putClientProperty("apple.awt.brushMetalLook", true); > jFrame.getRootPane().setLayout(new BorderLayout()); > final JPanel blackPanel = new JPanel(); > blackPanel.setBackground(new Color(0xe1e1e1)); > jFrame.getRootPane().add(blackPanel, BorderLayout.CENTER); > jFrame.setBounds(100, 100, 100, 100); > jFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > jFrame.setVisible(true); > } > } -- Best regards, Sergey. From hs at tagtraum.com Mon Jan 7 01:56:28 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Mon, 7 Jan 2013 10:56:28 +0100 Subject: apple.awt.brushMetalLook not respected in full screen mode In-Reply-To: <50EA0617.2030304@oracle.com> References: <50EA0617.2030304@oracle.com> Message-ID: On 07.01.2013, at 00:17, Sergey Bylokhov wrote: > Looks like this is the same issue. > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003173 > Most probably this will be fixed in 7u12. Yep - that's the same issue! Looking forward to the fix :-) Thanks, -hendrik From hs at tagtraum.com Mon Jan 7 03:20:30 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Mon, 7 Jan 2013 12:20:30 +0100 Subject: reducing size of bundled jre Message-ID: <8B758328-9BE1-4186-8695-E2748CF660FE@tagtraum.com> Hi, I just fiddled around for the first time with the appbundler ant task - and was shocked that the bundled (Oracle) JRE amounts to 140 MB. This is far bigger than a bundled Windows JRE. Is there any way to reduce this? And a second (fairly unrelated) question: Are there still any public builds of OpenJDK out there? Thanks, -hendrik From Kustaa.Nyholm at planmeca.com Mon Jan 7 04:40:25 2013 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Jan 2013 14:40:25 +0200 Subject: reducing size of bundled jre In-Reply-To: <8B758328-9BE1-4186-8695-E2748CF660FE@tagtraum.com> Message-ID: On 7.1.2013 13.20, "Hendrik Schreiber" wrote: >Hi, > >I just fiddled around for the first time with the appbundler ant task - >and was shocked that the bundled (Oracle) JRE amounts to 140 MB. This is >far bigger than a bundled Windows JRE. Is there any way to reduce this? > >And a second (fairly unrelated) question: Are there still any public >builds of OpenJDK out there? > >Thanks, > >-hendrik +140 MB is the uncompressed size. If you look at these: http://www.oracle.com/technetwork/java/javase/downloads/jre7-downloads-1880 261.html they are quite similar for similar packaging, compare the tar.gz sizes. Which kind of makes sense as I guess lot of the JRE is Java byte code so should be more or less same for all platforms. I've not tried this myself as I've postponed bundling until we get proper Retina support, but looking at above page I see that for Mac .dmg is close .tar.gz in size so I would expect that if you create a compressed .dmg from your bundled app then the download size would be much smaller than 140 MB and more importantly same as the other platforms. Still, we could all do with a lot less! br Kusti From lordpixel at me.com Mon Jan 7 06:07:59 2013 From: lordpixel at me.com (lordpixel at me.com) Date: Mon, 7 Jan 2013 09:07:59 -0500 Subject: reducing size of bundled jre In-Reply-To: References: Message-ID: <894A85F9-B62B-4CFF-BB34-62AFF4DB8C6D@me.com> On Jan 7, 2013, at 7:40 AM, Kustaa Nyholm wrote: > Still, we could all do with a lot less! You mean something like this in Java 8? http://openjdk.java.net/jeps/161 Or the much delayed Jigsaw in Java 9 (hopefully)? http://openjdk.java.net/projects/jigsaw/ 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 Kustaa.Nyholm at planmeca.com Mon Jan 7 06:19:27 2013 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Jan 2013 16:19:27 +0200 Subject: reducing size of bundled jre In-Reply-To: <894A85F9-B62B-4CFF-BB34-62AFF4DB8C6D@me.com> Message-ID: On Jan 7, 2013, at 7:40 AM, Kustaa Nyholm > wrote: Still, we could all do with a lot less! You mean something like this in Java 8? http://openjdk.java.net/jeps/161 >From a quick look at that I could envision that all I ever want to write could live with 'compact1' profile, any idea how much smaller that would be? Or the much delayed Jigsaw in Java 9 (hopefully)? http://openjdk.java.net/projects/jigsaw/ >From a quick look it is not clear what this amounts to, basically my small requirements are what most desktop applications would require and thus a 'desktop profile' might be easier than managing modules one by one, on the otherhand, this might not be much more work and could be more compact. br Kusti From hs at tagtraum.com Mon Jan 7 08:38:40 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Mon, 7 Jan 2013 17:38:40 +0100 Subject: reducing size of bundled jre In-Reply-To: References: Message-ID: <5836C08F-065D-4B5D-847B-8E76AD1C35FA@tagtraum.com> On 07.01.2013, at 13:40, Kustaa Nyholm wrote: > I've not tried this myself as I've postponed bundling until > we get proper Retina support, I have tried 1.7.0_10 and umlauts in filenames still don't seem to be supported (is that fixed in update 12?), Retina is missing, full screen is buggy (according to Sergey will be fixed soon!), but probably worst of all - and I didn't realize that until now - OS X 10.6 is not supported. Meaning: ~1/3 of all Mac users can't use it. http://www.macrumors.com/2013/01/04/os-x-10-8-mountain-lion-tops-lion-as-most-popular-mac-operating-system/ So I guess at this point, one is unfortunately still well advised to wait a little before shipping anything with Java7. The good news is though: Besides that other problem with the FileManager class (http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-January/005261.html) I didn't encounter any serious problems when starting my app on Java7. And that's pretty cool. not quite Java6 quality, but we're definitely getting there. -hendrik From Kustaa.Nyholm at planmeca.com Mon Jan 7 09:38:49 2013 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Jan 2013 19:38:49 +0200 Subject: reducing size of bundled jre In-Reply-To: <5836C08F-065D-4B5D-847B-8E76AD1C35FA@tagtraum.com> Message-ID: On 7.1.2013 18.38, "Hendrik Schreiber" wrote: >On 07.01.2013, at 13:40, Kustaa Nyholm wrote: > >>I've not tried this myself as I've postponed bundling until >>we get proper Retina support, > >I have tried 1.7.0_10 and umlauts in filenames still don't seem to be >supported (is that fixed in update 12?), Retina is missing, full screen >is buggy (according to Sergey will be fixed soon!), but probably worst of >all - and I didn't realize that until now - OS X 10.6 is not supported. > >Meaning: > >~1/3 of all Mac users can't use it. > >http://www.macrumors.com/2013/01/04/os-x-10-8-mountain-lion-tops-lion-as-m >ost-popular-mac-operating-system/ > >So I guess at this point, one is unfortunately still well advised to wait >a little before shipping anything with Java7. > >The good news is though: > >Besides that other problem with the FileManager class >(http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-January/00526 >1.html) I didn't encounter any serious problems when starting my app on >Java7. And that's pretty cool. not quite Java6 quality, but we're >definitely getting there. > >-hendrik That just about sums up my reservations for this. I don't see Apple Java (1.6) disappearing in the foreseeable future so it is hard to justify the 'expense' of bundling for me or my users so for the time being I just wait and see and it is business as usual until something forces me to bundle. This same applies to Windows and Linux as well for my small applications. br Kusti From Sergey.Bylokhov at oracle.com Wed Jan 9 05:32:55 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 09 Jan 2013 17:32:55 +0400 Subject: [8] Request for review: 8003173 [macosx] Fullscreen on Mac leaves an empty rectangle Message-ID: <50ED7187.3010207@oracle.com> Hello, Please review the fix. The reason why we have an empty space in the full screen mode is that we did not update our insets. - I update insets in the deliverMoveResizeEvent not in the windowDidEnterFullScreen, in this case animation became more smooth(since we update insets just before paint action). So all old fullscreen handle methods in CPlatformWindow were removed. - LWWindowPeer.updateInsets will post ComponentEvent if insets were changed. - CGraphicsDevice.setDisplayMode now stores/restores full screen window, because otherwise NSView looks shifted on screen. - CPlatformView.enterFullScreenMode(): code related to insets was removed, since NSVIew uses the whole screen unlike jdk 6.(see related changes in CPlatformWindow.enter/exitFullScreenMode) Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003173 Webrev can be found at: http://cr.openjdk.java.net/~serb/8003173/webrev.00 -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Jan 9 06:40:48 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 09 Jan 2013 18:40:48 +0400 Subject: [8] Request for review: 8003173 [macosx] Fullscreen on Mac leaves an empty rectangle In-Reply-To: <50ED7187.3010207@oracle.com> References: <50ED7187.3010207@oracle.com> Message-ID: <50ED8170.5050601@oracle.com> Hi Sergey, src/macosx/classes/sun/lwawt/LWWindowPeer.java: Note that theoretically the insets can be changed w/o changing the content size. For example, if a user switches to a theme with enlarged window decorations. Not sure if this applies to Mac presently, but in theory this is possible. Will sending the COMPONENT_RESIZE event be equivalent to calling the replaceSurfaceData() in this case? Also, since the event is only posted but not processed yet, what is the point to call repaintPeer() before the surface data is replaced? src/macosx/classes/sun/lwawt/macosx/CPlatformView.java: The actual fix seems to reside in this file. Why doesn't peer.getInsets() return zeros in the full screen mode? If it does actually, why do we need this change then? A generic, insets-accounting size calculation seems to be preferable in case we need a non-zero insets for some specific use-cases in the future. src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java: > 876 peer.updateInsets(getInsets()); This will call a native method upon sending every move/resize event. Why do we actually have to do this? I assume the peer already calls the PlatformWindow.getInsets() whenever needed. Also, AFAIK, insets rarely change on Mac, and you already handle their manual changes when entering/exiting the full screen mode. Can we just remove this line? src/macosx/native/sun/awt/AWTWindow.m > 821 [ThreadUtilities performOnMainThreadWaiting:YES block:^(){ > 822 AWT_ASSERT_APPKIT_THREAD; This ASSERT statement may safely be removed since the ThreadUtilities already guarantee us that we're running on the main thread. -- best regards, Anthony On 1/9/2013 17:32, Sergey Bylokhov wrote: > Hello, > Please review the fix. > The reason why we have an empty space in the full screen mode is that we > did not update our insets. > - I update insets in the deliverMoveResizeEvent not in the > windowDidEnterFullScreen, in this case animation became more > smooth(since we update insets just before paint action). So all old > fullscreen handle methods in CPlatformWindow were removed. > - LWWindowPeer.updateInsets will post ComponentEvent if insets were > changed. > - CGraphicsDevice.setDisplayMode now stores/restores full screen > window, because otherwise NSView looks shifted on screen. > - CPlatformView.enterFullScreenMode(): code related to insets was > removed, since NSVIew uses the whole screen unlike jdk 6.(see related > changes in CPlatformWindow.enter/exitFullScreenMode) > > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003173 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8003173/webrev.00 > From Sergey.Bylokhov at oracle.com Wed Jan 9 07:57:17 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 09 Jan 2013 19:57:17 +0400 Subject: [8] Request for review: 8003173 [macosx] Fullscreen on Mac leaves an empty rectangle In-Reply-To: <50ED8170.5050601@oracle.com> References: <50ED7187.3010207@oracle.com> <50ED8170.5050601@oracle.com> Message-ID: <50ED935D.6050104@oracle.com> Hi, Anthony. Thanks for review. 09.01.2013 18:40, Anthony Petrov wrote: > Hi Sergey, > > src/macosx/classes/sun/lwawt/LWWindowPeer.java: > Note that theoretically the insets can be changed w/o changing the > content size. For example, if a user switches to a theme with enlarged > window decorations. Not sure if this applies to Mac presently, but in > theory this is possible. Will sending the COMPONENT_RESIZE event be > equivalent to calling the replaceSurfaceData() in this case? Also, > since the event is only posted but not processed yet, what is the > point to call repaintPeer() before the surface data is replaced? In general surfaceData should include top level size of the window(including insets) So it's not necessary to replace surface here. Because there is no api for target notification about new insets I use COMPONENT_RESIZE event. > > > src/macosx/classes/sun/lwawt/macosx/CPlatformView.java: > The actual fix seems to reside in this file. Why doesn't > peer.getInsets() return zeros in the full screen mode? If it does > actually, why do we need this change then? A generic, > insets-accounting size calculation seems to be preferable in case we > need a non-zero insets for some specific use-cases in the future. When we set NSView to full screen the native insets(as we calculate it) does not change. Because of that we use synthetic resize notifications in enterFullScreenMode() we just should not include insets in this case. > > > src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java: >> 876 peer.updateInsets(getInsets()); > > This will call a native method upon sending every move/resize event. > Why do we actually have to do this? I assume the peer already calls > the PlatformWindow.getInsets() whenever needed. No. It does not call, that's the problem. > Also, AFAIK, insets rarely change on Mac, and you already handle their > manual changes when entering/exiting the full screen mode. Can we just > remove this line? No. There are two different fullscreens. 1 The full screen based on Nsview, which is used via Graphics device. For this we emulate insets and events. 2 The full screen in lion style. We can handle it in windowWillEnterFullScreen/windowDidEnterFullScreen. In the WillEnterXX window have old insets and in the DidEnterXX window have new insets. DidEnterXX comes after Resize events, which will repaint the window ==> we get content's jumping. > > > src/macosx/native/sun/awt/AWTWindow.m >> 821 [ThreadUtilities performOnMainThreadWaiting:YES block:^(){ >> 822 AWT_ASSERT_APPKIT_THREAD; > > This ASSERT statement may safely be removed since the ThreadUtilities > already guarantee us that we're running on the main thread. I just use standard template from AWTWindow.m, so it will be simple to change this template at once. > > -- > best regards, > Anthony > > On 1/9/2013 17:32, Sergey Bylokhov wrote: >> Hello, >> Please review the fix. >> The reason why we have an empty space in the full screen mode is that >> we did not update our insets. >> - I update insets in the deliverMoveResizeEvent not in the >> windowDidEnterFullScreen, in this case animation became more >> smooth(since we update insets just before paint action). So all old >> fullscreen handle methods in CPlatformWindow were removed. >> - LWWindowPeer.updateInsets will post ComponentEvent if insets were >> changed. >> - CGraphicsDevice.setDisplayMode now stores/restores full screen >> window, because otherwise NSView looks shifted on screen. >> - CPlatformView.enterFullScreenMode(): code related to insets was >> removed, since NSVIew uses the whole screen unlike jdk 6.(see related >> changes in CPlatformWindow.enter/exitFullScreenMode) >> >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003173 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8003173/webrev.00 >> -- Best regards, Sergey. From leonid.romanov at oracle.com Thu Jan 10 08:18:44 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 10 Jan 2013 20:18:44 +0400 Subject: [7u12] Review request for 2223196 : [macosx] Situation when KeyEventDispatcher doesn't work on AWT but does on Swing In-Reply-To: <50C71809.5050203@oracle.com> References: <7AB66D3D-E82D-45CC-98FE-7017A548D2F4@oracle.com> <50C71809.5050203@oracle.com> Message-ID: <9613ACD3-D968-4709-A819-58F41E6F1D14@oracle.com> Hi, Actually, there was no need. It was a mistake. Please, take a look at the updated webrev: http://cr.openjdk.java.net/~leonidr/2223196/webrev.01/ On 11.12.2012, at 15:24, Anton V. Tarasov wrote: > Hi Leonid, > > The problem with lost key events is fixed with the only change in the LWWindowPeer.dispatchKeyEvent method. > Did you have any specific need to backport the rest of the changes? I'm not against backporting it, but just would like to understand the reason. > > Thanks, > Anton. > > On 29.11.2012 1:19, Leonid Romanov wrote: >> >> Hi, >> Please review a fix for 2223196 : [macosx] Situation when KeyEventDispatcher doesn't work on AWT but does on Swing. In JDK 8 this bug was fixed by the Anton Tarasov fix for 6981400 (*). This fix is a OS X specific subset of the Anton's fix. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2223196 >> Wbrev: http://cr.openjdk.java.net/~leonidr/2223196/webrev.00/ >> >> >> * http://cr.openjdk.java.net/~ant/6981400/webrev.7/ >> >> Thanks, >> Leonid. >> >> > From anton.tarasov at oracle.com Fri Jan 11 02:14:15 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 11 Jan 2013 14:14:15 +0400 Subject: [7u12] Review request for 2223196 : [macosx] Situation when KeyEventDispatcher doesn't work on AWT but does on Swing In-Reply-To: <9613ACD3-D968-4709-A819-58F41E6F1D14@oracle.com> References: <7AB66D3D-E82D-45CC-98FE-7017A548D2F4@oracle.com> <50C71809.5050203@oracle.com> <9613ACD3-D968-4709-A819-58F41E6F1D14@oracle.com> Message-ID: <50EFE5F7.2030809@oracle.com> Looks fine! Thanks, Anton. On 10.01.2013 20:18, Leonid Romanov wrote: > Hi, > Actually, there was no need. It was a mistake. Please, take a look at the updated webrev: > > http://cr.openjdk.java.net/~leonidr/2223196/webrev.01/ > > > On 11.12.2012, at 15:24, Anton V. Tarasov > wrote: > >> Hi Leonid, >> >> The problem with lost key events is fixed with the only change in the >> LWWindowPeer.dispatchKeyEvent method. >> Did you have any specific need to backport the rest of the changes? I'm not against backporting >> it, but just would like to understand the reason. >> >> Thanks, >> Anton. >> >> On 29.11.2012 1:19, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 2223196 : [macosx] Situation when KeyEventDispatcher doesn't work on AWT >>> but does on Swing. In JDK 8 this bug was fixed by the Anton Tarasov fix for 6981400 (*). This >>> fix is a OS X specific subset of the Anton's fix. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2223196 >>> Wbrev: http://cr.openjdk.java.net/~leonidr/2223196/webrev.00/ >>> >>> >>> >>> * http://cr.openjdk.java.net/~ant/6981400/webrev.7/ >>> >>> >>> Thanks, >>> Leonid. >>> >>> >> > From bob.vandette at oracle.com Fri Jan 11 13:20:08 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 11 Jan 2013 16:20:08 -0500 Subject: System.out.println on Mountain Lion Message-ID: <1F253919-4CD9-45E2-9FAE-3FEBA4D5D3A2@oracle.com> I don't know if this alias is still active but we've had reports that System.out.println doesn't work on OSX Mountain Lion. Has anyone looked into this problem yet? Bob. Vandette From leonid.romanov at oracle.com Fri Jan 11 13:35:36 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Sat, 12 Jan 2013 01:35:36 +0400 Subject: System.out.println on Mountain Lion In-Reply-To: <1F253919-4CD9-45E2-9FAE-3FEBA4D5D3A2@oracle.com> References: <1F253919-4CD9-45E2-9FAE-3FEBA4D5D3A2@oracle.com> Message-ID: Hi, I've never encountered such problem while working on JDK 7 and 8. And I use System.out.println quite a lot for the debugging purposes. Could you be more specific about JDK version and build number? On Jan 12, 2013, at 1:20 AM, Bob Vandette wrote: > I don't know if this alias is still active but we've had reports that System.out.println doesn't work > on OSX Mountain Lion. > > Has anyone looked into this problem yet? > > Bob. Vandette > > From bob.vandette at oracle.com Fri Jan 11 13:42:51 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 11 Jan 2013 16:42:51 -0500 Subject: System.out.println on Mountain Lion In-Reply-To: References: <1F253919-4CD9-45E2-9FAE-3FEBA4D5D3A2@oracle.com> Message-ID: The reported problem seems to not be an issue with output showing up in a terminal window but in the Console App. I'm not sure what the expected behavior for the Console App and Java. Bob. On Jan 11, 2013, at 4:35 PM, Leonid Romanov wrote: > Hi, > I've never encountered such problem while working on JDK 7 and 8. And I use System.out.println quite a lot for the debugging purposes. Could you be more specific about JDK version and build number? > > On Jan 12, 2013, at 1:20 AM, Bob Vandette wrote: > >> I don't know if this alias is still active but we've had reports that System.out.println doesn't work >> on OSX Mountain Lion. >> >> Has anyone looked into this problem yet? >> >> Bob. Vandette >> >> > From leonid.romanov at oracle.com Fri Jan 11 13:48:57 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Sat, 12 Jan 2013 01:48:57 +0400 Subject: System.out.println on Mountain Lion In-Reply-To: References: <1F253919-4CD9-45E2-9FAE-3FEBA4D5D3A2@oracle.com> Message-ID: <764E49FD-7928-4F1C-BCE2-000A401C9A98@oracle.com> Ah, I see. Thanks. This is something I have to check.. On Jan 12, 2013, at 1:42 AM, Bob Vandette wrote: > The reported problem seems to not be an issue with output showing up in a terminal window but > in the Console App. I'm not sure what the expected behavior for the Console App and Java. > > Bob. > > > On Jan 11, 2013, at 4:35 PM, Leonid Romanov wrote: > >> Hi, >> I've never encountered such problem while working on JDK 7 and 8. And I use System.out.println quite a lot for the debugging purposes. Could you be more specific about JDK version and build number? >> >> On Jan 12, 2013, at 1:20 AM, Bob Vandette wrote: >> >>> I don't know if this alias is still active but we've had reports that System.out.println doesn't work >>> on OSX Mountain Lion. >>> >>> Has anyone looked into this problem yet? >>> >>> Bob. Vandette >>> >>> >> > From mik3hall at gmail.com Fri Jan 11 16:03:00 2013 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 11 Jan 2013 18:03:00 -0600 Subject: All Menus disappear In-Reply-To: References: <45F4F32C-ECA9-413A-9A9B-7402F62C7A0D@gmail.com> <8653D42E-11AF-418C-AA12-55A10DEE107A@oracle.com> <1A4F007B-4F01-4953-AD94-65ED7187E27A@gmail.com> <5098EAA4.1020100@oracle.com> <936137C4-F665-400A-9457-14A3ECA47ED5@gmail.com> <3C9122A8-72C6-4B4D-9CC9-CF422BF7332F@oracle.com> Message-ID: On Nov 9, 2012, at 4:53 PM, Michael Hall wrote: > On Nov 8, 2012, at 8:55 PM, Michael Hall wrote: > >> On Nov 8, 2012, at 8:09 AM, Leonid Romanov wrote: >> >>> Yes, the behavior you're experiencing is a bug. >> >> OK, I have a test case I'll try to come up with a bug report tomorrow. > > > Your report has been assigned an internal review ID of 2376841. > > Michael Hall Bit of a bump. I am again at the point where I am going to add a menu bar to an application I'm working on. I would like the OS X behavior of screen menu bars. So I remembered this prior bug report. As I recently mentioned I had done three bug reports and was unable in searching the bug database to locate any of them. One I determined was not an actual bug after filing, but at this time as far as I know the other two were and still are. How do I check to see what happened to these bug reports? Were they not accepted but how am I supposed to know this happened and for what reason? Possibly my search was bad and they were accepted. How then do I know what 'real' bug report they ended up with? Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From Kustaa.Nyholm at planmeca.com Fri Jan 11 21:22:30 2013 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Sat, 12 Jan 2013 07:22:30 +0200 Subject: System.out.println on Mountain Lion In-Reply-To: <764E49FD-7928-4F1C-BCE2-000A401C9A98@oracle.com> Message-ID: On 11.1.2013 23.48, "Leonid Romanov" wrote: >> The reported problem seems to not be an issue with output showing up in >>a terminal window but >> in the Console App. I'm not sure what the expected behavior for the >>Console App and Java. I seem to remember that this was discussed in java-dev at lists.apple.com when Mountain Lion came out or there abouts and IIRC this is a system wide (bad) design decision from Apple. I maybe wrong, just thought I'd mention this. br Kusti From paul_t100 at fastmail.fm Sat Jan 12 02:35:47 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sat, 12 Jan 2013 10:35:47 +0000 Subject: System.out.println on Mountain Lion In-Reply-To: References: Message-ID: <50F13C83.8060100@fastmail.fm> On 12/01/2013 05:22, Kustaa Nyholm wrote: > On 11.1.2013 23.48, "Leonid Romanov" wrote: > >>> The reported problem seems to not be an issue with output showing up in >>> a terminal window but >>> in the Console App. I'm not sure what the expected behavior for the >>> Console App and Java. > I seem to remember that this was discussed in java-dev at lists.apple.com > when Mountain Lion came out or there abouts and IIRC this is a system > wide (bad) design decision from Apple. I maybe wrong, just thought I'd > mention this. > > br Kusti > > > > > I've encountered this problem, before mountain lion if printed a stack trace or used system.out or system the information would come out on in the System Log, visible via the Console. With the release of Mountain Lion this ouput disappeared into the ether, I asked Mike Swingler and got a response about this on the Java-Apple mailing list but I dont remember getting an answer to why the behaviour had changed. Paul From swingler at apple.com Sat Jan 12 17:19:52 2013 From: swingler at apple.com (Mike Swingler) Date: Sat, 12 Jan 2013 17:19:52 -0800 Subject: System.out.println on Mountain Lion In-Reply-To: <50F13C83.8060100@fastmail.fm> References: <50F13C83.8060100@fastmail.fm> Message-ID: <85C99A87-95CC-473A-ADB7-E38A179D61E9@apple.com> On Jan 12, 2013, at 2:35 AM, Paul Taylor wrote: > On 12/01/2013 05:22, Kustaa Nyholm wrote: >> On 11.1.2013 23.48, "Leonid Romanov" wrote: >> >>>> The reported problem seems to not be an issue with output showing up in >>>> a terminal window but >>>> in the Console App. I'm not sure what the expected behavior for the >>>> Console App and Java. >> I seem to remember that this was discussed in java-dev at lists.apple.com >> when Mountain Lion came out or there abouts and IIRC this is a system >> wide (bad) design decision from Apple. I maybe wrong, just thought I'd >> mention this. >> >> br Kusti >> > I've encountered this problem, before mountain lion if printed a stack trace or used system.out or system the information would come out on in the System Log, visible via the Console. With the release of Mountain Lion this ouput disappeared into the ether, I asked Mike Swingler and got a response about this on the Java-Apple mailing list but I dont remember getting an answer to why the behaviour had changed. > > Paul As I recall (though I can't find any public documentation about this), the logging policy was changed in Mountain Lion to ignore ordinary inherited stdout/stderr, and to only log records into the ASL database that came through the ASL API (of which NSLog does use). Regards, Mike Swingler Apple Inc. From mik3hall at gmail.com Sat Jan 12 17:26:56 2013 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 12 Jan 2013 19:26:56 -0600 Subject: System.out.println on Mountain Lion In-Reply-To: <85C99A87-95CC-473A-ADB7-E38A179D61E9@apple.com> References: <50F13C83.8060100@fastmail.fm> <85C99A87-95CC-473A-ADB7-E38A179D61E9@apple.com> Message-ID: On Jan 12, 2013, at 7:19 PM, Mike Swingler wrote: > As I recall (though I can't find any public documentation about this), the logging policy was changed in Mountain Lion to ignore ordinary inherited stdout/stderr, and to only log records into the ASL database that came through the ASL API (of which NSLog does use). Might not always work for everyone but why not redirect standard i/o to custom classes that wrap NSLog's? Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From paul_t100 at fastmail.fm Sun Jan 13 00:58:55 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sun, 13 Jan 2013 08:58:55 +0000 Subject: System.out.println on Mountain Lion In-Reply-To: References: <50F13C83.8060100@fastmail.fm> <85C99A87-95CC-473A-ADB7-E38A179D61E9@apple.com> Message-ID: <50F2774F.7010502@fastmail.fm> On 13/01/2013 01:26, Michael Hall wrote: > On Jan 12, 2013, at 7:19 PM, Mike Swingler wrote: > >> As I recall (though I can't find any public documentation about this), the logging policy was changed in Mountain Lion to ignore ordinary inherited stdout/stderr, and to only log records into the ASL database that came through the ASL API (of which NSLog does use). > Might not always work for everyone but why not redirect standard i/o to custom classes that wrap NSLog's? > > Michael Hall How do we do that, and why did Apple change this anyway ? Paul From mik3hall at gmail.com Sun Jan 13 03:36:47 2013 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 13 Jan 2013 05:36:47 -0600 Subject: System.out.println on Mountain Lion In-Reply-To: <50F2774F.7010502@fastmail.fm> References: <50F13C83.8060100@fastmail.fm> <85C99A87-95CC-473A-ADB7-E38A179D61E9@apple.com> <50F2774F.7010502@fastmail.fm> Message-ID: <907E58EB-6D0A-4FE6-BA14-75010585B63F@gmail.com> On Jan 13, 2013, at 2:58 AM, Paul Taylor wrote: > On 13/01/2013 01:26, Michael Hall wrote: >> On Jan 12, 2013, at 7:19 PM, Mike Swingler wrote: >> >>> As I recall (though I can't find any public documentation about this), the logging policy was changed in Mountain Lion to ignore ordinary inherited stdout/stderr, and to only log records into the ASL database that came through the ASL API (of which NSLog does use). >> Might not always work for everyone but why not redirect standard i/o to custom classes that wrap NSLog's? >> >> Michael Hall > How do we do that, and Redirect i/o using the System.setOut method. Some permissions are involved, might not be available to all code. Write a custom PrintStream subclass that passes it''s print,println and write methods off to JNI. Write the JNI counterpart that takes the System.out print, println, and write parameters and instead passes them to NSLog. My HalfPipe java shell application below does something similar for redirecting normal System.out to a Java text component, if indicated on the command line it also can redirect to a text file. I would suggest my own app but the console has become a bit complicated with interdependencies to the rest of the application over the years. > why did Apple change this anyway ? No idea. I'm still just Lion with no immediate plans to upgrade. I tend to ignore Mountain Lion specific discussion and remember no prior mention of this. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From mik3hall at gmail.com Sun Jan 13 03:44:51 2013 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 13 Jan 2013 05:44:51 -0600 Subject: System.out.println on Mountain Lion In-Reply-To: <907E58EB-6D0A-4FE6-BA14-75010585B63F@gmail.com> References: <50F13C83.8060100@fastmail.fm> <85C99A87-95CC-473A-ADB7-E38A179D61E9@apple.com> <50F2774F.7010502@fastmail.fm> <907E58EB-6D0A-4FE6-BA14-75010585B63F@gmail.com> Message-ID: On Jan 13, 2013, at 5:36 AM, Michael Hall wrote: >>> redirect standard i/o to custom classes that wrap NSLog's? >> Oh, by the way, actually I started to write something for this last night, along the lines of what I outlined. More or less had the java class done, prints and printlns (the println's just called the print methods, I saw no reason for the distinction here), I was thinking about the write methods and hadn't started the JN, but then thought I might be getting a little over achiever for code I probably wouldn't use and no one else had said they wanted. So I stopped working on it. If anyone thinks they'd get use out of it, I'd be happy to finish throwing something together that would probably work at least for simple debug println'.s Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From mik3hall at gmail.com Sun Jan 13 11:11:45 2013 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 13 Jan 2013 13:11:45 -0600 Subject: System.out.println on Mountain Lion In-Reply-To: <50F2774F.7010502@fastmail.fm> References: <50F13C83.8060100@fastmail.fm> <85C99A87-95CC-473A-ADB7-E38A179D61E9@apple.com> <50F2774F.7010502@fastmail.fm> Message-ID: On Jan 13, 2013, at 2:58 AM, Paul Taylor wrote: > How do we do that For the exercise I finished throwing together something that I think could work for this. http://www195.pair.com/mik3hall/logio.dmg To redirect System.out.println's to go to JNI NSLog's can be done something like? System.setOut(LogOut.getInstance()); You could do that based on os version, system property, whatever. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From mik3hall at gmail.com Sun Jan 13 19:22:56 2013 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 13 Jan 2013 21:22:56 -0600 Subject: 7u11 install Message-ID: I was running a jws application when it said there was a java update and prompted for install. When I said ok, I got some kind of error, try later. I went into Update for the java control panel and tried the update from there, I got the same error, try later. I found the update off the browser and downloaded and installed from there, went fine. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From pranav.bhat at oracle.com Sun Jan 13 19:45:43 2013 From: pranav.bhat at oracle.com (Pranav Bhat) Date: Sun, 13 Jan 2013 22:45:43 -0500 Subject: 7u11 install In-Reply-To: References: Message-ID: <9ED5B106-023F-48D3-8047-478A03C158A8@oracle.com> Hello, Do you remember what was the error? What did it say? Did it print the error on the terminal, java console or show a UI? Thanks, - Pranav On Jan 13, 2013, at 10:22 PM, Michael Hall wrote: > I was running a jws application when it said there was a java update and prompted for install. When I said ok, I got some kind of error, try later. > I went into Update for the java control panel and tried the update from there, I got the same error, try later. > I found the update off the browser and downloaded and installed from there, went fine. > > Michael Hall > > trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz > > HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe > > AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter > > > > From terry at trwarren.com Sun Jan 13 20:07:33 2013 From: terry at trwarren.com (Terry Warren) Date: Sun, 13 Jan 2013 20:07:33 -0800 Subject: 7u11 install In-Reply-To: <9ED5B106-023F-48D3-8047-478A03C158A8@oracle.com> References: <9ED5B106-023F-48D3-8047-478A03C158A8@oracle.com> Message-ID: <8554C08F-FE3B-45BE-B9D8-AE87F6E0C00B@trwarren.com> I also got this error; it shows up as a ui dialog with the wording: Update Error! An error occurred while downloading the update. Please try again later. On Jan 13, 2013, at 7:45 PM, Pranav Bhat wrote: > Hello, > > Do you remember what was the error? What did it say? Did it print the error on the terminal, java console or show a UI? > > Thanks, > - Pranav > > On Jan 13, 2013, at 10:22 PM, Michael Hall wrote: > >> I was running a jws application when it said there was a java update and prompted for install. When I said ok, I got some kind of error, try later. >> I went into Update for the java control panel and tried the update from there, I got the same error, try later. >> I found the update off the browser and downloaded and installed from there, went fine. >> >> Michael Hall >> >> trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz >> >> HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe >> >> AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter >> >> >> >> > From jcpalmer at rochester.rr.com Sun Jan 13 21:09:10 2013 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Mon, 14 Jan 2013 00:09:10 -0500 Subject: 7u11 did not self update on Lion Message-ID: FYI, Detected a release came out. Got lazy and tried going to the control panel & clicking update now, a progress box came up followed immediately some failure message. Wanting to check things still ran. Did a manual download & install. Now of course I cannot reproduce the problem, since shared JRE is not un-installable, or cannot have an older version installed. Do not remember the message, but there was not much detail. Hopefully, this is network related & goes away. From alexandr.scherbatiy at oracle.com Mon Jan 14 02:14:16 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 14 Jan 2013 14:14:16 +0400 Subject: [8] Request for review: 7124525 [macosx] No animation on certain Swing components in Aqua LaF In-Reply-To: <50DDA70A.9050806@oracle.com> References: <50DDA70A.9050806@oracle.com> Message-ID: <50F3DA78.2060701@oracle.com> The fix looks good for me. Thanks, Alexandr. On 12/28/2012 6:04 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix. > Change description: > - ImageCache shouldn't cache images for animated components + cleanup. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124525 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124525/webrev.00 > > -- > Best regards, Sergey. From pranav.bhat at oracle.com Mon Jan 14 07:05:14 2013 From: pranav.bhat at oracle.com (Pranav Bhat) Date: Mon, 14 Jan 2013 10:05:14 -0500 Subject: 7u11 did not self update on Lion In-Reply-To: References: Message-ID: <287F8EE6-2BA0-4676-801A-91AD8812B2C6@oracle.com> I'll test on Lion?.Tested this on Mountain Lion last night (I'm on EST) after it was first reported and it worked fine for me. I _think_ (rather hope!) that this was network related too?let us know if you see more of this?. Thanks, - Pranav On Jan 14, 2013, at 12:09 AM, Jeff Palmer wrote: > FYI, Detected a release came out. Got lazy and tried going to the control panel & clicking update now, a progress box came up followed immediately some failure message. Wanting to check things still ran. Did a manual download & install. > > Now of course I cannot reproduce the problem, since shared JRE is not un-installable, or cannot have an older version installed. Do not remember the message, but there was not much detail. Hopefully, this is network related & goes away. From terry at trwarren.com Mon Jan 14 11:21:35 2013 From: terry at trwarren.com (Terry Warren) Date: Mon, 14 Jan 2013 11:21:35 -0800 Subject: 7u11 did not self update on Lion In-Reply-To: <287F8EE6-2BA0-4676-801A-91AD8812B2C6@oracle.com> References: <287F8EE6-2BA0-4676-801A-91AD8812B2C6@oracle.com> Message-ID: I had the update problem last night; when I tried it this morning it downloaded and installed, so maybe just a network problem? - question though: this is first time I've updated 1.7 and even though it "installed", when I open terminal window and enter java -version command it still shows older 1.7 version - even after computer reboot - so how to enable new version? thanks Terry W On Jan 14, 2013, at 7:05 AM, Pranav Bhat wrote: > I'll test on Lion?.Tested this on Mountain Lion last night (I'm on EST) after it was first reported and it worked fine for me. > > I _think_ (rather hope!) that this was network related too?let us know if you see more of this?. > > Thanks, > - Pranav > > > On Jan 14, 2013, at 12:09 AM, Jeff Palmer wrote: > >> FYI, Detected a release came out. Got lazy and tried going to the control panel & clicking update now, a progress box came up followed immediately some failure message. Wanting to check things still ran. Did a manual download & install. >> >> Now of course I cannot reproduce the problem, since shared JRE is not un-installable, or cannot have an older version installed. Do not remember the message, but there was not much detail. Hopefully, this is network related & goes away. > From swingler at apple.com Mon Jan 14 11:30:09 2013 From: swingler at apple.com (Mike Swingler) Date: Mon, 14 Jan 2013 11:30:09 -0800 Subject: 7u11 did not self update on Lion In-Reply-To: References: <287F8EE6-2BA0-4676-801A-91AD8812B2C6@oracle.com> Message-ID: <34C2A0E5-784B-4F50-84AF-6A974EF7E3D6@apple.com> The auto-update only updated the vulnerable Java applet plug-in in /Library/Internet Plug-ins. The JDK (developer tools) you installed in /Library/Java/JavaVirtualMachines was not touched. You developer command-line tools will not be modified, even if you install newer versions - the newer versions should install side-by-side with the old ones. It's a feature, not a bug! Regards, Mike Swingler Apple Inc. On Jan 14, 2013, at 11:21 AM, Terry Warren wrote: > I had the update problem last night; when I tried it this morning it downloaded and installed, so maybe just a network problem? - question though: this is first time I've updated 1.7 and even though it "installed", when I open terminal window and enter java -version command it still shows older 1.7 version - even after computer reboot - so how to enable new version? > > thanks > Terry W > > On Jan 14, 2013, at 7:05 AM, Pranav Bhat wrote: > >> I'll test on Lion?.Tested this on Mountain Lion last night (I'm on EST) after it was first reported and it worked fine for me. >> >> I _think_ (rather hope!) that this was network related too?let us know if you see more of this?. >> >> Thanks, >> - Pranav >> >> >> On Jan 14, 2013, at 12:09 AM, Jeff Palmer wrote: >> >>> FYI, Detected a release came out. Got lazy and tried going to the control panel & clicking update now, a progress box came up followed immediately some failure message. Wanting to check things still ran. Did a manual download & install. >>> >>> Now of course I cannot reproduce the problem, since shared JRE is not un-installable, or cannot have an older version installed. Do not remember the message, but there was not much detail. Hopefully, this is network related & goes away. >> > From Sergey.Bylokhov at oracle.com Tue Jan 15 07:12:13 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 15 Jan 2013 19:12:13 +0400 Subject: [8] Request for review: 8003173 [macosx] Fullscreen on Mac leaves an empty rectangle In-Reply-To: <50ED935D.6050104@oracle.com> References: <50ED7187.3010207@oracle.com> <50ED8170.5050601@oracle.com> <50ED935D.6050104@oracle.com> Message-ID: <50F571CD.5080903@oracle.com> 09.01.2013 19:57, Sergey Bylokhov wrote: > >> src/macosx/native/sun/awt/AWTWindow.m >>> 821 [ThreadUtilities performOnMainThreadWaiting:YES block:^(){ >>> 822 AWT_ASSERT_APPKIT_THREAD; >> >> This ASSERT statement may safely be removed since the ThreadUtilities >> already guarantee us that we're running on the main thread. > I just use standard template from AWTWindow.m, so it will be simple to > change this template at once. Because Petr removes this native macros, I'll remove it also from my fix. I'll send new version soon. -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Jan 15 08:47:35 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 15 Jan 2013 20:47:35 +0400 Subject: [8] Request for review: 8003173 [macosx] Fullscreen on Mac leaves an empty rectangle In-Reply-To: <50ED935D.6050104@oracle.com> References: <50ED7187.3010207@oracle.com> <50ED8170.5050601@oracle.com> <50ED935D.6050104@oracle.com> Message-ID: <50F58827.9000506@oracle.com> On 1/9/2013 19:57, Sergey Bylokhov wrote: > 09.01.2013 18:40, Anthony Petrov wrote: >> src/macosx/classes/sun/lwawt/LWWindowPeer.java: >> Note that theoretically the insets can be changed w/o changing the >> content size. For example, if a user switches to a theme with enlarged >> window decorations. Not sure if this applies to Mac presently, but in >> theory this is possible. Will sending the COMPONENT_RESIZE event be >> equivalent to calling the replaceSurfaceData() in this case? Also, >> since the event is only posted but not processed yet, what is the >> point to call repaintPeer() before the surface data is replaced? > In general surfaceData should include top level size of the > window(including insets) So it's not necessary to replace surface here. > Because there is no api for target notification about new insets I use > COMPONENT_RESIZE event. Thanks for clarifying that. >> src/macosx/classes/sun/lwawt/macosx/CPlatformView.java: >> The actual fix seems to reside in this file. Why doesn't >> peer.getInsets() return zeros in the full screen mode? If it does >> actually, why do we need this change then? A generic, >> insets-accounting size calculation seems to be preferable in case we >> need a non-zero insets for some specific use-cases in the future. > When we set NSView to full screen the native insets(as we calculate it) > does not change. Because of that we use synthetic resize notifications > in enterFullScreenMode() we just should not include insets in this case. At line 98 of CPlatformView.java in "peer.getInsets()", the peer is an LWWindowPeer instance associated with the view. In CPlatformWindow.enterFullScreenMode() you already call "peer.updateInsets(new Insets(0, 0, 0, 0))" which should zero out the insets stored in the same peer. So the peer.getInsets() call in CPlatformView will return these zeros, and hence they shouldn't affect the calculations you perform at lines 111-115 in CPlatformView. So I repeat my question, why do we need to change anything in CPlatformView then? Can we just revert the changes? >> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java: >>> 876 peer.updateInsets(getInsets()); >> >> This will call a native method upon sending every move/resize event. >> Why do we actually have to do this? I assume the peer already calls >> the PlatformWindow.getInsets() whenever needed. > No. It does not call, that's the problem. >> Also, AFAIK, insets rarely change on Mac, and you already handle their >> manual changes when entering/exiting the full screen mode. Can we just >> remove this line? > No. There are two different fullscreens. > 1 The full screen based on Nsview, which is used via Graphics device. > For this we emulate insets and events. > 2 The full screen in lion style. We can handle it in > windowWillEnterFullScreen/windowDidEnterFullScreen. In the WillEnterXX > window have old insets and in the DidEnterXX window have new insets. > DidEnterXX comes after Resize events, which will repaint the window ==> > we get content's jumping. So, why not simply call "peer.updateInsets(new Insets(0, 0, 0, 0))" from windowWillEnter... then? Otherwise this looks inconsistent because in the case of the GraphicsDevice-based full screen mode you zero out the insets manually, but they remain being non-zero in the native full screen mode. -- best regards, Anthony >> src/macosx/native/sun/awt/AWTWindow.m >>> 821 [ThreadUtilities performOnMainThreadWaiting:YES block:^(){ >>> 822 AWT_ASSERT_APPKIT_THREAD; >> >> This ASSERT statement may safely be removed since the ThreadUtilities >> already guarantee us that we're running on the main thread. > I just use standard template from AWTWindow.m, so it will be simple to > change this template at once. >> >> -- >> best regards, >> Anthony >> >> On 1/9/2013 17:32, Sergey Bylokhov wrote: >>> Hello, >>> Please review the fix. >>> The reason why we have an empty space in the full screen mode is that >>> we did not update our insets. >>> - I update insets in the deliverMoveResizeEvent not in the >>> windowDidEnterFullScreen, in this case animation became more >>> smooth(since we update insets just before paint action). So all old >>> fullscreen handle methods in CPlatformWindow were removed. >>> - LWWindowPeer.updateInsets will post ComponentEvent if insets were >>> changed. >>> - CGraphicsDevice.setDisplayMode now stores/restores full screen >>> window, because otherwise NSView looks shifted on screen. >>> - CPlatformView.enterFullScreenMode(): code related to insets was >>> removed, since NSVIew uses the whole screen unlike jdk 6.(see related >>> changes in CPlatformWindow.enter/exitFullScreenMode) >>> >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003173 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8003173/webrev.00 >>> > > From rjenks at ti.com Wed Jan 16 15:11:37 2013 From: rjenks at ti.com (Jenks, Robert) Date: Wed, 16 Jan 2013 23:11:37 +0000 Subject: Difference between Mac and Windows JNI Message-ID: I would like to ask (and I'm not sure if I should enter a bug/RFE in Oracle's java bug DB or not) that the definition of JNIEXPORT be changed for mac. I am in the process of moving a large cross-platform java/native application from Apple Java 1.6 to Oracle Java 1.7 on mac and ran into an issue. JNIEXPORT is defined in jni_md.h on each platform: Oracle Java for Windows: #define JNIEXPORT __declspec(dllexport) Apple Java for Mac: #define JNIEXPORT __attribute__((visibility("default"))) Oracle Java for Mac: #define JNIEXPORT The Oracle Java for Mac case is problematic if not broken. In case it is not well understood, let me give some background. On Windows when you build a DLL functions have to be explicitly marked as '__declspec(dllexport)' to make them callable from outside the DLL. Oracle java on windows' JNIEXPORT does this for you automatically. On Mac, GCC by default exports every function as callable from outside the dylib. However, to mimic the same behavior many developers build with '?fvisibility=hidden' to set the default to hidden (or do not export from the dylib). With Apple java JNIEXPORT properly defines that JNI functions must be callable from outside the dylib. Oracle's doesn't. Therefore if you compile with default settings everything works as expected. If you compile with -fvisibility=hidden your JNI functions won't be exported from the dylib. This worked with Apple's Java, but doesn't with Oracle's. That, in itself, isn't the issue, but I think that this should be consistent between Oracle's Windows and Mac versions. JNI functions should be explicitly marked as exported from shared libraries by using the JNIEXPORT macro. I can work around this, but I would hope that this would be changed. To me this is a bug, but I could see the argument the other way too. What is the best way to proceed to officially request this change? -Robert From swingler at apple.com Wed Jan 16 15:15:52 2013 From: swingler at apple.com (Mike Swingler) Date: Wed, 16 Jan 2013 15:15:52 -0800 Subject: Difference between Mac and Windows JNI In-Reply-To: References: Message-ID: <0DC80E58-6B12-4781-9492-0C8316D24DFB@apple.com> On Jan 16, 2013, at 3:11 PM, "Jenks, Robert" wrote: > I would like to ask (and I'm not sure if I should enter a bug/RFE in > Oracle's java bug DB or not) that the definition of JNIEXPORT be changed > for mac. > > I am in the process of moving a large cross-platform java/native > application from Apple Java 1.6 to Oracle Java 1.7 on mac and ran into an > issue. > > JNIEXPORT is defined in jni_md.h on each platform: > > Oracle Java for Windows: #define JNIEXPORT __declspec(dllexport) > Apple Java for Mac: #define JNIEXPORT > __attribute__((visibility("default"))) > Oracle Java for Mac: #define JNIEXPORT > > The Oracle Java for Mac case is problematic if not broken. > > In case it is not well understood, let me give some background. On > Windows when you build a DLL functions have to be explicitly marked as > '__declspec(dllexport)' to make them callable from outside the DLL. > Oracle java on windows' JNIEXPORT does this for you automatically. On > Mac, GCC by default exports every function as callable from outside the > dylib. However, to mimic the same behavior many developers build with > '?fvisibility=hidden' to set the default to hidden (or do not export from > the dylib). With Apple java JNIEXPORT properly defines that JNI functions > must be callable from outside the dylib. Oracle's doesn't. Therefore if > you compile with default settings everything works as expected. If you > compile with -fvisibility=hidden your JNI functions won't be exported from > the dylib. > > This worked with Apple's Java, but doesn't with Oracle's. That, in > itself, isn't the issue, but I think that this should be consistent > between Oracle's Windows and Mac versions. JNI functions should be > explicitly marked as exported from shared libraries by using the JNIEXPORT > macro. > > I can work around this, but I would hope that this would be changed. To > me this is a bug, but I could see the argument the other way too. What is > the best way to proceed to officially request this change? Please file this as a bug at . Thanks, Mike Swingler Apple Inc. From mikhail.cherkasov at oracle.com Thu Jan 17 08:29:18 2013 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 17 Jan 2013 20:29:18 +0400 Subject: Clipboard Formats In-Reply-To: <50D6292E.9050906@oracle.com> References: <50D61F52.6030701@oracle.com> <1864E993-E001-4CC0-A9B4-AE07D94299D8@apple.com> <50D6292E.9050906@oracle.com> Message-ID: <50F826DE.6020207@oracle.com> Hello All, I found why the flavor list is different, as I see DataTransferer.standardEncodings() produce different results for jdk6 and jdk7. Furthermore, all Mac* charsets and support classes( converters) were exclude form jdk7, however they present in jdk6. So have you any idea why this was done? is it possible to get them back? Also where can I get DataTransferer.standardEncodings() method sources? Because I still don't know why DataTransferer.standardEncodings() result depends on how it was launched. Thanks, Mikhail. 23.12.2012 1:42, Mikhail Cherkasov ?????: > Sounds like I don't have to dig native code, it's good news, thanks > for help. > > 23.12.2012 1:29, Mike Swingler ?????: >> On Dec 22, 2012, at 3:00 PM, Mikhail Cherkasov >> wrote: >> >>> Hello All, >>> >>> Jdk 7 has less data flavor types than jdk 6, the following types are >>> missing from in jdk 7: >>> -text/plain; class=java.io.InputStream; charset=MacRoman >>> -text/plain; class=java.nio.ByteBuffer; charset=MacRoman >>> -text/plain; class="[B"; charset=MacRoman >>> >>> You can print available formats by this code: >>> for (final DataFlavor flavor : >>> Toolkit.getDefaultToolkit().getSystemClipboard().getAvailableDataFlavors()) >>> { >>> System.out.println(flavor.getMimeType()); >>> } >>> >>> Does anyone know why this DataFlavors are absent in jdk 7? >>> And is it possible to get them back? if yes, how I can do this? >>> >>> I have not idea where to get jdk6 source code for macos, so I can't >>> compare >>> Java_sun_lwawt_macosx_CClipboard_getClipboardFormats method >>> implementation. >> Java_sun_lwawt_macosx_CClipboard_getClipboardFormats() and >> Java_apple_awt_CClipboard_getClipboardFormats() in Java SE 6 are >> line-for-line copies of each other. Also, CClipboard.m in OpenJDK 8 >> is largely identical to the original version created in 2002 by Scott >> Kovatch. :-) >> >> I have noticed that the flavormap.properties file is significantly >> different. Perhaps that would be a fruitful area of investigation. >> >> Regards, >> Mike Swingler >> Apple Inc. >> > From mikhail.cherkasov at oracle.com Thu Jan 17 09:17:55 2013 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 17 Jan 2013 21:17:55 +0400 Subject: Clipboard Formats In-Reply-To: <50F826DE.6020207@oracle.com> References: <50D61F52.6030701@oracle.com> <1864E993-E001-4CC0-A9B4-AE07D94299D8@apple.com> <50D6292E.9050906@oracle.com> <50F826DE.6020207@oracle.com> Message-ID: <50F83243.8020708@oracle.com> Looks like MacRomam is still here but has new form: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/b89ba9a6d9a6 But I sill intresting jdk6s DataTransferer.standardEncodings()code. 17.01.2013 20:29, mikhail cherkasov ?????: > Hello All, > > I found why the flavor list is different, as I see > DataTransferer.standardEncodings() produce different results for jdk6 > and jdk7. > Furthermore, all Mac* charsets and support classes( converters) were > exclude form jdk7, however they present in jdk6. > > So have you any idea why this was done? is it possible to get them back? > > Also where can I get DataTransferer.standardEncodings() method sources? > Because I still don't know why DataTransferer.standardEncodings() > result depends on how it was launched. > > Thanks, > Mikhail. > > 23.12.2012 1:42, Mikhail Cherkasov ?????: >> Sounds like I don't have to dig native code, it's good news, thanks >> for help. >> >> 23.12.2012 1:29, Mike Swingler ?????: >>> On Dec 22, 2012, at 3:00 PM, Mikhail Cherkasov >>> wrote: >>> >>>> Hello All, >>>> >>>> Jdk 7 has less data flavor types than jdk 6, the following types >>>> are missing from in jdk 7: >>>> -text/plain; class=java.io.InputStream; charset=MacRoman >>>> -text/plain; class=java.nio.ByteBuffer; charset=MacRoman >>>> -text/plain; class="[B"; charset=MacRoman >>>> >>>> You can print available formats by this code: >>>> for (final DataFlavor flavor : >>>> Toolkit.getDefaultToolkit().getSystemClipboard().getAvailableDataFlavors()) >>>> { >>>> System.out.println(flavor.getMimeType()); >>>> } >>>> >>>> Does anyone know why this DataFlavors are absent in jdk 7? >>>> And is it possible to get them back? if yes, how I can do this? >>>> >>>> I have not idea where to get jdk6 source code for macos, so I can't >>>> compare >>>> Java_sun_lwawt_macosx_CClipboard_getClipboardFormats method >>>> implementation. >>> Java_sun_lwawt_macosx_CClipboard_getClipboardFormats() and >>> Java_apple_awt_CClipboard_getClipboardFormats() in Java SE 6 are >>> line-for-line copies of each other. Also, CClipboard.m in OpenJDK 8 >>> is largely identical to the original version created in 2002 by >>> Scott Kovatch. :-) >>> >>> I have noticed that the flavormap.properties file is significantly >>> different. Perhaps that would be a fruitful area of investigation. >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> >> > From oleg.barbashov at oracle.com Fri Jan 18 07:45:55 2013 From: oleg.barbashov at oracle.com (Oleg G. Barbashov) Date: Fri, 18 Jan 2013 19:45:55 +0400 Subject: JVM crash on AXUIElementCopyAttributeValues(+) Message-ID: <50F96E33.2000004@oracle.com> Got JVM crash while trying to get accessibility attributes for simplest AWT application with one button (AXUIElementCopyAttributeValues is called on arbitrary thread of the application process). Is there any workaround? Thanks, Oleg 2013-01-10 18:42:07.622 java[48245:1803] Cocoa AWT: Not running on AppKit thread 0 when expected. ( 0 liblwawt.dylib 0x0000000109e639b2 -[AWTView accessibilityAttributeValue:] + 47 1 AppKit 0x00007fff8a0a80ba ValueOfAttributeWithDefault + 48 2 AppKit 0x00007fff8a0a806e NSAccessibilityChildrenOrEmptyArray + 19 3 AppKit 0x00007fff8a0a85c6 NSAccessibilityUnignoredChildren + 232 4 CoreFoundation 0x00007fff8584cfb1 -[NSObject performSelector:] + 49 5 AppKit 0x00007fff8a0a8275 NSAccessibilityAttributeValue + 107 6 AppKit 0x00007fff8a0a80ba ValueOfAttributeWithDefault + 48 7 AppKit 0x00007fff8a0a806e NSAccessibilityChildrenOrEmptyArray + 19 8 AppKit 0x00007fff8a0a85c6 NSAccessibilityUnignoredChildren + 232 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fff857c1a22, pid=48245, tid=6147 # # JRE version: 7.0_10-b31 # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.6-b04 mixed mode bsd-amd64 compressed oops) # Problematic frame: # C [CoreFoundation+0xfa22] CFArrayGetCount+0x12 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/Shared/Work/ErrorSample/hs_err_pid48245.log # 9 CoreFoundation 0x00007fff8584cfb1 -[NSObject performSelector:] + 49 10 AppKit 0x00007fff8a0a8275 NSAccessibilityAttributeValue + 107 11 AppKit 0x00007fff8a2698b2 NSAccessibilityAttributeValueAllowingOverrides + 74 12 AppKit 0x00007fff8a269e42 -[NSObject(NSObjectAccessibilityAttributeAccessAdditions) accessibilityArrayAttributeCount:] + 28 13 AppKit 0x00007fff8a26a62c -[NSObject(NSAccessibilityInternal) _accessibilityArrayAttributeValues:index:maxCount:clientError:] + 132 14 AppKit 0x00007fff8a26d9cb CopyAttributeValues + 219 15 HIServices 0x00007fff8c3c00a1 _AXXMIGCopyAttributeValues + 238 16 HIServices 0x00007fff8c3be344 AXUIElementCopyAttributeValues + 615 17 libJemmyNative_x64.dylib 0x000000010fc9ec7a Java_org_jemmy_osx_OSX_reproduce + 202 18 ??? 0x0000000100f37db1 0x0 + 4310924721 ) 2013-01-10 18:42:07.624 java[48245:1803] Please file a bug report at http://java.net/jira/browse/MACOSX_PORT with this message and a reproducible test case. 2013-01-10 18:42:07.628 java[48245:1803] Cocoa AWT: Not running on AppKit thread 0 when expected. ( 0 libosxapp.dylib 0x0000000109eff411 +[ThreadUtilities getJNIEnv] + 34 1 liblwawt.dylib 0x0000000109e63a0b -[AWTView accessibilityAttributeValue:] + 136 2 AppKit 0x00007fff8a0a80ba ValueOfAttributeWithDefault + 48 3 AppKit 0x00007fff8a0a806e NSAccessibilityChildrenOrEmptyArray + 19 4 AppKit 0x00007fff8a0a85c6 NSAccessibilityUnignoredChildren + 232 5 CoreFoundation 0x00007fff8584cfb1 -[NSObject performSelector:] + 49 6 AppKit 0x00007fff8a0a8275 NSAccessibilityAttributeValue + 107 7 AppKit 0x00007fff8a0a80ba ValueOfAttributeWithDefault + 48 8 AppKit 0x00007fff8a0a806e NSAccessibilityChildrenOrEmptyArray + 19 9 AppKit 0x00007fff8a0a85c6 NSAccessibilityUnignoredChildren + 232 10 CoreFoundation 0x00007fff8584cfb1 -[NSObject performSelector:] + 49 11 AppKit 0x00007fff8a0a8275 NSAccessibilityAttributeValue + 107 12 AppKit 0x00007fff8a2698b2 NSAccessibilityAttributeValueAllowingOverrides + 74 13 AppKit 0x00007fff8a269e42 -[NSObject(NSObjectAccessibilityAttributeAccessAdditions) accessibilityArrayAttributeCount:] + 28 14 AppKit 0x00007fff8a26a62c -[NSObject(NSAccessibilityInternal) _accessibilityArrayAttributeValues:index:maxCount:clientError:] + 132 15 AppKit 0x00007fff8a26d9cb CopyAttributeValues + 219 16 HIServices 0x00007fff8c3c00a1 _AXXMIGCopyAttributeValues + 238 17 HIServices 0x00007fff8c3be344 AXUIElementCopyAttributeValues + 615 18 libJemmyNative_x64.dylib 0x000000010fc9ec7a Java_org_jemmy_osx_OSX_reproduce + 202 19 ??? 0x0000000100f37db1 0x0 + 4310924721 ) 2013-01-10 18:42:07.631 java[48245:1803] Please file a bug report at http://java.net/jira/browse/MACOSX_PORT with this message and a reproducible test case. 2013-01-10 18:42:07.636 java[48245:1803] Cocoa AWT: Not running on AppKit thread 0 when expected. ( 0 libosxapp.dylib 0x0000000109eff411 +[ThreadUtilities getJNIEnv] + 34 1 liblwawt.dylib 0x0000000109e7e9c3 +[JavaComponentAccessibility initialize] + 277 2 libobjc.A.dylib 0x00007fff8df53662 _class_initialize + 320 3 libobjc.A.dylib 0x00007fff8df53517 prepareForMethodLookup + 237 # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp 4 libobjc.A.dylib 0x00007fff8df532bb lookUpMethod + 63 # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. 5 libobjc.A.dylib 0x00007fff8df50f3c objc_msgSend + 188 # 6 liblwawt.dylib 0x0000000109e61f40 -[AWTView getAxData:] + 39 7 liblwawt.dylib 0x0000000109e63a33 -[AWTView accessibilityAttributeValue:] + 176 8 AppKit 0x00007fff8a0a80ba ValueOfAttributeWithDefault + 48 9 AppKit 0x00007fff8a0a806e NSAccessibilityChildrenOrEmptyArray + 19 10 AppKit 0x00007fff8a0a85c6 NSAccessibilityUnignoredChildren + 232 11 CoreFoundation 0x00007fff8584cfb1 -[NSObject performSelector:] + 49 12 AppKit 0x00007fff8a0a8275 NSAccessibilityAttributeValue + 107 13 AppKit 0x00007fff8a0a80ba ValueOfAttributeWithDefault + 48 14 AppKit 0x00007fff8a0a806e NSAccessibilityChildrenOrEmptyArray + 19 15 AppKit 0x00007fff8a0a85c6 NSAccessibilityUnignoredChildren + 232 16 CoreFoundation 0x00007fff8584cfb1 -[NSObject performSelector:] + 49 17 AppKit 0x00007fff8a0a8275 NSAccessibilityAttributeValue + 107 18 AppKit 0x00007fff8a2698b2 NSAccessibilityAttributeValueAllowingOverrides + 74 19 AppKit 0x00007fff8a269e42 -[NSObject(NSObjectAccessibilityAttributeAccessAdditions) accessibilityArrayAttributeCount:] + 28 20 AppKit 0x00007fff8a26a62c -[NSObject(NSAccessibilityInternal) _accessibilityArrayAttributeValues:index:maxCount:clientError:] + 132 21 AppKit 0x00007fff8a26d9cb CopyAttributeValues + 219 22 HIServices 0x00007fff8c3c00a1 _AXXMIGCopyAttributeValues + 238 23 HIServices 0x00007fff8c3be344 AXUIElementCopyAttributeValues + 615 24 libJemmyNative_x64.dylib 0x000000010fc9ec7a Java_org_jemmy_osx_OSX_reproduce + 202 25 ??? 0x0000000100f37db1 0x0 + 4310924721 ) 2013-01-10 18:42:07.637 java[48245:1803] Please file a bug report at http://java.net/jira/browse/MACOSX_PORT with this message and a reproducible test case. Java Result: 134 From Sergey.Bylokhov at oracle.com Fri Jan 18 09:59:29 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 18 Jan 2013 21:59:29 +0400 Subject: JVM crash on AXUIElementCopyAttributeValues(+) In-Reply-To: <50F96E33.2000004@oracle.com> References: <50F96E33.2000004@oracle.com> Message-ID: <50F98D81.5000909@oracle.com> Hi, Oleg. Please create new CR for this issue. 18.01.2013 19:45, Oleg G. Barbashov wrote: > Got JVM crash while trying to get accessibility attributes for > simplest AWT application with one button > (AXUIElementCopyAttributeValues is called on arbitrary thread of the > application process). Is there any workaround? > > Thanks, > Oleg -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Jan 19 05:32:56 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 19 Jan 2013 17:32:56 +0400 Subject: [8] Request for review: 8003173 [macosx] Fullscreen on Mac leaves an empty rectangle In-Reply-To: <50F58827.9000506@oracle.com> References: <50ED7187.3010207@oracle.com> <50ED8170.5050601@oracle.com> <50ED935D.6050104@oracle.com> <50F58827.9000506@oracle.com> Message-ID: <50FAA088.5010804@oracle.com> Hi, Anthony. Please review the new version of the fix: http://cr.openjdk.java.net/~serb/8003173/webrev.01 Now only CPWindow is responsible for all move/resize/newinsets notification, all related code was removed from CPView. isFullScreenAnimationOn was added to make fullscreen animation smooth. See inline comments. 15.01.2013 20:47, Anthony Petrov wrote: > On 1/9/2013 19:57, Sergey Bylokhov wrote: >> 09.01.2013 18:40, Anthony Petrov wrote: >>> src/macosx/classes/sun/lwawt/LWWindowPeer.java: >>> Note that theoretically the insets can be changed w/o changing the >>> content size. For example, if a user switches to a theme with >>> enlarged window decorations. Not sure if this applies to Mac >>> presently, but in theory this is possible. Will sending the >>> COMPONENT_RESIZE event be equivalent to calling the >>> replaceSurfaceData() in this case? Also, since the event is only >>> posted but not processed yet, what is the point to call >>> repaintPeer() before the surface data is replaced? >> In general surfaceData should include top level size of the >> window(including insets) So it's not necessary to replace surface >> here. Because there is no api for target notification about new >> insets I use COMPONENT_RESIZE event. > > Thanks for clarifying that. > >>> src/macosx/classes/sun/lwawt/macosx/CPlatformView.java: >>> The actual fix seems to reside in this file. Why doesn't >>> peer.getInsets() return zeros in the full screen mode? If it does >>> actually, why do we need this change then? A generic, >>> insets-accounting size calculation seems to be preferable in case we >>> need a non-zero insets for some specific use-cases in the future. >> When we set NSView to full screen the native insets(as we calculate >> it) does not change. Because of that we use synthetic resize >> notifications in enterFullScreenMode() we just should not include >> insets in this case. > > At line 98 of CPlatformView.java in "peer.getInsets()", the peer is an > LWWindowPeer instance associated with the view. In > CPlatformWindow.enterFullScreenMode() you already call > "peer.updateInsets(new Insets(0, 0, 0, 0))" which should zero out the > insets stored in the same peer. So the peer.getInsets() call in > CPlatformView will return these zeros, and hence they shouldn't affect > the calculations you perform at lines 111-115 in CPlatformView. But why we need this calculation there? I guess CPlatformWindow is a better place for insets calculation, otherwise in the CPlatformView.exitFullScreenMode() I'll get something like: peer.updateInsets(peer.getPlatformWindow().getInsets()); Which looks strange. In the new version of the fix LWWindowPeer fetch this information when necessary, and getPlatformWindow().getInsets() return correct value. > > So I repeat my question, why do we need to change anything in > CPlatformView then? Can we just revert the changes? Better to have related stuff in one class. > > >>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java: >>>> 876 peer.updateInsets(getInsets()); >>> >>> This will call a native method upon sending every move/resize event. >>> Why do we actually have to do this? I assume the peer already calls >>> the PlatformWindow.getInsets() whenever needed. >> No. It does not call, that's the problem. >>> Also, AFAIK, insets rarely change on Mac, and you already handle >>> their manual changes when entering/exiting the full screen mode. Can >>> we just remove this line? >> No. There are two different fullscreens. >> 1 The full screen based on Nsview, which is used via Graphics device. >> For this we emulate insets and events. >> 2 The full screen in lion style. We can handle it in >> windowWillEnterFullScreen/windowDidEnterFullScreen. In the >> WillEnterXX window have old insets and in the DidEnterXX window have >> new insets. DidEnterXX comes after Resize events, which will repaint >> the window ==> we get content's jumping. > > So, why not simply call "peer.updateInsets(new Insets(0, 0, 0, 0))" > from windowWillEnter... then? It is not necessary to make them empty, because native system changes decoration and insets for us. But this happens after willEnter and before didEnter. > Otherwise this looks inconsistent because in the case of the > GraphicsDevice-based full screen mode you zero out the insets > manually, but they remain being non-zero in the native full screen mode. In both cases insets will be empty, but in GraphicsDevice-based full screen mode we emulate insets/notification manually. > > -- > best regards, > Anthony > >>> src/macosx/native/sun/awt/AWTWindow.m >>>> 821 [ThreadUtilities performOnMainThreadWaiting:YES block:^(){ >>>> 822 AWT_ASSERT_APPKIT_THREAD; >>> >>> This ASSERT statement may safely be removed since the >>> ThreadUtilities already guarantee us that we're running on the main >>> thread. >> I just use standard template from AWTWindow.m, so it will be simple >> to change this template at once. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/9/2013 17:32, Sergey Bylokhov wrote: >>>> Hello, >>>> Please review the fix. >>>> The reason why we have an empty space in the full screen mode is >>>> that we did not update our insets. >>>> - I update insets in the deliverMoveResizeEvent not in the >>>> windowDidEnterFullScreen, in this case animation became more >>>> smooth(since we update insets just before paint action). So all old >>>> fullscreen handle methods in CPlatformWindow were removed. >>>> - LWWindowPeer.updateInsets will post ComponentEvent if insets >>>> were changed. >>>> - CGraphicsDevice.setDisplayMode now stores/restores full screen >>>> window, because otherwise NSView looks shifted on screen. >>>> - CPlatformView.enterFullScreenMode(): code related to insets was >>>> removed, since NSVIew uses the whole screen unlike jdk 6.(see >>>> related changes in CPlatformWindow.enter/exitFullScreenMode) >>>> >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003173 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/8003173/webrev.00 >>>> >> >> -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Jan 22 03:21:45 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Jan 2013 15:21:45 +0400 Subject: [8] Request for review: 8003173 [macosx] Fullscreen on Mac leaves an empty rectangle In-Reply-To: <50FAA088.5010804@oracle.com> References: <50ED7187.3010207@oracle.com> <50ED8170.5050601@oracle.com> <50ED935D.6050104@oracle.com> <50F58827.9000506@oracle.com> <50FAA088.5010804@oracle.com> Message-ID: <50FE7649.3050203@oracle.com> Hi Sergey, Thanks for the comments and the updated fix. It looks great. -- best regards, Anthony On 1/19/2013 17:32, Sergey Bylokhov wrote: > Hi, Anthony. > Please review the new version of the fix: > http://cr.openjdk.java.net/~serb/8003173/webrev.01 > Now only CPWindow is responsible for all move/resize/newinsets > notification, all related code was removed from CPView. > isFullScreenAnimationOn was added to make fullscreen animation smooth. > See inline comments. > > 15.01.2013 20:47, Anthony Petrov wrote: >> On 1/9/2013 19:57, Sergey Bylokhov wrote: >>> 09.01.2013 18:40, Anthony Petrov wrote: >>>> src/macosx/classes/sun/lwawt/LWWindowPeer.java: >>>> Note that theoretically the insets can be changed w/o changing the >>>> content size. For example, if a user switches to a theme with >>>> enlarged window decorations. Not sure if this applies to Mac >>>> presently, but in theory this is possible. Will sending the >>>> COMPONENT_RESIZE event be equivalent to calling the >>>> replaceSurfaceData() in this case? Also, since the event is only >>>> posted but not processed yet, what is the point to call >>>> repaintPeer() before the surface data is replaced? >>> In general surfaceData should include top level size of the >>> window(including insets) So it's not necessary to replace surface >>> here. Because there is no api for target notification about new >>> insets I use COMPONENT_RESIZE event. >> >> Thanks for clarifying that. >> >>>> src/macosx/classes/sun/lwawt/macosx/CPlatformView.java: >>>> The actual fix seems to reside in this file. Why doesn't >>>> peer.getInsets() return zeros in the full screen mode? If it does >>>> actually, why do we need this change then? A generic, >>>> insets-accounting size calculation seems to be preferable in case we >>>> need a non-zero insets for some specific use-cases in the future. >>> When we set NSView to full screen the native insets(as we calculate >>> it) does not change. Because of that we use synthetic resize >>> notifications in enterFullScreenMode() we just should not include >>> insets in this case. >> >> At line 98 of CPlatformView.java in "peer.getInsets()", the peer is an >> LWWindowPeer instance associated with the view. In >> CPlatformWindow.enterFullScreenMode() you already call >> "peer.updateInsets(new Insets(0, 0, 0, 0))" which should zero out the >> insets stored in the same peer. So the peer.getInsets() call in >> CPlatformView will return these zeros, and hence they shouldn't affect >> the calculations you perform at lines 111-115 in CPlatformView. > But why we need this calculation there? I guess CPlatformWindow is a > better place for insets calculation, otherwise in the > CPlatformView.exitFullScreenMode() I'll get something like: > peer.updateInsets(peer.getPlatformWindow().getInsets()); > Which looks strange. > In the new version of the fix LWWindowPeer fetch this information when > necessary, and getPlatformWindow().getInsets() return correct value. >> >> So I repeat my question, why do we need to change anything in >> CPlatformView then? Can we just revert the changes? > Better to have related stuff in one class. >> >> >>>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java: >>>>> 876 peer.updateInsets(getInsets()); >>>> >>>> This will call a native method upon sending every move/resize event. >>>> Why do we actually have to do this? I assume the peer already calls >>>> the PlatformWindow.getInsets() whenever needed. >>> No. It does not call, that's the problem. >>>> Also, AFAIK, insets rarely change on Mac, and you already handle >>>> their manual changes when entering/exiting the full screen mode. Can >>>> we just remove this line? >>> No. There are two different fullscreens. >>> 1 The full screen based on Nsview, which is used via Graphics device. >>> For this we emulate insets and events. >>> 2 The full screen in lion style. We can handle it in >>> windowWillEnterFullScreen/windowDidEnterFullScreen. In the >>> WillEnterXX window have old insets and in the DidEnterXX window have >>> new insets. DidEnterXX comes after Resize events, which will repaint >>> the window ==> we get content's jumping. >> >> So, why not simply call "peer.updateInsets(new Insets(0, 0, 0, 0))" >> from windowWillEnter... then? > It is not necessary to make them empty, because native system changes > decoration and insets for us. But this happens after willEnter and > before didEnter. >> Otherwise this looks inconsistent because in the case of the >> GraphicsDevice-based full screen mode you zero out the insets >> manually, but they remain being non-zero in the native full screen mode. > In both cases insets will be empty, but in GraphicsDevice-based full > screen mode we emulate insets/notification manually. >> >> -- >> best regards, >> Anthony >> >>>> src/macosx/native/sun/awt/AWTWindow.m >>>>> 821 [ThreadUtilities performOnMainThreadWaiting:YES block:^(){ >>>>> 822 AWT_ASSERT_APPKIT_THREAD; >>>> >>>> This ASSERT statement may safely be removed since the >>>> ThreadUtilities already guarantee us that we're running on the main >>>> thread. >>> I just use standard template from AWTWindow.m, so it will be simple >>> to change this template at once. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 1/9/2013 17:32, Sergey Bylokhov wrote: >>>>> Hello, >>>>> Please review the fix. >>>>> The reason why we have an empty space in the full screen mode is >>>>> that we did not update our insets. >>>>> - I update insets in the deliverMoveResizeEvent not in the >>>>> windowDidEnterFullScreen, in this case animation became more >>>>> smooth(since we update insets just before paint action). So all old >>>>> fullscreen handle methods in CPlatformWindow were removed. >>>>> - LWWindowPeer.updateInsets will post ComponentEvent if insets >>>>> were changed. >>>>> - CGraphicsDevice.setDisplayMode now stores/restores full screen >>>>> window, because otherwise NSView looks shifted on screen. >>>>> - CPlatformView.enterFullScreenMode(): code related to insets was >>>>> removed, since NSVIew uses the whole screen unlike jdk 6.(see >>>>> related changes in CPlatformWindow.enter/exitFullScreenMode) >>>>> >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003173 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/8003173/webrev.00 >>>>> >>> >>> > > From steve at weblite.ca Tue Jan 22 13:41:37 2013 From: steve at weblite.ca (Steve Hannah) Date: Tue, 22 Jan 2013 13:41:37 -0800 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> Message-ID: I just wanted to post my experiences with this bug. I was having trouble on OS X in both 1.7.0u11 and 1.7.0u12 with Japanese file names (File.exists() erroneously returning false). Scott's fix for LC_CTYPE was the only thing that worked for me. (tried file.encoding=UTF8, and sun.jnu.encoding=UTF8 to no avail). As I am deploying to the Mac App store I needed to set this environment variable using the Info.plist file, and the current appbundler ant task didn't have an option to set arbitrary keys/values in the Info.plist, so I modified the appbundler source (I was actually working off of the infinitekind fork of appbundler at https://bitbucket.org/infinitekind/appbundler) to automatically set the LSEnvironment key. The diff for this change is: diff -r 563fcd766efe appbundler/src/com/oracle/appbundler/AppBundlerTask.java --- a/appbundler/src/com/oracle/appbundler/AppBundlerTask.java Wed Sep 19 17:54:08 2012 +0100 +++ b/appbundler/src/com/oracle/appbundler/AppBundlerTask.java Tue Jan 22 13:31:11 2013 -0800 @@ -577,7 +577,16 @@ xout.writeEndElement(); xout.writeCharacters("\n"); - + + // Write Environment + writeKey(xout, "LSEnvironment"); + xout.writeStartElement(DICT_TAG); + xout.writeCharacters("\n"); + writeKey(xout, "LC_CTYPE"); + writeString(xout, "UTF-8"); + xout.writeEndElement(); + xout.writeCharacters("\n"); + // Write options writeKey(xout, "JVMOptions"); I'm not working off the trunk, so I don't know if this problem has actually been resolved... but this workaround works for me. Just thought I'd share in case it helps someone else along the line. -Steve On Wed, Oct 10, 2012 at 8:58 AM, Scott Kovatch wrote: > We fixed/worked around this in the plugin by setting the environment variable LC_CTYPE to UTF-8. Given that file names are in UTF-8 by default on OS X this seems unnecessary to me, but there you go. > > -- Scott K. > > > On Oct 10, 2012, at 4:41 AM, David Kocher wrote: > >> Agust, >> >> My workaround is to use NSFFileManager instead (with bridging through JNA or JNI). >> >> -- David >> >> On 10.10.2012, at 13:16, Thorkelsson wrote: >> >>> Thanks for this link David. >>> >>> I can see that this bug was marked critical for a year ago, but then I don't know what happens. Obviously it's a tough one. >>> >>> But just some feedback for all from a company perspective. At the risk of stating the obvious: This bug is really killing us. We can't release a huge upgrade depending on Java 7 (because of use of the JavaFX 2.2) because of this. We've been trying to workaround this bug for more than a week now without success. We just can't believe that this is something that is out in an official Java release. That's why we've been trying everything to find out what could be wrong on our side. But it doesn't seem to be that way (still don't believe it?) >>> >>> I can understand that this has slipped by before because Java 7 hasn't been out long for the Mac. But if it is the way that this is in the release, it will start affecting people quickly. >>> >>> This doesn't add to the solution, so I will not write more about it. But please, to those who have the influence, do everything you can to get this into the next update. We are here to help with anything regarding testing or reproducing the bug. >>> >>> And of course, if anyone has a workaround, it would be greatly appreciated to learn about it! >>> >>> Thanks, >>> >>> Agust >>> >>> >>> Agust Thorkelsson >>> Sideline Sports >>> thorkelsson at sidelinesports.com >>> www.sidelinesports.com >>> Mobile: +46 (0) 704 244 359 >>> EU Office: +46 (0) 40 692 7942 >>> >>> >>> On 10 okt 2012, at 11:35, David Kocher wrote: >>> >>>> This issue is being discussed in http://java.net/jira/browse/MACOSX_PORT-165. I will attach a test case again for the non believers. >>>> >>>> -- David >>>> >>>> On 10.10.2012, at 10:53, Alan Bateman wrote: >>>> >>>>> On 09/10/2012 21:21, ?orvaldur Bl?ndal wrote: >>>>>> Hi Alan and thanks for the suggestion. >>>>>> >>>>>> I downloaded version 1.8.0-ea-b59 and unfortunately it's the same. >>>>>> And this is not just about the exists()-method. I can't create a FileInputStream or anything like that. >>>>>> I can also tell you that files with atypical names are not seen at all in JFileChooser. I have to use java.awt.FileDialog. See attached picture. >>>>>> >>>>>> Note: I made a mistake when I said in the report that it previously worked in version 7. I meant to say version 6. >>>>>> >>>>> I'll bet this is related to your locale, you can print out the value of the file.encoding property? >>>>> >>>>> -Alan. >>>>> >>>> >>> >> > -- Steve Hannah Web Lite Solutions Corp. From paul_t100 at fastmail.fm Wed Jan 23 00:50:17 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 23 Jan 2013 08:50:17 +0000 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> Message-ID: <50FFA449.8040300@fastmail.fm> On 22/01/2013 21:41, Steve Hannah wrote: > I just wanted to post my experiences with this bug. I was having > trouble on OS X in both 1.7.0u11 and 1.7.0u12 with Japanese file names > (File.exists() erroneously returning false). > > Scott's fix for LC_CTYPE was the only thing that worked for me. > (tried file.encoding=UTF8, and sun.jnu.encoding=UTF8 to no avail). > > As I am deploying to the Mac App store I needed to set this > environment variable using the Info.plist file, and the current > appbundler ant task didn't have an option to set arbitrary keys/values > in the Info.plist, so I modified the appbundler source (I was actually > working off of the infinitekind fork of appbundler at > https://bitbucket.org/infinitekind/appbundler) to automatically set > the LSEnvironment key. > > The diff for this change is: > > diff -r 563fcd766efe appbundler/src/com/oracle/appbundler/AppBundlerTask.java > --- a/appbundler/src/com/oracle/appbundler/AppBundlerTask.java Wed Sep > 19 17:54:08 2012 +0100 > +++ b/appbundler/src/com/oracle/appbundler/AppBundlerTask.java Tue Jan > 22 13:31:11 2013 -0800 > @@ -577,7 +577,16 @@ > > xout.writeEndElement(); > xout.writeCharacters("\n"); > - > + > + // Write Environment > + writeKey(xout, "LSEnvironment"); > + xout.writeStartElement(DICT_TAG); > + xout.writeCharacters("\n"); > + writeKey(xout, "LC_CTYPE"); > + writeString(xout, "UTF-8"); > + xout.writeEndElement(); > + xout.writeCharacters("\n"); > + > // Write options > writeKey(xout, "JVMOptions"); > > > I'm not working off the trunk, so I don't know if this problem has > actually been resolved... but this workaround works for me. > > Just thought I'd share in case it helps someone else along the line. > > -Steve > Thanks all the fixes in that fork are great, but cant we get these incorporated into trunk - I know its been asked before but nothing seems to have been added to appbundler for some time Paul From Alan.Bateman at oracle.com Wed Jan 23 01:05:22 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2013 09:05:22 +0000 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> Message-ID: <50FFA7D2.7070002@oracle.com> On 22/01/2013 21:41, Steve Hannah wrote: > I just wanted to post my experiences with this bug. I was having > trouble on OS X in both 1.7.0u11 and 1.7.0u12 with Japanese file names > (File.exists() erroneously returning false). > Can you try jdk8-b73 in your environment without the app bundle change and see if you still have an issue? Brent pushed a change to b73 that defaults the value of sun.jnu.encoding to UTF-8 on Mac and we think this should the issues that several folks on this list have reported. There are several other changes in this general area so rnning with the latest jdk8 build means a build with all the changes. I know Brent is planning on getting wider feedback from folks that are willing to try out jdk8 builds. We need this before backports to jdk7u can be considered. -Alan From alexandr.scherbatiy at oracle.com Wed Jan 23 05:56:44 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 23 Jan 2013 17:56:44 +0400 Subject: [8] Request for review: 8003173 [macosx] Fullscreen on Mac leaves an empty rectangle In-Reply-To: <50FAA088.5010804@oracle.com> References: <50ED7187.3010207@oracle.com> <50ED8170.5050601@oracle.com> <50ED935D.6050104@oracle.com> <50F58827.9000506@oracle.com> <50FAA088.5010804@oracle.com> Message-ID: <50FFEC1C.9070805@oracle.com> The api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode TCK test shows the following warning after the fix: 2013-01-23 17:54:27.027 java[4695:707] Cocoa AWT: Running on AppKit thread 0 when not expected. ( 0 libawt_lwawt.dylib 0x000000011e662263 Java_sun_lwawt_macosx_CPlatformWindow_nativeGetNSWindowInsets + 72 1 ??? 0x0000000110df9ce9 0x0 + 4578057449 ) 2013-01-23 17:54:27.053 java[4695:707] Please file a bug report at http://java.net/jira/browse/MACOSX_PORT with this message and a reproducible test case. Thanks, Alexandr. On 1/19/2013 5:32 PM, Sergey Bylokhov wrote: > Hi, Anthony. > Please review the new version of the fix: > http://cr.openjdk.java.net/~serb/8003173/webrev.01 > Now only CPWindow is responsible for all move/resize/newinsets > notification, all related code was removed from CPView. > isFullScreenAnimationOn was added to make fullscreen animation smooth. > See inline comments. > > 15.01.2013 20:47, Anthony Petrov wrote: >> On 1/9/2013 19:57, Sergey Bylokhov wrote: >>> 09.01.2013 18:40, Anthony Petrov wrote: >>>> src/macosx/classes/sun/lwawt/LWWindowPeer.java: >>>> Note that theoretically the insets can be changed w/o changing the >>>> content size. For example, if a user switches to a theme with >>>> enlarged window decorations. Not sure if this applies to Mac >>>> presently, but in theory this is possible. Will sending the >>>> COMPONENT_RESIZE event be equivalent to calling the >>>> replaceSurfaceData() in this case? Also, since the event is only >>>> posted but not processed yet, what is the point to call >>>> repaintPeer() before the surface data is replaced? >>> In general surfaceData should include top level size of the >>> window(including insets) So it's not necessary to replace surface >>> here. Because there is no api for target notification about new >>> insets I use COMPONENT_RESIZE event. >> >> Thanks for clarifying that. >> >>>> src/macosx/classes/sun/lwawt/macosx/CPlatformView.java: >>>> The actual fix seems to reside in this file. Why doesn't >>>> peer.getInsets() return zeros in the full screen mode? If it does >>>> actually, why do we need this change then? A generic, >>>> insets-accounting size calculation seems to be preferable in case >>>> we need a non-zero insets for some specific use-cases in the future. >>> When we set NSView to full screen the native insets(as we calculate >>> it) does not change. Because of that we use synthetic resize >>> notifications in enterFullScreenMode() we just should not include >>> insets in this case. >> >> At line 98 of CPlatformView.java in "peer.getInsets()", the peer is >> an LWWindowPeer instance associated with the view. In >> CPlatformWindow.enterFullScreenMode() you already call >> "peer.updateInsets(new Insets(0, 0, 0, 0))" which should zero out the >> insets stored in the same peer. So the peer.getInsets() call in >> CPlatformView will return these zeros, and hence they shouldn't >> affect the calculations you perform at lines 111-115 in CPlatformView. > But why we need this calculation there? I guess CPlatformWindow is a > better place for insets calculation, otherwise in the > CPlatformView.exitFullScreenMode() I'll get something like: > peer.updateInsets(peer.getPlatformWindow().getInsets()); > Which looks strange. > In the new version of the fix LWWindowPeer fetch this information when > necessary, and getPlatformWindow().getInsets() return correct value. >> >> So I repeat my question, why do we need to change anything in >> CPlatformView then? Can we just revert the changes? > Better to have related stuff in one class. >> >> >>>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java: >>>>> 876 peer.updateInsets(getInsets()); >>>> >>>> This will call a native method upon sending every move/resize >>>> event. Why do we actually have to do this? I assume the peer >>>> already calls the PlatformWindow.getInsets() whenever needed. >>> No. It does not call, that's the problem. >>>> Also, AFAIK, insets rarely change on Mac, and you already handle >>>> their manual changes when entering/exiting the full screen mode. >>>> Can we just remove this line? >>> No. There are two different fullscreens. >>> 1 The full screen based on Nsview, which is used via Graphics >>> device. For this we emulate insets and events. >>> 2 The full screen in lion style. We can handle it in >>> windowWillEnterFullScreen/windowDidEnterFullScreen. In the >>> WillEnterXX window have old insets and in the DidEnterXX window have >>> new insets. DidEnterXX comes after Resize events, which will repaint >>> the window ==> we get content's jumping. >> >> So, why not simply call "peer.updateInsets(new Insets(0, 0, 0, 0))" >> from windowWillEnter... then? > It is not necessary to make them empty, because native system changes > decoration and insets for us. But this happens after willEnter and > before didEnter. >> Otherwise this looks inconsistent because in the case of the >> GraphicsDevice-based full screen mode you zero out the insets >> manually, but they remain being non-zero in the native full screen mode. > In both cases insets will be empty, but in GraphicsDevice-based full > screen mode we emulate insets/notification manually. >> >> -- >> best regards, >> Anthony >> >>>> src/macosx/native/sun/awt/AWTWindow.m >>>>> 821 [ThreadUtilities performOnMainThreadWaiting:YES block:^(){ >>>>> 822 AWT_ASSERT_APPKIT_THREAD; >>>> >>>> This ASSERT statement may safely be removed since the >>>> ThreadUtilities already guarantee us that we're running on the main >>>> thread. >>> I just use standard template from AWTWindow.m, so it will be simple >>> to change this template at once. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 1/9/2013 17:32, Sergey Bylokhov wrote: >>>>> Hello, >>>>> Please review the fix. >>>>> The reason why we have an empty space in the full screen mode is >>>>> that we did not update our insets. >>>>> - I update insets in the deliverMoveResizeEvent not in the >>>>> windowDidEnterFullScreen, in this case animation became more >>>>> smooth(since we update insets just before paint action). So all >>>>> old fullscreen handle methods in CPlatformWindow were removed. >>>>> - LWWindowPeer.updateInsets will post ComponentEvent if insets >>>>> were changed. >>>>> - CGraphicsDevice.setDisplayMode now stores/restores full screen >>>>> window, because otherwise NSView looks shifted on screen. >>>>> - CPlatformView.enterFullScreenMode(): code related to insets was >>>>> removed, since NSVIew uses the whole screen unlike jdk 6.(see >>>>> related changes in CPlatformWindow.enter/exitFullScreenMode) >>>>> >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003173 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/8003173/webrev.00 >>>>> >>> >>> > > From Sergey.Bylokhov at oracle.com Wed Jan 23 06:00:22 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 Jan 2013 18:00:22 +0400 Subject: [8] Request for review: 8003173 [macosx] Fullscreen on Mac leaves an empty rectangle In-Reply-To: <50FFEC1C.9070805@oracle.com> References: <50ED7187.3010207@oracle.com> <50ED8170.5050601@oracle.com> <50ED935D.6050104@oracle.com> <50F58827.9000506@oracle.com> <50FAA088.5010804@oracle.com> <50FFEC1C.9070805@oracle.com> Message-ID: <50FFECF6.1080700@oracle.com> Hi, Alexander. You workspace is not up to date. Pls update it. 23.01.2013 17:56, Alexander Scherbatiy wrote: > > The api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode TCK > test shows the following warning after the fix: > > 2013-01-23 17:54:27.027 java[4695:707] Cocoa AWT: Running on AppKit > thread 0 when not expected. ( > 0 libawt_lwawt.dylib 0x000000011e662263 > Java_sun_lwawt_macosx_CPlatformWindow_nativeGetNSWindowInsets + 72 > 1 ??? 0x0000000110df9ce9 0x0 > + 4578057449 > ) > 2013-01-23 17:54:27.053 java[4695:707] Please file a bug report at > http://java.net/jira/browse/MACOSX_PORT with this message and a > reproducible test case. > > Thanks, > Alexandr. > > On 1/19/2013 5:32 PM, Sergey Bylokhov wrote: >> Hi, Anthony. >> Please review the new version of the fix: >> http://cr.openjdk.java.net/~serb/8003173/webrev.01 >> Now only CPWindow is responsible for all move/resize/newinsets >> notification, all related code was removed from CPView. >> isFullScreenAnimationOn was added to make fullscreen animation smooth. >> See inline comments. >> >> 15.01.2013 20:47, Anthony Petrov wrote: >>> On 1/9/2013 19:57, Sergey Bylokhov wrote: >>>> 09.01.2013 18:40, Anthony Petrov wrote: >>>>> src/macosx/classes/sun/lwawt/LWWindowPeer.java: >>>>> Note that theoretically the insets can be changed w/o changing the >>>>> content size. For example, if a user switches to a theme with >>>>> enlarged window decorations. Not sure if this applies to Mac >>>>> presently, but in theory this is possible. Will sending the >>>>> COMPONENT_RESIZE event be equivalent to calling the >>>>> replaceSurfaceData() in this case? Also, since the event is only >>>>> posted but not processed yet, what is the point to call >>>>> repaintPeer() before the surface data is replaced? >>>> In general surfaceData should include top level size of the >>>> window(including insets) So it's not necessary to replace surface >>>> here. Because there is no api for target notification about new >>>> insets I use COMPONENT_RESIZE event. >>> >>> Thanks for clarifying that. >>> >>>>> src/macosx/classes/sun/lwawt/macosx/CPlatformView.java: >>>>> The actual fix seems to reside in this file. Why doesn't >>>>> peer.getInsets() return zeros in the full screen mode? If it does >>>>> actually, why do we need this change then? A generic, >>>>> insets-accounting size calculation seems to be preferable in case >>>>> we need a non-zero insets for some specific use-cases in the future. >>>> When we set NSView to full screen the native insets(as we calculate >>>> it) does not change. Because of that we use synthetic resize >>>> notifications in enterFullScreenMode() we just should not include >>>> insets in this case. >>> >>> At line 98 of CPlatformView.java in "peer.getInsets()", the peer is >>> an LWWindowPeer instance associated with the view. In >>> CPlatformWindow.enterFullScreenMode() you already call >>> "peer.updateInsets(new Insets(0, 0, 0, 0))" which should zero out >>> the insets stored in the same peer. So the peer.getInsets() call in >>> CPlatformView will return these zeros, and hence they shouldn't >>> affect the calculations you perform at lines 111-115 in CPlatformView. >> But why we need this calculation there? I guess CPlatformWindow is a >> better place for insets calculation, otherwise in the >> CPlatformView.exitFullScreenMode() I'll get something like: >> peer.updateInsets(peer.getPlatformWindow().getInsets()); >> Which looks strange. >> In the new version of the fix LWWindowPeer fetch this information >> when necessary, and getPlatformWindow().getInsets() return correct >> value. >>> >>> So I repeat my question, why do we need to change anything in >>> CPlatformView then? Can we just revert the changes? >> Better to have related stuff in one class. >>> >>> >>>>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java: >>>>>> 876 peer.updateInsets(getInsets()); >>>>> >>>>> This will call a native method upon sending every move/resize >>>>> event. Why do we actually have to do this? I assume the peer >>>>> already calls the PlatformWindow.getInsets() whenever needed. >>>> No. It does not call, that's the problem. >>>>> Also, AFAIK, insets rarely change on Mac, and you already handle >>>>> their manual changes when entering/exiting the full screen mode. >>>>> Can we just remove this line? >>>> No. There are two different fullscreens. >>>> 1 The full screen based on Nsview, which is used via Graphics >>>> device. For this we emulate insets and events. >>>> 2 The full screen in lion style. We can handle it in >>>> windowWillEnterFullScreen/windowDidEnterFullScreen. In the >>>> WillEnterXX window have old insets and in the DidEnterXX window >>>> have new insets. DidEnterXX comes after Resize events, which will >>>> repaint the window ==> we get content's jumping. >>> >>> So, why not simply call "peer.updateInsets(new Insets(0, 0, 0, 0))" >>> from windowWillEnter... then? >> It is not necessary to make them empty, because native system changes >> decoration and insets for us. But this happens after willEnter and >> before didEnter. >>> Otherwise this looks inconsistent because in the case of the >>> GraphicsDevice-based full screen mode you zero out the insets >>> manually, but they remain being non-zero in the native full screen >>> mode. >> In both cases insets will be empty, but in GraphicsDevice-based full >> screen mode we emulate insets/notification manually. >>> >>> -- >>> best regards, >>> Anthony >>> >>>>> src/macosx/native/sun/awt/AWTWindow.m >>>>>> 821 [ThreadUtilities performOnMainThreadWaiting:YES block:^(){ >>>>>> 822 AWT_ASSERT_APPKIT_THREAD; >>>>> >>>>> This ASSERT statement may safely be removed since the >>>>> ThreadUtilities already guarantee us that we're running on the >>>>> main thread. >>>> I just use standard template from AWTWindow.m, so it will be simple >>>> to change this template at once. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 1/9/2013 17:32, Sergey Bylokhov wrote: >>>>>> Hello, >>>>>> Please review the fix. >>>>>> The reason why we have an empty space in the full screen mode is >>>>>> that we did not update our insets. >>>>>> - I update insets in the deliverMoveResizeEvent not in the >>>>>> windowDidEnterFullScreen, in this case animation became more >>>>>> smooth(since we update insets just before paint action). So all >>>>>> old fullscreen handle methods in CPlatformWindow were removed. >>>>>> - LWWindowPeer.updateInsets will post ComponentEvent if insets >>>>>> were changed. >>>>>> - CGraphicsDevice.setDisplayMode now stores/restores full screen >>>>>> window, because otherwise NSView looks shifted on screen. >>>>>> - CPlatformView.enterFullScreenMode(): code related to insets >>>>>> was removed, since NSVIew uses the whole screen unlike jdk 6.(see >>>>>> related changes in CPlatformWindow.enter/exitFullScreenMode) >>>>>> >>>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003173 >>>>>> Webrev can be found at: >>>>>> http://cr.openjdk.java.net/~serb/8003173/webrev.00 >>>>>> >>>> >>>> >> >> > -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Jan 23 06:15:51 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 23 Jan 2013 18:15:51 +0400 Subject: [8] Request for review: 8003173 [macosx] Fullscreen on Mac leaves an empty rectangle In-Reply-To: <50FFEC1C.9070805@oracle.com> References: <50ED7187.3010207@oracle.com> <50ED8170.5050601@oracle.com> <50ED935D.6050104@oracle.com> <50F58827.9000506@oracle.com> <50FAA088.5010804@oracle.com> <50FFEC1C.9070805@oracle.com> Message-ID: <50FFF097.6070607@oracle.com> BTW, should we change the URL at which a user should file a bug? -- best regards, Anthony On 1/23/2013 17:56, Alexander Scherbatiy wrote: > > The api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode TCK test > shows the following warning after the fix: > > 2013-01-23 17:54:27.027 java[4695:707] Cocoa AWT: Running on AppKit > thread 0 when not expected. ( > 0 libawt_lwawt.dylib 0x000000011e662263 > Java_sun_lwawt_macosx_CPlatformWindow_nativeGetNSWindowInsets + 72 > 1 ??? 0x0000000110df9ce9 0x0 + > 4578057449 > ) > 2013-01-23 17:54:27.053 java[4695:707] Please file a bug report at > http://java.net/jira/browse/MACOSX_PORT with this message and a > reproducible test case. > > Thanks, > Alexandr. > > On 1/19/2013 5:32 PM, Sergey Bylokhov wrote: >> Hi, Anthony. >> Please review the new version of the fix: >> http://cr.openjdk.java.net/~serb/8003173/webrev.01 >> Now only CPWindow is responsible for all move/resize/newinsets >> notification, all related code was removed from CPView. >> isFullScreenAnimationOn was added to make fullscreen animation smooth. >> See inline comments. >> >> 15.01.2013 20:47, Anthony Petrov wrote: >>> On 1/9/2013 19:57, Sergey Bylokhov wrote: >>>> 09.01.2013 18:40, Anthony Petrov wrote: >>>>> src/macosx/classes/sun/lwawt/LWWindowPeer.java: >>>>> Note that theoretically the insets can be changed w/o changing the >>>>> content size. For example, if a user switches to a theme with >>>>> enlarged window decorations. Not sure if this applies to Mac >>>>> presently, but in theory this is possible. Will sending the >>>>> COMPONENT_RESIZE event be equivalent to calling the >>>>> replaceSurfaceData() in this case? Also, since the event is only >>>>> posted but not processed yet, what is the point to call >>>>> repaintPeer() before the surface data is replaced? >>>> In general surfaceData should include top level size of the >>>> window(including insets) So it's not necessary to replace surface >>>> here. Because there is no api for target notification about new >>>> insets I use COMPONENT_RESIZE event. >>> >>> Thanks for clarifying that. >>> >>>>> src/macosx/classes/sun/lwawt/macosx/CPlatformView.java: >>>>> The actual fix seems to reside in this file. Why doesn't >>>>> peer.getInsets() return zeros in the full screen mode? If it does >>>>> actually, why do we need this change then? A generic, >>>>> insets-accounting size calculation seems to be preferable in case >>>>> we need a non-zero insets for some specific use-cases in the future. >>>> When we set NSView to full screen the native insets(as we calculate >>>> it) does not change. Because of that we use synthetic resize >>>> notifications in enterFullScreenMode() we just should not include >>>> insets in this case. >>> >>> At line 98 of CPlatformView.java in "peer.getInsets()", the peer is >>> an LWWindowPeer instance associated with the view. In >>> CPlatformWindow.enterFullScreenMode() you already call >>> "peer.updateInsets(new Insets(0, 0, 0, 0))" which should zero out the >>> insets stored in the same peer. So the peer.getInsets() call in >>> CPlatformView will return these zeros, and hence they shouldn't >>> affect the calculations you perform at lines 111-115 in CPlatformView. >> But why we need this calculation there? I guess CPlatformWindow is a >> better place for insets calculation, otherwise in the >> CPlatformView.exitFullScreenMode() I'll get something like: >> peer.updateInsets(peer.getPlatformWindow().getInsets()); >> Which looks strange. >> In the new version of the fix LWWindowPeer fetch this information when >> necessary, and getPlatformWindow().getInsets() return correct value. >>> >>> So I repeat my question, why do we need to change anything in >>> CPlatformView then? Can we just revert the changes? >> Better to have related stuff in one class. >>> >>> >>>>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java: >>>>>> 876 peer.updateInsets(getInsets()); >>>>> >>>>> This will call a native method upon sending every move/resize >>>>> event. Why do we actually have to do this? I assume the peer >>>>> already calls the PlatformWindow.getInsets() whenever needed. >>>> No. It does not call, that's the problem. >>>>> Also, AFAIK, insets rarely change on Mac, and you already handle >>>>> their manual changes when entering/exiting the full screen mode. >>>>> Can we just remove this line? >>>> No. There are two different fullscreens. >>>> 1 The full screen based on Nsview, which is used via Graphics >>>> device. For this we emulate insets and events. >>>> 2 The full screen in lion style. We can handle it in >>>> windowWillEnterFullScreen/windowDidEnterFullScreen. In the >>>> WillEnterXX window have old insets and in the DidEnterXX window have >>>> new insets. DidEnterXX comes after Resize events, which will repaint >>>> the window ==> we get content's jumping. >>> >>> So, why not simply call "peer.updateInsets(new Insets(0, 0, 0, 0))" >>> from windowWillEnter... then? >> It is not necessary to make them empty, because native system changes >> decoration and insets for us. But this happens after willEnter and >> before didEnter. >>> Otherwise this looks inconsistent because in the case of the >>> GraphicsDevice-based full screen mode you zero out the insets >>> manually, but they remain being non-zero in the native full screen mode. >> In both cases insets will be empty, but in GraphicsDevice-based full >> screen mode we emulate insets/notification manually. >>> >>> -- >>> best regards, >>> Anthony >>> >>>>> src/macosx/native/sun/awt/AWTWindow.m >>>>>> 821 [ThreadUtilities performOnMainThreadWaiting:YES block:^(){ >>>>>> 822 AWT_ASSERT_APPKIT_THREAD; >>>>> >>>>> This ASSERT statement may safely be removed since the >>>>> ThreadUtilities already guarantee us that we're running on the main >>>>> thread. >>>> I just use standard template from AWTWindow.m, so it will be simple >>>> to change this template at once. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 1/9/2013 17:32, Sergey Bylokhov wrote: >>>>>> Hello, >>>>>> Please review the fix. >>>>>> The reason why we have an empty space in the full screen mode is >>>>>> that we did not update our insets. >>>>>> - I update insets in the deliverMoveResizeEvent not in the >>>>>> windowDidEnterFullScreen, in this case animation became more >>>>>> smooth(since we update insets just before paint action). So all >>>>>> old fullscreen handle methods in CPlatformWindow were removed. >>>>>> - LWWindowPeer.updateInsets will post ComponentEvent if insets >>>>>> were changed. >>>>>> - CGraphicsDevice.setDisplayMode now stores/restores full screen >>>>>> window, because otherwise NSView looks shifted on screen. >>>>>> - CPlatformView.enterFullScreenMode(): code related to insets was >>>>>> removed, since NSVIew uses the whole screen unlike jdk 6.(see >>>>>> related changes in CPlatformWindow.enter/exitFullScreenMode) >>>>>> >>>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003173 >>>>>> Webrev can be found at: >>>>>> http://cr.openjdk.java.net/~serb/8003173/webrev.00 >>>>>> >>>> >>>> >> >> > From steve at weblite.ca Wed Jan 23 09:34:42 2013 From: steve at weblite.ca (Steve Hannah) Date: Wed, 23 Jan 2013 09:34:42 -0800 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: <50FFA7D2.7070002@oracle.com> References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> <50FFA7D2.7070002@oracle.com> Message-ID: I tried with jdk8-b73 and it appears to work properly without the LC_CTYPE workaround. On a side note, I sent the Appbundler LC_CTYPE patch to Marco and he has applied it to his Appbundler fork already. Best regards Steve On Wed, Jan 23, 2013 at 1:05 AM, Alan Bateman wrote: > On 22/01/2013 21:41, Steve Hannah wrote: >> >> I just wanted to post my experiences with this bug. I was having >> trouble on OS X in both 1.7.0u11 and 1.7.0u12 with Japanese file names >> (File.exists() erroneously returning false). >> > Can you try jdk8-b73 in your environment without the app bundle change and > see if you still have an issue? Brent pushed a change to b73 that defaults > the value of sun.jnu.encoding to UTF-8 on Mac and we think this should the > issues that several folks on this list have reported. There are several > other changes in this general area so rnning with the latest jdk8 build > means a build with all the changes. I know Brent is planning on getting > wider feedback from folks that are willing to try out jdk8 builds. We need > this before backports to jdk7u can be considered. > > -Alan -- Steve Hannah Web Lite Solutions Corp. From brent.christian at oracle.com Wed Jan 23 10:27:52 2013 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 23 Jan 2013 10:27:52 -0800 Subject: UTF-8 filename fix in jdk8 b73 - sun.jnu.encoding set to UTF-8 on Mac by 8003228 (was Re: File.exists() does not work on mac for non-English characters on Java 7 on Mac) In-Reply-To: <50FFA7D2.7070002@oracle.com> References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> <50FFA7D2.7070002@oracle.com> Message-ID: <51002BA8.2080502@oracle.com> Alan pretty much said it. We have a fix in b73 of jdk8 that we're hoping will solve a lot of the remaining problems that people have seen in this area. If we hear that people are having success with b73, that will make a strong case for backporting this fix into a jdk7 update. So if you're in a position to give b73 a try, that would be a big help. Thanks, -Brent On 1/23/13 1:05 AM, Alan Bateman wrote: > On 22/01/2013 21:41, Steve Hannah wrote: >> I just wanted to post my experiences with this bug. I was having >> trouble on OS X in both 1.7.0u11 and 1.7.0u12 with Japanese file names >> (File.exists() erroneously returning false). >> > Can you try jdk8-b73 in your environment without the app bundle change > and see if you still have an issue? Brent pushed a change to b73 that > defaults the value of sun.jnu.encoding to UTF-8 on Mac and we think this > should the issues that several folks on this list have reported. There > are several other changes in this general area so rnning with the latest > jdk8 build means a build with all the changes. I know Brent is planning > on getting wider feedback from folks that are willing to try out jdk8 > builds. We need this before backports to jdk7u can be considered. From brent.christian at oracle.com Wed Jan 23 10:28:50 2013 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 23 Jan 2013 10:28:50 -0800 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> <50FFA7D2.7070002@oracle.com> Message-ID: <51002BE2.7000903@oracle.com> Thanks, Steve. That's good feedback - thanks for giving it a try. -Brent On 1/23/13 9:34 AM, Steve Hannah wrote: > I tried with jdk8-b73 and it appears to work properly without the > LC_CTYPE workaround. > > On a side note, I sent the Appbundler LC_CTYPE patch to Marco and he > has applied it to his Appbundler fork already. > > Best regards > > Steve > > On Wed, Jan 23, 2013 at 1:05 AM, Alan Bateman wrote: >> On 22/01/2013 21:41, Steve Hannah wrote: >>> >>> I just wanted to post my experiences with this bug. I was having >>> trouble on OS X in both 1.7.0u11 and 1.7.0u12 with Japanese file names >>> (File.exists() erroneously returning false). >>> >> Can you try jdk8-b73 in your environment without the app bundle change and >> see if you still have an issue? Brent pushed a change to b73 that defaults >> the value of sun.jnu.encoding to UTF-8 on Mac and we think this should the >> issues that several folks on this list have reported. There are several >> other changes in this general area so rnning with the latest jdk8 build >> means a build with all the changes. I know Brent is planning on getting >> wider feedback from folks that are willing to try out jdk8 builds. We need >> this before backports to jdk7u can be considered. >> >> -Alan > > > From steve at weblite.ca Wed Jan 23 10:53:14 2013 From: steve at weblite.ca (Steve Hannah) Date: Wed, 23 Jan 2013 10:53:14 -0800 Subject: UTF-8 filename fix in jdk8 b73 - sun.jnu.encoding set to UTF-8 on Mac by 8003228 (was Re: File.exists() does not work on mac for non-English characters on Java 7 on Mac) In-Reply-To: <51002BA8.2080502@oracle.com> References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> <50FFA7D2.7070002@oracle.com> <51002BA8.2080502@oracle.com> Message-ID: I replied to the original thread, but I'll mention it here too. I tried b73 and it seems to handle unicode characters in file names correctly now, without requiring any workarounds. -Steve On Wed, Jan 23, 2013 at 10:27 AM, Brent Christian wrote: > Alan pretty much said it. > > We have a fix in b73 of jdk8 that we're hoping will solve a lot of the > remaining problems that people have seen in this area. > > If we hear that people are having success with b73, that will make a strong > case for backporting this fix into a jdk7 update. > > So if you're in a position to give b73 a try, that would be a big help. > > Thanks, > -Brent > > On 1/23/13 1:05 AM, Alan Bateman wrote: >> >> On 22/01/2013 21:41, Steve Hannah wrote: >>> >>> I just wanted to post my experiences with this bug. I was having >>> trouble on OS X in both 1.7.0u11 and 1.7.0u12 with Japanese file names >>> (File.exists() erroneously returning false). >>> >> Can you try jdk8-b73 in your environment without the app bundle change >> and see if you still have an issue? Brent pushed a change to b73 that >> defaults the value of sun.jnu.encoding to UTF-8 on Mac and we think this >> should the issues that several folks on this list have reported. There >> are several other changes in this general area so rnning with the latest >> jdk8 build means a build with all the changes. I know Brent is planning >> on getting wider feedback from folks that are willing to try out jdk8 >> builds. We need this before backports to jdk7u can be considered. -- Steve Hannah Web Lite Solutions Corp. From alexandr.scherbatiy at oracle.com Thu Jan 24 03:02:51 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 24 Jan 2013 15:02:51 +0400 Subject: [8] Request for review: 8003173 [macosx] Fullscreen on Mac leaves an empty rectangle In-Reply-To: <50FFECF6.1080700@oracle.com> References: <50ED7187.3010207@oracle.com> <50ED8170.5050601@oracle.com> <50ED935D.6050104@oracle.com> <50F58827.9000506@oracle.com> <50FAA088.5010804@oracle.com> <50FFEC1C.9070805@oracle.com> <50FFECF6.1080700@oracle.com> Message-ID: <510114DB.9010808@oracle.com> The fix looks good for me. On 1/23/2013 6:00 PM, Sergey Bylokhov wrote: > Hi, Alexander. > You workspace is not up to date. Pls update it. Yes. After updating the TCK test does not show the warning. Thanks, Alexandr. > > > 23.01.2013 17:56, Alexander Scherbatiy wrote: >> >> The api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode TCK >> test shows the following warning after the fix: >> >> 2013-01-23 17:54:27.027 java[4695:707] Cocoa AWT: Running on AppKit >> thread 0 when not expected. ( >> 0 libawt_lwawt.dylib 0x000000011e662263 >> Java_sun_lwawt_macosx_CPlatformWindow_nativeGetNSWindowInsets + 72 >> 1 ??? 0x0000000110df9ce9 >> 0x0 + 4578057449 >> ) >> 2013-01-23 17:54:27.053 java[4695:707] Please file a bug report at >> http://java.net/jira/browse/MACOSX_PORT with this message and a >> reproducible test case. >> >> Thanks, >> Alexandr. >> >> On 1/19/2013 5:32 PM, Sergey Bylokhov wrote: >>> Hi, Anthony. >>> Please review the new version of the fix: >>> http://cr.openjdk.java.net/~serb/8003173/webrev.01 >>> Now only CPWindow is responsible for all move/resize/newinsets >>> notification, all related code was removed from CPView. >>> isFullScreenAnimationOn was added to make fullscreen animation smooth. >>> See inline comments. >>> >>> 15.01.2013 20:47, Anthony Petrov wrote: >>>> On 1/9/2013 19:57, Sergey Bylokhov wrote: >>>>> 09.01.2013 18:40, Anthony Petrov wrote: >>>>>> src/macosx/classes/sun/lwawt/LWWindowPeer.java: >>>>>> Note that theoretically the insets can be changed w/o changing >>>>>> the content size. For example, if a user switches to a theme with >>>>>> enlarged window decorations. Not sure if this applies to Mac >>>>>> presently, but in theory this is possible. Will sending the >>>>>> COMPONENT_RESIZE event be equivalent to calling the >>>>>> replaceSurfaceData() in this case? Also, since the event is only >>>>>> posted but not processed yet, what is the point to call >>>>>> repaintPeer() before the surface data is replaced? >>>>> In general surfaceData should include top level size of the >>>>> window(including insets) So it's not necessary to replace surface >>>>> here. Because there is no api for target notification about new >>>>> insets I use COMPONENT_RESIZE event. >>>> >>>> Thanks for clarifying that. >>>> >>>>>> src/macosx/classes/sun/lwawt/macosx/CPlatformView.java: >>>>>> The actual fix seems to reside in this file. Why doesn't >>>>>> peer.getInsets() return zeros in the full screen mode? If it does >>>>>> actually, why do we need this change then? A generic, >>>>>> insets-accounting size calculation seems to be preferable in case >>>>>> we need a non-zero insets for some specific use-cases in the future. >>>>> When we set NSView to full screen the native insets(as we >>>>> calculate it) does not change. Because of that we use synthetic >>>>> resize notifications in enterFullScreenMode() we just should not >>>>> include insets in this case. >>>> >>>> At line 98 of CPlatformView.java in "peer.getInsets()", the peer is >>>> an LWWindowPeer instance associated with the view. In >>>> CPlatformWindow.enterFullScreenMode() you already call >>>> "peer.updateInsets(new Insets(0, 0, 0, 0))" which should zero out >>>> the insets stored in the same peer. So the peer.getInsets() call in >>>> CPlatformView will return these zeros, and hence they shouldn't >>>> affect the calculations you perform at lines 111-115 in CPlatformView. >>> But why we need this calculation there? I guess CPlatformWindow is a >>> better place for insets calculation, otherwise in the >>> CPlatformView.exitFullScreenMode() I'll get something like: >>> peer.updateInsets(peer.getPlatformWindow().getInsets()); >>> Which looks strange. >>> In the new version of the fix LWWindowPeer fetch this information >>> when necessary, and getPlatformWindow().getInsets() return correct >>> value. >>>> >>>> So I repeat my question, why do we need to change anything in >>>> CPlatformView then? Can we just revert the changes? >>> Better to have related stuff in one class. >>>> >>>> >>>>>> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java: >>>>>>> 876 peer.updateInsets(getInsets()); >>>>>> >>>>>> This will call a native method upon sending every move/resize >>>>>> event. Why do we actually have to do this? I assume the peer >>>>>> already calls the PlatformWindow.getInsets() whenever needed. >>>>> No. It does not call, that's the problem. >>>>>> Also, AFAIK, insets rarely change on Mac, and you already handle >>>>>> their manual changes when entering/exiting the full screen mode. >>>>>> Can we just remove this line? >>>>> No. There are two different fullscreens. >>>>> 1 The full screen based on Nsview, which is used via Graphics >>>>> device. For this we emulate insets and events. >>>>> 2 The full screen in lion style. We can handle it in >>>>> windowWillEnterFullScreen/windowDidEnterFullScreen. In the >>>>> WillEnterXX window have old insets and in the DidEnterXX window >>>>> have new insets. DidEnterXX comes after Resize events, which will >>>>> repaint the window ==> we get content's jumping. >>>> >>>> So, why not simply call "peer.updateInsets(new Insets(0, 0, 0, 0))" >>>> from windowWillEnter... then? >>> It is not necessary to make them empty, because native system >>> changes decoration and insets for us. But this happens after >>> willEnter and before didEnter. >>>> Otherwise this looks inconsistent because in the case of the >>>> GraphicsDevice-based full screen mode you zero out the insets >>>> manually, but they remain being non-zero in the native full screen >>>> mode. >>> In both cases insets will be empty, but in GraphicsDevice-based full >>> screen mode we emulate insets/notification manually. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>>>> src/macosx/native/sun/awt/AWTWindow.m >>>>>>> 821 [ThreadUtilities performOnMainThreadWaiting:YES block:^(){ >>>>>>> 822 AWT_ASSERT_APPKIT_THREAD; >>>>>> >>>>>> This ASSERT statement may safely be removed since the >>>>>> ThreadUtilities already guarantee us that we're running on the >>>>>> main thread. >>>>> I just use standard template from AWTWindow.m, so it will be >>>>> simple to change this template at once. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 1/9/2013 17:32, Sergey Bylokhov wrote: >>>>>>> Hello, >>>>>>> Please review the fix. >>>>>>> The reason why we have an empty space in the full screen mode is >>>>>>> that we did not update our insets. >>>>>>> - I update insets in the deliverMoveResizeEvent not in the >>>>>>> windowDidEnterFullScreen, in this case animation became more >>>>>>> smooth(since we update insets just before paint action). So all >>>>>>> old fullscreen handle methods in CPlatformWindow were removed. >>>>>>> - LWWindowPeer.updateInsets will post ComponentEvent if insets >>>>>>> were changed. >>>>>>> - CGraphicsDevice.setDisplayMode now stores/restores full >>>>>>> screen window, because otherwise NSView looks shifted on screen. >>>>>>> - CPlatformView.enterFullScreenMode(): code related to insets >>>>>>> was removed, since NSVIew uses the whole screen unlike jdk >>>>>>> 6.(see related changes in CPlatformWindow.enter/exitFullScreenMode) >>>>>>> >>>>>>> >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003173 >>>>>>> Webrev can be found at: >>>>>>> http://cr.openjdk.java.net/~serb/8003173/webrev.00 >>>>>>> >>>>> >>>>> >>> >>> >> > > From nick at transparentech.com Thu Jan 24 05:05:09 2013 From: nick at transparentech.com (Nicholas Rahn) Date: Thu, 24 Jan 2013 14:05:09 +0100 Subject: SWT with Java 7 on Mac Message-ID: Hi. I've submitted a number of bugs relating to using SWT with Java7 on the Mac (see below) and am looking for advice on finding the right path to getting them fixed. The general problem, as I see it, is that it's not really clear if the issues are in SWT or in Java 7, and thus which development group to ask for advice on fixing them. None of the issues are present when using the Apple-provided Java6, so it seems possible that things need to be resolved in Java 7. On the other hand, because the issues arise when using SWT, perhaps the problems actually need to be addressed there, to compensate for changes in Java 7. Here's the list of bug. - Oracle Bug #2366830 (no link cause doesn't show up in bug database) SWT app using AWT does not receive Dock's Quit event - https://bugs.eclipse.org/bugs/show_bug.cgi?id=389486 App freeze when going fullscreen using Java 7 on Mac - https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886 Table/tree rubber banding does not work with Java 7 on Mac The first one (submitted to Oracle) is a show-stopper for bundling Java 7 with an app, imho. So my questions is, what's the best way to attack these bugs? From the SWT side or from the Java 7 side? Thanks for any help and advice. Nick From paul_t100 at fastmail.fm Thu Jan 24 07:17:58 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 24 Jan 2013 15:17:58 +0000 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> Message-ID: <510150A6.6040605@fastmail.fm> On 22/01/2013 21:41, Steve Hannah wrote: > I just wanted to post my experiences with this bug. I was having > trouble on OS X in both 1.7.0u11 and 1.7.0u12 with Japanese file names > (File.exists() erroneously returning false). > > Scott's fix for LC_CTYPE was the only thing that worked for me. > (tried file.encoding=UTF8, and sun.jnu.encoding=UTF8 to no avail). > > As I am deploying to the Mac App store I needed to set this > environment variable using the Info.plist file, and the current > appbundler ant task didn't have an option to set arbitrary keys/values > in the Info.plist, so I modified the appbundler source (I was actually > working off of the infinitekind fork of appbundler at > https://bitbucket.org/infinitekind/appbundler) to automatically set > the LSEnvironment key. In case it helps Steves fix works if you add the following to Info.plist once it has been created by AppBundler LSEnvironment LC_CTYPE UTF-8 BTW I tried using infinitekind fork, but there doesn't seem to be a prebuilt binary. I downloaded the source and ran ant but it complained unable to find gcc. Fixing this is probably obvious to a Mac developer but for a Java developer like myself whose main dev platform is windows and just knows the minimum about macs to get by its a headache. Paul From steve at weblite.ca Thu Jan 24 07:23:44 2013 From: steve at weblite.ca (Steve Hannah) Date: Thu, 24 Jan 2013 07:23:44 -0800 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: <510150A6.6040605@fastmail.fm> References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> <510150A6.6040605@fastmail.fm> Message-ID: You have to set JAVA_HOME before building . I ran into the same problem. Steve On Thursday, January 24, 2013, Paul Taylor wrote: > On 22/01/2013 21:41, Steve Hannah wrote: > >> I just wanted to post my experiences with this bug. I was having >> trouble on OS X in both 1.7.0u11 and 1.7.0u12 with Japanese file names >> (File.exists() erroneously returning false). >> >> Scott's fix for LC_CTYPE was the only thing that worked for me. >> (tried file.encoding=UTF8, and sun.jnu.encoding=UTF8 to no avail). >> >> As I am deploying to the Mac App store I needed to set this >> environment variable using the Info.plist file, and the current >> appbundler ant task didn't have an option to set arbitrary keys/values >> in the Info.plist, so I modified the appbundler source (I was actually >> working off of the infinitekind fork of appbundler at >> https://bitbucket.org/**infinitekind/appbundler) >> to automatically set >> the LSEnvironment key. >> > In case it helps Steves fix works if you add the following to Info.plist > once it has been created by AppBundler > > LSEnvironment > > LC_CTYPE > UTF-8 > > > BTW I tried using infinitekind fork, but there doesn't seem to be a > prebuilt binary. I downloaded the source and ran ant > but it complained unable to find gcc. Fixing this is probably obvious to a > Mac developer but for a Java developer like myself whose main dev platform > is windows and just knows the minimum about macs > to get by its a headache. > > Paul > > -- Steve Hannah Web Lite Solutions Corp. From paul_t100 at fastmail.fm Thu Jan 24 08:08:41 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 24 Jan 2013 16:08:41 +0000 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> <510150A6.6040605@fastmail.fm> Message-ID: <51015C89.8050209@fastmail.fm> On 24/01/2013 15:23, Steve Hannah wrote: > You have to set JAVA_HOME before building . I ran into the same problem. Hi Steve I have JAVA_HOME set, Im talking about building the appbundler itself not using it build my application because no jar is provided in the download. However I've found that the class files are actually provided so I modified the package task in the build.xml file so that it doesnt depend on the compiler, this built the jar succesfully. Then I could copy this into ants share folder and then I could use it to try and build my application However I found it doesn't like my existing build.xml complaining java.lang.NullPointerException at com.oracle.appbundler.AppBundlerTask.copy(AppBundlerTask.java:692) at com.oracle.appbundler.AppBundlerTask.execute(AppBundlerTask.java:323) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:392) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:180) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:82) at org.apache.tools.ant.Main.runBuild(Main.java:795) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) So it seems not compatible with the original appbundler, unless the problem is me running the package task without the compile task Paul > Steve > > On Thursday, January 24, 2013, Paul Taylor wrote: > >> On 22/01/2013 21:41, Steve Hannah wrote: >> >>> I just wanted to post my experiences with this bug. I was having >>> trouble on OS X in both 1.7.0u11 and 1.7.0u12 with Japanese file names >>> (File.exists() erroneously returning false). >>> >>> Scott's fix for LC_CTYPE was the only thing that worked for me. >>> (tried file.encoding=UTF8, and sun.jnu.encoding=UTF8 to no avail). >>> >>> As I am deploying to the Mac App store I needed to set this >>> environment variable using the Info.plist file, and the current >>> appbundler ant task didn't have an option to set arbitrary keys/values >>> in the Info.plist, so I modified the appbundler source (I was actually >>> working off of the infinitekind fork of appbundler at >>> https://bitbucket.org/**infinitekind/appbundler) >>> to automatically set >>> the LSEnvironment key. >>> >> In case it helps Steves fix works if you add the following to Info.plist >> once it has been created by AppBundler >> >> LSEnvironment >> >> LC_CTYPE >> UTF-8 >> >> >> BTW I tried using infinitekind fork, but there doesn't seem to be a >> prebuilt binary. I downloaded the source and ran ant >> but it complained unable to find gcc. Fixing this is probably obvious to a >> Mac developer but for a Java developer like myself whose main dev platform >> is windows and just knows the minimum about macs >> to get by its a headache. >> >> Paul >> >> From steve at weblite.ca Thu Jan 24 08:44:12 2013 From: steve at weblite.ca (Steve Hannah) Date: Thu, 24 Jan 2013 08:44:12 -0800 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: <51015C89.8050209@fastmail.fm> References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> <510150A6.6040605@fastmail.fm> <51015C89.8050209@fastmail.fm> Message-ID: It is possible that it isn't compatible, but I don't recall having to make any changes to my build.xml to go to the infinitkind appbundler. The other way around I did because the oracle one doesn't support as many tags. You might want to just check the appbundler jar file and make sure it includes the JavaAppLauncher file inside com/oracle/appbundler. If the compile step didn't work then this will be missing and the ant task won't work. My experience was that the first time I build the appbundler it didn't include the JavaAppLauncher because the compile step failed. But if I first set JAVA_HOME, e.g. export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0.jdk/Contents/Home Then the compile step worked properly, and everything thereafter worked smoothly as well. -Steve On Thu, Jan 24, 2013 at 8:08 AM, Paul Taylor wrote: > On 24/01/2013 15:23, Steve Hannah wrote: >> >> You have to set JAVA_HOME before building . I ran into the same problem. > > Hi Steve > > I have JAVA_HOME set, Im talking about building the appbundler itself not > using it build my application because no jar is provided in the download. > However I've found that the class files are actually provided so I modified > the package task in the build.xml file so that it doesnt depend on the > compiler, this built the jar succesfully. > Then I could copy this into ants share folder and then I could use it to try > and build my application > > However I found it doesn't like my existing build.xml complaining > > java.lang.NullPointerException > at com.oracle.appbundler.AppBundlerTask.copy(AppBundlerTask.java:692) > at com.oracle.appbundler.AppBundlerTask.execute(AppBundlerTask.java:323) > at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:392) > at > org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:180) > at > org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:82) > at org.apache.tools.ant.Main.runBuild(Main.java:795) > at org.apache.tools.ant.Main.startAnt(Main.java:217) > at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) > at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) > > So it seems not compatible with the original appbundler, unless the problem > is me running the package task without the compile task > > Paul >> >> Steve >> >> On Thursday, January 24, 2013, Paul Taylor wrote: >> >>> On 22/01/2013 21:41, Steve Hannah wrote: >>> >>>> I just wanted to post my experiences with this bug. I was having >>>> trouble on OS X in both 1.7.0u11 and 1.7.0u12 with Japanese file names >>>> (File.exists() erroneously returning false). >>>> >>>> Scott's fix for LC_CTYPE was the only thing that worked for me. >>>> (tried file.encoding=UTF8, and sun.jnu.encoding=UTF8 to no avail). >>>> >>>> As I am deploying to the Mac App store I needed to set this >>>> environment variable using the Info.plist file, and the current >>>> appbundler ant task didn't have an option to set arbitrary keys/values >>>> in the Info.plist, so I modified the appbundler source (I was actually >>>> working off of the infinitekind fork of appbundler at >>>> >>>> https://bitbucket.org/**infinitekind/appbundler) >>>> >>>> to automatically set >>>> the LSEnvironment key. >>>> >>> In case it helps Steves fix works if you add the following to Info.plist >>> once it has been created by AppBundler >>> >>> LSEnvironment >>> >>> LC_CTYPE >>> UTF-8 >>> >>> >>> BTW I tried using infinitekind fork, but there doesn't seem to be a >>> prebuilt binary. I downloaded the source and ran ant >>> but it complained unable to find gcc. Fixing this is probably obvious to >>> a >>> Mac developer but for a Java developer like myself whose main dev >>> platform >>> is windows and just knows the minimum about macs >>> to get by its a headache. >>> >>> Paul >>> >>> > -- Steve Hannah Web Lite Solutions Corp. From paul_t100 at fastmail.fm Thu Jan 24 09:01:39 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 24 Jan 2013 17:01:39 +0000 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> <510150A6.6040605@fastmail.fm> <51015C89.8050209@fastmail.fm> Message-ID: <510168F3.2050507@fastmail.fm> On 24/01/2013 16:44, Steve Hannah wrote: > It is possible that it isn't compatible, but I don't recall having to > make any changes to my build.xml to go to the infinitkind appbundler. > The other way around I did because the oracle one doesn't support as > many tags. > > You might want to just check the appbundler jar file and make sure it > includes the JavaAppLauncher file inside com/oracle/appbundler. If > the compile step didn't work then this will be missing and the ant > task won't work. > > My experience was that the first time I build the appbundler it didn't > include the JavaAppLauncher because the compile step failed. But if I > first set JAVA_HOME, e.g. > export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0.jdk/Contents/Home > > Then the compile step worked properly, and everything thereafter > worked smoothly as well. Ahh, your right JavaAppLauncher is missing , but JAVA_HOME is already set and still build not working for me unfortunately Paul From paul_t100 at fastmail.fm Thu Jan 24 09:52:00 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Thu, 24 Jan 2013 17:52:00 +0000 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: <510168F3.2050507@fastmail.fm> References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> <510150A6.6040605@fastmail.fm> <51015C89.8050209@fastmail.fm> <510168F3.2050507@fastmail.fm> Message-ID: <510174C0.9070103@fastmail.fm> On 24/01/2013 17:01, Paul Taylor wrote: > On 24/01/2013 16:44, Steve Hannah wrote: >> It is possible that it isn't compatible, but I don't recall having to >> make any changes to my build.xml to go to the infinitkind appbundler. >> The other way around I did because the oracle one doesn't support as >> many tags. >> >> You might want to just check the appbundler jar file and make sure it >> includes the JavaAppLauncher file inside com/oracle/appbundler. If >> the compile step didn't work then this will be missing and the ant >> task won't work. >> >> My experience was that the first time I build the appbundler it didn't >> include the JavaAppLauncher because the compile step failed. But if I >> first set JAVA_HOME, e.g. >> export >> JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0.jdk/Contents/Home >> >> Then the compile step worked properly, and everything thereafter >> worked smoothly as well. > Ahh, your right JavaAppLauncher is missing , but JAVA_HOME is already > set and still build not working for me unfortunately > > Paul > Found gcc Adding export PATH=$PATH:./Applications/Xcode.app/Contents/Developer/usr/bin/ now builds okay, and can confirm now builds my bundle okay including putting in the LC_TYpe fix Paul From anthony.petrov at oracle.com Fri Jan 25 03:25:01 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 Jan 2013 15:25:01 +0400 Subject: SWT with Java 7 on Mac In-Reply-To: References: Message-ID: <51026B8D.9020905@oracle.com> Hi Nicholas, Since the issues arise when using SWT, I suggest to start with filing a bug against SWT. If engineers working on the SWT issue diagnose the problem and conclude that this is a JDK bug, they will file a corresponding bug report against JDK then. -- best regards, Anthony On 1/24/2013 17:05, Nicholas Rahn wrote: > Hi. I've submitted a number of bugs relating to using SWT with Java7 on the > Mac (see below) and am looking for advice on finding the right path to > getting them fixed. > > The general problem, as I see it, is that it's not really clear if the > issues are in SWT or in Java 7, and thus which development group to ask for > advice on fixing them. None of the issues are present when using the > Apple-provided Java6, so it seems possible that things need to be resolved > in Java 7. On the other hand, because the issues arise when using SWT, > perhaps the problems actually need to be addressed there, to compensate for > changes in Java 7. > > Here's the list of bug. > > - Oracle Bug #2366830 (no link cause doesn't show up in bug database) SWT > app using AWT does not receive Dock's Quit event > > - https://bugs.eclipse.org/bugs/show_bug.cgi?id=389486 App freeze when > going fullscreen using Java 7 on Mac > > - https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886 Table/tree rubber > banding does not work with Java 7 on Mac > > > The first one (submitted to Oracle) is a show-stopper for bundling Java 7 > with an app, imho. > > So my questions is, what's the best way to attack these bugs? From the SWT > side or from the Java 7 side? > > Thanks for any help and advice. > Nick From leonid.romanov at oracle.com Tue Jan 29 07:57:01 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 29 Jan 2013 19:57:01 +0400 Subject: [8] Review request for 8007006 : [macosx] Closing subwindow loses main window menus Message-ID: <7394B852-F793-4CD0-907F-917CBFF5DE73@oracle.com> Hi, Please review a fix for 8007006 : [macosx] Closing subwindow loses main window menus. The problem manifests itself when the global menu bar is used and we change menu for an inactive window. In this case current global menu gets replaced by the menu we set for the inactive window (or disappear completely, if the inactive window menu was removed). webrev: http://cr.openjdk.java.net/~leonidr/8007006/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 Leonid. From Sergey.Bylokhov at oracle.com Tue Jan 29 08:04:03 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 29 Jan 2013 20:04:03 +0400 Subject: [8] Review request for 8007006 : [macosx] Closing subwindow loses main window menus In-Reply-To: <7394B852-F793-4CD0-907F-917CBFF5DE73@oracle.com> References: <7394B852-F793-4CD0-907F-917CBFF5DE73@oracle.com> Message-ID: <5107F2F3.5040406@oracle.com> Hi, Leonid. Why this code was commented? 29.01.2013 19:57, Leonid Romanov wrote: > Hi, > Please review a fix for 8007006 : [macosx] Closing subwindow loses > main window menus. The problem manifests itself when the global menu > bar is used and we change menu for an inactive window. In this case > current global menu gets replaced by the menu we set for the inactive > window (or disappear completely, if the inactive window menu was removed). > > webrev: http://cr.openjdk.java.net/~leonidr/8007006/webrev.00/ > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 > > Leonid. -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Jan 29 08:06:36 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 29 Jan 2013 20:06:36 +0400 Subject: [8] Review request for 8007006 : [macosx] Closing subwindow loses main window menus In-Reply-To: <7394B852-F793-4CD0-907F-917CBFF5DE73@oracle.com> References: <7394B852-F793-4CD0-907F-917CBFF5DE73@oracle.com> Message-ID: <5107F38C.2010203@oracle.com> Hi Leonid, I see that the lines were commented out since the initial push of the MacOSX port code to the JDK repository. Could you please clone the old workspace (when we worked in a separate set of repositories) and investigate why were the lines commented out in the first place? PS. The fix looks fine and correct. But I'd like to make sure we don't remove a workaround for some other problem with this fix. -- best regards, Anthony On 1/29/2013 19:57, Leonid Romanov wrote: > Hi, > Please review a fix for 8007006 : [macosx] Closing subwindow loses main > window menus. The problem manifests itself when the global menu bar is > used and we change menu for an inactive window. In this case current > global menu gets replaced by the menu we set for the inactive window (or > disappear completely, if the inactive window menu was removed). > > webrev: http://cr.openjdk.java.net/~leonidr/8007006/webrev.00/ > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 > > Leonid. > From leonid.romanov at oracle.com Tue Jan 29 09:05:31 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 29 Jan 2013 21:05:31 +0400 Subject: [8] Review request for 8007006 : [macosx] Closing subwindow loses main window menus In-Reply-To: <5107F2F3.5040406@oracle.com> References: <7394B852-F793-4CD0-907F-917CBFF5DE73@oracle.com> <5107F2F3.5040406@oracle.com> Message-ID: I've no idea: whoever did it, hasn't left any explanation. My hope is that he would read this thread. Meanwhile, I'll do what Anthony suggested. On Jan 29, 2013, at 8:04 PM, Sergey Bylokhov wrote: > Hi, Leonid. > Why this code was commented? > > 29.01.2013 19:57, Leonid Romanov wrote: >> Hi, >> Please review a fix for 8007006 : [macosx] Closing subwindow loses main window menus. The problem manifests itself when the global menu bar is used and we change menu for an inactive window. In this case current global menu gets replaced by the menu we set for the inactive window (or disappear completely, if the inactive window menu was removed). >> >> webrev: http://cr.openjdk.java.net/~leonidr/8007006/webrev.00/ >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 >> >> Leonid. >> > > > -- > Best regards, Sergey. From leonid.romanov at oracle.com Tue Jan 29 09:52:37 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 29 Jan 2013 21:52:37 +0400 Subject: [8] Review request for 8007006 : [macosx] Closing subwindow loses main window menus In-Reply-To: <5107F38C.2010203@oracle.com> References: <7394B852-F793-4CD0-907F-917CBFF5DE73@oracle.com> <5107F38C.2010203@oracle.com> Message-ID: Looks like it was Mike Swingler who committed this, already commented code, to the old repo. Adding him to CC. On Jan 29, 2013, at 8:06 PM, Anthony Petrov wrote: > Hi Leonid, > > I see that the lines were commented out since the initial push of the MacOSX port code to the JDK repository. Could you please clone the old workspace (when we worked in a separate set of repositories) and investigate why were the lines commented out in the first place? > > PS. The fix looks fine and correct. But I'd like to make sure we don't remove a workaround for some other problem with this fix. > > -- > best regards, > Anthony > > On 1/29/2013 19:57, Leonid Romanov wrote: >> Hi, >> Please review a fix for 8007006 : [macosx] Closing subwindow loses main window menus. The problem manifests itself when the global menu bar is used and we change menu for an inactive window. In this case current global menu gets replaced by the menu we set for the inactive window (or disappear completely, if the inactive window menu was removed). >> webrev: http://cr.openjdk.java.net/~leonidr/8007006/webrev.00/ >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 >> Leonid. >> From swingler at apple.com Tue Jan 29 10:15:17 2013 From: swingler at apple.com (Mike Swingler) Date: Tue, 29 Jan 2013 10:15:17 -0800 Subject: [8] Review request for 8007006 : [macosx] Closing subwindow loses main window menus In-Reply-To: References: <7394B852-F793-4CD0-907F-917CBFF5DE73@oracle.com> <5107F38C.2010203@oracle.com> Message-ID: Honestly, I have no idea why that was commented out. Perhaps we were debugging the support for the default menu stuff in com.apple.eawt.Application.setDefaultMenuBar(JMenuBar)? It was so long ago I honestly have no idea. Regards, Mike Swingler Apple Inc. On Jan 29, 2013, at 9:52 AM, Leonid Romanov wrote: > Looks like it was Mike Swingler who committed this, already commented code, to the old repo. Adding him to CC. > > On Jan 29, 2013, at 8:06 PM, Anthony Petrov wrote: > >> Hi Leonid, >> >> I see that the lines were commented out since the initial push of the MacOSX port code to the JDK repository. Could you please clone the old workspace (when we worked in a separate set of repositories) and investigate why were the lines commented out in the first place? >> >> PS. The fix looks fine and correct. But I'd like to make sure we don't remove a workaround for some other problem with this fix. >> >> -- >> best regards, >> Anthony >> >> On 1/29/2013 19:57, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 8007006 : [macosx] Closing subwindow loses main window menus. The problem manifests itself when the global menu bar is used and we change menu for an inactive window. In this case current global menu gets replaced by the menu we set for the inactive window (or disappear completely, if the inactive window menu was removed). >>> webrev: http://cr.openjdk.java.net/~leonidr/8007006/webrev.00/ >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 >>> Leonid. >>> > From mik3hall at gmail.com Tue Jan 29 16:59:09 2013 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 29 Jan 2013 18:59:09 -0600 Subject: JVM options Message-ID: <1DD6C0AC-0667-494A-96EB-03C3FDD3C6F0@gmail.com> I was interested in what JIT might be doing and remembered there were some launch switches for the HotSpot JVM that might show you some information. I found this http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html detailing some of those. I have been unable to get any of these switches to generate any output though so far in testing. Are the debug switches enabled in the distributed JRE's? Either shared or JDK? Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From nmrview at me.com Tue Jan 29 18:51:43 2013 From: nmrview at me.com (Bruce Johnson) Date: Tue, 29 Jan 2013 21:51:43 -0500 Subject: Status of Application.setDefaultMenuBar In-Reply-To: <8B6006C8-903A-4080-B6EC-6249C3F6B2F4@me.com> References: <522D32ED-0F0A-42CC-95FF-755972E9BF00@me.com> <50BF200C.3050204@oracle.com> <8B6006C8-903A-4080-B6EC-6249C3F6B2F4@me.com> Message-ID: Is there any news on this (that is, is anyone actually working on implementing the default menubar)? I never saw an actual bug generated for my report. Not having a default screen menubar is a real blocker for a decent Mac application. Bruce On Dec 5, 2012, at 1:16 PM, Bruce Johnson wrote: > I've filed a bug. The internal review code is: 2396618 > > cheers, > > Bruce > > On Dec 5, 2012, at 5:21 AM, Anthony Petrov wrote: > >> Hi Bruce, >> >> So, did you file a bug at bugs.sun.com about this issue yet? If not, you should do so. There's really nothing wrong with filing a bug even if it exists already - it will just be closed as a duplicate. >> >> A general rule: when in doubt - file a bug. >> >> PS. The JIRA instance you're referring to is no longer used to track JDK issues on the Mac. It might happen that the bug was filed after the migration had been completed, and thus it didn't make it to the real bug database. This is our fault that the JIRA project hasn't been made read-only after the migration. Sorry about that. >> >> -- >> best regards, >> Anthony >> >> On 12/4/2012 10:09 PM, Bruce Johnson wrote: >>> I can't readily release my application for Java 1.7 on the Mac without support for Application.setDefaultMenuBar. This seems pretty important for anyone that wants their application to look like a native Mac application and the lack of it is a big step backwards relative to Java 1.6. >>> Is there any hope that this will be supported in the "near future"? Or do we need to go back to the crazy old days of creating an identical, hidden, menubar for every window? >>> Also, does anyone know if there is an actual bug filed for the lack of setDefaultMenuBar. I can't find anything in bugs.sun.com, though there was an item in the old Jira system: http://java.net/jira/browse/MACOSX_PORT-775. I thought all those bugs had been migrated to bugs.sun.com. >>> Thanks for any info, >>> Bruce > From anthony.petrov at oracle.com Wed Jan 30 04:55:58 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 30 Jan 2013 16:55:58 +0400 Subject: [8] Review request for 8007006 : [macosx] Closing subwindow loses main window menus In-Reply-To: References: <7394B852-F793-4CD0-907F-917CBFF5DE73@oracle.com> <5107F38C.2010203@oracle.com> Message-ID: <5109185E.1000001@oracle.com> Thanks Mike. I'm fine with your fix, Leonid. -- best regards, Anthony On 1/29/2013 22:15, Mike Swingler wrote: > Honestly, I have no idea why that was commented out. Perhaps we were debugging the support for the default menu stuff in com.apple.eawt.Application.setDefaultMenuBar(JMenuBar)? It was so long ago I honestly have no idea. > > Regards, > Mike Swingler > Apple Inc. > > On Jan 29, 2013, at 9:52 AM, Leonid Romanov wrote: > >> Looks like it was Mike Swingler who committed this, already commented code, to the old repo. Adding him to CC. >> >> On Jan 29, 2013, at 8:06 PM, Anthony Petrov wrote: >> >>> Hi Leonid, >>> >>> I see that the lines were commented out since the initial push of the MacOSX port code to the JDK repository. Could you please clone the old workspace (when we worked in a separate set of repositories) and investigate why were the lines commented out in the first place? >>> >>> PS. The fix looks fine and correct. But I'd like to make sure we don't remove a workaround for some other problem with this fix. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/29/2013 19:57, Leonid Romanov wrote: >>>> Hi, >>>> Please review a fix for 8007006 : [macosx] Closing subwindow loses main window menus. The problem manifests itself when the global menu bar is used and we change menu for an inactive window. In this case current global menu gets replaced by the menu we set for the inactive window (or disappear completely, if the inactive window menu was removed). >>>> webrev: http://cr.openjdk.java.net/~leonidr/8007006/webrev.00/ >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 >>>> Leonid. >>>> > From private at claudio.ch Wed Jan 30 16:34:14 2013 From: private at claudio.ch (Claudio Nieder) Date: Thu, 31 Jan 2013 01:34:14 +0100 Subject: JVM options In-Reply-To: <1DD6C0AC-0667-494A-96EB-03C3FDD3C6F0@gmail.com> References: <1DD6C0AC-0667-494A-96EB-03C3FDD3C6F0@gmail.com> Message-ID: <4BAFBF11-4B4E-4C68-A50F-F7C4DB624075@claudio.ch> Hi, > http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html Those mentioned there should work in your standard JDK. Besides there are those which are accessible only once you specify -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions and finally there are some which are only available if you compile the JDK yourself and enable additional debugging support. As I have seen, you can look at http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/9b0ca45cd756/src/share/vm/runtime/globals.hpp to get a good overview of all the options hotspot knows about and the condition under which they can be used. E.g. product(bool, PrintGCApplicationConcurrentTime, false, \ "Print the time the application has been running") \ means you can use -XX:+PrintGCApplicationConcurrentTime in your regular JDK while develop(bool, PrintVMMessages, true, \ "Print vm messages on console") \ would require your special built JDK so you can use -XX:+PrintVMMessages. If a flag is unsupported, then java will exit with an error message right away, e.g. $ java -XX:+PrintVMMessage Unrecognized VM option 'PrintVMMessage' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Flags in diagnostic(...) or experimental(...) are only available if unlocked with one of the options I mentioned at the beginning of this mail. Lines 346 to 408 in the globals.hpp explain the different categories of flags. As you can see in lines 28 to 117 other files are included, which slightly modify the list of available flags or their default values depending on target architecture or OS. Finally let me add, that not all flags are found in globals.hpp, a few are handled in these files http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/9b0ca45cd756/src/share/vm/runtime/arguments.cpp http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/bfa88fb4cb01/src/share/tools/launcher/java.c claudio -- Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch From mik3hall at gmail.com Wed Jan 30 18:09:48 2013 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 30 Jan 2013 20:09:48 -0600 Subject: JVM options In-Reply-To: <4BAFBF11-4B4E-4C68-A50F-F7C4DB624075@claudio.ch> References: <1DD6C0AC-0667-494A-96EB-03C3FDD3C6F0@gmail.com> <4BAFBF11-4B4E-4C68-A50F-F7C4DB624075@claudio.ch> Message-ID: <4B573D63-5D33-42D3-A64E-BEB46EAB5FB8@gmail.com> On Jan 30, 2013, at 6:34 PM, Claudio Nieder wrote: > Hi, > >> http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html > > Those mentioned there should work in your standard JDK. I did think they used to work at Java 6 (Apple's jdk build) I thought I used to get some jit stats dumped at application shutdown, by including some option or other. That doesn't appear to be working with the openjdk 7 build. I tried various other options with command line launched code, including gc ones, and saw no output, I didn't see the invalid option error you indicated either. I have for now decided to cut over to using the jstat command runtime exec'ed for the JIT info. Actually, better suited to how I've been handling similar from my application anyhow. Some other time maybe I'll try to figure out why I am seeing nothing on the other HotSpot options. Thanks for the detailed response. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From alexandr.scherbatiy at oracle.com Thu Jan 31 05:46:02 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 31 Jan 2013 17:46:02 +0400 Subject: [8] Review request for 8007146 [macosx] Setting a display mode crashes JDK under VNC Message-ID: <510A759A.6020303@oracle.com> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007146 webrev: http://cr.openjdk.java.net/~alexsch/8007146/webrev.00 The issue is reproduced when a program is running under a VNC and all monitors are disconnected from the Mac OS X system. The CGDisplayCopyAllDisplayModes returns display modes with width and height equal to 1. CGCompleteDisplayConfiguration returns error when the invalid display mode is set and JDK crashes after releasing the display configuration. According to the CGCompleteDisplayConfiguration doc: "On return, this configuration is no longer valid." The fix filters the invalid display modes and does not release the display configuration. Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Thu Jan 31 05:56:21 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 31 Jan 2013 17:56:21 +0400 Subject: [8] Review request for 8007146 [macosx] Setting a display mode crashes JDK under VNC In-Reply-To: <510A759A.6020303@oracle.com> References: <510A759A.6020303@oracle.com> Message-ID: <510A7805.1090707@oracle.com> Hi, Alexander. Could we check DM in setDisplayMode() against modes from CGraphicsDevice.getDisplayModes() on java lvl? 31.01.2013 17:46, Alexander Scherbatiy wrote: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007146 > webrev: http://cr.openjdk.java.net/~alexsch/8007146/webrev.00 > > The issue is reproduced when a program is running under a VNC and all > monitors are disconnected from the Mac OS X system. > The CGDisplayCopyAllDisplayModes returns display modes with width and > height equal to 1. > CGCompleteDisplayConfiguration returns error when the invalid display > mode is set and JDK crashes after releasing the display configuration. > According to the CGCompleteDisplayConfiguration doc: "On return, this > configuration is no longer valid." > > The fix filters the invalid display modes and does not release the > display configuration. > > Thanks, > Alexandr. > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Jan 31 06:28:27 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 31 Jan 2013 18:28:27 +0400 Subject: [8] Review request for 8007146 [macosx] Setting a display mode crashes JDK under VNC In-Reply-To: <510A7805.1090707@oracle.com> References: <510A759A.6020303@oracle.com> <510A7805.1090707@oracle.com> Message-ID: <510A7F8B.50700@oracle.com> On 1/31/2013 5:56 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Could we check DM in setDisplayMode() against modes from > CGraphicsDevice.getDisplayModes() on java lvl? 1. We need to filter display modes which have width = 1 and height = 1 in the list returned by the CGDisplayCopyAllDisplayModes function. The code below reproduces the problem in pure Cocoa application: ------------------------------------------ - (void) test { int MAX_DISPLAYS = 100; CGDirectDisplayID displays[MAX_DISPLAYS]; uint32_t numDisplays; uint32_t i; CGGetActiveDisplayList(MAX_DISPLAYS, displays, &numDisplays); for(i=0; i > 31.01.2013 17:46, Alexander Scherbatiy wrote: >> >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007146 >> webrev: http://cr.openjdk.java.net/~alexsch/8007146/webrev.00 >> >> The issue is reproduced when a program is running under a VNC and all >> monitors are disconnected from the Mac OS X system. >> The CGDisplayCopyAllDisplayModes returns display modes with width and >> height equal to 1. >> CGCompleteDisplayConfiguration returns error when the invalid display >> mode is set and JDK crashes after releasing the display configuration. >> According to the CGCompleteDisplayConfiguration doc: "On return, this >> configuration is no longer valid." >> >> The fix filters the invalid display modes and does not release the >> display configuration. >> >> Thanks, >> Alexandr. >> > > From Sergey.Bylokhov at oracle.com Thu Jan 31 06:50:27 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 31 Jan 2013 18:50:27 +0400 Subject: [8] Review request for 8007146 [macosx] Setting a display mode crashes JDK under VNC In-Reply-To: <510A7F8B.50700@oracle.com> References: <510A759A.6020303@oracle.com> <510A7805.1090707@oracle.com> <510A7F8B.50700@oracle.com> Message-ID: <510A84B3.3080500@oracle.com> Hi, Alexander. Thanks for info. Fix looks good to me. But I am not sure about CFRelease removing, because "On return, this configuration is no longer valid." is not clear. 31.01.2013 18:28, Alexander Scherbatiy wrote: > On 1/31/2013 5:56 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Could we check DM in setDisplayMode() against modes from >> CGraphicsDevice.getDisplayModes() on java lvl? > 1. We need to filter display modes which have width = 1 and height > = 1 in the list returned by the CGDisplayCopyAllDisplayModes function. > The code below reproduces the problem in pure Cocoa application: > > ------------------------------------------ > - (void) test { > int MAX_DISPLAYS = 100; > CGDirectDisplayID displays[MAX_DISPLAYS]; > uint32_t numDisplays; > uint32_t i; > CGGetActiveDisplayList(MAX_DISPLAYS, displays, &numDisplays); > for(i=0; i { > CGDisplayModeRef mode; > CFIndex index, count; > CFArrayRef modeList; > modeList=CGDisplayCopyAllDisplayModes(displays[i], NULL); > count=CFArrayGetCount(modeList); > NSLog(@"\n\nmode --"); > for(index=0;index { > mode=(CGDisplayModeRef)CFArrayGetValueAtIndex(modeList, index); > long h=0, w=0; > h=CGDisplayModeGetHeight(mode); > w=CGDisplayModeGetWidth(mode); > uint32_t flags=CGDisplayModeGetIOFlags(mode); > NSLog(@"flags: %d", flags); > NSLog(@"w, h: %ld, %ld", w, h); > } > CFRelease(modeList); > } > > } > ------------------------------------------------ > mode -- > 2013-01-31 18:29:35.220 MyWindowTest[78789:707] flags: 7 > 2013-01-31 18:29:35.221 MyWindowTest[78789:707] w, h: 1, 1 > 2013-01-31 18:29:35.221 MyWindowTest[78789:707] flags: 7 > 2013-01-31 18:29:35.222 MyWindowTest[78789:707] w, h: 1, 1 > 2013-01-31 18:29:35.222 MyWindowTest[78789:707] flags: 7 > 2013-01-31 18:29:35.223 MyWindowTest[78789:707] w, h: 1, 1 > 2013-01-31 18:29:35.223 MyWindowTest[78789:707] flags: 7 > 2013-01-31 18:29:35.223 MyWindowTest[78789:707] w, h: 1, 1 > 2013-01-31 18:29:35.224 MyWindowTest[78789:707] flags: 7 > 2013-01-31 18:29:35.224 MyWindowTest[78789:707] w, h: 1, 1 > --------------------------------------------------------------------------- > > > > 2. The getBestModeForParameters method allows to set only those > display methods which have the same width, height, and bit depth with > the existed display modes. > It seems that there is no need to check the display modes one more > time on java level. > > Thanks, > Alexandr. > > > >> >> 31.01.2013 17:46, Alexander Scherbatiy wrote: >>> >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007146 >>> webrev: http://cr.openjdk.java.net/~alexsch/8007146/webrev.00 >>> >>> The issue is reproduced when a program is running under a VNC and >>> all monitors are disconnected from the Mac OS X system. >>> The CGDisplayCopyAllDisplayModes returns display modes with width >>> and height equal to 1. >>> CGCompleteDisplayConfiguration returns error when the invalid >>> display mode is set and JDK crashes after releasing the display >>> configuration. >>> According to the CGCompleteDisplayConfiguration doc: "On return, >>> this configuration is no longer valid." >>> >>> The fix filters the invalid display modes and does not release the >>> display configuration. >>> >>> Thanks, >>> Alexandr. >>> >> >> > -- Best regards, Sergey. From private at claudio.ch Thu Jan 31 13:43:55 2013 From: private at claudio.ch (Claudio Nieder) Date: Thu, 31 Jan 2013 22:43:55 +0100 Subject: JVM options In-Reply-To: <4B573D63-5D33-42D3-A64E-BEB46EAB5FB8@gmail.com> References: <1DD6C0AC-0667-494A-96EB-03C3FDD3C6F0@gmail.com> <4BAFBF11-4B4E-4C68-A50F-F7C4DB624075@claudio.ch> <4B573D63-5D33-42D3-A64E-BEB46EAB5FB8@gmail.com> Message-ID: <305FD3BC-5B57-4C67-BC1C-E73FC128051A@claudio.ch> Hi, > That doesn't appear to be working with the openjdk 7 build. $ java -showversion -XX:+PrintGC -XX:+PrintGCDetails C java version "1.7.0_11" Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode) [GC [PSYoungGen: 17600K->464K(20480K)] 17600K->464K(67200K), 0.0012910 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] ... [GC [PSYoungGen: 373469K->159K(373632K)] 373825K->516K(420352K), 0.0003640 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] Heap PSYoungGen total 373632K, used 14955K [0x0000000136be0000, 0x000000014d930000, 0x000000014d930000) eden space 373312K, 3% used [0x0000000136be0000,0x0000000137a52ec0,0x000000014d870000) from space 320K, 49% used [0x000000014d8c0000,0x000000014d8e7ff0,0x000000014d910000) to space 320K, 0% used [0x000000014d870000,0x000000014d870000,0x000000014d8c0000) ParOldGen total 46720K, used 356K [0x0000000109130000, 0x000000010bed0000, 0x0000000136be0000) object space 46720K, 0% used [0x0000000109130000,0x0000000109189060,0x000000010bed0000) PSPermGen total 21248K, used 2639K [0x0000000103f30000, 0x00000001053f0000, 0x0000000109130000) object space 21248K, 12% used [0x0000000103f30000,0x00000001041c3df0,0x00000001053f0000) Did you copy the options from that webpage verbatim? I notice, that it says there e.g. -XX:-PrintGCDetails Print more details at garbage collection. Now PrintGCDetails is a boolean flag, and the sign between -XX: and PrintGCDetails is +/- depending on whether you want to switch it on or off. It is unfortunate, that on that page the "-" is set. Maybe to indicate that by default this is switched off. When you use it you have to put a + in there as I did on my example. claudio -- Claudio Nieder, Talweg 6, CH-8610 Uster, Tel +4179 357 6743, www.claudio.ch From mik3hall at gmail.com Thu Jan 31 15:26:42 2013 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 31 Jan 2013 17:26:42 -0600 Subject: JVM options In-Reply-To: <305FD3BC-5B57-4C67-BC1C-E73FC128051A@claudio.ch> References: <1DD6C0AC-0667-494A-96EB-03C3FDD3C6F0@gmail.com> <4BAFBF11-4B4E-4C68-A50F-F7C4DB624075@claudio.ch> <4B573D63-5D33-42D3-A64E-BEB46EAB5FB8@gmail.com> <305FD3BC-5B57-4C67-BC1C-E73FC128051A@claudio.ch> Message-ID: <2C6BD7B9-B8FC-48E0-A7BC-8AEBE66292FA@gmail.com> On Jan 31, 2013, at 3:43 PM, Claudio Nieder wrote: > Now PrintGCDetails is a boolean flag, and the sign between -XX: and PrintGCDetails is +/- I had forgotten that and added the switch off the page exactly. I got it working a little later last night when I remembered that and changed to '+'. It is a little strange the page shows the setting that turns it off. It is also a little strange that there is an off setting at all since that would probably be the default. Just omitting the switch should be sufficient for 'off'? I still haven't looked at it in detail though, there is probably some reason for this. Thanks again. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter