From mik3hall at gmail.com Sun Jan 1 05:23:33 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 1 Jan 2012 07:23:33 -0600 Subject: com.sun.tools.attach.VirtualMachine not there Message-ID: <96565382-F792-4428-ABFB-0B796FBDF964@gmail.com> Happy New Year I was going to search JIRA and noticed this in issues due. http://java.net/jira/browse/MACOSX_PORT-97 Possibly related? Otherwise any idea why this class is not present? (b223) Thanks From Alan.Bateman at oracle.com Sun Jan 1 06:23:37 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 01 Jan 2012 14:23:37 +0000 Subject: com.sun.tools.attach.VirtualMachine not there In-Reply-To: <96565382-F792-4428-ABFB-0B796FBDF964@gmail.com> References: <96565382-F792-4428-ABFB-0B796FBDF964@gmail.com> Message-ID: <4F006C69.3090806@oracle.com> On 01/01/2012 13:23, Michael Hall wrote: > Happy New Year > > I was going to search JIRA and noticed this in issues due. > http://java.net/jira/browse/MACOSX_PORT-97 > > Possibly related? > > Otherwise any idea why this class is not present? (b223) > > Thanks I don't know what b223 is but I just checked my (up to date) build of jdk7u/jdk7u-osx and the attach API is in tools.jar as expected. I also checked jstack and jmap (they use the attach API) and these tools are attaching to running VMs which proves that the mechanism is working. The tests cited in the above JIRA are probably not going to pass through, this is because networking (when IPv6 is enabled) is temporarily broken. I expect Michael will sort that out quickly once he gets back after the holidays. -Alan. From mik3hall at gmail.com Sun Jan 1 06:36:18 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 1 Jan 2012 08:36:18 -0600 Subject: com.sun.tools.attach.VirtualMachine not there In-Reply-To: <4F006C69.3090806@oracle.com> References: <96565382-F792-4428-ABFB-0B796FBDF964@gmail.com> <4F006C69.3090806@oracle.com> Message-ID: <7994FEBB-30AF-418F-814D-6D7ABEF8839E@gmail.com> On Jan 1, 2012, at 8:23 AM, Alan Bateman wrote: > On 01/01/2012 13:23, Michael Hall wrote: >> Happy New Year >> >> I was going to search JIRA and noticed this in issues due. >> http://java.net/jira/browse/MACOSX_PORT-97 >> >> Possibly related? >> >> Otherwise any idea why this class is not present? (b223) >> >> Thanks > I don't know what b223 is but I just checked my (up to date) build of jdk7u/jdk7u-osx and the attach API is in tools.jar as expected. I also checked jstack and jmap (they use the attach API) and these tools are attaching to running VMs which proves that the mechanism is working. The tests cited in the above JIRA are probably not going to pass through, this is because networking (when IPv6 is enabled) is temporarily broken. I expect Michael will sort that out quickly once he gets back after the holidays. No sorry, thought I might of typo'ed the name, I was confusing them a minute ago but not here... showc com.sun.tools.attach.VirtualMachine showc: invoked with: com.sun.tools.attach.VirtualMachine java.lang.ClassNotFoundException: com.sun.tools.attach.VirtualMachine at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at org.cmdline.cmds.showc.main(showc.java:76) 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.cmdline.psuedoGestalt.Runner.invoke(Runner.java:183) at org.cmdline.psuedoGestalt.Runner.runStatic(Runner.java:210) at org.cmdline.psuedoGestalt.Runner.runMain(Runner.java:202) at org.cmdline.psuedoGestalt.Runner.run(Runner.java:124) versions System.in:3:java.runtime.version=1.7.0-ea-b223 System.in:4:java.version=1.7.0-ea System.in:7:java.class.version=51.0 System.in:10:java.vm.version=21.0-b17 System.in:20:java.vm.specification.version=1.7 System.in:27:java.specification.version=1.7 As opposed to... showc com.sun.tools.attach.VirtualMachine showc: invoked with: com.sun.tools.attach.VirtualMachine public abstract class com.sun.tools.attach.VirtualMachine extends java.lang.Object { // Constructors protected com.sun.tools.attach.VirtualMachine(com.sun.tools.attach.spi.AttachProvider, java.lang.String); // Fields .... versions System.in:3:java.runtime.version=1.6.0_29-b11-402-10M3527 System.in:4:java.version=1.6.0_29 System.in:7:java.class.version=50.0 System.in:10:java.vm.version=20.4-b02-402 System.in:20:java.vm.specification.version=1.0 System.in:27:java.specification.version=1.6 No rush on the answer, I just came across it, I can look at other things. Thanks again From paul.hohensee at oracle.com Sun Jan 1 08:25:39 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Sun, 01 Jan 2012 11:25:39 -0500 Subject: The latest 7u-osx crashes In-Reply-To: <4EFD6440.5010609@oracle.com> References: <4EFCADF0.5070909@oracle.com> <4EFD6440.5010609@oracle.com> Message-ID: <4F008903.5020505@oracle.com> I've pulled hotspot down from jdk7u-dev to jdk7u-osx, which includes the fix for 7118648. Should work now. Paul On 12/30/11 2:12 AM, Daniel D. Daugherty wrote: > Compressed Oops is broken in the MacOS X port. The following bug: > > 7118648 3/3 disable compressed oops by default on MacOS X until > 7118647 is fixed > > was used to disable compressed oops in RT_Baseline for HSX-23-B08. > That fix has made it to 7u4, but is not in the 7u-osx/hotspot repo. > I don't know when the next resync is planned. > > The following bug: > > 7118647 3/3 compressed oops crashes on MacOS X with JPRT GCBasher test > > is being used to track the actual failure. > > Dan > > > > On 12/29/11 11:14 AM, Alexander Potochkin wrote: >> Hello >> >> I just built the latest 7u-osx jdk on Mac >> and found that it crashes when I run any application >> >> I hear that our release team observed the same problem, >> wonder if anybody knows how to fix it >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00000001015fe2e4, pid=78258, tid=4401594368 >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK 64-Bit Server VM (23.0-b06 mixed mode bsd-amd64 >> compressed oops) >> # Problematic frame: >> # V [libjvm.dylib+0x27b2e4] >> >> Thanks >> alexp From Alan.Bateman at oracle.com Sun Jan 1 12:41:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 01 Jan 2012 20:41:27 +0000 Subject: com.sun.tools.attach.VirtualMachine not there In-Reply-To: <7994FEBB-30AF-418F-814D-6D7ABEF8839E@gmail.com> References: <96565382-F792-4428-ABFB-0B796FBDF964@gmail.com> <4F006C69.3090806@oracle.com> <7994FEBB-30AF-418F-814D-6D7ABEF8839E@gmail.com> Message-ID: <4F00C4F7.2080801@oracle.com> On 01/01/2012 14:36, Michael Hall wrote: > > No sorry, thought I might of typo'ed the name, I was confusing them a minute ago but not here... > > showc com.sun.tools.attach.VirtualMachine > showc: invoked with: com.sun.tools.attach.VirtualMachine > java.lang.ClassNotFoundException: com.sun.tools.attach.VirtualMachine > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > at java.lang.ClassLoader.loadClass(ClassLoader.java:423) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:186) > at org.cmdline.cmds.showc.main(showc.java:76) > 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.cmdline.psuedoGestalt.Runner.invoke(Runner.java:183) > at org.cmdline.psuedoGestalt.Runner.runStatic(Runner.java:210) > at org.cmdline.psuedoGestalt.Runner.runMain(Runner.java:202) > at org.cmdline.psuedoGestalt.Runner.run(Runner.java:124) > versions > System.in:3:java.runtime.version=1.7.0-ea-b223 > System.in:4:java.version=1.7.0-ea > System.in:7:java.class.version=51.0 > System.in:10:java.vm.version=21.0-b17 > System.in:20:java.vm.specification.version=1.7 > System.in:27:java.specification.version=1.7 > > As opposed to... > showc com.sun.tools.attach.VirtualMachine > showc: invoked with: com.sun.tools.attach.VirtualMachine > public abstract class com.sun.tools.attach.VirtualMachine extends java.lang.Object { > // Constructors > protected com.sun.tools.attach.VirtualMachine(com.sun.tools.attach.spi.AttachProvider, java.lang.String); > // Fields > .... > versions > System.in:3:java.runtime.version=1.6.0_29-b11-402-10M3527 > System.in:4:java.version=1.6.0_29 > System.in:7:java.class.version=50.0 > System.in:10:java.vm.version=20.4-b02-402 > System.in:20:java.vm.specification.version=1.0 > System.in:27:java.specification.version=1.6 > > No rush on the answer, I just came across it, I can look at other things. > Thanks again I'll bet this is just that tools.jar isn't on the classpath. In Apple's JDK then the tools that are normally in tools.jar are in classes.jar which is on the boot class path. I assume this why it works for 6u29 in the above. -Alan. From mik3hall at gmail.com Sun Jan 1 13:32:46 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 1 Jan 2012 15:32:46 -0600 Subject: com.sun.tools.attach.VirtualMachine not there In-Reply-To: <4F00C4F7.2080801@oracle.com> References: <96565382-F792-4428-ABFB-0B796FBDF964@gmail.com> <4F006C69.3090806@oracle.com> <7994FEBB-30AF-418F-814D-6D7ABEF8839E@gmail.com> <4F00C4F7.2080801@oracle.com> Message-ID: <25CBF78F-61A2-4536-9E3A-DB1C0DF83712@gmail.com> On Jan 1, 2012, at 2:41 PM, Alan Bateman wrote: > I'll bet this is just that tools.jar isn't on the classpath. In Apple's JDK then the tools that are normally in tools.jar are in classes.jar which is on the boot class path. I assume this why it works for 6u29 in the above. That was it. Different from previous OS X versions is true. Not easy to get as an external jar with Eclipse through the jdk bundle. I copied the jar and added it that way. Thanks From michael.x.mcmahon at oracle.com Tue Jan 3 09:07:30 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 03 Jan 2012 17:07:30 +0000 Subject: Code review: 71257522 [macosx] 7u4 b200 crash i.e. in Tonga Message-ID: <4F0335D2.7040304@oracle.com> Could I get the following webrev reviewed please? http://cr.openjdk.java.net/~michaelm/7125722/webrev.1/ JNI field ids were being used before being initialized. Thanks, Michael. From Alan.Bateman at oracle.com Tue Jan 3 10:20:03 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 03 Jan 2012 18:20:03 +0000 Subject: Code review: 71257522 [macosx] 7u4 b200 crash i.e. in Tonga In-Reply-To: <4F0335D2.7040304@oracle.com> References: <4F0335D2.7040304@oracle.com> Message-ID: <4F0346D3.2020000@oracle.com> On 03/01/2012 17:07, Michael McMahon wrote: > Could I get the following webrev reviewed please? > > http://cr.openjdk.java.net/~michaelm/7125722/webrev.1/ > > JNI field ids were being used before being initialized. > > Thanks, > Michael. What you have is fine to address the current crash but at some point it would be good to re-visit this to avoid possible race conditions. -Alan. From daniel.daugherty at oracle.com Tue Jan 3 10:39:13 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 03 Jan 2012 11:39:13 -0700 Subject: RFR (S): 7125793: MAC: test_gamma should always work In-Reply-To: <4EFECA5D.6010905@oracle.com> References: <4EFECA5D.6010905@oracle.com> Message-ID: <4F034B51.3070609@oracle.com> > http://cr.openjdk.java.net/~jmelvin/7125793/webrev.00 Jim, Thanks for diving in and improving the MacOS X port! Comments below. Dan make/bsd/makefiles/buildtree.make line 422: The new 'java -fullversion' invocation does not include the $(JAVA_FLAG) option like the old code did. Any particular reason for the change? Looks like that means the '-d32' or '-d64' options won't be specified as they were before. line 447: Why not just echo FULL_VERSION? Why pipe to awk? line 465: The 'jre/lib/libjava.dylib' part of the new check is MacOS X specific. Other BSDs don't necessarily use the '.dylib' extension (instead of .so) and I don't think that other BSDs have dropped the "arch" subdir. line 484: The DYLD_LIBRARY_PATH part is MacOS X specific. Will still need to set LD_LIBRARY_PATH for other BSDs. line 492: You switched from $(TESTFLAGS) to literal flag values, but you left the TESTFLAGS variable around. Any reason for the switch? make/bsd/makefiles/launcher.make Please add a comment explaining why '-framework CoreFoundation' is needed. Your explanatory block below is a really good start. make/bsd/makefiles/vm.make No comments. src/os/bsd/vm/os_bsd.cpp line 2585: Uses a suffix of ".so". That shouldn't work on MacOS X since MacOS X uses '.dylib'. That's OK for other BSDs, but not MacOS X. Also the comments that mention '.so' should be updated to include '.dylib' (not caused by your changes). To David H. - Yes, this change added another '#fdef __APPLE__'. It is not the first and it likely won't be the last since we're not done yet with the MacOS X port. There are a number of things that need to be cleaned up and we're tracking them. However, as you know, we don't have enough folks to handle all of the work so we'll just have to live with the warts for now. src/os/posix/launcher/java_md.c No comments. On 12/31/11 1:39 AM, James Melvin wrote: > Hi, > > This change fixes the 'gamma' simple launcher for HotSpot on Mac OS X. > There were 3 primary changes required to re-enable gamma... > > 1) Statically link with CoreFoundation framework to resolve symbols > > The gamma launcher dlopen()s libjava.dylib from $JAVA_HOME/jre/lib. > Because Mac OS X files are case-insensitive by default, we collide on > $FRAMEWORK/libJPEG.dylib and ${JAVA_HOME}/jre/lib/libjpeg.dylib. This > resulted in unresolved symbols in the Mac OS X framework libraries. The > solution for gamma was to statically link with CoreFoundation framework > to properly resolve framework symbols and allow gamma to successfully > dlopen() libjava.dylib. > > 2) Adjust various paths to reflect no arch subdirs > > On Mac OS X, there are no arch subdirs, e.g jre/lib vs jre/lib/. > Instead, one can use universal binaries to package multiple > architectures in a single binary. At the moment though, we are only > building 64-bit non-universal binaries. Note, the test_gamma script > assumes an Oracle JDK layout for JAVA_HOME, derived from ALT_BOOTDIR. > Using an Apple JDK for ALT_BOOTDIR will fail the test_gamma script > gracefully, as libjava.dylib is in a different, unexpected place. > > 3) Modify test_gamma script to set library path only for gamma launch > > Setting DYLD_LIBRARY_PATH adversely affects the real java launcher(s). > Instead, set this later in the script only for the gamma launcher test > run. While in there, I took the liberty of decrypting the script to make > it more maintainable and more easily merged whenever we reconcile the > unix ports into a single codebase. There is no change to the script > output. > > Feedback welcome... > > WEBREV: > http://cr.openjdk.java.net/~jmelvin/7125793/webrev.00 > > TESTS RUN: > JPRT 2011-12-31-061123.jmelvin.7125793 > local Mac OS X builds/tests > > > Thanks and Happy New Year! > > Jim From paul.hohensee at oracle.com Tue Jan 3 13:20:02 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 03 Jan 2012 16:20:02 -0500 Subject: [7u4-osx] Request for approval for 7125722: [macosx] 7u4 b200 crash i.e. in Tonga In-Reply-To: <4F036E1E.2010804@oracle.com> References: <4F036E1E.2010804@oracle.com> Message-ID: <4F037102.5010509@oracle.com> Approved. Note that you're relying on ni_class being initialized to NULL by the compiler+runtime system. Paul On 1/3/12 4:07 PM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125722 > > Webrev: http://cr.openjdk.java.net/~michaelm/7125722/webrev.1/ > > Reviewed by: alanb > > Thanks, > Michael. From michael.x.mcmahon at oracle.com Tue Jan 3 13:51:18 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 03 Jan 2012 21:51:18 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7125722: [macosx] 7u4 b200 crash i.e. in Tonga Message-ID: <20120103215128.E98BB47868@hg.openjdk.java.net> Changeset: a301b69dfdc3 Author: michaelm Date: 2012-01-03 13:43 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/a301b69dfdc3 7125722: [macosx] 7u4 b200 crash i.e. in Tonga Reviewed-by: alanb, dcubed ! src/solaris/native/java/net/net_util_md.c From swingler at apple.com Tue Jan 3 16:16:10 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 03 Jan 2012 16:16:10 -0800 Subject: error building jobjc during build of jdk7u-osx In-Reply-To: References: Message-ID: On Dec 28, 2011, at 1:46 PM, Stephen Bannasch wrote: > At 12:33 AM -0500 12/28/11, Stephen Bannasch wrote: > >> I tried the following to build jdk7u-osx: >> >> hg clone http://hg.openjdk.java.net/jdk7u/jdk7u-osx >> cd jdk7u-osx >> hg fpull -u >> unset LC_ALL LANG CLASSPATH JAVA_HOME LD_LIBRARY_PATH; make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` >> >> But got the following error building jobjc: >> >> ./jdk/src/macosx/native/jobjc/build.xml:131: exec returned: 1 >> at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:646) >> at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:672) >> at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:498) >> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) >> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >> at org.apache.tools.ant.Task.perform(Task.java:348) >> at org.apache.tools.ant.Target.execute(Target.java:390) >> at org.apache.tools.ant.Target.performTasks(Target.java:411) >> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) >> at org.apache.tools.ant.Project.executeTarget(Project.java:1368) >> at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >> at org.apache.tools.ant.Project.executeTargets(Project.java:1251) >> at org.apache.tools.ant.Main.runBuild(Main.java:809) >> at org.apache.tools.ant.Main.startAnt(Main.java:217) >> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) >> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) >> > > Evidently this ruby script used as part of the jobjc build process doesn't work in Ruby 1.9.2p290: > > jdk/src/macosx/native/jobjc/run-and-write-if-okay > > I am using RVM to manage multiple ruby installs and I use Ruby 1.9.2p290 as the default. > > Selecting the system Ruby with an '.rvmrc' file before running the build now completes without this error. > > [jdk7u-osx ]$ cat .rvmrc > rvm system > > [jdk7u-osx ]$ ruby -v > ruby 1.8.7 (2010-01-10 patchlevel 249) [universal-darwin10.0] > > I've updated my scripts for building jdk7u-osx: > > https://gist.github.com/1529906 Feel free to transliterate that script into pure bash shell script, or something more maintainable. The Java build process should not depend on the system installed version of Ruby. It's also quite deceptive that that script doesn't end in .rb either. Regards, Mike Swingler Apple Inc. From kumar.x.srinivasan at oracle.COM Tue Jan 3 16:50:04 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 03 Jan 2012 16:50:04 -0800 Subject: launcher src/solaris/bin Message-ID: <4F03A23C.8060408@oracle.COM> Hi, I am planning on refactoring/layout currently in src/solaris/bin as shown below. Is this correct for embedded and macosx ? Thanks Kumar src/solaris/bin java_md.{c,h} ergo.{c,h} ergo_i586.h jexec.{c,h} // config directories amd64 i586 sparc sparcv9 src/linux/bin java_md.{c,h} ergo.{c,h} ergo_i586.h jexec.{c,h} // config directories amd64 i586 ia64 ppc zero src/macosx/bin ergo.{c,h} // maybe ergo_i586.h // maybe java_md.{c,h} // config directories universal From swingler at apple.com Tue Jan 3 16:59:37 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 03 Jan 2012 16:59:37 -0800 Subject: Build instructions on the wiki Message-ID: <6848BA4D-D048-4859-811F-630DA1342831@apple.com> Just an FYI, would someone at Oracle please update the build instructions on the wiki page to point to the new source at ? There are probably a few pages that point at the old macosx-port repo. Thanks, Mike Swingler Apple Inc. From swingler at apple.com Tue Jan 3 17:08:49 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 03 Jan 2012 17:08:49 -0800 Subject: launcher src/solaris/bin In-Reply-To: <4F03A23C.8060408@oracle.COM> References: <4F03A23C.8060408@oracle.COM> Message-ID: <0F29BFF3-80F8-493D-B91E-093D0F034D5A@apple.com> On Jan 3, 2012, at 4:50 PM, Kumar Srinivasan wrote: > Hi, > > I am planning on refactoring/layout currently in src/solaris/bin as > shown below. Is this correct for embedded and macosx ? > > Thanks > Kumar > > src/solaris/bin > java_md.{c,h} > ergo.{c,h} > ergo_i586.h > jexec.{c,h} > // config directories > amd64 > i586 > sparc > sparcv9 > > src/linux/bin > java_md.{c,h} > ergo.{c,h} > ergo_i586.h > jexec.{c,h} > // config directories > amd64 > i586 > ia64 > ppc > zero > > src/macosx/bin > ergo.{c,h} // maybe > ergo_i586.h // maybe > java_md.{c,h} > // config directories > universal For Mac OS X, ergo and ergo_i586 seem silly, because every Mac that qualifies for Mac OS X 10.7 falls into the definition of "Server Class", as currently written. The universal directory looks like a good choice. Cheers, Mike Swingler Apple Inc. From david.holmes at oracle.com Tue Jan 3 17:28:51 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Jan 2012 11:28:51 +1000 Subject: launcher src/solaris/bin In-Reply-To: <4F03A23C.8060408@oracle.COM> References: <4F03A23C.8060408@oracle.COM> Message-ID: <4F03AB53.6080608@oracle.com> Hi Kumar, On 4/01/2012 10:50 AM, Kumar Srinivasan wrote: > I am planning on refactoring/layout currently in src/solaris/bin as > shown below. Is this correct for embedded and macosx ? You seem to have lost "arm" under linux. But for embedded we dynamically rewrite jvm.cfg as part of the build anyway. I think only zero may need the existing layout. I hate seeing all those per-arch directories just for a jvm.cfg file :( David > Thanks > Kumar > > src/solaris/bin > java_md.{c,h} > ergo.{c,h} > ergo_i586.h > jexec.{c,h} > // config directories > amd64 > i586 > sparc > sparcv9 > > src/linux/bin > java_md.{c,h} > ergo.{c,h} > ergo_i586.h > jexec.{c,h} > // config directories > amd64 > i586 > ia64 > ppc > zero > > src/macosx/bin > ergo.{c,h} // maybe > ergo_i586.h // maybe > java_md.{c,h} > // config directories > universal From kelly.ohair at oracle.com Tue Jan 3 17:32:24 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 3 Jan 2012 17:32:24 -0800 Subject: Build instructions on the wiki In-Reply-To: <6848BA4D-D048-4859-811F-630DA1342831@apple.com> References: <6848BA4D-D048-4859-811F-630DA1342831@apple.com> Message-ID: <4D131BB2-67CC-4138-9047-218BC9CA7C37@oracle.com> I can do this I think... Want me to try and fix it? -kto On Jan 3, 2012, at 4:59 PM, Mike Swingler wrote: > Just an FYI, would someone at Oracle please update the build instructions on the wiki page to point to the new source at ? There are probably a few pages that point at the old macosx-port repo. > > Thanks, > Mike Swingler > Apple Inc. > From mik3hall at gmail.com Tue Jan 3 19:06:46 2012 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 3 Jan 2012 21:06:46 -0600 Subject: jhat 1.6/1.7 difference Message-ID: <5BA28A39-A56F-4F18-9F20-C5BE0D888289@gmail.com> 1.7 shows a dock icon. Intentional? From kumar.x.srinivasan at oracle.COM Wed Jan 4 07:27:12 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Wed, 04 Jan 2012 07:27:12 -0800 Subject: launcher src/solaris/bin In-Reply-To: <4F03AB53.6080608@oracle.com> References: <4F03A23C.8060408@oracle.COM> <4F03AB53.6080608@oracle.com> Message-ID: <4F046FD0.1010706@oracle.COM> Hi David, > Hi Kumar, > > On 4/01/2012 10:50 AM, Kumar Srinivasan wrote: >> I am planning on refactoring/layout currently in src/solaris/bin as >> shown below. Is this correct for embedded and macosx ? > > You seem to have lost "arm" under linux. But for embedded we > dynamically rewrite jvm.cfg as part of the build anyway. I think only > zero may need the existing layout. Oops missed it, will take care of it. > > I hate seeing all those per-arch directories just for a jvm.cfg file :( I'll do something about it in jdk8 there is a CR to remove it completely 4764675, if not I will have one generated as embedded does. Thanks Kumar > > David > >> Thanks >> Kumar >> >> src/solaris/bin >> java_md.{c,h} >> ergo.{c,h} >> ergo_i586.h >> jexec.{c,h} >> // config directories >> amd64 >> i586 >> sparc >> sparcv9 >> >> src/linux/bin >> java_md.{c,h} >> ergo.{c,h} >> ergo_i586.h >> jexec.{c,h} >> // config directories >> amd64 >> i586 >> ia64 >> ppc >> zero >> >> src/macosx/bin >> ergo.{c,h} // maybe >> ergo_i586.h // maybe >> java_md.{c,h} >> // config directories >> universal From kelly.ohair at oracle.com Wed Jan 4 11:12:09 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 4 Jan 2012 11:12:09 -0800 Subject: Build instructions on the wiki In-Reply-To: <1B37E224-C748-44F4-8270-836CF3EF0225@apple.com> References: <6848BA4D-D048-4859-811F-630DA1342831@apple.com> <4D131BB2-67CC-4138-9047-218BC9CA7C37@oracle.com> <1B37E224-C748-44F4-8270-836CF3EF0225@apple.com> Message-ID: <8C20BCA0-AD25-47E1-96A8-4BF74BBB4454@oracle.com> Sorry. I thought we were talking about the pages at: http://openjdk.java.net/projects/macosx-port/ I don't think I have rights to change the wiki: https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port I can add to or edit the http://openjdk.java.net/ pages if needed. -kto On Jan 3, 2012, at 6:06 PM, Mike Swingler wrote: > Sure thing. I just thought that someone else should take ownership of some the content (or replace it with links to more official pages), since I'm not always going to be the right person with the right answers as the port mainlines. > > Thanks much, > Mike Swingler > Apple Inc. > > On Jan 3, 2012, at 5:32 PM, Kelly O'Hair wrote: > >> I can do this I think... >> >> Want me to try and fix it? >> >> -kto >> >> On Jan 3, 2012, at 4:59 PM, Mike Swingler wrote: >> >>> Just an FYI, would someone at Oracle please update the build instructions on the wiki page to point to the new source at ? There are probably a few pages that point at the old macosx-port repo. >>> >>> Thanks, >>> Mike Swingler >>> Apple Inc. >>> >> > From mik3hall at gmail.com Wed Jan 4 12:54:44 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 4 Jan 2012 14:54:44 -0600 Subject: JIRA] Commented: (MACOSX_PORT-105) Create a .jre bundle, suitable for embedding in a .app Message-ID: I notice Scott Kovatch commented on this one. I'm not sure about the appropriateness of debating it through JIRA comments or even off-list e-mails so bringing it up here instead. I have asked about it on list a couple times I think. One question I think I had was what version of XCode is required? When I tried starting the JavaAppLauncher project with XCode it ended up with the events locked spinning wheel cursor. I have to assume I'm either software and/or hardware versions behind what I need. I could see the project contents but couldn't figure out how you would manage the embedding with a command line build. From the JIRA comment is including a jre required? Every application will do this? I think I've also asked if a JavaApplicationStub like executable couldn't be provided? Which would launch the default installed, I guess in this case openjdk, jre. Mike Swingler did tell me before that the ApplicationDelegate handled AppleEvent related stuff like file associations. I have noticed that is provided separately from the JavaAppLauncher XCode project. Any chance for a brief description of how that works? Thanks From kelly.ohair at oracle.com Wed Jan 4 13:53:42 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 4 Jan 2012 13:53:42 -0800 Subject: Build instructions on the wiki In-Reply-To: References: <6848BA4D-D048-4859-811F-630DA1342831@apple.com> <4D131BB2-67CC-4138-9047-218BC9CA7C37@oracle.com> <1B37E224-C748-44F4-8270-836CF3EF0225@apple.com> <8C20BCA0-AD25-47E1-96A8-4BF74BBB4454@oracle.com> Message-ID: <5C4F3E98-D349-4CDF-AC6E-5D460BA66802@oracle.com> On Jan 4, 2012, at 11:18 AM, Mike Swingler wrote: > On Jan 4, 2012, at 11:12 AM, Kelly O'Hair wrote: > >> Sorry. I thought we were talking about the pages at: http://openjdk.java.net/projects/macosx-port/ > > Actually, that page should be fixed too. I didn't see anything on these pages that needed changing, but let me know what you think needs changing and I will fix it. > >> I don't think I have rights to change the wiki: https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port > > Anyone can edit those pages?it's an open wiki, you just have to sign up with a different account than your Oracle internal one. I'll draw the line on that for me. If it can be edited by anyone, then I'll let anyone (else) do that one. ;^) -kto > >> I can add to or edit the http://openjdk.java.net/ pages if needed. >> >> -kto > > Thanks, > Mike Swingler > Apple Inc. > >> On Jan 3, 2012, at 6:06 PM, Mike Swingler wrote: >> >>> Sure thing. I just thought that someone else should take ownership of some the content (or replace it with links to more official pages), since I'm not always going to be the right person with the right answers as the port mainlines. >>> >>> Thanks much, >>> Mike Swingler >>> Apple Inc. >>> >>> On Jan 3, 2012, at 5:32 PM, Kelly O'Hair wrote: >>> >>>> I can do this I think... >>>> >>>> Want me to try and fix it? >>>> >>>> -kto >>>> >>>> On Jan 3, 2012, at 4:59 PM, Mike Swingler wrote: >>>> >>>>> Just an FYI, would someone at Oracle please update the build instructions on the wiki page to point to the new source at ? There are probably a few pages that point at the old macosx-port repo. >>>>> >>>>> Thanks, >>>>> Mike Swingler >>>>> Apple Inc. >>>>> >>>> >>> >> > From swingler at apple.com Wed Jan 4 14:26:57 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 04 Jan 2012 14:26:57 -0800 Subject: Build instructions on the wiki In-Reply-To: <5C4F3E98-D349-4CDF-AC6E-5D460BA66802@oracle.com> References: <6848BA4D-D048-4859-811F-630DA1342831@apple.com> <4D131BB2-67CC-4138-9047-218BC9CA7C37@oracle.com> <1B37E224-C748-44F4-8270-836CF3EF0225@apple.com> <8C20BCA0-AD25-47E1-96A8-4BF74BBB4454@oracle.com> <5C4F3E98-D349-4CDF-AC6E-5D460BA66802@oracle.com> Message-ID: <23B4AC57-E6E1-42FC-A9FA-D24233D86723@apple.com> On Jan 4, 2012, at 1:53 PM, Kelly O'Hair wrote: > On Jan 4, 2012, at 11:18 AM, Mike Swingler wrote: > >> On Jan 4, 2012, at 11:12 AM, Kelly O'Hair wrote: >> >>> Sorry. I thought we were talking about the pages at: http://openjdk.java.net/projects/macosx-port/ >> >> Actually, that page should be fixed too. > > I didn't see anything on these pages that needed changing, but let me know what you think needs changing and > I will fix it. The OS requirement of 10.6 instead of 10.7. >>> I don't think I have rights to change the wiki: https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port >> >> Anyone can edit those pages?it's an open wiki, you just have to sign up with a different account than your Oracle internal one. > > I'll draw the line on that for me. If it can be edited by anyone, then I'll let anyone (else) do that one. ;^) Who is the responsible individual driving the change over in repositories from macosx-port to 7u-osx? It's that person. If no-one at Oracle can be bothered to update the wiki, it should be explicitly marked as abandoned. >>> I can add to or edit the http://openjdk.java.net/ pages if needed. >>> >>> -kto >> >> Thanks, >> Mike Swingler >> Apple Inc. >> >>> On Jan 3, 2012, at 6:06 PM, Mike Swingler wrote: >>> >>>> Sure thing. I just thought that someone else should take ownership of some the content (or replace it with links to more official pages), since I'm not always going to be the right person with the right answers as the port mainlines. >>>> >>>> Thanks much, >>>> Mike Swingler >>>> Apple Inc. >>>> >>>> On Jan 3, 2012, at 5:32 PM, Kelly O'Hair wrote: >>>> >>>>> I can do this I think... >>>>> >>>>> Want me to try and fix it? >>>>> >>>>> -kto >>>>> >>>>> On Jan 3, 2012, at 4:59 PM, Mike Swingler wrote: >>>>> >>>>>> Just an FYI, would someone at Oracle please update the build instructions on the wiki page to point to the new source at ? There are probably a few pages that point at the old macosx-port repo. >>>>>> >>>>>> Thanks, >>>>>> Mike Swingler >>>>>> Apple Inc. >>>>>> >>>>> >>>> >>> >> > From kelly.ohair at oracle.com Wed Jan 4 14:41:49 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 4 Jan 2012 14:41:49 -0800 Subject: Build instructions on the wiki In-Reply-To: <23B4AC57-E6E1-42FC-A9FA-D24233D86723@apple.com> References: <6848BA4D-D048-4859-811F-630DA1342831@apple.com> <4D131BB2-67CC-4138-9047-218BC9CA7C37@oracle.com> <1B37E224-C748-44F4-8270-836CF3EF0225@apple.com> <8C20BCA0-AD25-47E1-96A8-4BF74BBB4454@oracle.com> <5C4F3E98-D349-4CDF-AC6E-5D460BA66802@oracle.com> <23B4AC57-E6E1-42FC-A9FA-D24233D86723@apple.com> Message-ID: <2EDE73D8-1BDE-481D-816F-2B315BFF50CB@oracle.com> On Jan 4, 2012, at 2:26 PM, Mike Swingler wrote: > On Jan 4, 2012, at 1:53 PM, Kelly O'Hair wrote: > >> On Jan 4, 2012, at 11:18 AM, Mike Swingler wrote: >> >>> On Jan 4, 2012, at 11:12 AM, Kelly O'Hair wrote: >>> >>>> Sorry. I thought we were talking about the pages at: http://openjdk.java.net/projects/macosx-port/ >>> >>> Actually, that page should be fixed too. >> >> I didn't see anything on these pages that needed changing, but let me know what you think needs changing and >> I will fix it. > > The OS requirement of 10.6 instead of 10.7. Should be fixed shortly. > >>>> I don't think I have rights to change the wiki: https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port >>> >>> Anyone can edit those pages?it's an open wiki, you just have to sign up with a different account than your Oracle internal one. >> >> I'll draw the line on that for me. If it can be edited by anyone, then I'll let anyone (else) do that one. ;^) > > Who is the responsible individual driving the change over in repositories from macosx-port to 7u-osx? It's that person. I'll wait until that person stands up. ;^) > > If no-one at Oracle can be bothered to update the wiki, it should be explicitly marked as abandoned. Please don't get me wrong, I agree that it needs to be fixed, I'll try and find out who that would be. -kto > >>>> I can add to or edit the http://openjdk.java.net/ pages if needed. >>>> >>>> -kto >>> >>> Thanks, >>> Mike Swingler >>> Apple Inc. >>> >>>> On Jan 3, 2012, at 6:06 PM, Mike Swingler wrote: >>>> >>>>> Sure thing. I just thought that someone else should take ownership of some the content (or replace it with links to more official pages), since I'm not always going to be the right person with the right answers as the port mainlines. >>>>> >>>>> Thanks much, >>>>> Mike Swingler >>>>> Apple Inc. >>>>> >>>>> On Jan 3, 2012, at 5:32 PM, Kelly O'Hair wrote: >>>>> >>>>>> I can do this I think... >>>>>> >>>>>> Want me to try and fix it? >>>>>> >>>>>> -kto >>>>>> >>>>>> On Jan 3, 2012, at 4:59 PM, Mike Swingler wrote: >>>>>> >>>>>>> Just an FYI, would someone at Oracle please update the build instructions on the wiki page to point to the new source at ? There are probably a few pages that point at the old macosx-port repo. >>>>>>> >>>>>>> Thanks, >>>>>>> Mike Swingler >>>>>>> Apple Inc. >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mik3hall at gmail.com Wed Jan 4 16:08:14 2012 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 4 Jan 2012 18:08:14 -0600 Subject: JIRA] Commented: (MACOSX_PORT-105) Create a .jre bundle, suitable for embedding in a .app In-Reply-To: References: Message-ID: I guess unanswered is unanswered whether JIRA, list or Wiki. New years wishes hoping sometime in the new year this information will be revealed to some users somewhere. From kurchi.subhra.hazra at oracle.com Wed Jan 4 16:28:37 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 04 Jan 2012 16:28:37 -0800 Subject: Review request: 7123679 Update regression tests that use os.name to work on MacOSX In-Reply-To: <4EE90DBB.6010801@oracle.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> Message-ID: <4F04EEB5.1020400@oracle.com> Hi, Some test files in jdk/test have behavior defined by what the os.name property of the system evaluates to. These changes adds Mac OS X as a recognized OS in a bunch of such test files. In addition, since many tests are failing with the sun.nio.ch.KQueueSelectorProvider, the changes also include using sun.nio.ch.PollSelectorProvider as the DefaultSelector for now until the kqueue selector is fixed. Webrev: http://cr.openjdk.java.net/~khazra/7123679/webrev.00/ Thanks, Kurchi From scott.kovatch at oracle.com Wed Jan 4 20:05:31 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 4 Jan 2012 23:05:31 -0500 Subject: JIRA] Commented: (MACOSX_PORT-105) Create a .jre bundle, suitable for embedding in a .app In-Reply-To: References: Message-ID: <9B5F62F2-C2AD-451F-B835-E5C6F6A49405@oracle.com> First off, the JIRA is open to all, so feel free to have discussions relevant to a specific bug in the comments. Here's what I see happening in this area (or maybe better put, what I'd like to see happen): The Xcode project that is currently checked in at jdk/src/macosx/bundle should be used as a template for building a bundled application. It will build the native portion of the launcher from source and also copy all of the needed jars and other resources needed for your application. This mostly works now. If you need to sign the app for submission to the app store, the native portion of the launcher has some problems that will keep the app from working in sandboxd and need to be fixed. On Jan 4, 2012, at 7:08 PM, Michael Hall wrote: > One question I think I had was what version of XCode is required? When I tried starting the JavaAppLauncher project with XCode it ended up with the events locked spinning wheel cursor. I have to assume I'm either software and/or hardware versions behind what I need. I could see the project contents but couldn't figure out how you would manage the embedding with a command line build. I shouldn't guess, but I'm going to say 3.2.6 or later should be enough to open the project. As currently checked in, there are some folder references that need fixing. What you would do for a command line build is use Xcode once to set up the project the way you want it and then use the 'xcodebuild' command to build it. > From the JIRA comment is including a jre required? Every application will do this? Yes, this is the current plan. > I think I've also asked if a JavaApplicationStub like executable couldn't be provided? Which would launch the default installed, I guess in this case openjdk, jre. We want to allow people to build a bundled Mac app on any platform. So, yes, we will need a pre-built binary of the native part of the application launcher, and an ant task or shell script that creates all of the directories and copies the bits into the right place. This will give you a bundled app, but if you need to sign it you will still need to build on Mac OS X. You will also need to build the JRE on a Mac and put it someplace from which the other platform can copy it. > Mike Swingler did tell me before that the ApplicationDelegate handled AppleEvent related stuff like file associations. I have noticed that is provided separately from the JavaAppLauncher XCode project. Any chance for a brief description of how that works? Once the AWT and ApplicationDelegate classes are loaded the standard Cocoa mechanisms for handling file open events are used, and then your ApplicationListener is invoked. You don't need do anything in the app launcher other than quickly parse the Info.plist and start up the JVM so the AWT can respond to the AppleEvent. > I guess unanswered is unanswered whether JIRA, list or Wiki. > New years wishes hoping sometime in the new year this information will be revealed to some users somewhere. We're going to need to write a lot of documentation over the next few months. The wiki location identified in the bug is a good place to start. -- Scott K. ------------------------ Scott Kovatch Oracle Pleasanton, CA > From mik3hall at gmail.com Thu Jan 5 00:28:29 2012 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 5 Jan 2012 02:28:29 -0600 Subject: JIRA] Commented: (MACOSX_PORT-105) Create a .jre bundle, suitable for embedding in a .app In-Reply-To: <9B5F62F2-C2AD-451F-B835-E5C6F6A49405@oracle.com> References: <9B5F62F2-C2AD-451F-B835-E5C6F6A49405@oracle.com> Message-ID: On Jan 4, 2012, at 10:05 PM, Scott Kovatch wrote: > First off, the JIRA is open to all, so feel free to have discussions relevant to a specific bug in the comments. OK, fair enough, next time I'll confine my response there. > I shouldn't guess, but I'm going to say 3.2.6 or later should be enough to open the project. As currently checked in, there are some folder references that need fixing. I am 3.2.6 so I don't know why I have problems with this project. Theres a 64 bit machine available to me now. I'll try that or a different user or reinstall XCode or the usual things, I again guess. >> From the JIRA comment is including a jre required? Every application will do this? > > Yes, this is the current plan. This seems a little contrary to the effort that was putting into providing support for multiple user selectable JVM's. But ok, I guess since you can't count on a OS installation I can understand this. Unfortunately for the time being being unable to build the XCode project I have no fallback. > What you would do for a command line build is use Xcode once to set up the project the way you want it and then use the 'xcodebuild' command to build it. Again the hitch with the XCode project for whatever reason being unusable to me. For the code I'm thinking about generating a application for I will probably still start out with a 1.6 while I figure this part out. Thanks for the response. Looking forward to the documentation so you don't have to explain these things here or in a JIRA. From michael.x.mcmahon at oracle.com Thu Jan 5 02:16:55 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 05 Jan 2012 10:16:55 +0000 Subject: hg: jdk7u/jdk7u-osx: 5 new changesets Message-ID: <20120105101656.69FD447890@hg.openjdk.java.net> Changeset: 9324f43c05d3 Author: katleman Date: 2011-12-15 09:36 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/rev/9324f43c05d3 Added tag jdk7u4-b04 for changeset bcc37b8ac1b0 ! .hgtags Changeset: 1637ced8f617 Author: katleman Date: 2011-12-14 17:30 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/rev/1637ced8f617 Added tag jdk7u4-b02 for changeset 870fd5101f66 ! .hgtags Changeset: a15712a2304e Author: katleman Date: 2011-12-15 12:56 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/rev/a15712a2304e Merge ! .hgtags Changeset: 1231e80827d0 Author: cl Date: 2011-12-21 20:02 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/rev/1231e80827d0 Added tag jdk7u4-b05 for changeset a15712a2304e ! .hgtags Changeset: 2fea92d741b7 Author: michaelm Date: 2012-01-05 09:26 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/rev/2fea92d741b7 Merge ! .hgtags From michael.x.mcmahon at oracle.com Thu Jan 5 02:17:08 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 05 Jan 2012 10:17:08 +0000 Subject: hg: jdk7u/jdk7u-osx/corba: 7 new changesets Message-ID: <20120105101713.D2DCC47891@hg.openjdk.java.net> Changeset: 87894172c349 Author: dmeetry Date: 2011-12-28 01:18 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/87894172c349 7046238: new InitialContext(); hangs Summary: Synchronization on a single monitor for contactInfo parameters with identical hashCode() Reviewed-by: robm, skoppar ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java Changeset: 132fa5ab1720 Author: katleman Date: 2011-12-15 09:37 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/132fa5ab1720 Added tag jdk7u4-b04 for changeset de83741c8ba0 ! .hgtags Changeset: 32a8fc6ada54 Author: katleman Date: 2011-12-14 17:30 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/32a8fc6ada54 Added tag jdk7u4-b02 for changeset 6dd348fb7091 ! .hgtags Changeset: 1a7656c7a8b9 Author: katleman Date: 2011-12-15 12:57 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/1a7656c7a8b9 Merge ! .hgtags Changeset: 185304fa5422 Author: cl Date: 2011-12-21 20:02 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/185304fa5422 Added tag jdk7u4-b05 for changeset 1a7656c7a8b9 ! .hgtags Changeset: 6fe1094ea7d3 Author: lana Date: 2011-12-28 10:50 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/6fe1094ea7d3 Merge Changeset: 48ac2f190ad1 Author: michaelm Date: 2012-01-05 09:26 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/48ac2f190ad1 Merge ! .hgtags From michael.x.mcmahon at oracle.com Thu Jan 5 02:17:35 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 05 Jan 2012 10:17:35 +0000 Subject: hg: jdk7u/jdk7u-osx/jaxp: 5 new changesets Message-ID: <20120105101735.21F2E47892@hg.openjdk.java.net> Changeset: 102da00555e0 Author: katleman Date: 2011-12-15 09:37 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/102da00555e0 Added tag jdk7u4-b04 for changeset 26f5422f16af ! .hgtags Changeset: f49c3d793120 Author: katleman Date: 2011-12-14 17:30 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/f49c3d793120 Added tag jdk7u4-b02 for changeset c09b58cfa2c6 ! .hgtags Changeset: f98a23328572 Author: katleman Date: 2011-12-15 12:59 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/f98a23328572 Merge ! .hgtags Changeset: 4ec17260df0f Author: cl Date: 2011-12-21 20:02 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/4ec17260df0f Added tag jdk7u4-b05 for changeset f98a23328572 ! .hgtags Changeset: a7da5cf6decb Author: michaelm Date: 2012-01-05 09:26 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/a7da5cf6decb Merge ! .hgtags From michael.x.mcmahon at oracle.com Thu Jan 5 02:17:47 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 05 Jan 2012 10:17:47 +0000 Subject: hg: jdk7u/jdk7u-osx/jaxws: 5 new changesets Message-ID: <20120105101747.1F59E47893@hg.openjdk.java.net> Changeset: 81a66b4fb1b9 Author: katleman Date: 2011-12-15 09:37 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxws/rev/81a66b4fb1b9 Added tag jdk7u4-b04 for changeset 8f089c74c312 ! .hgtags Changeset: 4ea033c5f751 Author: katleman Date: 2011-12-14 17:31 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxws/rev/4ea033c5f751 Added tag jdk7u4-b02 for changeset 5bc0433f1611 ! .hgtags Changeset: a2800128a3ac Author: katleman Date: 2011-12-15 12:59 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxws/rev/a2800128a3ac Merge ! .hgtags Changeset: 961f897b134d Author: cl Date: 2011-12-21 20:03 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxws/rev/961f897b134d Added tag jdk7u4-b05 for changeset a2800128a3ac ! .hgtags Changeset: 596322b0a046 Author: michaelm Date: 2012-01-05 09:26 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxws/rev/596322b0a046 Merge ! .hgtags From michael.x.mcmahon at oracle.com Thu Jan 5 02:18:27 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 05 Jan 2012 10:18:27 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 16 new changesets Message-ID: <20120105102123.F30B347894@hg.openjdk.java.net> Changeset: c42b880f2f4b Author: sherman Date: 2011-12-16 14:27 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/c42b880f2f4b 7109837: Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer Summary: Added ByteBuffer support via com.oracle.util.Checksums Reviewed-by: alanb ! make/common/Release.gmk ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Adler32.java + src/share/classes/sun/misc/JavaUtilZipAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/native/java/util/zip/Adler32.c Changeset: 8ee4164ea612 Author: anthony Date: 2011-12-20 13:51 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/8ee4164ea612 7122796: SunToolkit constructor should create the EventQueue for the Main AppContext Summary: Always create an EQ for the main AppContext in SunToolkit constructor Reviewed-by: art ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/SunToolkit.java + test/java/awt/EventQueue/MainAppContext/MainAppContext.java Changeset: 3396ba84c859 Author: dcubed Date: 2011-12-23 09:42 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/3396ba84c859 7121600: Instrumentation.redefineClasses() leaks class bytes Summary: Call JNI ReleaseByteArrayElements() on memory returned by JNI GetByteArrayElements(). Also push test for 7122253. Reviewed-by: acorn, poonam ! src/share/instrument/JPLISAgent.c + test/java/lang/instrument/BigClass.java + test/java/lang/instrument/MakeJAR4.sh + test/java/lang/instrument/RedefineBigClass.sh + test/java/lang/instrument/RedefineBigClassAgent.java + test/java/lang/instrument/RedefineBigClassApp.java + test/java/lang/instrument/RetransformBigClass.sh + test/java/lang/instrument/RetransformBigClassAgent.java + test/java/lang/instrument/RetransformBigClassApp.java Changeset: a048ff0d868b Author: mbankal Date: 2011-12-26 01:34 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/a048ff0d868b 7078816: /test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failure Reviewed-by: weijun ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh Changeset: ea43b1e91196 Author: mbankal Date: 2011-12-26 02:39 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/ea43b1e91196 Merge Changeset: 28fc012689e8 Author: katleman Date: 2011-12-15 09:37 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/28fc012689e8 Added tag jdk7u4-b04 for changeset 6f7af0f0e7db ! .hgtags Changeset: 7e5dcaa19010 Author: katleman Date: 2011-12-14 17:31 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/7e5dcaa19010 Added tag jdk7u4-b02 for changeset b97711a21785 ! .hgtags Changeset: be4a2f376e73 Author: katleman Date: 2011-12-15 12:59 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/be4a2f376e73 Merge ! .hgtags Changeset: 0e546acf224f Author: ngthomas Date: 2011-11-13 21:39 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/0e546acf224f 7109885: security baseline for 7u2 or above is not set correctly Reviewed-by: ccheung, igor, ohair ! make/common/shared/Sanity.gmk Changeset: 9621edd8118f Author: ngthomas Date: 2011-11-15 23:33 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/9621edd8118f 7112298: remove security baseline sanity check Reviewed-by: ccheung, igor, ohair ! make/common/shared/Sanity.gmk Changeset: b89c77e529b0 Author: cl Date: 2011-12-21 20:03 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/b89c77e529b0 Added tag jdk7u4-b05 for changeset 9621edd8118f ! .hgtags Changeset: 25936ce70254 Author: lana Date: 2011-12-20 14:53 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/25936ce70254 Merge Changeset: 2c1b789d1803 Author: lana Date: 2011-12-23 16:08 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/2c1b789d1803 Merge Changeset: 69304428880a Author: lana Date: 2011-12-28 10:52 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/69304428880a Merge Changeset: eff45ca3391b Author: lana Date: 2011-12-28 13:02 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/eff45ca3391b Merge Changeset: 15b5f3ec1c55 Author: michaelm Date: 2012-01-05 09:27 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/15b5f3ec1c55 Merge ! .hgtags ! make/common/Release.gmk ! make/common/shared/Sanity.gmk ! src/share/classes/sun/awt/SunToolkit.java From michael.x.mcmahon at oracle.com Thu Jan 5 02:21:42 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 05 Jan 2012 10:21:42 +0000 Subject: hg: jdk7u/jdk7u-osx/langtools: 9 new changesets Message-ID: <20120105102216.54E5147895@hg.openjdk.java.net> Changeset: 41a303cb946e Author: dmeetry Date: 2011-12-28 19:40 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/41a303cb946e 7003595: IncompatibleClassChangeError with unreferenced local class with subclass Summary: Compiler omits unreferenced local inner classes from the InnerClasses attribute Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/7003595/T7003595.java + test/tools/javac/7003595/T7003595b.java Changeset: 78d0507580a6 Author: katleman Date: 2011-12-15 09:37 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/78d0507580a6 Added tag jdk7u4-b04 for changeset 358c42289352 ! .hgtags Changeset: 0b858fc21092 Author: katleman Date: 2011-12-14 17:31 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/0b858fc21092 Added tag jdk7u4-b02 for changeset 8556ecc20a5b ! .hgtags Changeset: 62ee502a4649 Author: katleman Date: 2011-12-15 13:02 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/62ee502a4649 Merge ! .hgtags Changeset: 8b3849ab64af Author: cl Date: 2011-12-21 20:03 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/8b3849ab64af Added tag jdk7u4-b05 for changeset 62ee502a4649 ! .hgtags Changeset: 1abcfd1a42a5 Author: lana Date: 2011-12-20 14:54 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/1abcfd1a42a5 Merge Changeset: 083eac71addf Author: lana Date: 2011-12-23 16:09 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/083eac71addf Merge Changeset: c66bb51b9aa7 Author: lana Date: 2011-12-28 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/c66bb51b9aa7 Merge Changeset: c864786394dc Author: michaelm Date: 2012-01-05 09:27 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/c864786394dc Merge ! .hgtags From Alan.Bateman at oracle.com Thu Jan 5 04:51:16 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Jan 2012 12:51:16 +0000 Subject: Review request: 7123679 Update regression tests that use os.name to work on MacOSX In-Reply-To: <4F04EEB5.1020400@oracle.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> <4F04EEB5.1020400@oracle.com> Message-ID: <4F059CC4.9060403@oracle.com> On 05/01/2012 00:28, Kurchi Hazra wrote: > Hi, > > Some test files in jdk/test have behavior defined by what the os.name > property of the system evaluates to. > These changes adds Mac OS X as a recognized OS in a bunch of such test > files. > > In addition, since many tests are failing with the > sun.nio.ch.KQueueSelectorProvider, > the changes also include using sun.nio.ch.PollSelectorProvider as the > DefaultSelector for now > until the kqueue selector is fixed. > > Webrev: > http://cr.openjdk.java.net/~khazra/7123679/webrev.00/ Thanks for following on the tests that use os.name. A couple of comments: test/java/nio/channels/DatagramChannel/Refused.java - the method is onSolarisOrLinux so a bit strange for it to return true when on Mac :-) I think you can get rid of this method as ICMP port unreachable has been reported as a PortUnreachableException on Windows for some times (we no longer support the old editions of Windows where this was an issue). test/java/nio/channels/FileChannel/Size.java (same thing in Transfer.java) - I suspect the comments here are stale (jdk1.4 era) but okay for now. test/java/nio/channels/FileChannel/Write.java - this test was originally a Solaris 64-bit only test. I would suggest ignoring it for now. For some of these older tests we need to remove the os.name checking as they should run on other platforms too. test/java/nio/file/Path/PathOps.java - I think the simplest thing for this test is to remove the check for SunOS/Linux and invoke doUnixTests when not on Windows. test/java/util/zip/ZipFile/ManyZipFiles.java - looks like this is a Windows only test so might be best to just return if os.name doesn't start with "Windows". src/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java. - I think we should should get rid of the Mac specific java.nio.preferSelect property as the standard way to specify it via the java.nio.channels.spi.SelectorProvider property. So I would suggest changing the create method to: public static SelectorProvider create() { return new PollSelectorProvider(); } Once the kqueue Selector is passing all tests then we can change it. That's all I have, Alan. From kumar.x.srinivasan at oracle.COM Thu Jan 5 08:49:31 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 05 Jan 2012 08:49:31 -0800 Subject: [7u4-osx] Request for approval for 7123392 (launcher) fix MacOSX launcher failures Message-ID: <4F05D49B.8030201@oracle.COM> Hi, Please approve, CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123392 Webrev: http://cr.openjdk.java.net/~ksrini/7123392/ Fixes for the launcher tests which fail with MacOSX and OpenJDK, a precursor to the re-factoring launcher work in progress. Thanks Kumar From paul.hohensee at oracle.com Thu Jan 5 09:07:04 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 05 Jan 2012 12:07:04 -0500 Subject: [7u4-osx] Request for approval for 7123392 (launcher) fix MacOSX launcher failures In-Reply-To: <4F05D49B.8030201@oracle.COM> References: <4F05D49B.8030201@oracle.COM> Message-ID: <4F05D8B8.6090501@oracle.com> Approved. Paul On 1/5/12 11:49 AM, Kumar Srinivasan wrote: > Hi, > > Please approve, > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123392 > Webrev: http://cr.openjdk.java.net/~ksrini/7123392/ > > Fixes for the launcher tests which fail with MacOSX and OpenJDK, a > precursor to > the re-factoring launcher work in progress. > > Thanks > Kumar > From kurchi.subhra.hazra at oracle.com Thu Jan 5 12:11:42 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 05 Jan 2012 12:11:42 -0800 Subject: Review request: 7123679 Update regression tests that use os.name to work on MacOSX In-Reply-To: <4F059CC4.9060403@oracle.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> <4F04EEB5.1020400@oracle.com> <4F059CC4.9060403@oracle.com> Message-ID: <4F0603FE.5060003@oracle.com> On 1/5/2012 4:51 AM, Alan Bateman wrote: > On 05/01/2012 00:28, Kurchi Hazra wrote: >> Hi, >> >> Some test files in jdk/test have behavior defined by what the os.name >> property of the system evaluates to. >> These changes adds Mac OS X as a recognized OS in a bunch of such >> test files. >> >> In addition, since many tests are failing with the >> sun.nio.ch.KQueueSelectorProvider, >> the changes also include using sun.nio.ch.PollSelectorProvider as the >> DefaultSelector for now >> until the kqueue selector is fixed. >> >> Webrev: >> http://cr.openjdk.java.net/~khazra/7123679/webrev.00/ > Thanks for following on the tests that use os.name. A couple of comments: > > test/java/nio/channels/DatagramChannel/Refused.java > - the method is onSolarisOrLinux so a bit strange for it to return > true when on Mac :-) I think you can get rid of this method as ICMP > port unreachable has been reported as a PortUnreachableException on > Windows for some times (we no longer support the old editions of > Windows where this was an issue). Hi Alan, Thanks for the review. By method here, did you mean the onSolarisOrLinux() method? The updated webrev is at http://cr.openjdk.java.net/~khazra/7123679/webrev.01/ I changed osName.equals("Mac OS X") to osName.startsWith("Mac OS") to make these tests valid across versions (Thanks to Sandeep for pointing that out). Thanks, Kurchi > > test/java/nio/channels/FileChannel/Size.java (same thing in > Transfer.java) > - I suspect the comments here are stale (jdk1.4 era) but okay for now. > > test/java/nio/channels/FileChannel/Write.java > - this test was originally a Solaris 64-bit only test. I would suggest > ignoring it for now. For some of these older tests we need to remove > the os.name checking as they should run on other platforms too. > > test/java/nio/file/Path/PathOps.java > - I think the simplest thing for this test is to remove the check for > SunOS/Linux and invoke doUnixTests when not on Windows. > > test/java/util/zip/ZipFile/ManyZipFiles.java > - looks like this is a Windows only test so might be best to just > return if os.name doesn't start with "Windows". > > src/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java. > - I think we should should get rid of the Mac specific > java.nio.preferSelect property as the standard way to specify it via > the java.nio.channels.spi.SelectorProvider property. So I would > suggest changing the create method to: > > public static SelectorProvider create() { > return new PollSelectorProvider(); > } > > Once the kqueue Selector is passing all tests then we can change it. > > That's all I have, > > Alan. > > > > > > > > -- -Kurchi From swingler at apple.com Thu Jan 5 13:19:50 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 05 Jan 2012 13:19:50 -0800 Subject: Review request: 7123679 Update regression tests that use os.name to work on MacOSX In-Reply-To: <4F0603FE.5060003@oracle.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> <4F04EEB5.1020400@oracle.com> <4F059CC4.9060403@oracle.com> <4F0603FE.5060003@oracle.com> Message-ID: <9DD5C3BB-8A63-4496-8711-B86EEF6246FB@apple.com> On Jan 5, 2012, at 12:11 PM, Kurchi Hazra wrote: > I changed osName.equals("Mac OS X") to osName.startsWith("Mac OS") to make these tests valid across versions (Thanks to Sandeep for pointing that out). This is particularly important on the server versions which report themselves as "Mac OS X Server". :-) Regards, Mike Swingler Apple Inc. From Alan.Bateman at oracle.com Thu Jan 5 13:29:38 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Jan 2012 21:29:38 +0000 Subject: Review request: 7123679 Update regression tests that use os.name to work on MacOSX In-Reply-To: <4F0603FE.5060003@oracle.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> <4F04EEB5.1020400@oracle.com> <4F059CC4.9060403@oracle.com> <4F0603FE.5060003@oracle.com> Message-ID: <4F061642.8020505@oracle.com> On 05/01/2012 20:11, Kurchi Hazra wrote: > > : > > Hi Alan, > > > Thanks for the review. By method here, did you mean the > onSolarisOrLinux() method? > > The updated webrev is at > http://cr.openjdk.java.net/~khazra/7123679/webrev.01/ > > I changed osName.equals("Mac OS X") to osName.startsWith("Mac OS") to > make these tests valid across versions (Thanks to Sandeep for pointing > that out). > This looks much better. Minor nit in PathOps.java where L994 should be "} else {". In DefaultSelectorProvider.java it looks like there are now unused imports that can be removed. -Alan. From Alan.Bateman at oracle.com Thu Jan 5 13:34:40 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Jan 2012 21:34:40 +0000 Subject: Review request: 7123679 Update regression tests that use os.name to work on MacOSX In-Reply-To: <9DD5C3BB-8A63-4496-8711-B86EEF6246FB@apple.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> <4F04EEB5.1020400@oracle.com> <4F059CC4.9060403@oracle.com> <4F0603FE.5060003@oracle.com> <9DD5C3BB-8A63-4496-8711-B86EEF6246FB@apple.com> Message-ID: <4F061770.7090207@oracle.com> On 05/01/2012 21:19, Mike Swingler wrote: > On Jan 5, 2012, at 12:11 PM, Kurchi Hazra wrote: > >> I changed osName.equals("Mac OS X") to osName.startsWith("Mac OS") to make these tests valid across versions (Thanks to Sandeep for pointing that out). > This is particularly important on the server versions which report themselves as "Mac OS X Server". :-) > This might be a dumb question but it looks like the value of os.name/os.version comes from /System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/JavaRuntimeSupport - what is that library? -Alan From kurchi.subhra.hazra at oracle.com Thu Jan 5 14:01:35 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 05 Jan 2012 14:01:35 -0800 Subject: Review request: 7123679 Update regression tests that use os.name to work on MacOSX In-Reply-To: <4F061642.8020505@oracle.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> <4F04EEB5.1020400@oracle.com> <4F059CC4.9060403@oracle.com> <4F0603FE.5060003@oracle.com> <4F061642.8020505@oracle.com> Message-ID: <4F061DBF.6080702@oracle.com> >> > This looks much better. > > Minor nit in PathOps.java where L994 should be "} else {". > > In DefaultSelectorProvider.java it looks like there are now unused > imports that can be removed. Updated webrev: http://cr.openjdk.java.net/~khazra/7123679/webrev.02/ Thanks, Kurchi > > -Alan. > > -- -Kurchi From kurchi.subhra.hazra at oracle.com Thu Jan 5 14:09:27 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 05 Jan 2012 14:09:27 -0800 Subject: Review request: 7127199 test/com/sun/jdi/ShellScaffold.sh needs to include Darwin as a recognized platform In-Reply-To: <4F04EEB5.1020400@oracle.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> <4F04EEB5.1020400@oracle.com> Message-ID: <4F061F97.9000303@oracle.com> Hi, This is a minor change to update the schell script test/com/sun/jdi/ShellScaffold.sh to include Darwin as a platform. Webrev : http://cr.openjdk.java.net/~khazra/7127199/webrev.00/ Thanks, Kurchi From kumar.x.srinivasan at oracle.com Thu Jan 5 14:15:56 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 05 Jan 2012 22:15:56 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7123392: (launcher) fix MacOSX launcher failures Message-ID: <20120105221607.2D942478AA@hg.openjdk.java.net> Changeset: d291e5d9733b Author: ksrini Date: 2012-01-05 10:13 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d291e5d9733b 7123392: (launcher) fix MacOSX launcher failures Reviewed-by: phh ! test/tools/launcher/ChangeDataModel.sh ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java ! test/tools/launcher/VersionCheck.java From daniel.daugherty at oracle.com Thu Jan 5 14:44:59 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 05 Jan 2012 15:44:59 -0700 Subject: Review request: 7127199 test/com/sun/jdi/ShellScaffold.sh needs to include Darwin as a recognized platform In-Reply-To: <4F061F97.9000303@oracle.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> <4F04EEB5.1020400@oracle.com> <4F061F97.9000303@oracle.com> Message-ID: <4F0627EB.3060302@oracle.com> Thumbs up. Dan On 1/5/12 3:09 PM, Kurchi Hazra wrote: > Hi, > > This is a minor change to update the schell script > test/com/sun/jdi/ShellScaffold.sh to > include Darwin as a platform. > > Webrev : http://cr.openjdk.java.net/~khazra/7127199/webrev.00/ > > Thanks, > Kurchi From daniel.daugherty at oracle.com Thu Jan 5 14:51:54 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 05 Jan 2012 15:51:54 -0700 Subject: Review request: 7127199 test/com/sun/jdi/ShellScaffold.sh needs to include Darwin as a recognized platform In-Reply-To: <4F0627EB.3060302@oracle.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> <4F04EEB5.1020400@oracle.com> <4F061F97.9000303@oracle.com> <4F0627EB.3060302@oracle.com> Message-ID: <4F06298A.7040108@oracle.com> This one puzzled me since I hadn't seen any failures due to ShellScaffold.sh in my own testing on MacOS X. I checked my results archive and no failures. So I checked the testbase and this bug is fixed in macosx-port/jdk. So why is this broken again in jdk7u-osx/jdk? Dan On 1/5/12 3:44 PM, Daniel D. Daugherty wrote: > Thumbs up. > > Dan > > > On 1/5/12 3:09 PM, Kurchi Hazra wrote: >> Hi, >> >> This is a minor change to update the schell script >> test/com/sun/jdi/ShellScaffold.sh to >> include Darwin as a platform. >> >> Webrev : http://cr.openjdk.java.net/~khazra/7127199/webrev.00/ >> >> Thanks, >> Kurchi From kurchi.subhra.hazra at oracle.com Thu Jan 5 15:06:03 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 05 Jan 2012 15:06:03 -0800 Subject: Review request: 7127199 test/com/sun/jdi/ShellScaffold.sh needs to include Darwin as a recognized platform In-Reply-To: <4F06298A.7040108@oracle.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> <4F04EEB5.1020400@oracle.com> <4F061F97.9000303@oracle.com> <4F0627EB.3060302@oracle.com> <4F06298A.7040108@oracle.com> Message-ID: <4F062CDB.7080308@oracle.com> I checked and found the same thing, but I do not know why. Michael: do you know? - Kurchi On 1/5/2012 2:51 PM, Daniel D. Daugherty wrote: > This one puzzled me since I hadn't seen any failures due to > ShellScaffold.sh in my own testing on MacOS X. I checked my > results archive and no failures. So I checked the testbase > and this bug is fixed in macosx-port/jdk. > > So why is this broken again in jdk7u-osx/jdk? > > Dan > > > > On 1/5/12 3:44 PM, Daniel D. Daugherty wrote: >> Thumbs up. >> >> Dan >> >> >> On 1/5/12 3:09 PM, Kurchi Hazra wrote: >>> Hi, >>> >>> This is a minor change to update the schell script >>> test/com/sun/jdi/ShellScaffold.sh to >>> include Darwin as a platform. >>> >>> Webrev : http://cr.openjdk.java.net/~khazra/7127199/webrev.00/ >>> >>> Thanks, >>> Kurchi -- -Kurchi From Alan.Bateman at oracle.com Fri Jan 6 01:31:23 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Jan 2012 09:31:23 +0000 Subject: Review request: 7127199 test/com/sun/jdi/ShellScaffold.sh needs to include Darwin as a recognized platform In-Reply-To: <4F06298A.7040108@oracle.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> <4F04EEB5.1020400@oracle.com> <4F061F97.9000303@oracle.com> <4F0627EB.3060302@oracle.com> <4F06298A.7040108@oracle.com> Message-ID: <4F06BF6B.8050005@oracle.com> On 05/01/2012 22:51, Daniel D. Daugherty wrote: > This one puzzled me since I hadn't seen any failures due to > ShellScaffold.sh in my own testing on MacOS X. I checked my > results archive and no failures. So I checked the testbase > and this bug is fixed in macosx-port/jdk. > > So why is this broken again in jdk7u-osx/jdk? When Michael brought the changes from macosx-port/macosx-port/jdk to jdk7u/jdk7u-osx/jdk then it didn't include the test changes. This was discussed on the list at the time and the test changes were to follow. Kurchi is working on this now so hopefully soon all the tests will be able to run on Mac too. -Alan. From Alan.Bateman at oracle.com Fri Jan 6 02:03:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Jan 2012 10:03:25 +0000 Subject: Review request: 7123679 Update regression tests that use os.name to work on MacOSX In-Reply-To: <4F061DBF.6080702@oracle.com> References: <4EE8FB87.8000004@oracle.com> <4EE8FEE2.2040303@oracle.com> <4EE90DBB.6010801@oracle.com> <4F04EEB5.1020400@oracle.com> <4F059CC4.9060403@oracle.com> <4F0603FE.5060003@oracle.com> <4F061642.8020505@oracle.com> <4F061DBF.6080702@oracle.com> Message-ID: <4F06C6ED.4030501@oracle.com> On 05/01/2012 22:01, Kurchi Hazra wrote: > > Updated webrev: > http://cr.openjdk.java.net/~khazra/7123679/webrev.02/ Thumbs up from me. Is Michael going to push this for you? -Alan From henri.gomez at gmail.com Fri Jan 6 04:01:46 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 6 Jan 2012 13:01:46 +0100 Subject: jdk7u-osx tag number Message-ID: Mercurial tags for jdk7u-osx (http://hg.openjdk.java.net/jdk7u/jdk7u-osx) bump from jdk7u4-b04 to jdk7u4-b200 and now jdk7u4-b05 ? jdk7u4-b05 396:a15712a2304e jdk7u4-b200 392:25457f672756 jdk7u4-b04 391:bcc37b8ac1b0 jdk7u4-b200 was a mistake ? From kelly.ohair at oracle.com Fri Jan 6 10:26:44 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 6 Jan 2012 10:26:44 -0800 Subject: jdk7u-osx tag number In-Reply-To: References: Message-ID: Someone should edit the .hgtags file and get rid of this. -kto On Jan 6, 2012, at 4:01 AM, Henri Gomez wrote: > Mercurial tags for jdk7u-osx (http://hg.openjdk.java.net/jdk7u/jdk7u-osx) > bump from jdk7u4-b04 to jdk7u4-b200 and now jdk7u4-b05 ? > > jdk7u4-b05 396:a15712a2304e > jdk7u4-b200 392:25457f672756 > jdk7u4-b04 391:bcc37b8ac1b0 > > jdk7u4-b200 was a mistake ? From daniel.daugherty at oracle.com Fri Jan 6 11:08:33 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 06 Jan 2012 12:08:33 -0700 Subject: jdk7u-osx tag number In-Reply-To: References: Message-ID: <4F0746B1.20005@oracle.com> b200 was a special build done by RE. I would check with David K before deleting that tag... Dan On 1/6/12 11:26 AM, Kelly O'Hair wrote: > Someone should edit the .hgtags file and get rid of this. > > -kto > > On Jan 6, 2012, at 4:01 AM, Henri Gomez wrote: > >> Mercurial tags for jdk7u-osx (http://hg.openjdk.java.net/jdk7u/jdk7u-osx) >> bump from jdk7u4-b04 to jdk7u4-b200 and now jdk7u4-b05 ? >> >> jdk7u4-b05 396:a15712a2304e >> jdk7u4-b200 392:25457f672756 >> jdk7u4-b04 391:bcc37b8ac1b0 >> >> jdk7u4-b200 was a mistake ? From kurchi.subhra.hazra at oracle.com Fri Jan 6 12:24:42 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Fri, 06 Jan 2012 12:24:42 -0800 Subject: [7u4-osx] Request for approval for 7127199: [macosx] test/com/sun/jdi/ShellScaffold.sh needs to include Darwin as a recognized platform Message-ID: <4F07588A.9020509@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127199 Webrev: http://cr.openjdk.java.net/~khazra/7127199/webrev.00/ Reviewed by: dcubed, alanb This changeset will be pushed on my behalf by Michael McMahon (michaelm). Thanks, Kurchi From paul.hohensee at oracle.com Fri Jan 6 12:36:14 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 06 Jan 2012 15:36:14 -0500 Subject: [7u4-osx] Request for approval for 7127199: [macosx] test/com/sun/jdi/ShellScaffold.sh needs to include Darwin as a recognized platform In-Reply-To: <4F07588A.9020509@oracle.com> References: <4F07588A.9020509@oracle.com> Message-ID: <4F075B3E.1050709@oracle.com> Approved. Paul On 1/6/12 3:24 PM, Kurchi Hazra wrote: > > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127199 > > Webrev: http://cr.openjdk.java.net/~khazra/7127199/webrev.00/ > > Reviewed by: dcubed, alanb > > This changeset will be pushed on my behalf by Michael McMahon (michaelm). > > Thanks, > Kurchi From roger.yeung at oracle.com Fri Jan 6 14:56:17 2012 From: roger.yeung at oracle.com (Roger Yeung) Date: Fri, 06 Jan 2012 14:56:17 -0800 Subject: No Java Mac Port Promotion This Week Message-ID: <4F077C11.8010107@oracle.com> We are working on upgrading our build machines and will not have a Java Mac Port promotion this week. The next promotion will resume early next week. Thanks, Roger Y. From jhuxhorn at googlemail.com Sat Jan 7 06:08:27 2012 From: jhuxhorn at googlemail.com (Joern Huxhorn) Date: Sat, 7 Jan 2012 15:08:27 +0100 Subject: I tried my app with the current build and found some issues Message-ID: I don't know if those are new to you but when I start Lilith ( http://lilith.huxhorn.de ) I get the following error during startup: 2012-01-07 14:28:36.380 java[17379:407] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil 2012-01-07 14:28:36.390 java[17379:407] ( 0 CoreFoundation 0x00007fff91e44286 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x00007fff9527cd5e objc_exception_throw + 43 2 CoreFoundation 0x00007fff91deb108 -[__NSArrayM insertObject:atIndex:] + 296 3 AppKit 0x00007fff895a4109 -[NSMenu insertItem:atIndex:] + 478 4 liblwawt.dylib 0x0000000113517c14 addMenuItem + 185 5 liblwawt.dylib 0x0000000113517905 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 6 liblwawt.dylib 0x0000000113517ee1 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 227 7 JavaNativeFoundation 0x00000001127595fd +[JNFRunLoop _performCopiedBlock:] + 20 8 CoreFoundation 0x00007fff91e6e0cd +[NSObject performSelector:withObject:] + 61 9 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 10 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 11 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 12 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 13 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 14 HIToolbox 0x00007fff8dd6d3d3 RunCurrentEventLoopInMode + 277 15 HIToolbox 0x00007fff8dd7463d ReceiveNextEventCommon + 355 16 HIToolbox 0x00007fff8dd744ca BlockUntilNextEventMatchingListInMode + 62 17 AppKit 0x00007fff8958d3f1 _DPSNextEvent + 659 18 AppKit 0x00007fff8958ccf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 19 libosxapp.dylib 0x000000011327882c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 20 AppKit 0x00007fff8958962d -[NSApplication run] + 470 21 libosxapp.dylib 0x000000011327874b +[NSApplicationAWT runAWTLoopWithApp:] + 156 22 liblwawt.dylib 0x0000000113515dad -[AWTStarter starter:] + 1616 23 CoreFoundation 0x00007fff91e33a1d -[NSObject performSelector:withObject:] + 61 24 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 25 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 26 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 27 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 28 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 29 java 0x000000010d93dcb4 CreateExecutionEnvironment + 841 30 java 0x000000010d93b7b8 JLI_Launch + 1933 31 java 0x000000010d93fa30 main + 108 32 java 0x000000010d9393f4 start + 52 33 ??? 0x0000000000000008 0x0 + 8 ) 2012-01-07 14:28:36.391 java[17379:407] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil 2012-01-07 14:28:36.397 java[17379:407] ( 0 CoreFoundation 0x00007fff91e44286 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x00007fff9527cd5e objc_exception_throw + 43 2 CoreFoundation 0x00007fff91deb108 -[__NSArrayM insertObject:atIndex:] + 296 3 AppKit 0x00007fff895a4109 -[NSMenu insertItem:atIndex:] + 478 4 liblwawt.dylib 0x0000000113517c14 addMenuItem + 185 5 liblwawt.dylib 0x0000000113517905 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 6 liblwawt.dylib 0x0000000113517ee1 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 227 7 JavaNativeFoundation 0x00000001127595fd +[JNFRunLoop _performCopiedBlock:] + 20 8 CoreFoundation 0x00007fff91e6e0cd +[NSObject performSelector:withObject:] + 61 9 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 10 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 11 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 12 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 13 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 14 HIToolbox 0x00007fff8dd6d3d3 RunCurrentEventLoopInMode + 277 15 HIToolbox 0x00007fff8dd7458f ReceiveNextEventCommon + 181 16 HIToolbox 0x00007fff8dd744ca BlockUntilNextEventMatchingListInMode + 62 17 AppKit 0x00007fff8958d3f1 _DPSNextEvent + 659 18 AppKit 0x00007fff8958ccf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 19 libosxapp.dylib 0x000000011327882c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 20 AppKit 0x00007fff8958962d -[NSApplication run] + 470 21 libosxapp.dylib 0x000000011327874b +[NSApplicationAWT runAWTLoopWithApp:] + 156 22 liblwawt.dylib 0x0000000113515dad -[AWTStarter starter:] + 1616 23 CoreFoundation 0x00007fff91e33a1d -[NSObject performSelector:withObject:] + 61 24 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 25 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 26 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 27 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 28 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 29 java 0x000000010d93dcb4 CreateExecutionEnvironment + 841 30 java 0x000000010d93b7b8 JLI_Launch + 1933 31 java 0x000000010d93fa30 main + 108 32 java 0x000000010d9393f4 start + 52 33 ??? 0x0000000000000008 0x0 + 8 ) Additionally, I saw that the accelerators are displayed as Meta instead of the Command symbol ( ⌘ ). It also appears like something is wrong with java.util.preferences, i.e. it just doesn't work/save preferences. Hope this helps, Joern. From james.melvin at oracle.com Sat Jan 7 08:38:46 2012 From: james.melvin at oracle.com (James Melvin) Date: Sat, 07 Jan 2012 11:38:46 -0500 Subject: RFR (S): 7125793: MAC: test_gamma should always work In-Reply-To: <4F034B51.3070609@oracle.com> References: <4EFECA5D.6010905@oracle.com> <4F034B51.3070609@oracle.com> Message-ID: <4F087516.40505@oracle.com> Hi Dan, Finally getting back on the trail to fix the gamma launcher. Sorry for the delayed response. Thanks for the review, Dan and David. Replies inline... On 1/3/12 1:39 PM, Daniel D. Daugherty wrote: >> http://cr.openjdk.java.net/~jmelvin/7125793/webrev.00 > > Jim, > > Thanks for diving in and improving the MacOS X port! > Comments below. > > Dan > > > make/bsd/makefiles/buildtree.make > > line 422: The new 'java -fullversion' invocation does not include > the $(JAVA_FLAG) option like the old code did. Any particular > reason for the change? > > Looks like that means the '-d32' or '-d64' options won't be > specified as they were before. Originally, this no longer made sense as both -d32 and -d64 were mapped to 64-bit. After further review, I'm going to readd this option in case we ever change our minds and decide to support both 32 and 64-bit JVMs on Mac OS X. > > line 447: Why not just echo FULL_VERSION? Why pipe to awk? To preserve the original script output, I needed to trim the extra newline... 1 from $FULLVERSION and 1 from echo. > > line 465: The 'jre/lib/libjava.dylib' part of the new check is > MacOS X specific. Other BSDs don't necessarily use the > '.dylib' extension (instead of .so) and I don't think that > other BSDs have dropped the "arch" subdir. To be more friendly to other BSDs, I've added a $(LIBARCH) subdir check and $(LIBRARY_SUFFIX) instead of hardcoded .dylib. However, I really don't have a way of testing this for those other BSDs. > > line 484: The DYLD_LIBRARY_PATH part is MacOS X specific. Will > still need to set LD_LIBRARY_PATH for other BSDs. Also, a good point. I've re-added LD_LIBRARY_PATH with it's original setting. > > line 492: You switched from $(TESTFLAGS) to literal flag values, > but you left the TESTFLAGS variable around. Any reason for > the switch? Nice find. Cut-paste overwrite. Fixed by restoring $(TESTFLAGS). > > > make/bsd/makefiles/launcher.make > Please add a comment explaining why '-framework CoreFoundation' > is needed. Your explanatory block below is a really good start. Done. > > > make/bsd/makefiles/vm.make > No comments. > > > src/os/bsd/vm/os_bsd.cpp > line 2585: Uses a suffix of ".so". That shouldn't work on MacOS X > since MacOS X uses '.dylib'. That's OK for other BSDs, but not > MacOS X. Also the comments that mention '.so' should be updated > to include '.dylib' (not caused by your changes). I've replaced .so with $JNI_LIB_SUFFIX defined earlier in the source. In the area comments, I've just dropped .so extension altogether to cheaply ambiguate. > > To David H. - Yes, this change added another '#fdef __APPLE__'. It > is not the first and it likely won't be the last since we're > not done yet with the MacOS X port. There are a number of > things that need to be cleaned up and we're tracking them. > However, as you know, we don't have enough folks to handle all > of the work so we'll just have to live with the warts for now. For this particular change to fix gamma, I've managed to resolve David's concerns by adding support for no-arch paths in the code rather than using #ifdefs. However, ifdefs are sprinkled everywhere and this will need to be resolved whenever we reconcile the unix platforms into a more common codebase. > > src/os/posix/launcher/java_md.c > No comments. > Thanks for the review comments. I've also added a 1 line change in make/bsd/makefiles/defs.make to fix a build warning around duplicate targets for Xusage.txt due to a variable expansion. This has already been resolved for other platforms. Changes included in new webrev. More feedback welcome. WEBREV: http://cr.openjdk.java.net/~jmelvin/7125793/webrev.01 TESTS RUN: JPRT 2012-01-07-064433.jmelvin.7125793 local Mac OS X builds/tests - Jim > > On 12/31/11 1:39 AM, James Melvin wrote: >> Hi, >> >> This change fixes the 'gamma' simple launcher for HotSpot on Mac OS X. >> There were 3 primary changes required to re-enable gamma... >> >> 1) Statically link with CoreFoundation framework to resolve symbols >> >> The gamma launcher dlopen()s libjava.dylib from $JAVA_HOME/jre/lib. >> Because Mac OS X files are case-insensitive by default, we collide on >> $FRAMEWORK/libJPEG.dylib and ${JAVA_HOME}/jre/lib/libjpeg.dylib. This >> resulted in unresolved symbols in the Mac OS X framework libraries. The >> solution for gamma was to statically link with CoreFoundation framework >> to properly resolve framework symbols and allow gamma to successfully >> dlopen() libjava.dylib. >> >> 2) Adjust various paths to reflect no arch subdirs >> >> On Mac OS X, there are no arch subdirs, e.g jre/lib vs jre/lib/. >> Instead, one can use universal binaries to package multiple >> architectures in a single binary. At the moment though, we are only >> building 64-bit non-universal binaries. Note, the test_gamma script >> assumes an Oracle JDK layout for JAVA_HOME, derived from ALT_BOOTDIR. >> Using an Apple JDK for ALT_BOOTDIR will fail the test_gamma script >> gracefully, as libjava.dylib is in a different, unexpected place. >> >> 3) Modify test_gamma script to set library path only for gamma launch >> >> Setting DYLD_LIBRARY_PATH adversely affects the real java launcher(s). >> Instead, set this later in the script only for the gamma launcher test >> run. While in there, I took the liberty of decrypting the script to make >> it more maintainable and more easily merged whenever we reconcile the >> unix ports into a single codebase. There is no change to the script >> output. >> >> Feedback welcome... >> >> WEBREV: >> http://cr.openjdk.java.net/~jmelvin/7125793/webrev.00 >> >> TESTS RUN: >> JPRT 2011-12-31-061123.jmelvin.7125793 >> local Mac OS X builds/tests >> >> >> Thanks and Happy New Year! >> >> Jim From david.holmes at oracle.com Sun Jan 8 15:51:19 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Jan 2012 09:51:19 +1000 Subject: RFR (S): 7125793: MAC: test_gamma should always work In-Reply-To: <4F087516.40505@oracle.com> References: <4EFECA5D.6010905@oracle.com> <4F034B51.3070609@oracle.com> <4F087516.40505@oracle.com> Message-ID: <4F0A2BF7.8060903@oracle.com> Thanks Jim, I'm much happier now. David ----- On 8/01/2012 2:38 AM, James Melvin wrote: > Hi Dan, > > Finally getting back on the trail to fix the gamma launcher. Sorry for > the delayed response. Thanks for the review, Dan and David. Replies > inline... > > > On 1/3/12 1:39 PM, Daniel D. Daugherty wrote: >>> http://cr.openjdk.java.net/~jmelvin/7125793/webrev.00 >> >> Jim, >> >> Thanks for diving in and improving the MacOS X port! >> Comments below. >> >> Dan >> >> >> make/bsd/makefiles/buildtree.make >> >> line 422: The new 'java -fullversion' invocation does not include >> the $(JAVA_FLAG) option like the old code did. Any particular >> reason for the change? >> >> Looks like that means the '-d32' or '-d64' options won't be >> specified as they were before. > > Originally, this no longer made sense as both -d32 and -d64 were mapped > to 64-bit. After further review, I'm going to readd this option in case > we ever change our minds and decide to support both 32 and 64-bit JVMs > on Mac OS X. > > >> >> line 447: Why not just echo FULL_VERSION? Why pipe to awk? > > To preserve the original script output, I needed to trim the extra > newline... 1 from $FULLVERSION and 1 from echo. > >> >> line 465: The 'jre/lib/libjava.dylib' part of the new check is >> MacOS X specific. Other BSDs don't necessarily use the >> '.dylib' extension (instead of .so) and I don't think that >> other BSDs have dropped the "arch" subdir. > > To be more friendly to other BSDs, I've added a $(LIBARCH) subdir check > and $(LIBRARY_SUFFIX) instead of hardcoded .dylib. However, I really > don't have a way of testing this for those other BSDs. > >> >> line 484: The DYLD_LIBRARY_PATH part is MacOS X specific. Will >> still need to set LD_LIBRARY_PATH for other BSDs. > > Also, a good point. I've re-added LD_LIBRARY_PATH with it's original > setting. > >> >> line 492: You switched from $(TESTFLAGS) to literal flag values, >> but you left the TESTFLAGS variable around. Any reason for >> the switch? > > Nice find. Cut-paste overwrite. Fixed by restoring $(TESTFLAGS). > >> >> >> make/bsd/makefiles/launcher.make >> Please add a comment explaining why '-framework CoreFoundation' >> is needed. Your explanatory block below is a really good start. > > Done. > >> >> >> make/bsd/makefiles/vm.make >> No comments. >> >> >> src/os/bsd/vm/os_bsd.cpp >> line 2585: Uses a suffix of ".so". That shouldn't work on MacOS X >> since MacOS X uses '.dylib'. That's OK for other BSDs, but not >> MacOS X. Also the comments that mention '.so' should be updated >> to include '.dylib' (not caused by your changes). > > I've replaced .so with $JNI_LIB_SUFFIX defined earlier in the source. > In the area comments, I've just dropped .so extension altogether to > cheaply ambiguate. > >> >> To David H. - Yes, this change added another '#fdef __APPLE__'. It >> is not the first and it likely won't be the last since we're >> not done yet with the MacOS X port. There are a number of >> things that need to be cleaned up and we're tracking them. >> However, as you know, we don't have enough folks to handle all >> of the work so we'll just have to live with the warts for now. > > For this particular change to fix gamma, I've managed to resolve David's > concerns by adding support for no-arch paths in the code rather than > using #ifdefs. However, ifdefs are sprinkled everywhere and this will > need to be resolved whenever we reconcile the unix platforms into a more > common codebase. > > >> >> src/os/posix/launcher/java_md.c >> No comments. >> > > Thanks for the review comments. I've also added a 1 line change in > make/bsd/makefiles/defs.make to fix a build warning around duplicate > targets for Xusage.txt due to a variable expansion. This has already > been resolved for other platforms. > > > Changes included in new webrev. More feedback welcome. > > WEBREV: > http://cr.openjdk.java.net/~jmelvin/7125793/webrev.01 > > TESTS RUN: > JPRT 2012-01-07-064433.jmelvin.7125793 > local Mac OS X builds/tests > > > - Jim > > >> >> On 12/31/11 1:39 AM, James Melvin wrote: >>> Hi, >>> >>> This change fixes the 'gamma' simple launcher for HotSpot on Mac OS X. >>> There were 3 primary changes required to re-enable gamma... >>> >>> 1) Statically link with CoreFoundation framework to resolve symbols >>> >>> The gamma launcher dlopen()s libjava.dylib from $JAVA_HOME/jre/lib. >>> Because Mac OS X files are case-insensitive by default, we collide on >>> $FRAMEWORK/libJPEG.dylib and ${JAVA_HOME}/jre/lib/libjpeg.dylib. This >>> resulted in unresolved symbols in the Mac OS X framework libraries. The >>> solution for gamma was to statically link with CoreFoundation framework >>> to properly resolve framework symbols and allow gamma to successfully >>> dlopen() libjava.dylib. >>> >>> 2) Adjust various paths to reflect no arch subdirs >>> >>> On Mac OS X, there are no arch subdirs, e.g jre/lib vs jre/lib/. >>> Instead, one can use universal binaries to package multiple >>> architectures in a single binary. At the moment though, we are only >>> building 64-bit non-universal binaries. Note, the test_gamma script >>> assumes an Oracle JDK layout for JAVA_HOME, derived from ALT_BOOTDIR. >>> Using an Apple JDK for ALT_BOOTDIR will fail the test_gamma script >>> gracefully, as libjava.dylib is in a different, unexpected place. >>> >>> 3) Modify test_gamma script to set library path only for gamma launch >>> >>> Setting DYLD_LIBRARY_PATH adversely affects the real java launcher(s). >>> Instead, set this later in the script only for the gamma launcher test >>> run. While in there, I took the liberty of decrypting the script to make >>> it more maintainable and more easily merged whenever we reconcile the >>> unix ports into a single codebase. There is no change to the script >>> output. >>> >>> Feedback welcome... >>> >>> WEBREV: >>> http://cr.openjdk.java.net/~jmelvin/7125793/webrev.00 >>> >>> TESTS RUN: >>> JPRT 2011-12-31-061123.jmelvin.7125793 >>> local Mac OS X builds/tests >>> >>> >>> Thanks and Happy New Year! >>> >>> Jim From peter.brunet at oracle.com Sun Jan 8 17:52:52 2012 From: peter.brunet at oracle.com (Pete Brunet) Date: Sun, 08 Jan 2012 19:52:52 -0600 Subject: Patch for review - fixes hangs when VoiceOver is active In-Reply-To: <4EF476EE.6090107@oracle.com> References: <4EF0B7CD.9060901@oracle.com> <4EF1AA74.8000204@oracle.com> <4EF2021C.2060805@oracle.com> <4EF476EE.6090107@oracle.com> Message-ID: <4F0A4874.10002@oracle.com> I haven't seen any responses to this request. What needs to be done so this fix can go into a build? -Pete On 12/23/11 6:41 AM, Artem Ananiev wrote: > Hi, team, > > as Pete doesn't have access to cr.openjdk.java.net yet and therefore > can't put the webrev there, I have published the patch here: > > http://cr.openjdk.java.net/~art/macosx-port/mac_voiceover_hangs/ > > Please, bear in mind I'm not the author of the fix, so address all the > questions to Pete :) > > Thanks, > > Artem > > On 12/21/2011 7:58 PM, Pete Brunet wrote: >> Hi Artem, Apparently the list manager stripped off my zip file. Should >> I upload it somewhere? -Pete >> >> On 12/21/11 3:44 AM, Artem Ananiev wrote: >>> >>> Did you forget to attach the patch? :) >>> >>> Thanks, >>> >>> Artem >>> >>> On 12/20/2011 8:29 PM, Pete Brunet wrote: >>>> The attached patch was created by Kevin Miller, reviewed by Mike >>>> Swingler, and tested by me. >>>> >>>> This patch will fix the following bugs: >>>> http://java.net/jira/browse/MACOSX_PORT-630 >>>> http://java.net/jira/browse/MACOSX_PORT-644 >>>> http://java.net/jira/browse/MACOSX_PORT-646 >>>> >>>> It also includes a fix to a bug in an NSLog that I noticed when doing >>>> some other debugging. >>>> >>>> Please review. >>>> >>>> Also, is there any information missing or something else I should have >>>> done in the process of creating the patch? >>>> >>>> Pete From alexander.zuev at oracle.com Mon Jan 9 06:33:08 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 9 Jan 2012 18:33:08 +0400 Subject: Patch for review - fixes hangs when VoiceOver is active In-Reply-To: <4F0A4874.10002@oracle.com> References: <4EF0B7CD.9060901@oracle.com> <4EF1AA74.8000204@oracle.com> <4EF2021C.2060805@oracle.com> <4EF476EE.6090107@oracle.com> <4F0A4874.10002@oracle.com> Message-ID: Pete, Most of the people who should review your fix lives in Russia and we have long holiday break. We will be at office tomorrow jan.10th. As for me - fix looks ok. With best regards, Alexander Zuev 09.01.2012, ? 5:52, Pete Brunet ???????(?): > I haven't seen any responses to this request. What needs to be done so > this fix can go into a build? -Pete > > On 12/23/11 6:41 AM, Artem Ananiev wrote: >> Hi, team, >> >> as Pete doesn't have access to cr.openjdk.java.net yet and therefore >> can't put the webrev there, I have published the patch here: >> >> http://cr.openjdk.java.net/~art/macosx-port/mac_voiceover_hangs/ >> >> Please, bear in mind I'm not the author of the fix, so address all the >> questions to Pete :) >> >> Thanks, >> >> Artem >> >> On 12/21/2011 7:58 PM, Pete Brunet wrote: >>> Hi Artem, Apparently the list manager stripped off my zip file. Should >>> I upload it somewhere? -Pete >>> >>> On 12/21/11 3:44 AM, Artem Ananiev wrote: >>>> >>>> Did you forget to attach the patch? :) >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 12/20/2011 8:29 PM, Pete Brunet wrote: >>>>> The attached patch was created by Kevin Miller, reviewed by Mike >>>>> Swingler, and tested by me. >>>>> >>>>> This patch will fix the following bugs: >>>>> http://java.net/jira/browse/MACOSX_PORT-630 >>>>> http://java.net/jira/browse/MACOSX_PORT-644 >>>>> http://java.net/jira/browse/MACOSX_PORT-646 >>>>> >>>>> It also includes a fix to a bug in an NSLog that I noticed when doing >>>>> some other debugging. >>>>> >>>>> Please review. >>>>> >>>>> Also, is there any information missing or something else I should have >>>>> done in the process of creating the patch? >>>>> >>>>> Pete From michael.x.mcmahon at oracle.com Mon Jan 9 08:03:30 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 09 Jan 2012 16:03:30 +0000 Subject: Code review request: 7127660 (macosx) *Socket Async close not working Message-ID: <4F0B0FD2.60104@oracle.com> Could I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ The asynchronous close mechanism was not being compiled for Mac OS. Also, the pthread mutexes used by this code, need to be explicitly initialized on Mac, which was not being done previously (on Linux). Thanks, Michael. From Alan.Bateman at oracle.com Mon Jan 9 08:15:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 09 Jan 2012 16:15:54 +0000 Subject: Code review request: 7127660 (macosx) *Socket Async close not working In-Reply-To: <4F0B0FD2.60104@oracle.com> References: <4F0B0FD2.60104@oracle.com> Message-ID: <4F0B12BA.5000408@oracle.com> On 09/01/2012 16:03, Michael McMahon wrote: > Could I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ > > The asynchronous close mechanism was not being compiled for Mac OS. > Also, the pthread mutexes used by this code, need to be explicitly > initialized > on Mac, which was not being done previously (on Linux). This looks okay to me. Do you also need to changes in src/solaris/native/sun/nio/ch/NativeThread.c? -Alan. From michael.x.mcmahon at oracle.com Mon Jan 9 08:26:26 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 09 Jan 2012 16:26:26 +0000 Subject: Code review request: 7127660 (macosx) *Socket Async close not working In-Reply-To: <4F0B12BA.5000408@oracle.com> References: <4F0B0FD2.60104@oracle.com> <4F0B12BA.5000408@oracle.com> Message-ID: <4F0B1532.4010809@oracle.com> On 09/01/12 16:15, Alan Bateman wrote: > On 09/01/2012 16:03, Michael McMahon wrote: >> Could I get the following change reviewed please? >> >> http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ >> >> The asynchronous close mechanism was not being compiled for Mac OS. >> Also, the pthread mutexes used by this code, need to be explicitly >> initialized >> on Mac, which was not being done previously (on Linux). > This looks okay to me. Do you also need to changes in > src/solaris/native/sun/nio/ch/NativeThread.c? > > -Alan. Yes, that needs to be changed. But, I'd prefer to do that under a nio specific CR along with other changes needed for NIO. Thanks Michael. From swingler at apple.com Mon Jan 9 09:33:59 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 09 Jan 2012 09:33:59 -0800 Subject: I tried my app with the current build and found some issues In-Reply-To: References: Message-ID: <1F4D66D1-9CFB-467A-A1B6-17959B9A1F6A@apple.com> On Jan 7, 2012, at 6:08 AM, Joern Huxhorn wrote: > I don't know if those are new to you but when I start Lilith ( http://lilith.huxhorn.de ) I get the following error during startup: > > 2012-01-07 14:28:36.380 java[17379:407] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil > 2012-01-07 14:28:36.390 java[17379:407] ( > 0 CoreFoundation 0x00007fff91e44286 __exceptionPreprocess + 198 > 1 libobjc.A.dylib 0x00007fff9527cd5e objc_exception_throw + 43 > 2 CoreFoundation 0x00007fff91deb108 -[__NSArrayM insertObject:atIndex:] + 296 > 3 AppKit 0x00007fff895a4109 -[NSMenu insertItem:atIndex:] + 478 > 4 liblwawt.dylib 0x0000000113517c14 addMenuItem + 185 > 5 liblwawt.dylib 0x0000000113517905 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 > 6 liblwawt.dylib 0x0000000113517ee1 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 227 > 7 JavaNativeFoundation 0x00000001127595fd +[JNFRunLoop _performCopiedBlock:] + 20 > 8 CoreFoundation 0x00007fff91e6e0cd +[NSObject performSelector:withObject:] + 61 > 9 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 > 10 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 11 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 > 12 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 > 13 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 > 14 HIToolbox 0x00007fff8dd6d3d3 RunCurrentEventLoopInMode + 277 > 15 HIToolbox 0x00007fff8dd7463d ReceiveNextEventCommon + 355 > 16 HIToolbox 0x00007fff8dd744ca BlockUntilNextEventMatchingListInMode + 62 > 17 AppKit 0x00007fff8958d3f1 _DPSNextEvent + 659 > 18 AppKit 0x00007fff8958ccf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 > 19 libosxapp.dylib 0x000000011327882c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 > 20 AppKit 0x00007fff8958962d -[NSApplication run] + 470 > 21 libosxapp.dylib 0x000000011327874b +[NSApplicationAWT runAWTLoopWithApp:] + 156 > 22 liblwawt.dylib 0x0000000113515dad -[AWTStarter starter:] + 1616 > 23 CoreFoundation 0x00007fff91e33a1d -[NSObject performSelector:withObject:] + 61 > 24 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 > 25 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 26 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 > 27 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 > 28 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 > 29 java 0x000000010d93dcb4 CreateExecutionEnvironment + 841 > 30 java 0x000000010d93b7b8 JLI_Launch + 1933 > 31 java 0x000000010d93fa30 main + 108 > 32 java 0x000000010d9393f4 start + 52 > 33 ??? 0x0000000000000008 0x0 + 8 > ) > 2012-01-07 14:28:36.391 java[17379:407] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil > 2012-01-07 14:28:36.397 java[17379:407] ( > 0 CoreFoundation 0x00007fff91e44286 __exceptionPreprocess + 198 > 1 libobjc.A.dylib 0x00007fff9527cd5e objc_exception_throw + 43 > 2 CoreFoundation 0x00007fff91deb108 -[__NSArrayM insertObject:atIndex:] + 296 > 3 AppKit 0x00007fff895a4109 -[NSMenu insertItem:atIndex:] + 478 > 4 liblwawt.dylib 0x0000000113517c14 addMenuItem + 185 > 5 liblwawt.dylib 0x0000000113517905 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 > 6 liblwawt.dylib 0x0000000113517ee1 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 227 > 7 JavaNativeFoundation 0x00000001127595fd +[JNFRunLoop _performCopiedBlock:] + 20 > 8 CoreFoundation 0x00007fff91e6e0cd +[NSObject performSelector:withObject:] + 61 > 9 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 > 10 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 11 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 > 12 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 > 13 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 > 14 HIToolbox 0x00007fff8dd6d3d3 RunCurrentEventLoopInMode + 277 > 15 HIToolbox 0x00007fff8dd7458f ReceiveNextEventCommon + 181 > 16 HIToolbox 0x00007fff8dd744ca BlockUntilNextEventMatchingListInMode + 62 > 17 AppKit 0x00007fff8958d3f1 _DPSNextEvent + 659 > 18 AppKit 0x00007fff8958ccf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 > 19 libosxapp.dylib 0x000000011327882c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 > 20 AppKit 0x00007fff8958962d -[NSApplication run] + 470 > 21 libosxapp.dylib 0x000000011327874b +[NSApplicationAWT runAWTLoopWithApp:] + 156 > 22 liblwawt.dylib 0x0000000113515dad -[AWTStarter starter:] + 1616 > 23 CoreFoundation 0x00007fff91e33a1d -[NSObject performSelector:withObject:] + 61 > 24 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 > 25 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 26 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 > 27 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 > 28 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 > 29 java 0x000000010d93dcb4 CreateExecutionEnvironment + 841 > 30 java 0x000000010d93b7b8 JLI_Launch + 1933 > 31 java 0x000000010d93fa30 main + 108 > 32 java 0x000000010d9393f4 start + 52 > 33 ??? 0x0000000000000008 0x0 + 8 > ) This seems like a straightforward bug in the AWT/Cocoa menu handling code that could be solved with a nil check. Have you filed a bug at ? > Additionally, I saw that the accelerators are displayed as Meta instead of the Command symbol ( ⌘ ). > It also appears like something is wrong with java.util.preferences, i.e. it just doesn't work/save preferences. This should be another bug filed at . Apple's Java SE 6 has slightly different awt.properties files that have the unicode values instead of the full textual names of the key shortcuts. -------------- next part -------------- Cheers, ~Mike From kurchi.subhra.hazra at oracle.com Mon Jan 9 10:27:09 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 09 Jan 2012 10:27:09 -0800 Subject: [7u4-osx] Request for approval for 7127199: [macosx] Update regression tests that use os.name to work on MacOSX Message-ID: <4F0B317D.9020307@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123679 Webrev: http://cr.openjdk.java.net/~khazra/7123679/webrev.02/ Reviewed by: alanb, swingler This changeset will be pushed on my behalf by Michael McMahon (michaelm). Thanks, Kurchi From kurchi.subhra.hazra at oracle.com Mon Jan 9 10:29:09 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 09 Jan 2012 10:29:09 -0800 Subject: [7u4-osx] Request for approval for 7123679: [macosx] Update regression tests that use os.name to work on MacOSX Message-ID: <4F0B31F5.3060908@oracle.com> Apologies for the wrong CR number in the subject. Corrected it here. Thanks, - Kurchi -------- Original Message -------- Subject: [7u4-osx] Request for approval for 7127199: [macosx] Update regression tests that use os.name to work on MacOSX Date: Mon, 09 Jan 2012 10:27:09 -0800 From: Kurchi Hazra Organization: Oracle Corporation To: jdk7u-dev at openjdk.java.net CC: macosx-port-dev at openjdk.java.net This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123679 Webrev: http://cr.openjdk.java.net/~khazra/7123679/webrev.02/ Reviewed by: alanb, swingler This changeset will be pushed on my behalf by Michael McMahon (michaelm). Thanks, Kurchi From paul.hohensee at oracle.com Mon Jan 9 10:54:13 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 09 Jan 2012 13:54:13 -0500 Subject: [7u4-osx] Request for approval for 7123679: [macosx] Update regression tests that use os.name to work on MacOSX In-Reply-To: <4F0B31F5.3060908@oracle.com> References: <4F0B31F5.3060908@oracle.com> Message-ID: <4F0B37D5.30603@oracle.com> Approved. Though there does seem to be a bit of confusion (to me, anyway) between the places that check for solaris | linux | macos and the places that check for !windows. It would be good to define the check in a single method and use that rather than scatter similar-to- identical checks around the code. Paul On 1/9/12 1:29 PM, Kurchi Hazra wrote: > > Apologies for the wrong CR number in the subject. Corrected it here. > > Thanks, > - Kurchi > > > -------- Original Message -------- > Subject: [7u4-osx] Request for approval for 7127199: [macosx] > Update regression tests that use os.name to work on MacOSX > Date: Mon, 09 Jan 2012 10:27:09 -0800 > From: Kurchi Hazra > Organization: Oracle Corporation > To: jdk7u-dev at openjdk.java.net > CC: macosx-port-dev at openjdk.java.net > > > > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123679 > > Webrev: http://cr.openjdk.java.net/~khazra/7123679/webrev.02/ > > Reviewed by: alanb, swingler > > This changeset will be pushed on my behalf by Michael McMahon (michaelm). > > Thanks, > Kurchi > From kurchi.subhra.hazra at oracle.com Mon Jan 9 11:26:34 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 09 Jan 2012 11:26:34 -0800 Subject: [7u4-osx] Request for approval for 7123679: [macosx] Update regression tests that use os.name to work on MacOSX In-Reply-To: <4F0B37D5.30603@oracle.com> References: <4F0B31F5.3060908@oracle.com> <4F0B37D5.30603@oracle.com> Message-ID: <4F0B3F6A.5020709@oracle.com> There was some room for improvement in test/java/nio/file/Files/CopyAndMove.java and I changed it: http://cr.openjdk.java.net/~khazra/7123679/webrev.03/ On 1/9/2012 10:54 AM, Paul Hohensee wrote: > Approved. > > Though there does seem to be a bit of confusion (to me, anyway) > between the places that check for solaris | linux | macos and the > places that check for !windows. It would be good to define the > check in a single method and use that rather than scatter similar-to- > identical checks around the code. I agree - but since the checks are in various tests files scattered all over jdk/test directory, I am not sure how I could define a single method to be used in all such files. - Kurchi > > Paul > > On 1/9/12 1:29 PM, Kurchi Hazra wrote: >> >> Apologies for the wrong CR number in the subject. Corrected it here. >> >> Thanks, >> - Kurchi >> >> >> -------- Original Message -------- >> Subject: [7u4-osx] Request for approval for 7127199: [macosx] >> Update regression tests that use os.name to work on MacOSX >> Date: Mon, 09 Jan 2012 10:27:09 -0800 >> From: Kurchi Hazra >> Organization: Oracle Corporation >> To: jdk7u-dev at openjdk.java.net >> CC: macosx-port-dev at openjdk.java.net >> >> >> >> This is a request to push the following fix to jdk7u-osx: >> >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123679 >> >> Webrev: http://cr.openjdk.java.net/~khazra/7123679/webrev.02/ >> >> Reviewed by: alanb, swingler >> >> This changeset will be pushed on my behalf by Michael McMahon >> (michaelm). >> >> Thanks, >> Kurchi >> -- -Kurchi From paul.hohensee at oracle.com Mon Jan 9 11:43:35 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 09 Jan 2012 14:43:35 -0500 Subject: [7u4-osx] Request for approval for 7123679: [macosx] Update regression tests that use os.name to work on MacOSX In-Reply-To: <4F0B3F6A.5020709@oracle.com> References: <4F0B31F5.3060908@oracle.com> <4F0B37D5.30603@oracle.com> <4F0B3F6A.5020709@oracle.com> Message-ID: <4F0B4367.2060606@oracle.com> On 1/9/12 2:26 PM, Kurchi Hazra wrote: > There was some room for improvement in > test/java/nio/file/Files/CopyAndMove.java > and I changed it: > http://cr.openjdk.java.net/~khazra/7123679/webrev.03/ Ok. > > > On 1/9/2012 10:54 AM, Paul Hohensee wrote: >> Approved. >> >> Though there does seem to be a bit of confusion (to me, anyway) >> between the places that check for solaris | linux | macos and the >> places that check for !windows. It would be good to define the >> check in a single method and use that rather than scatter similar-to- >> identical checks around the code. > > I agree - but since the checks are in various tests files scattered > all over jdk/test directory, > I am not sure how I could define a single method to be used in all > such files. Me neither, which is why I approved the change as is. Paul > > - Kurchi > > > >> >> Paul >> >> On 1/9/12 1:29 PM, Kurchi Hazra wrote: >>> >>> Apologies for the wrong CR number in the subject. Corrected it here. >>> >>> Thanks, >>> - Kurchi >>> >>> >>> -------- Original Message -------- >>> Subject: [7u4-osx] Request for approval for 7127199: [macosx] >>> Update regression tests that use os.name to work on MacOSX >>> Date: Mon, 09 Jan 2012 10:27:09 -0800 >>> From: Kurchi Hazra >>> Organization: Oracle Corporation >>> To: jdk7u-dev at openjdk.java.net >>> CC: macosx-port-dev at openjdk.java.net >>> >>> >>> >>> This is a request to push the following fix to jdk7u-osx: >>> >>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123679 >>> >>> Webrev: http://cr.openjdk.java.net/~khazra/7123679/webrev.02/ >>> >>> Reviewed by: alanb, swingler >>> >>> This changeset will be pushed on my behalf by Michael McMahon >>> (michaelm). >>> >>> Thanks, >>> Kurchi >>> > From michael.x.mcmahon at oracle.com Mon Jan 9 13:27:42 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 09 Jan 2012 21:27:42 +0000 Subject: [7u4-osx] Request for approval for 7127660 (macosx) *Socket Async close not working Message-ID: <4F0B5BCE.4010808@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127660 Webrev: http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ Reviewed by: alanb Thanks, Michael. From paul.hohensee at oracle.com Mon Jan 9 13:42:03 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 09 Jan 2012 16:42:03 -0500 Subject: [7u4-osx] Request for approval for 7127660 (macosx) *Socket Async close not working In-Reply-To: <4F0B5BCE.4010808@oracle.com> References: <4F0B5BCE.4010808@oracle.com> Message-ID: <4F0B5F2B.7040804@oracle.com> In NET_RecvFrom(), isn't the last line *fromlen = socklen; dead code that really shouldn't be dead? Paul On 1/9/12 4:27 PM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127660 > > Webrev: http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ > > Reviewed by: alanb > > Thanks, > Michael. From kelly.ohair at oracle.com Mon Jan 9 13:56:35 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 9 Jan 2012 13:56:35 -0800 Subject: [7u4-osx] Request for approval for 7127660 (macosx) *Socket Async close not working In-Reply-To: <4F0B5F2B.7040804@oracle.com> References: <4F0B5BCE.4010808@oracle.com> <4F0B5F2B.7040804@oracle.com> Message-ID: <809FF15E-E647-48EC-A5CD-DCC58618E7F6@oracle.com> Don't think so. I assume this socklen is to get around the different types needed. -kto On Jan 9, 2012, at 1:42 PM, Paul Hohensee wrote: > In NET_RecvFrom(), isn't the last line > > *fromlen = socklen; > > dead code that really shouldn't be dead? > > Paul > > On 1/9/12 4:27 PM, Michael McMahon wrote: >> This is a request to push the following fix to jdk7u-osx: >> >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127660 >> >> Webrev: http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ >> >> Reviewed by: alanb >> >> Thanks, >> Michael. From kelly.ohair at oracle.com Mon Jan 9 13:56:51 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 9 Jan 2012 13:56:51 -0800 Subject: [7u4-osx] Request for approval for 7127660 (macosx) *Socket Async close not working In-Reply-To: <4F0B5BCE.4010808@oracle.com> References: <4F0B5BCE.4010808@oracle.com> Message-ID: <4D48C76F-74AF-4B9E-9084-41F3B3EA1F20@oracle.com> Looks ok to me. -kto On Jan 9, 2012, at 1:27 PM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127660 > > Webrev: http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ > > Reviewed by: alanb > > Thanks, > Michael. From daniel.daugherty at oracle.com Mon Jan 9 14:09:35 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 09 Jan 2012 15:09:35 -0700 Subject: [7u4-osx] Request for approval for 7127660 (macosx) *Socket Async close not working In-Reply-To: <809FF15E-E647-48EC-A5CD-DCC58618E7F6@oracle.com> References: <4F0B5BCE.4010808@oracle.com> <4F0B5F2B.7040804@oracle.com> <809FF15E-E647-48EC-A5CD-DCC58618E7F6@oracle.com> Message-ID: <4F0B659F.1060101@oracle.com> The macro does a return so I think the code is dead... Dan On 1/9/12 2:56 PM, Kelly O'Hair wrote: > Don't think so. > > I assume this socklen is to get around the different types needed. > > -kto > > On Jan 9, 2012, at 1:42 PM, Paul Hohensee wrote: > >> In NET_RecvFrom(), isn't the last line >> >> *fromlen = socklen; >> >> dead code that really shouldn't be dead? >> >> Paul >> >> On 1/9/12 4:27 PM, Michael McMahon wrote: >>> This is a request to push the following fix to jdk7u-osx: >>> >>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127660 >>> >>> Webrev: http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ >>> >>> Reviewed by: alanb >>> >>> Thanks, >>> Michael. From michael.x.mcmahon at oracle.com Mon Jan 9 14:13:26 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 09 Jan 2012 22:13:26 +0000 Subject: [7u4-osx] Request for approval for 7127660 (macosx) *Socket Async close not working In-Reply-To: <809FF15E-E647-48EC-A5CD-DCC58618E7F6@oracle.com> References: <4F0B5BCE.4010808@oracle.com> <4F0B5F2B.7040804@oracle.com> <809FF15E-E647-48EC-A5CD-DCC58618E7F6@oracle.com> Message-ID: <4F0B6686.8080909@oracle.com> This is actually the same code that's always been there on Linux. It's an interesting observation though because on the face of it, it is dead code that shouldn't be. The reason it has always worked is that the value passed in is never different to the value returned. And we don't even check the returned value anywhere. Socket addresses always have the same size at runtime. I think I will remove the dead code at least, and add a comment. - Michael On 09/01/12 21:56, Kelly O'Hair wrote: > Don't think so. > > I assume this socklen is to get around the different types needed. > > -kto > > On Jan 9, 2012, at 1:42 PM, Paul Hohensee wrote: > >> In NET_RecvFrom(), isn't the last line >> >> *fromlen = socklen; >> >> dead code that really shouldn't be dead? >> >> Paul >> >> On 1/9/12 4:27 PM, Michael McMahon wrote: >>> This is a request to push the following fix to jdk7u-osx: >>> >>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127660 >>> >>> Webrev: http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ >>> >>> Reviewed by: alanb >>> >>> Thanks, >>> Michael. From paul.hohensee at oracle.com Mon Jan 9 14:20:33 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 09 Jan 2012 17:20:33 -0500 Subject: [7u4-osx] Request for approval for 7127660 (macosx) *Socket Async close not working In-Reply-To: <4F0B659F.1060101@oracle.com> References: <4F0B5BCE.4010808@oracle.com> <4F0B5F2B.7040804@oracle.com> <809FF15E-E647-48EC-A5CD-DCC58618E7F6@oracle.com> <4F0B659F.1060101@oracle.com> Message-ID: <4F0B6831.6050902@oracle.com> Exactly. Paul On 1/9/12 5:09 PM, Daniel D. Daugherty wrote: > The macro does a return so I think the code is dead... > > Dan > > > On 1/9/12 2:56 PM, Kelly O'Hair wrote: >> Don't think so. >> >> I assume this socklen is to get around the different types needed. >> >> -kto >> >> On Jan 9, 2012, at 1:42 PM, Paul Hohensee wrote: >> >>> In NET_RecvFrom(), isn't the last line >>> >>> *fromlen = socklen; >>> >>> dead code that really shouldn't be dead? >>> >>> Paul >>> >>> On 1/9/12 4:27 PM, Michael McMahon wrote: >>>> This is a request to push the following fix to jdk7u-osx: >>>> >>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127660 >>>> >>>> Webrev: http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ >>>> >>>> Reviewed by: alanb >>>> >>>> Thanks, >>>> Michael. From kelly.ohair at oracle.com Mon Jan 9 14:33:21 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 9 Jan 2012 14:33:21 -0800 Subject: [7u4-osx] Request for approval for 7127660 (macosx) *Socket Async close not working In-Reply-To: <4F0B6831.6050902@oracle.com> References: <4F0B5BCE.4010808@oracle.com> <4F0B5F2B.7040804@oracle.com> <809FF15E-E647-48EC-A5CD-DCC58618E7F6@oracle.com> <4F0B659F.1060101@oracle.com> <4F0B6831.6050902@oracle.com> Message-ID: <3C2DA005-1747-4931-B637-8FDF5A1E4977@oracle.com> You are assuming that socklen_t and int are the same size. If socklen_t is size_t, you have a problem. -kto On Jan 9, 2012, at 2:20 PM, Paul Hohensee wrote: > Exactly. > > Paul > > On 1/9/12 5:09 PM, Daniel D. Daugherty wrote: >> The macro does a return so I think the code is dead... >> >> Dan >> >> >> On 1/9/12 2:56 PM, Kelly O'Hair wrote: >>> Don't think so. >>> >>> I assume this socklen is to get around the different types needed. >>> >>> -kto >>> >>> On Jan 9, 2012, at 1:42 PM, Paul Hohensee wrote: >>> >>>> In NET_RecvFrom(), isn't the last line >>>> >>>> *fromlen = socklen; >>>> >>>> dead code that really shouldn't be dead? >>>> >>>> Paul >>>> >>>> On 1/9/12 4:27 PM, Michael McMahon wrote: >>>>> This is a request to push the following fix to jdk7u-osx: >>>>> >>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127660 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ >>>>> >>>>> Reviewed by: alanb >>>>> >>>>> Thanks, >>>>> Michael. From michael.x.mcmahon at oracle.com Mon Jan 9 14:33:20 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 09 Jan 2012 22:33:20 +0000 Subject: [7u4-osx] Request for approval for 7127660 (macosx) *Socket Async close not working In-Reply-To: <4F0B6686.8080909@oracle.com> References: <4F0B5BCE.4010808@oracle.com> <4F0B5F2B.7040804@oracle.com> <809FF15E-E647-48EC-A5CD-DCC58618E7F6@oracle.com> <4F0B6686.8080909@oracle.com> Message-ID: <4F0B6B30.9050904@oracle.com> I've updated the webrev to fix it. http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ - Michael. On 09/01/12 22:13, Michael McMahon wrote: > This is actually the same code that's always been there on Linux. It's > an interesting observation though > because on the face of it, it is dead code that shouldn't be. The > reason it has always worked > is that the value passed in is never different to the value returned. > And we don't even check > the returned value anywhere. Socket addresses always have the same > size at runtime. > I think I will remove the dead code at least, and add a comment. > > - Michael > > On 09/01/12 21:56, Kelly O'Hair wrote: >> Don't think so. >> >> I assume this socklen is to get around the different types needed. >> >> -kto >> >> On Jan 9, 2012, at 1:42 PM, Paul Hohensee wrote: >> >>> In NET_RecvFrom(), isn't the last line >>> >>> *fromlen = socklen; >>> >>> dead code that really shouldn't be dead? >>> >>> Paul >>> >>> On 1/9/12 4:27 PM, Michael McMahon wrote: >>>> This is a request to push the following fix to jdk7u-osx: >>>> >>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127660 >>>> >>>> Webrev: http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ >>>> >>>> Reviewed by: alanb >>>> >>>> Thanks, >>>> Michael. > From paul.hohensee at oracle.com Mon Jan 9 14:41:02 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 9 Jan 2012 14:41:02 -0800 (PST) Subject: [7u4-osx] Request for approval for 7127660 (macosx) *Socket Async close not working In-Reply-To: <4F0B6B30.9050904@oracle.com> References: <4F0B5BCE.4010808@oracle.com> <4F0B5F2B.7040804@oracle.com> <809FF15E-E647-48EC-A5CD-DCC58618E7F6@oracle.com> <4F0B6686.8080909@oracle.com> <4F0B6B30.9050904@oracle.com> Message-ID: <4F0B6CFE.6010509@oracle.com> Hopefully that will work everywhere it matters. If there's a size mismatch between int an socklen_t, there will be a problem. Maybe put in a comment to that effect? paul On 1/9/12 5:33 PM, Michael McMahon wrote: > I've updated the webrev to fix it. > > http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ > > - Michael. > > On 09/01/12 22:13, Michael McMahon wrote: >> This is actually the same code that's always been there on Linux. >> It's an interesting observation though >> because on the face of it, it is dead code that shouldn't be. The >> reason it has always worked >> is that the value passed in is never different to the value returned. >> And we don't even check >> the returned value anywhere. Socket addresses always have the same >> size at runtime. >> I think I will remove the dead code at least, and add a comment. >> >> - Michael >> >> On 09/01/12 21:56, Kelly O'Hair wrote: >>> Don't think so. >>> >>> I assume this socklen is to get around the different types needed. >>> >>> -kto >>> >>> On Jan 9, 2012, at 1:42 PM, Paul Hohensee wrote: >>> >>>> In NET_RecvFrom(), isn't the last line >>>> >>>> *fromlen = socklen; >>>> >>>> dead code that really shouldn't be dead? >>>> >>>> Paul >>>> >>>> On 1/9/12 4:27 PM, Michael McMahon wrote: >>>>> This is a request to push the following fix to jdk7u-osx: >>>>> >>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127660 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ >>>>> >>>>> Reviewed by: alanb >>>>> >>>>> Thanks, >>>>> Michael. >> > From paul.hohensee at oracle.com Mon Jan 9 14:52:38 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 09 Jan 2012 17:52:38 -0500 Subject: [7u4-osx] Request for approval for 7127660 (macosx) *Socket Async close not working In-Reply-To: <4F0B6CFE.6010509@oracle.com> References: <4F0B5BCE.4010808@oracle.com> <4F0B5F2B.7040804@oracle.com> <809FF15E-E647-48EC-A5CD-DCC58618E7F6@oracle.com> <4F0B6686.8080909@oracle.com> <4F0B6B30.9050904@oracle.com> <4F0B6CFE.6010509@oracle.com> Message-ID: <4F0B6FB6.6080409@oracle.com> I actually fixed a similar problem in Hotspot a couple of weeks ago. See http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/11c26bfcf8c7 I made methods like NET_RecvFrom take a socklen_t* instead of an int* and fixed their callers, which latter were in the JVM. Couldn't fix the libs though, so the JVM/libs interface does the save/restore thing in your original solution. You could do a more extensive change and fix the callers of NET_RecvFrom. Paul On 1/9/12 5:41 PM, Paul Hohensee wrote: > Hopefully that will work everywhere it matters. If there's a size > mismatch between int an socklen_t, there will be a problem. > Maybe put in a comment to that effect? > > paul > > On 1/9/12 5:33 PM, Michael McMahon wrote: >> I've updated the webrev to fix it. >> >> http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ >> >> - Michael. >> >> On 09/01/12 22:13, Michael McMahon wrote: >>> This is actually the same code that's always been there on Linux. >>> It's an interesting observation though >>> because on the face of it, it is dead code that shouldn't be. The >>> reason it has always worked >>> is that the value passed in is never different to the value >>> returned. And we don't even check >>> the returned value anywhere. Socket addresses always have the same >>> size at runtime. >>> I think I will remove the dead code at least, and add a comment. >>> >>> - Michael >>> >>> On 09/01/12 21:56, Kelly O'Hair wrote: >>>> Don't think so. >>>> >>>> I assume this socklen is to get around the different types needed. >>>> >>>> -kto >>>> >>>> On Jan 9, 2012, at 1:42 PM, Paul Hohensee wrote: >>>> >>>>> In NET_RecvFrom(), isn't the last line >>>>> >>>>> *fromlen = socklen; >>>>> >>>>> dead code that really shouldn't be dead? >>>>> >>>>> Paul >>>>> >>>>> On 1/9/12 4:27 PM, Michael McMahon wrote: >>>>>> This is a request to push the following fix to jdk7u-osx: >>>>>> >>>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127660 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/ >>>>>> >>>>>> Reviewed by: alanb >>>>>> >>>>>> Thanks, >>>>>> Michael. >>> >> From swingler at apple.com Mon Jan 9 15:19:40 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 09 Jan 2012 15:19:40 -0800 Subject: Filing bugs Message-ID: <583F0098-C70A-41EE-ABB7-442112260CD4@apple.com> Where do we file bugs against the Java 7 Mac Developer Preview ? The page says to use: , but there doesn't seem to be any activity there. rejects any attempt to file a bug against Mac OS X. Ideas? Mike Swingler Apple Inc. From roger.lewis at oracle.com Mon Jan 9 15:35:12 2012 From: roger.lewis at oracle.com (Roger Lewis) Date: Mon, 09 Jan 2012 15:35:12 -0800 Subject: Filing bugs In-Reply-To: <583F0098-C70A-41EE-ABB7-442112260CD4@apple.com> References: <583F0098-C70A-41EE-ABB7-442112260CD4@apple.com> Message-ID: <4F0B79B0.5010302@oracle.com> Mike, The page at bugs.sun.com is in the process of being updated to accept bugs against Mac. The workaround would be to select another OS in the pull-down and clearly indicate that the bug is on Mac in the description. It would be useful bugs being being submitted to bugs.sun.com related to this project team to have a term at the beginning of the synopsis that would help identify it as a bug related to the project. This would be similar to how a keyword functions for querying purposes. Can I suggest "macosxport"? example synopis: macosxport: user locale and user interface locale...... -Roger On 1/9/12 3:19 PM, Mike Swingler wrote: > Where do we file bugs against the Java 7 Mac Developer Preview? > > The page says to use:, but there doesn't seem to be any activity there. > > rejects any attempt to file a bug against Mac OS X. > > Ideas? > Mike Swingler > Apple Inc. > From daniel.daugherty at oracle.com Mon Jan 9 15:37:24 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 09 Jan 2012 16:37:24 -0700 Subject: RFR (S): 7125793: MAC: test_gamma should always work In-Reply-To: <4F087516.40505@oracle.com> References: <4EFECA5D.6010905@oracle.com> <4F034B51.3070609@oracle.com> <4F087516.40505@oracle.com> Message-ID: <4F0B7A34.5070406@oracle.com> On 1/7/12 9:38 AM, James Melvin wrote: > WEBREV: > http://cr.openjdk.java.net/~jmelvin/7125793/webrev.01 make/bsd/Makefile No comments. make/bsd/makefiles/buildtree.make No comments. make/bsd/makefiles/defs.make Thanks for fixing this one for BSD platforms. make/bsd/makefiles/launcher.make line 60: typo: 'inadvertenly' -> 'inadvertently' Sorry I missed this in my first review, but the addition of '-framework CoreFoundation' to LFLAGS_LAUNCHER is probably MacOS X specific. I think: ifeq ($(OS_VENDOR), Darwin) else endif will work in launcher.make also. make/bsd/makefiles/vm.make No comments. src/os/bsd/vm/os_bsd.cpp line 2544: typo: 'overriden' -> 'overridden' line 2588: typo: 'overriden' -> 'overridden' Looks like old code line 2576 depended on the 'hotspot' symlink to refer to either 'client' or 'server' or whatever JVM you wanted to run. I'm fairly certain that the 'hotspot' symlink was retired; I'm just not sure when. src/os/posix/launcher/java_md.c No comments. Dan From scott.kovatch at oracle.com Mon Jan 9 15:51:13 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 9 Jan 2012 15:51:13 -0800 Subject: Filing bugs In-Reply-To: <4F0B79B0.5010302@oracle.com> References: <583F0098-C70A-41EE-ABB7-442112260CD4@apple.com> <4F0B79B0.5010302@oracle.com> Message-ID: <4FCC28F6-CA5D-4D82-9F73-42C57CD5765C@oracle.com> For Deploy we are already internally using the convention of putting '(Mac) ' at the start of the bug title, but only because it makes it easier for them to get routed directly to me. :-\ If we could use that, even just for the short term, it would be helpful for me, too. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA On Jan 9, 2012, at 3:35 PM, Roger Lewis wrote: > Mike, > > The page at bugs.sun.com is in the process of being updated to accept bugs against Mac. The workaround would be to select another OS in the pull-down and clearly indicate that the bug is on Mac in the description. > > It would be useful bugs being being submitted to bugs.sun.com related to this project team to have a term at the beginning of the synopsis that would help identify it as a bug related to the project. This would be similar to how a keyword functions for querying purposes. Can I suggest "macosxport"? > example synopis: macosxport: user locale and user interface locale...... > > -Roger > > > On 1/9/12 3:19 PM, Mike Swingler wrote: >> Where do we file bugs against the Java 7 Mac Developer Preview? >> >> The page says to use:, but there doesn't seem to be any activity there. >> >> rejects any attempt to file a bug against Mac OS X. >> >> Ideas? >> Mike Swingler >> Apple Inc. >> From victor.dyakov at oracle.com Mon Jan 9 20:34:25 2012 From: victor.dyakov at oracle.com (Victor Dyakov) Date: Tue, 10 Jan 2012 08:34:25 +0400 Subject: Filing bugs In-Reply-To: <4FCC28F6-CA5D-4D82-9F73-42C57CD5765C@oracle.com> References: <583F0098-C70A-41EE-ABB7-442112260CD4@apple.com> <4F0B79B0.5010302@oracle.com> <4FCC28F6-CA5D-4D82-9F73-42C57CD5765C@oracle.com> Message-ID: <4F0BBFD1.3090803@oracle.com> Hi, The same thing is implemented for AWT/Swing/2D bugs amount, our internal convention of [macosx] prefix at the start of the bug synopsis. Additionally we added "macosx" keyword. That is very useful to sort out related bugs. Victor Dyakov victor.dyakov at oracle.com Saint Petersburg, Russia On 1/10/2012 3:51 AM, Scott Kovatch wrote: > For Deploy we are already internally using the convention of putting '(Mac) ' at the start of the bug title, but only because it makes it easier for them to get routed directly to me. :-\ > > If we could use that, even just for the short term, it would be helpful for me, too. > > -- Scott K. > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > > On Jan 9, 2012, at 3:35 PM, Roger Lewis wrote: > >> Mike, >> >> The page at bugs.sun.com is in the process of being updated to accept bugs against Mac. The workaround would be to select another OS in the pull-down and clearly indicate that the bug is on Mac in the description. >> >> It would be useful bugs being being submitted to bugs.sun.com related to this project team to have a term at the beginning of the synopsis that would help identify it as a bug related to the project. This would be similar to how a keyword functions for querying purposes. Can I suggest "macosxport"? >> example synopis: macosxport: user locale and user interface locale...... >> >> -Roger >> >> >> On 1/9/12 3:19 PM, Mike Swingler wrote: >>> Where do we file bugs against the Java 7 Mac Developer Preview? >>> >>> The page says to use:, but there doesn't seem to be any activity there. >>> >>> rejects any attempt to file a bug against Mac OS X. >>> >>> Ideas? >>> Mike Swingler >>> Apple Inc. >>> From Alan.Bateman at oracle.com Tue Jan 10 00:50:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Jan 2012 08:50:54 +0000 Subject: Filing bugs In-Reply-To: <4F0B79B0.5010302@oracle.com> References: <583F0098-C70A-41EE-ABB7-442112260CD4@apple.com> <4F0B79B0.5010302@oracle.com> Message-ID: <4F0BFBEE.7010703@oracle.com> On 09/01/2012 23:35, Roger Lewis wrote: > > > It would be useful bugs being being submitted to bugs.sun.com related > to this project team to have a term at the beginning of the synopsis > that would help identify it as a bug related to the project. This > would be similar to how a keyword functions for querying purposes. Can > I suggest "macosxport"? > example synopis: macosxport: user locale and user interface > locale...... The only thing is that conflicts with conventions used in other areas, the core area in particular where the area of interest is at the beginning of the synopsis to make long lists of bugs sortable by synopsis. Where bugs are platform specific then the convention has been to put it at end of the synopsis. That said, there is an operating system field and maybe whoever moves this bugs to the right place can fix that up? -Alan From michael.x.mcmahon at oracle.com Tue Jan 10 02:39:16 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 10 Jan 2012 10:39:16 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7123679: Update regression tests that use os.name to work on MacOSX Message-ID: <20120110104006.504B1478FE@hg.openjdk.java.net> Changeset: 98564f184614 Author: khazra Date: 2012-01-10 02:35 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/98564f184614 7123679: Update regression tests that use os.name to work on MacOSX Reviewed-by: alanb, swingler ! src/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java ! test/java/io/File/GetXSpace.java ! test/java/net/DatagramSocket/SendDatagramToBadAddress.java ! test/java/nio/channels/DatagramChannel/Refused.java ! test/java/nio/channels/FileChannel/Size.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/file/FileSystem/Basic.java ! test/java/nio/file/Files/CopyAndMove.java ! test/java/nio/file/Path/PathOps.java ! test/java/util/zip/ZipFile/ManyZipFiles.java ! test/sun/nio/ch/SelProvider.java From michael.x.mcmahon at oracle.com Tue Jan 10 02:45:37 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 10 Jan 2012 10:45:37 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7127199: [macosx] test/com/sun/jdi/ShellScaffold.sh needs to include Darwin as a recognized platform Message-ID: <20120110104551.537B7478FF@hg.openjdk.java.net> Changeset: 1a0d29eae7a0 Author: khazra Date: 2012-01-10 02:46 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/1a0d29eae7a0 7127199: [macosx] test/com/sun/jdi/ShellScaffold.sh needs to include Darwin as a recognized platform Reviewed-by: dcubed, alanb ! test/com/sun/jdi/ShellScaffold.sh From anthony.petrov at oracle.com Tue Jan 10 06:30:45 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 10 Jan 2012 18:30:45 +0400 Subject: jhat 1.6/1.7 difference In-Reply-To: <5BA28A39-A56F-4F18-9F20-C5BE0D888289@gmail.com> References: <5BA28A39-A56F-4F18-9F20-C5BE0D888289@gmail.com> Message-ID: <4F0C4B95.405@oracle.com> Looks like a bug to me. Something triggers the initialization of an NSApplicationAWT instance which I think shouldn't happen since jhat isn't a GUI application. Have you filed a bug at http://bugs.sun.com on this? -- best regards, Anthony On 1/4/2012 7:06 AM, Michael Hall wrote: > 1.7 shows a dock icon. Intentional? From sergey.bylokhov at oracle.com Tue Jan 10 07:33:14 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Jan 2012 19:33:14 +0400 Subject: Request for review: 7124530 What is background color of AWT component? (And foreground, for that matter) In-Reply-To: <4EFC6C63.5010806@oracle.com> References: <4EFC6C63.5010806@oracle.com> Message-ID: <4F0C5A3A.3060200@oracle.com> Hi Everyone, Does anybody have a comments? 29.12.2011 17:34, Sergey Bylokhov wrote: > Hi Everyone, > This is a fix for some glitches in the code for > background/foreground/font properties. > 1. SystemColor.window was changed to color which is used by default in > swing l&f(Aqua). Changes in AquaImageFactory.java and CSystemColors.m. > Now most of the awt components use this color as default. > 2. set** methods were moved from LWWindowPeer to LWComponentPeer, > because there is an issues when these methods has no effect, because > repaint of the component does not happen.For example: > - call Label.setbackground which set component background property > - call Peer.setBackground > - call Delegate.setBackgound > - compare passed color with color from Label property, which was set > in the first step: changes in > LWWindowPeer,LWContainerPeer,LWComponentPeer. > 3. List default color was changed to SystemColor.text: changes in > LWListPeer.java. > 4. LWWIndow target color initialization was moved from CPlatformIndow > to LWWindowPeer, so it can be reused later by CPlatformEmbeddedFrame . > 5. unnecessary peers set** methods and unnecessary delegate in > LWCanvasPeer were removed: changes in LWCanvasPeer.java, > LWListPeer.java, LWPanelPeer.java. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124530/webrev.00/ > -- Best regards, Sergey. From michael.x.mcmahon at oracle.com Tue Jan 10 07:34:48 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 10 Jan 2012 15:34:48 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7127660: (macosx) *Socket Async close not working Message-ID: <20120110153459.1996347905@hg.openjdk.java.net> Changeset: d201644bbdb0 Author: michaelm Date: 2012-01-10 07:34 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d201644bbdb0 7127660: (macosx) *Socket Async close not working Reviewed-by: alanb, phh, ohair ! src/solaris/native/java/net/bsd_close.c ! src/solaris/native/java/net/net_util_md.h From anthony.petrov at oracle.com Tue Jan 10 08:51:23 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 10 Jan 2012 20:51:23 +0400 Subject: Request for review: 7124530 What is background color of AWT component? (And foreground, for that matter) In-Reply-To: <4F0C5A3A.3060200@oracle.com> References: <4EFC6C63.5010806@oracle.com> <4F0C5A3A.3060200@oracle.com> Message-ID: <4F0C6C8B.30309@oracle.com> Hi Sergey, src/macosx/classes/sun/lwawt/LWWindowPeer.java > 140 if (!target.isBackgroundSet()) { > 141 target.setBackground(SystemColor.window); > 142 } else { > 143 // first we check if user provided alpha for background. This is > 144 // similar to what Apple's Java do. > 145 // Since JDK7 we should rely on setOpacity() only. > 146 // this.opacity = c.getAlpha(); > 147 // System.out.println("Delegate assigns alpha (we ignore setOpacity()):" > 148 // +this.opacity); > 149 } A couple of questions regarding this piece of code: 1. Why do we need the else{} branch here? Are we going to use it? How? Should the comment explain this future use? 2. What do you mean by saying "we should rely on setOpacity() only"? The alpha value of the background color and the alpha value returned by getOpacity() are different kinds of opacity: the former affects the background surface of the window only, whilst the latter affects the entire window's surface including any content explicitly painted on top of the background. -- best regards, Anthony On 1/10/2012 7:33 PM, Sergey Bylokhov wrote: > Hi Everyone, > > Does anybody have a comments? > > 29.12.2011 17:34, Sergey Bylokhov wrote: >> Hi Everyone, >> This is a fix for some glitches in the code for >> background/foreground/font properties. >> 1. SystemColor.window was changed to color which is used by default in >> swing l&f(Aqua). Changes in AquaImageFactory.java and CSystemColors.m. >> Now most of the awt components use this color as default. >> 2. set** methods were moved from LWWindowPeer to LWComponentPeer, >> because there is an issues when these methods has no effect, because >> repaint of the component does not happen.For example: >> - call Label.setbackground which set component background property >> - call Peer.setBackground >> - call Delegate.setBackgound >> - compare passed color with color from Label property, which was set >> in the first step: changes in >> LWWindowPeer,LWContainerPeer,LWComponentPeer. >> 3. List default color was changed to SystemColor.text: changes in >> LWListPeer.java. >> 4. LWWIndow target color initialization was moved from CPlatformIndow >> to LWWindowPeer, so it can be reused later by CPlatformEmbeddedFrame . >> 5. unnecessary peers set** methods and unnecessary delegate in >> LWCanvasPeer were removed: changes in LWCanvasPeer.java, >> LWListPeer.java, LWPanelPeer.java. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7124530/webrev.00/ >> > > From sergey.bylokhov at oracle.com Tue Jan 10 09:07:50 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Jan 2012 21:07:50 +0400 Subject: Request for review: 7124530 What is background color of AWT component? (And foreground, for that matter) In-Reply-To: <4F0C6C8B.30309@oracle.com> References: <4EFC6C63.5010806@oracle.com> <4F0C5A3A.3060200@oracle.com> <4F0C6C8B.30309@oracle.com> Message-ID: <4F0C7066.2000908@oracle.com> Hi Anthony. 10.01.2012 20:51, Anthony Petrov wrote: > Hi Sergey, > > src/macosx/classes/sun/lwawt/LWWindowPeer.java >> 140 if (!target.isBackgroundSet()) { >> 141 target.setBackground(SystemColor.window); >> 142 } else { >> 143 // first we check if user provided alpha for >> background. This is >> 144 // similar to what Apple's Java do. >> 145 // Since JDK7 we should rely on setOpacity() only. >> 146 // this.opacity = c.getAlpha(); >> 147 // System.out.println("Delegate assigns alpha (we >> ignore setOpacity()):" >> 148 // +this.opacity); >> 149 } This code has been moved from CPlatformWindow as is, so it can be reused later by CPlatformEmbeddedFrame. > > A couple of questions regarding this piece of code: > > 1. Why do we need the else{} branch here? Are we going to use it? How? > Should the comment explain this future use? > > 2. What do you mean by saying "we should rely on setOpacity() only"? > The alpha value of the background color and the alpha value returned > by getOpacity() are different kinds of opacity: the former affects the > background surface of the window only, whilst the latter affects the > entire window's surface including any content explicitly painted on > top of the background. > > -- > best regards, > Anthony > > On 1/10/2012 7:33 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> >> Does anybody have a comments? >> >> 29.12.2011 17:34, Sergey Bylokhov wrote: >>> Hi Everyone, >>> This is a fix for some glitches in the code for >>> background/foreground/font properties. >>> 1. SystemColor.window was changed to color which is used by default >>> in swing l&f(Aqua). Changes in AquaImageFactory.java and >>> CSystemColors.m. Now most of the awt components use this color as >>> default. >>> 2. set** methods were moved from LWWindowPeer to LWComponentPeer, >>> because there is an issues when these methods has no effect, because >>> repaint of the component does not happen.For example: >>> - call Label.setbackground which set component background property >>> - call Peer.setBackground >>> - call Delegate.setBackgound >>> - compare passed color with color from Label property, which was >>> set in the first step: changes in >>> LWWindowPeer,LWContainerPeer,LWComponentPeer. >>> 3. List default color was changed to SystemColor.text: changes in >>> LWListPeer.java. >>> 4. LWWIndow target color initialization was moved from >>> CPlatformIndow to LWWindowPeer, so it can be reused later by >>> CPlatformEmbeddedFrame . >>> 5. unnecessary peers set** methods and unnecessary delegate in >>> LWCanvasPeer were removed: changes in LWCanvasPeer.java, >>> LWListPeer.java, LWPanelPeer.java. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7124530/webrev.00/ >>> >> >> -- Best regards, Sergey. From Alexander.Potochkin at oracle.com Tue Jan 10 09:24:20 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 10 Jan 2012 21:24:20 +0400 Subject: The latest 7u-osx crashes In-Reply-To: <4F008903.5020505@oracle.com> References: <4EFCADF0.5070909@oracle.com> <4EFD6440.5010609@oracle.com> <4F008903.5020505@oracle.com> Message-ID: <4F0C7444.1010004@oracle.com> Hello Paul > I've pulled hotspot down from jdk7u-dev to jdk7u-osx, which includes > the fix for 7118648. Should work now. It works indeed! Thanks alexp > > Paul > > On 12/30/11 2:12 AM, Daniel D. Daugherty wrote: >> Compressed Oops is broken in the MacOS X port. The following bug: >> >> 7118648 3/3 disable compressed oops by default on MacOS X until >> 7118647 is fixed >> >> was used to disable compressed oops in RT_Baseline for HSX-23-B08. >> That fix has made it to 7u4, but is not in the 7u-osx/hotspot repo. >> I don't know when the next resync is planned. >> >> The following bug: >> >> 7118647 3/3 compressed oops crashes on MacOS X with JPRT GCBasher test >> >> is being used to track the actual failure. >> >> Dan >> >> >> >> On 12/29/11 11:14 AM, Alexander Potochkin wrote: >>> Hello >>> >>> I just built the latest 7u-osx jdk on Mac >>> and found that it crashes when I run any application >>> >>> I hear that our release team observed the same problem, >>> wonder if anybody knows how to fix it >>> >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # SIGSEGV (0xb) at pc=0x00000001015fe2e4, pid=78258, tid=4401594368 >>> # >>> # JRE version: 7.0 >>> # Java VM: OpenJDK 64-Bit Server VM (23.0-b06 mixed mode bsd-amd64 >>> compressed oops) >>> # Problematic frame: >>> # V [libjvm.dylib+0x27b2e4] >>> >>> Thanks >>> alexp From scott.kovatch at oracle.com Tue Jan 10 11:39:14 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 10 Jan 2012 11:39:14 -0800 Subject: Filing bugs In-Reply-To: <4F0BFBEE.7010703@oracle.com> References: <583F0098-C70A-41EE-ABB7-442112260CD4@apple.com> <4F0B79B0.5010302@oracle.com> <4F0BFBEE.7010703@oracle.com> Message-ID: On Jan 10, 2012, at 12:50 AM, Alan Bateman wrote: > On 09/01/2012 23:35, Roger Lewis wrote: >> >> >> It would be useful bugs being being submitted to bugs.sun.com related to this project team to have a term at the beginning of the synopsis that would help identify it as a bug related to the project. This would be similar to how a keyword functions for querying purposes. Can I suggest "macosxport"? >> example synopis: macosxport: user locale and user interface locale...... > The only thing is that conflicts with conventions used in other areas, the core area in particular where the area of interest is at the beginning of the synopsis to make long lists of bugs sortable by synopsis. Where bugs are platform specific then the convention has been to put it at end of the synopsis. That said, there is an operating system field and maybe whoever moves this bugs to the right place can fix that up? I agree that pseudo-keywords aren't a good long-term solution. The short-term problem is that if you select Mac OS X we don't even allow the bug to be submitted on the assumption that it should go to Apple's bug reporting system. I think once that behavior is changed we can use the OS field as intended and then we won't need any synopsis hacking. I know I'm setting Mac OS X when I use Bugster. -- Scott From swingler at apple.com Tue Jan 10 12:44:29 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 10 Jan 2012 12:44:29 -0800 Subject: Filing bugs In-Reply-To: <4F0BEB51.30607@oracle.com> References: <583F0098-C70A-41EE-ABB7-442112260CD4@apple.com> <4F0B79B0.5010302@oracle.com> <4F0BEB51.30607@oracle.com> Message-ID: <8EE11106-7692-41E5-AC9A-1C91938E7630@apple.com> Great news. Thanks much for your help Nelson. Cheers, Mike Swingler Apple Inc. On Jan 9, 2012, at 11:40 PM, nelson.dcosta at oracle.com wrote: > Mike, > > I have deployed the changes to accept reports through bugreport.sun.com for bugs reported against the Mac OS X platform. These reports are filed in bugtraq against the macosx operating system. > > Regards, > Nelson > > On 1/10/2012 5:05 AM, Roger Lewis wrote: >> >> Mike, >> >> The page at bugs.sun.com is in the process of being updated to accept bugs against Mac. The workaround would be to select another OS in the pull-down and clearly indicate that the bug is on Mac in the description. >> >> It would be useful bugs being being submitted to bugs.sun.com related to this project team to have a term at the beginning of the synopsis that would help identify it as a bug related to the project. This would be similar to how a keyword functions for querying purposes. Can I suggest "macosxport"? >> example synopis: macosxport: user locale and user interface locale...... >> >> -Roger >> >> >> On 1/9/12 3:19 PM, Mike Swingler wrote: >>> Where do we file bugs against the Java 7 Mac Developer Preview? >>> >>> The page says to use:, but there doesn't seem to be any activity there. >>> >>> rejects any attempt to file a bug against Mac OS X. >>> >>> Ideas? >>> Mike Swingler >>> Apple Inc. >>> > From james.melvin at oracle.com Tue Jan 10 13:05:13 2012 From: james.melvin at oracle.com (James Melvin) Date: Tue, 10 Jan 2012 16:05:13 -0500 Subject: RFR (S): 7125793: MAC: test_gamma should always work In-Reply-To: <4F0B7A34.5070406@oracle.com> References: <4EFECA5D.6010905@oracle.com> <4F034B51.3070609@oracle.com> <4F087516.40505@oracle.com> <4F0B7A34.5070406@oracle.com> Message-ID: <4F0CA809.7020001@oracle.com> Hi Dan, Final webrev to reflect your comments... http://cr.openjdk.java.net/~jmelvin/7125793/webrev.02 Minor changes this round: make/bsd/makefiles/buildtree.make # Fail gracefully on Apple BOOTDIR make/bsd/makefiles/launcher.make # Link with framework only on Mac src/os/bsd/vm/os_bsd.cpp # Just spelling fix Lastly, I wanted to reply to John Coomes comments earlier about the test_gamma script simplification. Although I also value economy of expression, in this case I think the use of more advanced shell constructs increases the time for fresh eyes to decipher. Given performance and such is not an issue, I'd prefer to keep the simpler version I'm proposing with this change on Mac OS X, to make it easier on future maintenance. This should be a model for the other platforms when we reconcile. I've attached the before and after copies should there be further comments on the simplified short script. Thanks, Jim On 1/9/12 6:37 PM, Daniel D. Daugherty wrote: > On 1/7/12 9:38 AM, James Melvin wrote: >> WEBREV: >> http://cr.openjdk.java.net/~jmelvin/7125793/webrev.01 > > make/bsd/Makefile > No comments. > > make/bsd/makefiles/buildtree.make > No comments. > > make/bsd/makefiles/defs.make > Thanks for fixing this one for BSD platforms. > > make/bsd/makefiles/launcher.make > line 60: typo: 'inadvertenly' -> 'inadvertently' > > Sorry I missed this in my first review, but the addition > of '-framework CoreFoundation' to LFLAGS_LAUNCHER is > probably MacOS X specific. I think: > > ifeq ($(OS_VENDOR), Darwin) > else > endif > > will work in launcher.make also. > > make/bsd/makefiles/vm.make > No comments. > > src/os/bsd/vm/os_bsd.cpp > line 2544: typo: 'overriden' -> 'overridden' > line 2588: typo: 'overriden' -> 'overridden' > > Looks like old code line 2576 depended on the 'hotspot' > symlink to refer to either 'client' or 'server' or whatever > JVM you wanted to run. I'm fairly certain that the 'hotspot' > symlink was retired; I'm just not sure when. > > src/os/posix/launcher/java_md.c > No comments. > > Dan > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_gamma.before Url: http://mail.openjdk.java.net/pipermail/macosx-port-dev/attachments/20120110/6a912938/test_gamma.before -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test_gamma.after Url: http://mail.openjdk.java.net/pipermail/macosx-port-dev/attachments/20120110/6a912938/test_gamma.after From daniel.daugherty at oracle.com Tue Jan 10 13:27:17 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 10 Jan 2012 14:27:17 -0700 Subject: RFR (S): 7125793: MAC: test_gamma should always work In-Reply-To: <4F0CA809.7020001@oracle.com> References: <4EFECA5D.6010905@oracle.com> <4F034B51.3070609@oracle.com> <4F087516.40505@oracle.com> <4F0B7A34.5070406@oracle.com> <4F0CA809.7020001@oracle.com> Message-ID: <4F0CAD35.40809@oracle.com> On 1/10/12 2:05 PM, James Melvin wrote: > Hi Dan, > > Final webrev to reflect your comments... > > http://cr.openjdk.java.net/~jmelvin/7125793/webrev.02 > > Minor changes this round: > > make/bsd/makefiles/buildtree.make # Fail gracefully on Apple BOOTDIR > make/bsd/makefiles/launcher.make # Link with framework only on Mac > src/os/bsd/vm/os_bsd.cpp # Just spelling fix Thumbs up on the current version. To close the loop on one of my earlier comments: $ ls -l binaries/solsparc/jre/lib/sparc/hotspot lrwxrwxrwx 1 nobody nobody 6 Apr 1 2009 binaries/solsparc/jre/lib/sparc/hotspot -> client This symlink exists in JDK1.3.1, but I didn't find it in JDK1.4.0. > Lastly, I wanted to reply to John Coomes comments earlier about the > test_gamma script simplification. Although I also value economy of > expression, in this case I think the use of more advanced shell > constructs increases the time for fresh eyes to decipher. Given > performance and such is not an issue, I'd prefer to keep the simpler > version I'm proposing with this change on Mac OS X, to make it easier on > future maintenance. This should be a model for the other platforms when > we reconcile. I've attached the before and after copies should there be > further comments on the simplified short script. The attachments didn't come through because your e-mail went through the OpenJDK list servers. Just to be clear: I vote for the newer version. It is more straight forward and has comments. Dan > > Thanks, > > Jim > > > On 1/9/12 6:37 PM, Daniel D. Daugherty wrote: >> On 1/7/12 9:38 AM, James Melvin wrote: >>> WEBREV: >>> http://cr.openjdk.java.net/~jmelvin/7125793/webrev.01 >> >> make/bsd/Makefile >> No comments. >> >> make/bsd/makefiles/buildtree.make >> No comments. >> >> make/bsd/makefiles/defs.make >> Thanks for fixing this one for BSD platforms. >> >> make/bsd/makefiles/launcher.make >> line 60: typo: 'inadvertenly' -> 'inadvertently' >> >> Sorry I missed this in my first review, but the addition >> of '-framework CoreFoundation' to LFLAGS_LAUNCHER is >> probably MacOS X specific. I think: >> >> ifeq ($(OS_VENDOR), Darwin) >> else >> endif >> >> will work in launcher.make also. >> >> make/bsd/makefiles/vm.make >> No comments. >> >> src/os/bsd/vm/os_bsd.cpp >> line 2544: typo: 'overriden' -> 'overridden' >> line 2588: typo: 'overriden' -> 'overridden' >> >> Looks like old code line 2576 depended on the 'hotspot' >> symlink to refer to either 'client' or 'server' or whatever >> JVM you wanted to run. I'm fairly certain that the 'hotspot' >> symlink was retired; I'm just not sure when. >> >> src/os/posix/launcher/java_md.c >> No comments. >> >> Dan >> >> From artem.ananiev at oracle.com Wed Jan 11 01:01:26 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 11 Jan 2012 13:01:26 +0400 Subject: Review request for MACOSX_PORT-539: Need a java.awt.EmbeddedFrame subclass In-Reply-To: <4EFC73FC.1060607@oracle.com> References: <4EFC73FC.1060607@oracle.com> Message-ID: <4F0D4FE6.1010903@oracle.com> Hi, Dmitry, here are my comments: 1. CEmbeddedFrame and CPlatformEmbeddedFrame are probably not the best names. I can't suggest anything better, though. 2. Is there a reason to explicitly call addNotify() in CEF constructor? Will it be called automatically as a part of show()? 3. CEF.handle*Event(): please, add (responder != null) checks there to protect these methods from calling on invisible frames. 4. There are several (platformWindow instanceof CPlatformWindow) checks added. Could you comment on this, please? Do you expect anything else than CPlatformWindow there? 5. What is the reason of exporting the getPeer() method in the PlatformWindow interface? Thanks, Artem On 12/29/2011 6:06 PM, Dmitry Cherepanov wrote: > Hello, > > Please review an initial implementation for > http://java.net/jira/browse/MACOSX_PORT-539 at > > http://cr.openjdk.java.net/~dcherepanov/7124335/webrev.0/ > > Basically the fix provides a lightweight implementation of the > EmbeddedFrame class (isn't backed by a NSView/NSWindow). The > implementation creates an instance of CALayer and exposes it as > protected CEmbeddedFrame method. > > Please see the bug report http://java.net/jira/browse/MACOSX_PORT-539 > for more details about the current version of the fix. > > Thanks, > Dmitry > From anton.tarasov at oracle.com Wed Jan 11 04:18:14 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 11 Jan 2012 15:18:14 +0300 Subject: Review request for 7124283: [macosx] Can't move focus out of a table with the keyboard Message-ID: <4F0D7E06.5040204@oracle.com> Hello, Please review a fix for 7124283. webrev: http://cr.openjdk.java.net/~ant/7124283/v.1/webrev/ [ctrl+shift+tab] & [ctrl+tab] key combinations don't trigger focus transfer back or forward. The reason is that a key combination (like [modifier + key]) results in sending a performKeyEquivalent: message, not a keyDown: one. This method has not yet been implemented in AWTView.m Thanks, Anton. From anthony.petrov at oracle.com Wed Jan 11 03:40:55 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 11 Jan 2012 15:40:55 +0400 Subject: Review request for 7124283: [macosx] Can't move focus out of a table with the keyboard In-Reply-To: <4F0D7E06.5040204@oracle.com> References: <4F0D7E06.5040204@oracle.com> Message-ID: <4F0D7547.2020307@oracle.com> Looks good to me. -- best regards, Anthony On 1/11/2012 4:18 PM, Anton V. Tarasov wrote: > Hello, > > Please review a fix for 7124283. > > webrev: http://cr.openjdk.java.net/~ant/7124283/v.1/webrev/ > > > [ctrl+shift+tab] & [ctrl+tab] key combinations don't trigger focus > transfer back or forward. > > The reason is that a key combination (like [modifier + key]) results in > sending a performKeyEquivalent: message, > not a keyDown: one. This method has not yet been implemented in AWTView.m > > Thanks, > Anton. > > From anton.tarasov at oracle.com Wed Jan 11 05:20:19 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 11 Jan 2012 16:20:19 +0300 Subject: [7u4] Request for approval for CR 7124283 - [macosx] Can't move focus out of a table with the keyboard Message-ID: <4F0D8C93.1010406@oracle.com> Hello, This is a request to push the following changes to jdk7u-osx. The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124283 Webrev can be found at: http://cr.openjdk.java.net/~ant/7124283/v.1/webrev/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002121.html Thanks, Anton. From dmitry.cherepanov at oracle.com Wed Jan 11 05:31:58 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Wed, 11 Jan 2012 16:31:58 +0300 Subject: Review request for MACOSX_PORT-539: Need a java.awt.EmbeddedFrame subclass In-Reply-To: <4F0D4FE6.1010903@oracle.com> References: <4EFC73FC.1060607@oracle.com> <4F0D4FE6.1010903@oracle.com> Message-ID: <4F0D8F4E.20204@oracle.com> Hi Artem, Artem Ananiev wrote: > Hi, Dmitry, > > here are my comments: > > 1. CEmbeddedFrame and CPlatformEmbeddedFrame are probably not the best > names. I can't suggest anything better, though. I can't come up with anything better too but hopefully these names make sense to some extent. - "CEmbeddedFrame" seems to conform to existing names - "WEmbeddedFrame" on Windows and "XEmbeddedFrame" on X11. - "CPlatformEmbeddedFrame" is consistent with "CPlatformWindow". > > 2. Is there a reason to explicitly call addNotify() in CEF > constructor? Will it be called automatically as a part of show()? Done. > > 3. CEF.handle*Event(): please, add (responder != null) checks there to > protect these methods from calling on invisible frames. My understanding is that there's no strong reason to write these checks for null values. If there's a key/mouse event coming from the Plugin in case of invisible embedded frames, I would say that such events are unexpected and shouldn't be triggered. > > 4. There are several (platformWindow instanceof CPlatformWindow) > checks added. Could you comment on this, please? Do you expect > anything else than CPlatformWindow there? All these checks are needed to handle CPlatformEmbeddedFrame case: src/macosx/classes/sun/lwawt/macosx/CDropTarget.java skips registering drop target on CPlatformEmbeddedFrame (Scott wrote that the Plugin doesn't deliver drag-and-drop events). src/macosx/classes/sun/lwawt/macosx/CInputMethod.java skips notifying CInputMethod instances about focus/IME events (input methods aren't implemented yet in embedded env). src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java skip using embedded frames (which don't have underlying NSView/NSWindow) as owner windows. > > 5. What is the reason of exporting the getPeer() method in the > PlatformWindow interface? It's done as a part of the changes in src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java The change removes explicit reference to the CPlatformWindow class (to make it working for CPlatformEmbeddedFrame) but it still needs to call platformWindow.getPeer() (see the setBounds method). It could probably be refactored into a more simplified code (to remove the getPeer method from the PlatformWindow interface). Thanks for reviewing this! Dmitry > > Thanks, > > Artem > > On 12/29/2011 6:06 PM, Dmitry Cherepanov wrote: >> Hello, >> >> Please review an initial implementation for >> http://java.net/jira/browse/MACOSX_PORT-539 at >> >> http://cr.openjdk.java.net/~dcherepanov/7124335/webrev.0/ >> >> Basically the fix provides a lightweight implementation of the >> EmbeddedFrame class (isn't backed by a NSView/NSWindow). The >> implementation creates an instance of CALayer and exposes it as >> protected CEmbeddedFrame method. >> >> Please see the bug report http://java.net/jira/browse/MACOSX_PORT-539 >> for more details about the current version of the fix. >> >> Thanks, >> Dmitry >> From anton.tarasov at oracle.com Wed Jan 11 05:38:53 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 11 Jan 2012 16:38:53 +0300 Subject: [7u4] Request for approval for CR 7124283 - [macosx] Can't move focus out of a table with the keyboard Message-ID: <4F0D90ED.2010400@oracle.com> Hello, This is a request to push the following changes to jdk7u-osx. The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124283 Webrev can be found at: http://cr.openjdk.java.net/~ant/7124283/v.1/webrev/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002121.html Thanks, Anton. From anton.tarasov at oracle.com Wed Jan 11 04:40:14 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 11 Jan 2012 16:40:14 +0400 Subject: [7u4] Request for approval for CR 7124283 - [macosx] Can't move focus out of a table with the keyboard Message-ID: <4F0D832E.3040205@oracle.com> Hello, This is a request to push the following changes to jdk7u-osx. The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124283 Webrev can be found at: http://cr.openjdk.java.net/~ant/7124283/v.1/webrev/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002121.html Thanks, Anton. From dmitry.cherepanov at oracle.com Wed Jan 11 06:00:21 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Wed, 11 Jan 2012 17:00:21 +0300 Subject: Review request for MACOSX_PORT-784: Program freeze when Swing is used with -XstartOnFirstThread Message-ID: <4F0D95F5.1060808@oracle.com> Hello, Please review a fix for http://java.net/jira/browse/MACOSX_PORT-784 at http://cr.openjdk.java.net/~dcherepanov/7128597/webrev.0/ To avoid the deadlock, the fix includes: - the addition of +[NSThread isMainThread] to ensure that we don't call -performSelectorOnMainThread: when the current thread is the AppKit thread - also, the fix doesn't invoke the getCGLConfigInfo method on the queue flusher thread - after the fix, the getCGLConfigInfo method is executed on the current thread directly. Thanks, Dmitry From anton.tarasov at oracle.com Wed Jan 11 06:19:57 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 11 Jan 2012 17:19:57 +0300 Subject: Review request for 7124217: [macosx] key events are posted to the event queue twice Message-ID: <4F0D9A8D.3000803@oracle.com> Hello, Please review a fix for 7124217. webrev: http://cr.openjdk.java.net/~ant/7124217/webrev.0/ Eliminating old code. No need to post key events via invokeLater, they should be posted directly to the queue as it conforms to AWT architecture. Checked that the fix doesn't cause regressions with the focus reg tests. Thanks, Anton. From artem.ananiev at oracle.com Wed Jan 11 05:46:24 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 11 Jan 2012 17:46:24 +0400 Subject: [7u4] Request for approval for CR 7124283 - [macosx] Can't move focus out of a table with the keyboard In-Reply-To: <4F0D8C93.1010406@oracle.com> References: <4F0D8C93.1010406@oracle.com> Message-ID: <4F0D92B0.2080703@oracle.com> Approved. Thanks, Artem On 1/11/2012 5:20 PM, Anton V. Tarasov wrote: > Hello, > > This is a request to push the following changes to jdk7u-osx. > The fix has been reviewed on macosx-port-dev mailing list by Anthony > Petrov. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124283 > Webrev can be found at: http://cr.openjdk.java.net/~ant/7124283/v.1/webrev/ > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002121.html > > > Thanks, > Anton. From GREG.X.BROWN at oracle.com Wed Jan 11 05:45:47 2012 From: GREG.X.BROWN at oracle.com (Greg Brown) Date: Wed, 11 Jan 2012 08:45:47 -0500 Subject: [REVIEW] Update paths in JavaAppLauncher.xcodeproj Message-ID: This change fixes some broken paths in JavaAppLauncher.xcodeproj, allowing the project to build. The diff is a little tough to follow, but the things that changed were: - The path to the JDK and JRE plugins - The paths to the JNI header files Greg diff -r d201644bbdb0 src/macosx/bundle/JavaAppLauncher/JavaAppLauncher.xcodeproj/project.pbxproj --- a/src/macosx/bundle/JavaAppLauncher/JavaAppLauncher.xcodeproj/project.pbxproj Tue Jan 10 07:34:06 2012 -0800 +++ b/src/macosx/bundle/JavaAppLauncher/JavaAppLauncher.xcodeproj/project.pbxproj Wed Jan 11 08:39:57 2012 -0500 @@ -1,318 +1,318 @@ // !$*UTF8*$! { - archiveVersion = 1; - classes = { - }; - objectVersion = 45; - objects = { + archiveVersion = 1; + classes = { + }; + objectVersion = 46; + objects = { /* Begin PBXBuildFile section */ - 2C483E05143512EB00F2AEFD /* 1.7.0.jre in Copy PlugIns */ = {isa = PBXBuildFile; fileRef = 2C483E04143512EB00F2AEFD /* 1.7.0.jre */; }; - 89D3CD32142EEB2200A08AED /* InfoPlist.strings in Resources */ = {isa = PBXBuildFile; fileRef = 89D3CD29142EEB2200A08AED /* InfoPlist.strings */; }; - 89D3CD33142EEB2200A08AED /* GenericApp.icns in Resources */ = {isa = PBXBuildFile; fileRef = 89D3CD2B142EEB2200A08AED /* GenericApp.icns */; }; - 89D3CD35142EEB2200A08AED /* JVMArgs.m in Sources */ = {isa = PBXBuildFile; fileRef = 89D3CD30142EEB2200A08AED /* JVMArgs.m */; }; - 89D3CD36142EEB2200A08AED /* main.m in Sources */ = {isa = PBXBuildFile; fileRef = 89D3CD31142EEB2200A08AED /* main.m */; }; - 89D3D365143041F000A08AED /* JavaAppLauncher.m in Sources */ = {isa = PBXBuildFile; fileRef = 89D3D364143041F000A08AED /* JavaAppLauncher.m */; }; - 8D11072F0486CEB800E47090 /* Cocoa.framework in Frameworks */ = {isa = PBXBuildFile; fileRef = 1058C7A1FEA54F0111CA2CBB /* Cocoa.framework */; }; + 2C483E05143512EB00F2AEFD /* 1.7.0.jre in Copy PlugIns */ = {isa = PBXBuildFile; fileRef = 2C483E04143512EB00F2AEFD /* 1.7.0.jre */; }; + 89D3CD32142EEB2200A08AED /* InfoPlist.strings in Resources */ = {isa = PBXBuildFile; fileRef = 89D3CD29142EEB2200A08AED /* InfoPlist.strings */; }; + 89D3CD33142EEB2200A08AED /* GenericApp.icns in Resources */ = {isa = PBXBuildFile; fileRef = 89D3CD2B142EEB2200A08AED /* GenericApp.icns */; }; + 89D3CD35142EEB2200A08AED /* JVMArgs.m in Sources */ = {isa = PBXBuildFile; fileRef = 89D3CD30142EEB2200A08AED /* JVMArgs.m */; }; + 89D3CD36142EEB2200A08AED /* main.m in Sources */ = {isa = PBXBuildFile; fileRef = 89D3CD31142EEB2200A08AED /* main.m */; }; + 89D3D365143041F000A08AED /* JavaAppLauncher.m in Sources */ = {isa = PBXBuildFile; fileRef = 89D3D364143041F000A08AED /* JavaAppLauncher.m */; }; + 8D11072F0486CEB800E47090 /* Cocoa.framework in Frameworks */ = {isa = PBXBuildFile; fileRef = 1058C7A1FEA54F0111CA2CBB /* Cocoa.framework */; }; /* End PBXBuildFile section */ /* Begin PBXCopyFilesBuildPhase section */ - 2C48F06614350F0F00F2AEFD /* Copy PlugIns */ = { - isa = PBXCopyFilesBuildPhase; - buildActionMask = 2147483647; - dstPath = ""; - dstSubfolderSpec = 13; - files = ( - 2C483E05143512EB00F2AEFD /* 1.7.0.jre in Copy PlugIns */, - ); - name = "Copy PlugIns"; - runOnlyForDeploymentPostprocessing = 0; - }; + 2C48F06614350F0F00F2AEFD /* Copy PlugIns */ = { + isa = PBXCopyFilesBuildPhase; + buildActionMask = 2147483647; + dstPath = ""; + dstSubfolderSpec = 13; + files = ( + 2C483E05143512EB00F2AEFD /* 1.7.0.jre in Copy PlugIns */, + ); + name = "Copy PlugIns"; + runOnlyForDeploymentPostprocessing = 0; + }; /* End PBXCopyFilesBuildPhase section */ /* Begin PBXFileReference section */ - 1058C7A1FEA54F0111CA2CBB /* Cocoa.framework */ = {isa = PBXFileReference; lastKnownFileType = wrapper.framework; name = Cocoa.framework; path = /System/Library/Frameworks/Cocoa.framework; sourceTree = ""; }; - 2C483E04143512EB00F2AEFD /* 1.7.0.jre */ = {isa = PBXFileReference; lastKnownFileType = folder; name = 1.7.0.jre; path = "../../../../../build/macosx-universal/j2sdk-bundle/1.7.0.jdk/Contents/Home/1.7.0.jre"; sourceTree = SOURCE_ROOT; }; - 2C48F06714350F8300F2AEFD /* 1.7.0.jdk */ = {isa = PBXFileReference; lastKnownFileType = folder; name = 1.7.0.jdk; path = "../../../../../build/macosx-universal/j2sdk-bundle/1.7.0.jdk"; sourceTree = SOURCE_ROOT; }; - 2CB5DA5E14355FCA00D3A656 /* classfile_constants.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = classfile_constants.h; sourceTree = ""; }; - 2CB5DA6014355FCA00D3A656 /* jawt_md.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jawt_md.h; sourceTree = ""; }; - 2CB5DA6114355FCA00D3A656 /* jni_md.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jni_md.h; sourceTree = ""; }; - 2CB5DA6214355FCA00D3A656 /* jawt.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jawt.h; sourceTree = ""; }; - 2CB5DA6314355FCA00D3A656 /* jdwpTransport.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jdwpTransport.h; sourceTree = ""; }; - 2CB5DA6414355FCA00D3A656 /* jni.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jni.h; sourceTree = ""; }; - 2CB5DA6514355FCA00D3A656 /* jvmti.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jvmti.h; sourceTree = ""; }; - 2CB5DA6614355FCA00D3A656 /* jvmticmlr.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jvmticmlr.h; sourceTree = ""; }; - 89D3CD2A142EEB2200A08AED /* English */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text.plist.strings; name = English; path = English.lproj/InfoPlist.strings; sourceTree = ""; }; - 89D3CD2B142EEB2200A08AED /* GenericApp.icns */ = {isa = PBXFileReference; lastKnownFileType = image.icns; name = GenericApp.icns; path = /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/GenericApp.icns; sourceTree = ""; }; - 89D3CD2C142EEB2200A08AED /* JavaAppLauncher-Info.plist */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text.plist.xml; path = "JavaAppLauncher-Info.plist"; sourceTree = ""; }; - 89D3CD2E142EEB2200A08AED /* JavaAppLauncher_Prefix.pch */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = JavaAppLauncher_Prefix.pch; sourceTree = ""; }; - 89D3CD2F142EEB2200A08AED /* JVMArgs.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = JVMArgs.h; sourceTree = ""; }; - 89D3CD30142EEB2200A08AED /* JVMArgs.m */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.objc; path = JVMArgs.m; sourceTree = ""; }; - 89D3CD31142EEB2200A08AED /* main.m */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.objc; path = main.m; sourceTree = ""; }; - 89D3D363143041F000A08AED /* JavaAppLauncher.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = JavaAppLauncher.h; sourceTree = ""; }; - 89D3D364143041F000A08AED /* JavaAppLauncher.m */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.objc; path = JavaAppLauncher.m; sourceTree = ""; }; - 8D1107320486CEB800E47090 /* JavaAppLauncher.app */ = {isa = PBXFileReference; explicitFileType = wrapper.application; includeInIndex = 0; path = JavaAppLauncher.app; sourceTree = BUILT_PRODUCTS_DIR; }; + 1058C7A1FEA54F0111CA2CBB /* Cocoa.framework */ = {isa = PBXFileReference; lastKnownFileType = wrapper.framework; name = Cocoa.framework; path = /System/Library/Frameworks/Cocoa.framework; sourceTree = ""; }; + 2C483E04143512EB00F2AEFD /* 1.7.0.jre */ = {isa = PBXFileReference; lastKnownFileType = folder; name = 1.7.0.jre; path = "../../../../../build/macosx-universal/j2re-image/1.7.0.jre"; sourceTree = SOURCE_ROOT; }; + 2C48F06714350F8300F2AEFD /* 1.7.0.jdk */ = {isa = PBXFileReference; lastKnownFileType = folder; name = 1.7.0.jdk; path = "../../../../../build/macosx-universal/j2sdk-image/1.7.0.jdk"; sourceTree = SOURCE_ROOT; }; + 377D6E8C14BCBCFD0038C98B /* classfile_constants.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = classfile_constants.h; sourceTree = ""; }; + 377D6E8E14BCBCFD0038C98B /* jawt_md.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jawt_md.h; sourceTree = ""; }; + 377D6E8F14BCBCFD0038C98B /* jni_md.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jni_md.h; sourceTree = ""; }; + 377D6E9014BCBCFD0038C98B /* jawt.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jawt.h; sourceTree = ""; }; + 377D6E9114BCBCFD0038C98B /* jdwpTransport.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jdwpTransport.h; sourceTree = ""; }; + 377D6E9214BCBCFD0038C98B /* jni.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jni.h; sourceTree = ""; }; + 377D6E9314BCBCFD0038C98B /* jvmti.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jvmti.h; sourceTree = ""; }; + 377D6E9414BCBCFD0038C98B /* jvmticmlr.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = jvmticmlr.h; sourceTree = ""; }; + 89D3CD2A142EEB2200A08AED /* English */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text.plist.strings; name = English; path = English.lproj/InfoPlist.strings; sourceTree = ""; }; + 89D3CD2B142EEB2200A08AED /* GenericApp.icns */ = {isa = PBXFileReference; lastKnownFileType = image.icns; name = GenericApp.icns; path = /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/GenericApp.icns; sourceTree = ""; }; + 89D3CD2C142EEB2200A08AED /* JavaAppLauncher-Info.plist */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text.plist.xml; path = "JavaAppLauncher-Info.plist"; sourceTree = ""; }; + 89D3CD2E142EEB2200A08AED /* JavaAppLauncher_Prefix.pch */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = JavaAppLauncher_Prefix.pch; sourceTree = ""; }; + 89D3CD2F142EEB2200A08AED /* JVMArgs.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = JVMArgs.h; sourceTree = ""; }; + 89D3CD30142EEB2200A08AED /* JVMArgs.m */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.objc; path = JVMArgs.m; sourceTree = ""; }; + 89D3CD31142EEB2200A08AED /* main.m */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.objc; path = main.m; sourceTree = ""; }; + 89D3D363143041F000A08AED /* JavaAppLauncher.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = JavaAppLauncher.h; sourceTree = ""; }; + 89D3D364143041F000A08AED /* JavaAppLauncher.m */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.objc; path = JavaAppLauncher.m; sourceTree = ""; }; + 8D1107320486CEB800E47090 /* JavaAppLauncher.app */ = {isa = PBXFileReference; explicitFileType = wrapper.application; includeInIndex = 0; path = JavaAppLauncher.app; sourceTree = BUILT_PRODUCTS_DIR; }; /* End PBXFileReference section */ /* Begin PBXFrameworksBuildPhase section */ - 8D11072E0486CEB800E47090 /* Frameworks */ = { - isa = PBXFrameworksBuildPhase; - buildActionMask = 2147483647; - files = ( - 8D11072F0486CEB800E47090 /* Cocoa.framework in Frameworks */, - ); - runOnlyForDeploymentPostprocessing = 0; - }; + 8D11072E0486CEB800E47090 /* Frameworks */ = { + isa = PBXFrameworksBuildPhase; + buildActionMask = 2147483647; + files = ( + 8D11072F0486CEB800E47090 /* Cocoa.framework in Frameworks */, + ); + runOnlyForDeploymentPostprocessing = 0; + }; /* End PBXFrameworksBuildPhase section */ /* Begin PBXGroup section */ - 1058C7A0FEA54F0111CA2CBB /* frameworks */ = { - isa = PBXGroup; - children = ( - 1058C7A1FEA54F0111CA2CBB /* Cocoa.framework */, - ); - name = frameworks; - sourceTree = ""; - }; - 19C28FACFE9D520D11CA2CBB /* Products */ = { - isa = PBXGroup; - children = ( - 8D1107320486CEB800E47090 /* JavaAppLauncher.app */, - ); - name = Products; - sourceTree = ""; - }; - 29B97314FDCFA39411CA2CEA /* JavaAppLauncher */ = { - isa = PBXGroup; - children = ( - 89D3CD2D142EEB2200A08AED /* src */, - 89D3CD28142EEB2200A08AED /* resources */, - 29B97323FDCFA39411CA2CEA /* linking */, - 19C28FACFE9D520D11CA2CBB /* Products */, - ); - name = JavaAppLauncher; - sourceTree = ""; - }; - 29B97323FDCFA39411CA2CEA /* linking */ = { - isa = PBXGroup; - children = ( - 2C48F06714350F8300F2AEFD /* 1.7.0.jdk */, - 2C483E04143512EB00F2AEFD /* 1.7.0.jre */, - 2CB5DA5D14355FCA00D3A656 /* include */, - 1058C7A0FEA54F0111CA2CBB /* frameworks */, - ); - name = linking; - sourceTree = ""; - }; - 2CB5DA5D14355FCA00D3A656 /* include */ = { - isa = PBXGroup; - children = ( - 2CB5DA5E14355FCA00D3A656 /* classfile_constants.h */, - 2CB5DA5F14355FCA00D3A656 /* darwin */, - 2CB5DA6214355FCA00D3A656 /* jawt.h */, - 2CB5DA6314355FCA00D3A656 /* jdwpTransport.h */, - 2CB5DA6414355FCA00D3A656 /* jni.h */, - 2CB5DA6514355FCA00D3A656 /* jvmti.h */, - 2CB5DA6614355FCA00D3A656 /* jvmticmlr.h */, - ); - name = include; - path = "../../../../../build/macosx-universal/j2sdk-bundle/1.7.0.jdk/Contents/Home/include"; - sourceTree = ""; - }; - 2CB5DA5F14355FCA00D3A656 /* darwin */ = { - isa = PBXGroup; - children = ( - 2CB5DA6014355FCA00D3A656 /* jawt_md.h */, - 2CB5DA6114355FCA00D3A656 /* jni_md.h */, - ); - path = darwin; - sourceTree = ""; - }; - 89D3CD28142EEB2200A08AED /* resources */ = { - isa = PBXGroup; - children = ( - 89D3CD29142EEB2200A08AED /* InfoPlist.strings */, - 89D3CD2B142EEB2200A08AED /* GenericApp.icns */, - 89D3CD2C142EEB2200A08AED /* JavaAppLauncher-Info.plist */, - ); - path = resources; - sourceTree = ""; - }; - 89D3CD2D142EEB2200A08AED /* src */ = { - isa = PBXGroup; - children = ( - 89D3CD31142EEB2200A08AED /* main.m */, - 89D3D363143041F000A08AED /* JavaAppLauncher.h */, - 89D3D364143041F000A08AED /* JavaAppLauncher.m */, - 89D3CD2F142EEB2200A08AED /* JVMArgs.h */, - 89D3CD30142EEB2200A08AED /* JVMArgs.m */, - 89D3CD2E142EEB2200A08AED /* JavaAppLauncher_Prefix.pch */, - ); - path = src; - sourceTree = ""; - }; + 1058C7A0FEA54F0111CA2CBB /* frameworks */ = { + isa = PBXGroup; + children = ( + 1058C7A1FEA54F0111CA2CBB /* Cocoa.framework */, + ); + name = frameworks; + sourceTree = ""; + }; + 19C28FACFE9D520D11CA2CBB /* Products */ = { + isa = PBXGroup; + children = ( + 8D1107320486CEB800E47090 /* JavaAppLauncher.app */, + ); + name = Products; + sourceTree = ""; + }; + 29B97314FDCFA39411CA2CEA /* JavaAppLauncher */ = { + isa = PBXGroup; + children = ( + 89D3CD2D142EEB2200A08AED /* src */, + 89D3CD28142EEB2200A08AED /* resources */, + 29B97323FDCFA39411CA2CEA /* linking */, + 19C28FACFE9D520D11CA2CBB /* Products */, + ); + name = JavaAppLauncher; + sourceTree = ""; + }; + 29B97323FDCFA39411CA2CEA /* linking */ = { + isa = PBXGroup; + children = ( + 377D6E8B14BCBCFD0038C98B /* include */, + 2C48F06714350F8300F2AEFD /* 1.7.0.jdk */, + 2C483E04143512EB00F2AEFD /* 1.7.0.jre */, + 1058C7A0FEA54F0111CA2CBB /* frameworks */, + ); + name = linking; + sourceTree = ""; + }; + 377D6E8B14BCBCFD0038C98B /* include */ = { + isa = PBXGroup; + children = ( + 377D6E8C14BCBCFD0038C98B /* classfile_constants.h */, + 377D6E8D14BCBCFD0038C98B /* darwin */, + 377D6E9014BCBCFD0038C98B /* jawt.h */, + 377D6E9114BCBCFD0038C98B /* jdwpTransport.h */, + 377D6E9214BCBCFD0038C98B /* jni.h */, + 377D6E9314BCBCFD0038C98B /* jvmti.h */, + 377D6E9414BCBCFD0038C98B /* jvmticmlr.h */, + ); + name = include; + path = "../../../../../build/macosx-universal/include"; + sourceTree = ""; + }; + 377D6E8D14BCBCFD0038C98B /* darwin */ = { + isa = PBXGroup; + children = ( + 377D6E8E14BCBCFD0038C98B /* jawt_md.h */, + 377D6E8F14BCBCFD0038C98B /* jni_md.h */, + ); + path = darwin; + sourceTree = ""; + }; + 89D3CD28142EEB2200A08AED /* resources */ = { + isa = PBXGroup; + children = ( + 89D3CD29142EEB2200A08AED /* InfoPlist.strings */, + 89D3CD2B142EEB2200A08AED /* GenericApp.icns */, + 89D3CD2C142EEB2200A08AED /* JavaAppLauncher-Info.plist */, + ); + path = resources; + sourceTree = ""; + }; + 89D3CD2D142EEB2200A08AED /* src */ = { + isa = PBXGroup; + children = ( + 89D3CD31142EEB2200A08AED /* main.m */, + 89D3D363143041F000A08AED /* JavaAppLauncher.h */, + 89D3D364143041F000A08AED /* JavaAppLauncher.m */, + 89D3CD2F142EEB2200A08AED /* JVMArgs.h */, + 89D3CD30142EEB2200A08AED /* JVMArgs.m */, + 89D3CD2E142EEB2200A08AED /* JavaAppLauncher_Prefix.pch */, + ); + path = src; + sourceTree = ""; + }; /* End PBXGroup section */ /* Begin PBXNativeTarget section */ - 8D1107260486CEB800E47090 /* JavaAppLauncher */ = { - isa = PBXNativeTarget; - buildConfigurationList = C01FCF4A08A954540054247B /* Build configuration list for PBXNativeTarget "JavaAppLauncher" */; - buildPhases = ( - 8D1107290486CEB800E47090 /* Resources */, - 2C48F06614350F0F00F2AEFD /* Copy PlugIns */, - 8D11072C0486CEB800E47090 /* Sources */, - 8D11072E0486CEB800E47090 /* Frameworks */, - ); - buildRules = ( - ); - dependencies = ( - ); - name = JavaAppLauncher; - productInstallPath = "$(HOME)/Applications"; - productName = JavaAppLauncher; - productReference = 8D1107320486CEB800E47090 /* JavaAppLauncher.app */; - productType = "com.apple.product-type.application"; - }; + 8D1107260486CEB800E47090 /* JavaAppLauncher */ = { + isa = PBXNativeTarget; + buildConfigurationList = C01FCF4A08A954540054247B /* Build configuration list for PBXNativeTarget "JavaAppLauncher" */; + buildPhases = ( + 8D1107290486CEB800E47090 /* Resources */, + 2C48F06614350F0F00F2AEFD /* Copy PlugIns */, + 8D11072C0486CEB800E47090 /* Sources */, + 8D11072E0486CEB800E47090 /* Frameworks */, + ); + buildRules = ( + ); + dependencies = ( + ); + name = JavaAppLauncher; + productInstallPath = "$(HOME)/Applications"; + productName = JavaAppLauncher; + productReference = 8D1107320486CEB800E47090 /* JavaAppLauncher.app */; + productType = "com.apple.product-type.application"; + }; /* End PBXNativeTarget section */ /* Begin PBXProject section */ - 29B97313FDCFA39411CA2CEA /* Project object */ = { - isa = PBXProject; - buildConfigurationList = C01FCF4E08A954540054247B /* Build configuration list for PBXProject "JavaAppLauncher" */; - compatibilityVersion = "Xcode 3.1"; - developmentRegion = English; - hasScannedForEncodings = 1; - knownRegions = ( - en, - English, - ); - mainGroup = 29B97314FDCFA39411CA2CEA /* JavaAppLauncher */; - projectDirPath = ""; - projectRoot = ""; - targets = ( - 8D1107260486CEB800E47090 /* JavaAppLauncher */, - ); - }; + 29B97313FDCFA39411CA2CEA /* Project object */ = { + isa = PBXProject; + attributes = { + LastUpgradeCheck = 0420; + }; + buildConfigurationList = C01FCF4E08A954540054247B /* Build configuration list for PBXProject "JavaAppLauncher" */; + compatibilityVersion = "Xcode 3.2"; + developmentRegion = English; + hasScannedForEncodings = 1; + knownRegions = ( + en, + English, + ); + mainGroup = 29B97314FDCFA39411CA2CEA /* JavaAppLauncher */; + projectDirPath = ""; + projectRoot = ""; + targets = ( + 8D1107260486CEB800E47090 /* JavaAppLauncher */, + ); + }; /* End PBXProject section */ /* Begin PBXResourcesBuildPhase section */ - 8D1107290486CEB800E47090 /* Resources */ = { - isa = PBXResourcesBuildPhase; - buildActionMask = 2147483647; - files = ( - 89D3CD32142EEB2200A08AED /* InfoPlist.strings in Resources */, - 89D3CD33142EEB2200A08AED /* GenericApp.icns in Resources */, - ); - runOnlyForDeploymentPostprocessing = 0; - }; + 8D1107290486CEB800E47090 /* Resources */ = { + isa = PBXResourcesBuildPhase; + buildActionMask = 2147483647; + files = ( + 89D3CD32142EEB2200A08AED /* InfoPlist.strings in Resources */, + 89D3CD33142EEB2200A08AED /* GenericApp.icns in Resources */, + ); + runOnlyForDeploymentPostprocessing = 0; + }; /* End PBXResourcesBuildPhase section */ /* Begin PBXSourcesBuildPhase section */ - 8D11072C0486CEB800E47090 /* Sources */ = { - isa = PBXSourcesBuildPhase; - buildActionMask = 2147483647; - files = ( - 89D3CD35142EEB2200A08AED /* JVMArgs.m in Sources */, - 89D3CD36142EEB2200A08AED /* main.m in Sources */, - 89D3D365143041F000A08AED /* JavaAppLauncher.m in Sources */, - ); - runOnlyForDeploymentPostprocessing = 0; - }; + 8D11072C0486CEB800E47090 /* Sources */ = { + isa = PBXSourcesBuildPhase; + buildActionMask = 2147483647; + files = ( + 89D3CD35142EEB2200A08AED /* JVMArgs.m in Sources */, + 89D3CD36142EEB2200A08AED /* main.m in Sources */, + 89D3D365143041F000A08AED /* JavaAppLauncher.m in Sources */, + ); + runOnlyForDeploymentPostprocessing = 0; + }; /* End PBXSourcesBuildPhase section */ /* Begin PBXVariantGroup section */ - 89D3CD29142EEB2200A08AED /* InfoPlist.strings */ = { - isa = PBXVariantGroup; - children = ( - 89D3CD2A142EEB2200A08AED /* English */, - ); - name = InfoPlist.strings; - sourceTree = ""; - }; + 89D3CD29142EEB2200A08AED /* InfoPlist.strings */ = { + isa = PBXVariantGroup; + children = ( + 89D3CD2A142EEB2200A08AED /* English */, + ); + name = InfoPlist.strings; + sourceTree = ""; + }; /* End PBXVariantGroup section */ /* Begin XCBuildConfiguration section */ - C01FCF4B08A954540054247B /* Debug */ = { - isa = XCBuildConfiguration; - buildSettings = { - ALWAYS_SEARCH_USER_PATHS = NO; - COPY_PHASE_STRIP = NO; - GCC_DYNAMIC_NO_PIC = NO; - GCC_ENABLE_FIX_AND_CONTINUE = YES; - GCC_MODEL_TUNING = G5; - GCC_OPTIMIZATION_LEVEL = 0; - GCC_PRECOMPILE_PREFIX_HEADER = YES; - GCC_PREFIX_HEADER = src/JavaAppLauncher_Prefix.pch; - INFOPLIST_FILE = "resources/JavaAppLauncher-Info.plist"; - INSTALL_PATH = "$(HOME)/Applications"; - LIBRARY_SEARCH_PATHS = "$(inherited)"; - PRODUCT_NAME = JavaAppLauncher; - }; - name = Debug; - }; - C01FCF4C08A954540054247B /* Release */ = { - isa = XCBuildConfiguration; - buildSettings = { - ALWAYS_SEARCH_USER_PATHS = NO; - DEBUG_INFORMATION_FORMAT = "dwarf-with-dsym"; - GCC_MODEL_TUNING = G5; - GCC_PRECOMPILE_PREFIX_HEADER = YES; - GCC_PREFIX_HEADER = src/JavaAppLauncher_Prefix.pch; - INFOPLIST_FILE = "resources/JavaAppLauncher-Info.plist"; - INSTALL_PATH = "$(HOME)/Applications"; - LIBRARY_SEARCH_PATHS = "$(inherited)"; - PRODUCT_NAME = JavaAppLauncher; - }; - name = Release; - }; - C01FCF4F08A954540054247B /* Debug */ = { - isa = XCBuildConfiguration; - buildSettings = { - ARCHS = "$(ARCHS_STANDARD_32_64_BIT)"; - GCC_C_LANGUAGE_STANDARD = gnu99; - GCC_OPTIMIZATION_LEVEL = 0; - GCC_WARN_ABOUT_RETURN_TYPE = YES; - GCC_WARN_UNUSED_VARIABLE = YES; - ONLY_ACTIVE_ARCH = YES; - PREBINDING = NO; - SDKROOT = ""; - }; - name = Debug; - }; - C01FCF5008A954540054247B /* Release */ = { - isa = XCBuildConfiguration; - buildSettings = { - ARCHS = "$(ARCHS_STANDARD_32_64_BIT)"; - GCC_C_LANGUAGE_STANDARD = gnu99; - GCC_WARN_ABOUT_RETURN_TYPE = YES; - GCC_WARN_UNUSED_VARIABLE = YES; - PREBINDING = NO; - SDKROOT = ""; - }; - name = Release; - }; + C01FCF4B08A954540054247B /* Debug */ = { + isa = XCBuildConfiguration; + buildSettings = { + ALWAYS_SEARCH_USER_PATHS = NO; + COPY_PHASE_STRIP = NO; + GCC_DYNAMIC_NO_PIC = NO; + GCC_MODEL_TUNING = G5; + GCC_OPTIMIZATION_LEVEL = 0; + GCC_PRECOMPILE_PREFIX_HEADER = YES; + GCC_PREFIX_HEADER = src/JavaAppLauncher_Prefix.pch; + INFOPLIST_FILE = "resources/JavaAppLauncher-Info.plist"; + INSTALL_PATH = "$(HOME)/Applications"; + LIBRARY_SEARCH_PATHS = "$(inherited)"; + PRODUCT_NAME = JavaAppLauncher; + }; + name = Debug; + }; + C01FCF4C08A954540054247B /* Release */ = { + isa = XCBuildConfiguration; + buildSettings = { + ALWAYS_SEARCH_USER_PATHS = NO; + DEBUG_INFORMATION_FORMAT = "dwarf-with-dsym"; + GCC_MODEL_TUNING = G5; + GCC_PRECOMPILE_PREFIX_HEADER = YES; + GCC_PREFIX_HEADER = src/JavaAppLauncher_Prefix.pch; + INFOPLIST_FILE = "resources/JavaAppLauncher-Info.plist"; + INSTALL_PATH = "$(HOME)/Applications"; + LIBRARY_SEARCH_PATHS = "$(inherited)"; + PRODUCT_NAME = JavaAppLauncher; + }; + name = Release; + }; + C01FCF4F08A954540054247B /* Debug */ = { + isa = XCBuildConfiguration; + buildSettings = { + ARCHS = "$(ARCHS_STANDARD_32_64_BIT)"; + GCC_C_LANGUAGE_STANDARD = gnu99; + GCC_OPTIMIZATION_LEVEL = 0; + GCC_WARN_ABOUT_RETURN_TYPE = YES; + GCC_WARN_UNUSED_VARIABLE = YES; + ONLY_ACTIVE_ARCH = YES; + SDKROOT = ""; + }; + name = Debug; + }; + C01FCF5008A954540054247B /* Release */ = { + isa = XCBuildConfiguration; + buildSettings = { + ARCHS = "$(ARCHS_STANDARD_32_64_BIT)"; + GCC_C_LANGUAGE_STANDARD = gnu99; + GCC_WARN_ABOUT_RETURN_TYPE = YES; + GCC_WARN_UNUSED_VARIABLE = YES; + SDKROOT = ""; + }; + name = Release; + }; /* End XCBuildConfiguration section */ /* Begin XCConfigurationList section */ - C01FCF4A08A954540054247B /* Build configuration list for PBXNativeTarget "JavaAppLauncher" */ = { - isa = XCConfigurationList; - buildConfigurations = ( - C01FCF4B08A954540054247B /* Debug */, - C01FCF4C08A954540054247B /* Release */, - ); - defaultConfigurationIsVisible = 0; - defaultConfigurationName = Release; - }; - C01FCF4E08A954540054247B /* Build configuration list for PBXProject "JavaAppLauncher" */ = { - isa = XCConfigurationList; - buildConfigurations = ( - C01FCF4F08A954540054247B /* Debug */, - C01FCF5008A954540054247B /* Release */, - ); - defaultConfigurationIsVisible = 0; - defaultConfigurationName = Release; - }; + C01FCF4A08A954540054247B /* Build configuration list for PBXNativeTarget "JavaAppLauncher" */ = { + isa = XCConfigurationList; + buildConfigurations = ( + C01FCF4B08A954540054247B /* Debug */, + C01FCF4C08A954540054247B /* Release */, + ); + defaultConfigurationIsVisible = 0; + defaultConfigurationName = Release; + }; + C01FCF4E08A954540054247B /* Build configuration list for PBXProject "JavaAppLauncher" */ = { + isa = XCConfigurationList; + buildConfigurations = ( + C01FCF4F08A954540054247B /* Debug */, + C01FCF5008A954540054247B /* Release */, + ); + defaultConfigurationIsVisible = 0; + defaultConfigurationName = Release; + }; /* End XCConfigurationList section */ - }; - rootObject = 29B97313FDCFA39411CA2CEA /* Project object */; + }; + rootObject = 29B97313FDCFA39411CA2CEA /* Project object */; } From artem.ananiev at oracle.com Wed Jan 11 05:49:38 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 11 Jan 2012 17:49:38 +0400 Subject: Review request for MACOSX_PORT-784: Program freeze when Swing is used with -XstartOnFirstThread In-Reply-To: <4F0D95F5.1060808@oracle.com> References: <4F0D95F5.1060808@oracle.com> Message-ID: <4F0D9372.7010300@oracle.com> Dmitry and I discussed this change offline, and I don't see any problems with the fix. However, it would be fine if anyone who is more familiar with OGL could also take a look. Thanks, Artem On 1/11/2012 6:00 PM, Dmitry Cherepanov wrote: > Hello, > > Please review a fix for http://java.net/jira/browse/MACOSX_PORT-784 at > > http://cr.openjdk.java.net/~dcherepanov/7128597/webrev.0/ > > To avoid the deadlock, the fix includes: > > - the addition of +[NSThread isMainThread] to ensure that we don't call > -performSelectorOnMainThread: when the current thread is the AppKit thread > - also, the fix doesn't invoke the getCGLConfigInfo method on the queue > flusher thread - after the fix, the getCGLConfigInfo method is executed > on the current thread directly. > > Thanks, > Dmitry > From artem.ananiev at oracle.com Wed Jan 11 05:50:28 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 11 Jan 2012 17:50:28 +0400 Subject: Review request for 7124217: [macosx] key events are posted to the event queue twice In-Reply-To: <4F0D9A8D.3000803@oracle.com> References: <4F0D9A8D.3000803@oracle.com> Message-ID: <4F0D93A4.4070201@oracle.com> Looks fine. Thanks, Artem On 1/11/2012 6:19 PM, Anton V. Tarasov wrote: > Hello, > > Please review a fix for 7124217. > > webrev: http://cr.openjdk.java.net/~ant/7124217/webrev.0/ > > Eliminating old code. No need to post key events via invokeLater, > they should be posted directly to the queue as it conforms to AWT > architecture. > > Checked that the fix doesn't cause regressions with the focus reg tests. > > Thanks, > Anton. > > From greg.x.brown at oracle.com Wed Jan 11 05:51:01 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 11 Jan 2012 08:51:01 -0500 Subject: [REVIEW] Update paths in JavaAppLauncher.xcodeproj In-Reply-To: References: Message-ID: Also, apologies if the format/process is not correct for this review request - I wasn't sure if this change required a bug # or not. If so, let me know and I'll file one. Thanks, Greg From anton.tarasov at oracle.com Wed Jan 11 06:51:40 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 11 Jan 2012 17:51:40 +0300 Subject: [7u4] Request for approval for CR 7124217 - [macosx] key events are posted to the event queue twice Message-ID: <4F0DA1FC.6090000@oracle.com> Hello, This is a request to push the following changes to jdk7u-osx. The fix has been reviewed on macosx-port-dev mailing list by Artem Ananiev. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124217 Webrev can be found at: http://cr.openjdk.java.net/~ant/7124217/webrev.0/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002131.html Thanks, Anton. From alexandr.scherbatiy at oracle.com Wed Jan 11 06:08:25 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 11 Jan 2012 18:08:25 +0400 Subject: [7u4] Request for approval for CR 7124515 [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items) Message-ID: <4F0D97D9.5090104@oracle.com> Hello, Please review a fix for 7124515 [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124515 webrev: http://cr.openjdk.java.net/~alexsch/7124515/webrev.00/ To avoid the IOBE the fix - Gets the selected value by the getSelectedValue() method and checks it to null instead of using the getSelectedIndex() index in the processKeyEvent() method - Checks the selected index bounds in the processMouseEvent() method The attached to the bug test is added to the repository. Mouse double click checking is added to the test. Thanks, Alexandr. From dmitry.cherepanov at oracle.com Wed Jan 11 07:06:27 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Wed, 11 Jan 2012 18:06:27 +0300 Subject: Review request for MACOSX_PORT-539: Need a java.awt.EmbeddedFrame subclass In-Reply-To: <4F0D8F4E.20204@oracle.com> References: <4EFC73FC.1060607@oracle.com> <4F0D4FE6.1010903@oracle.com> <4F0D8F4E.20204@oracle.com> Message-ID: <4F0DA573.6000306@oracle.com> Dmitry Cherepanov wrote: >> >> 2. Is there a reason to explicitly call addNotify() in CEF >> constructor? Will it be called automatically as a part of show()? > Done. Here's the update webrev: http://cr.openjdk.java.net/~dcherepanov/7124335/webrev.1/ >> 5. What is the reason of exporting the getPeer() method in the >> PlatformWindow interface? > It's done as a part of the changes in > src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java > > The change removes explicit reference to the CPlatformWindow class (to > make it working for CPlatformEmbeddedFrame) but it still needs to call > platformWindow.getPeer() (see the setBounds method). It could probably > be refactored into a more simplified code (to remove the getPeer > method from the PlatformWindow interface). I'll refactor the code as a part of http://java.net/jira/browse/MACOSX_PORT-78 (still open issue as there's a number of limitation of the current JAWT implementation). Thanks, Dmitry From dmitry.cherepanov at oracle.com Wed Jan 11 07:16:12 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Wed, 11 Jan 2012 18:16:12 +0300 Subject: [7u4-osx] Request for approval for 7124335: [macosx] Need a java.awt.EmbeddedFrame subclass Message-ID: <4F0DA7BC.7060402@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124335 Webrev: http://cr.openjdk.java.net/~dcherepanov/7124335/webrev.1/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-December/001982.html (Reviewed and approved by Artem Ananiev) Thanks, Dmitry From artem.ananiev at oracle.com Wed Jan 11 06:46:04 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 11 Jan 2012 18:46:04 +0400 Subject: [7u4-osx] Request for approval for 7124335: [macosx] Need a java.awt.EmbeddedFrame subclass In-Reply-To: <4F0DA7BC.7060402@oracle.com> References: <4F0DA7BC.7060402@oracle.com> Message-ID: <4F0DA0AC.9040606@oracle.com> Approved. Thanks, Artem On 1/11/2012 7:16 PM, Dmitry Cherepanov wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124335 > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7124335/webrev.1/ > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-December/001982.html > > (Reviewed and approved by Artem Ananiev) > > Thanks, > Dmitry From dmitry.cherepanov at oracle.com Wed Jan 11 07:11:06 2012 From: dmitry.cherepanov at oracle.com (dmitry.cherepanov at oracle.com) Date: Wed, 11 Jan 2012 15:11:06 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124335: [macosx] Need a java.awt.EmbeddedFrame subclass Message-ID: <20120111151126.7E0E04791E@hg.openjdk.java.net> Changeset: d7e5eb51caa3 Author: dcherepanov Date: 2012-01-11 19:07 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d7e5eb51caa3 7124335: [macosx] Need a java.awt.EmbeddedFrame subclass Reviewed-by: art ! make/sun/lwawt/FILES_export_macosx.gmk ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CDropTarget.java + src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CInputMethod.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java + src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java + src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CocoaConstants.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/classes/sun/lwawt/macosx/event/NSEvent.java ! src/macosx/native/sun/awt/AWTEvent.h ! src/macosx/native/sun/awt/AWTEvent.m ! src/macosx/native/sun/awt/AWTView.m From anthony.petrov at oracle.com Wed Jan 11 07:22:40 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 11 Jan 2012 19:22:40 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property Message-ID: <4F0DA940.7040203@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. -- best regards, Anthony From paul.hohensee at oracle.com Wed Jan 11 07:41:47 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 11 Jan 2012 10:41:47 -0500 Subject: [7u4] Request for approval for CR 7124283 - [macosx] Can't move focus out of a table with the keyboard In-Reply-To: <4F0D832E.3040205@oracle.com> References: <4F0D832E.3040205@oracle.com> Message-ID: <4F0DADBB.9010909@oracle.com> Approved in Artem's stead. Paul On 1/11/12 7:40 AM, Anton V. Tarasov wrote: > Hello, > > This is a request to push the following changes to jdk7u-osx. > The fix has been reviewed on macosx-port-dev mailing list by Anthony > Petrov. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124283 > Webrev can be found at: > http://cr.openjdk.java.net/~ant/7124283/v.1/webrev/ > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002121.html > > Thanks, > Anton. From alexander.potochkin at sun.com Wed Jan 11 08:01:33 2012 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Wed, 11 Jan 2012 16:01:33 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124540: [macosx] the Color panel is a black for ColorTest0005 Message-ID: <20120111160143.A392E47921@hg.openjdk.java.net> Changeset: c4b4f0b11530 Author: alexp Date: 2012-01-11 20:24 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/c4b4f0b11530 7124540: [macosx] the Color panel is a black for ColorTest0005 Reviewed-by: serb ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java From alexander.potochkin at sun.com Wed Jan 11 08:10:32 2012 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Wed, 11 Jan 2012 16:10:32 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7122256: scrollbar thumb is not full height in SThumbTest0001 Message-ID: <20120111161043.18C1C47922@hg.openjdk.java.net> Changeset: 034394d320df Author: alexp Date: 2012-01-11 20:34 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/034394d320df 7122256: scrollbar thumb is not full height in SThumbTest0001 Reviewed-by: serb ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java From Alexander.Potochkin at oracle.com Wed Jan 11 08:30:23 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Wed, 11 Jan 2012 20:30:23 +0400 Subject: Request for review: 7124530 What is background color of AWT component? (And foreground, for that matter) In-Reply-To: <4EFDC588.7070708@oracle.com> References: <4EFC6C63.5010806@oracle.com> <4EFCB242.7020704@oracle.com> <4EFDC588.7070708@oracle.com> Message-ID: <4F0DB91F.4030507@oracle.com> Hello Sergey okay, makes sense approved Thanks alexp > Hi Alexander > 29.12.2011 22:32, Alexander Potochkin wrote: >> Hello Sergey >>> Hi Everyone, >>> This is a fix for some glitches in the code for >>> background/foreground/font properties. >>> 1. SystemColor.window was changed to color which is used by default >>> in swing l&f(Aqua). Changes in AquaImageFactory.java and >>> CSystemColors.m. Now most of the awt components use this color as >>> default. >>> 2. set** methods were moved from LWWindowPeer to LWComponentPeer, >>> because there is an issues when these methods has no effect, because >>> repaint of the component does not happen.For example: >>> - call Label.setbackground which set component background property >>> - call Peer.setBackground >>> - call Delegate.setBackgound >>> - compare passed color with color from Label property, which was >>> set in the first step: changes in >>> LWWindowPeer,LWContainerPeer,LWComponentPeer. >> could you give more details on that? > By default delegates uses colors from DelegateContainer which take > color from targets. So if we set color for target(Label) -> then set > color for peer ->then set color for delegete. this code does not > repaint our component: > public void setBackground(Color bg) { > Color oldBg = getBackground(); > super.setBackground(bg); > if ((oldBg != null) ? !oldBg.equals(bg) : ((bg != null) && > !bg.equals(oldBg))) { > // background already bound in AWT1.2 > repaint(); > } > } > Because bg and oldBg will be the same color. >> >> the pattern where every peer has its delegate which is responsible >> for storing/repainting for colors and fonts >> looks more laconic and consistent to me. > This is true if all our components had delegates. But we has LWWindow > which has no delegate and LWCanvas which the delegate serves only for > storage of colors(By default LWComponentPeer has not delegates so we > cannot simplify old code and eliminate null checks).Probably delegate > from LWPanelPeer can be removed too. > And i think it would be better not to have similar code in different > classes. > For example I believe this is better > > protected final Color getBackground() { > synchronized (getStateLock()) { > return background; > } > } > > Than 2 different methods in different classes: > > protected Color getBackground() { > synchronized (getDelegateLock()) { > D delegate = getDelegate(); > if (delegate != null) { > return delegate.getBackground(); > } > } > return null; > } > > protected Color getBackground() { > synchronized (getStateLock()) { > return background; > } > } > > same for setters > public void setBackground(final Color c) { > final Color oldBg = getBackground(); > if (oldBg == c || (oldBg != null&& oldBg.equals(c))) { > return; > } > synchronized (getStateLock()) { > background = c; > } > final D delegate = getDelegate(); > if (delegate != null) { > synchronized (getDelegateLock()) { > // delegate will repaint the target > delegate.setBackground(c); > } > } else { > repaintPeer(); > } > } > > against: > > public void setBackground(Color c) { > final boolean changed; > synchronized (getStateLock()) { > changed = ((background != null) ? !background.equals(c) : > ((c != null)&& !c.equals(background))); > background = c; > } > if (changed) { > repaintPeer(); > } > } > > public void setBackground(Color c) { > synchronized (getDelegateLock()) { > D delegate = getDelegate(); > if (delegate != null) { > // delegate will repaint the target > delegate.setBackground(c); > } > } > } > >> >>> 3. List default color was changed to SystemColor.text: changes in >>> LWListPeer.java. >> >> LWListPeer set the font and colors to its view component, >> with the proposed fix it seems to update the scrollPane instead > But in resetColorsAndFont() we clear default colors for view and it > use colors from its parent ScrollableJList. >> >> >>> 4. LWWIndow target color initialization was moved from >>> CPlatformIndow to LWWindowPeer, so it can be reused later by >>> CPlatformEmbeddedFrame . >>> 5. unnecessary peers set** methods and unnecessary delegate in >>> LWCanvasPeer were removed: changes in LWCanvasPeer.java, >>> LWListPeer.java, LWPanelPeer.java. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7124530/webrev.00/ >>> >> >> Thanks >> alexp > > From artem.ananiev at oracle.com Wed Jan 11 09:08:51 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 11 Jan 2012 21:08:51 +0400 Subject: I tried my app with the current build and found some issues In-Reply-To: References: Message-ID: <4F0DC223.7060103@oracle.com> I'll take care of filing these two bugs. Thanks, Artem On 1/7/2012 6:08 PM, Joern Huxhorn wrote: > I don't know if those are new to you but when I start Lilith ( http://lilith.huxhorn.de ) I get the following error during startup: > > 2012-01-07 14:28:36.380 java[17379:407] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil > 2012-01-07 14:28:36.390 java[17379:407] ( > 0 CoreFoundation 0x00007fff91e44286 __exceptionPreprocess + 198 > 1 libobjc.A.dylib 0x00007fff9527cd5e objc_exception_throw + 43 > 2 CoreFoundation 0x00007fff91deb108 -[__NSArrayM insertObject:atIndex:] + 296 > 3 AppKit 0x00007fff895a4109 -[NSMenu insertItem:atIndex:] + 478 > 4 liblwawt.dylib 0x0000000113517c14 addMenuItem + 185 > 5 liblwawt.dylib 0x0000000113517905 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 > 6 liblwawt.dylib 0x0000000113517ee1 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 227 > 7 JavaNativeFoundation 0x00000001127595fd +[JNFRunLoop _performCopiedBlock:] + 20 > 8 CoreFoundation 0x00007fff91e6e0cd +[NSObject performSelector:withObject:] + 61 > 9 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 > 10 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 11 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 > 12 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 > 13 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 > 14 HIToolbox 0x00007fff8dd6d3d3 RunCurrentEventLoopInMode + 277 > 15 HIToolbox 0x00007fff8dd7463d ReceiveNextEventCommon + 355 > 16 HIToolbox 0x00007fff8dd744ca BlockUntilNextEventMatchingListInMode + 62 > 17 AppKit 0x00007fff8958d3f1 _DPSNextEvent + 659 > 18 AppKit 0x00007fff8958ccf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 > 19 libosxapp.dylib 0x000000011327882c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 > 20 AppKit 0x00007fff8958962d -[NSApplication run] + 470 > 21 libosxapp.dylib 0x000000011327874b +[NSApplicationAWT runAWTLoopWithApp:] + 156 > 22 liblwawt.dylib 0x0000000113515dad -[AWTStarter starter:] + 1616 > 23 CoreFoundation 0x00007fff91e33a1d -[NSObject performSelector:withObject:] + 61 > 24 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 > 25 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 26 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 > 27 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 > 28 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 > 29 java 0x000000010d93dcb4 CreateExecutionEnvironment + 841 > 30 java 0x000000010d93b7b8 JLI_Launch + 1933 > 31 java 0x000000010d93fa30 main + 108 > 32 java 0x000000010d9393f4 start + 52 > 33 ??? 0x0000000000000008 0x0 + 8 > ) > 2012-01-07 14:28:36.391 java[17379:407] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil > 2012-01-07 14:28:36.397 java[17379:407] ( > 0 CoreFoundation 0x00007fff91e44286 __exceptionPreprocess + 198 > 1 libobjc.A.dylib 0x00007fff9527cd5e objc_exception_throw + 43 > 2 CoreFoundation 0x00007fff91deb108 -[__NSArrayM insertObject:atIndex:] + 296 > 3 AppKit 0x00007fff895a4109 -[NSMenu insertItem:atIndex:] + 478 > 4 liblwawt.dylib 0x0000000113517c14 addMenuItem + 185 > 5 liblwawt.dylib 0x0000000113517905 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 > 6 liblwawt.dylib 0x0000000113517ee1 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 227 > 7 JavaNativeFoundation 0x00000001127595fd +[JNFRunLoop _performCopiedBlock:] + 20 > 8 CoreFoundation 0x00007fff91e6e0cd +[NSObject performSelector:withObject:] + 61 > 9 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 > 10 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 11 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 > 12 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 > 13 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 > 14 HIToolbox 0x00007fff8dd6d3d3 RunCurrentEventLoopInMode + 277 > 15 HIToolbox 0x00007fff8dd7458f ReceiveNextEventCommon + 181 > 16 HIToolbox 0x00007fff8dd744ca BlockUntilNextEventMatchingListInMode + 62 > 17 AppKit 0x00007fff8958d3f1 _DPSNextEvent + 659 > 18 AppKit 0x00007fff8958ccf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 > 19 libosxapp.dylib 0x000000011327882c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 > 20 AppKit 0x00007fff8958962d -[NSApplication run] + 470 > 21 libosxapp.dylib 0x000000011327874b +[NSApplicationAWT runAWTLoopWithApp:] + 156 > 22 liblwawt.dylib 0x0000000113515dad -[AWTStarter starter:] + 1616 > 23 CoreFoundation 0x00007fff91e33a1d -[NSObject performSelector:withObject:] + 61 > 24 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 > 25 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 26 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 > 27 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 > 28 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 > 29 java 0x000000010d93dcb4 CreateExecutionEnvironment + 841 > 30 java 0x000000010d93b7b8 JLI_Launch + 1933 > 31 java 0x000000010d93fa30 main + 108 > 32 java 0x000000010d9393f4 start + 52 > 33 ??? 0x0000000000000008 0x0 + 8 > ) > > Additionally, I saw that the accelerators are displayed as Meta instead of the Command symbol (⌘ ). > It also appears like something is wrong with java.util.preferences, i.e. it just doesn't work/save preferences. > > Hope this helps, > Joern. From artem.ananiev at oracle.com Wed Jan 11 09:09:16 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 11 Jan 2012 21:09:16 +0400 Subject: I tried my app with the current build and found some issues In-Reply-To: <1F4D66D1-9CFB-467A-A1B6-17959B9A1F6A@apple.com> References: <1F4D66D1-9CFB-467A-A1B6-17959B9A1F6A@apple.com> Message-ID: <4F0DC23C.2020902@oracle.com> I'll take care of filing these two bugs. Thanks, Artem On 1/9/2012 9:33 PM, Mike Swingler wrote: > On Jan 7, 2012, at 6:08 AM, Joern Huxhorn wrote: > >> I don't know if those are new to you but when I start Lilith ( http://lilith.huxhorn.de ) I get the following error during startup: >> >> 2012-01-07 14:28:36.380 java[17379:407] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil >> 2012-01-07 14:28:36.390 java[17379:407] ( >> 0 CoreFoundation 0x00007fff91e44286 __exceptionPreprocess + 198 >> 1 libobjc.A.dylib 0x00007fff9527cd5e objc_exception_throw + 43 >> 2 CoreFoundation 0x00007fff91deb108 -[__NSArrayM insertObject:atIndex:] + 296 >> 3 AppKit 0x00007fff895a4109 -[NSMenu insertItem:atIndex:] + 478 >> 4 liblwawt.dylib 0x0000000113517c14 addMenuItem + 185 >> 5 liblwawt.dylib 0x0000000113517905 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 >> 6 liblwawt.dylib 0x0000000113517ee1 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 227 >> 7 JavaNativeFoundation 0x00000001127595fd +[JNFRunLoop _performCopiedBlock:] + 20 >> 8 CoreFoundation 0x00007fff91e6e0cd +[NSObject performSelector:withObject:] + 61 >> 9 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 >> 10 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >> 11 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 >> 12 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 >> 13 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 >> 14 HIToolbox 0x00007fff8dd6d3d3 RunCurrentEventLoopInMode + 277 >> 15 HIToolbox 0x00007fff8dd7463d ReceiveNextEventCommon + 355 >> 16 HIToolbox 0x00007fff8dd744ca BlockUntilNextEventMatchingListInMode + 62 >> 17 AppKit 0x00007fff8958d3f1 _DPSNextEvent + 659 >> 18 AppKit 0x00007fff8958ccf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 >> 19 libosxapp.dylib 0x000000011327882c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 >> 20 AppKit 0x00007fff8958962d -[NSApplication run] + 470 >> 21 libosxapp.dylib 0x000000011327874b +[NSApplicationAWT runAWTLoopWithApp:] + 156 >> 22 liblwawt.dylib 0x0000000113515dad -[AWTStarter starter:] + 1616 >> 23 CoreFoundation 0x00007fff91e33a1d -[NSObject performSelector:withObject:] + 61 >> 24 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 >> 25 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >> 26 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 >> 27 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 >> 28 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 >> 29 java 0x000000010d93dcb4 CreateExecutionEnvironment + 841 >> 30 java 0x000000010d93b7b8 JLI_Launch + 1933 >> 31 java 0x000000010d93fa30 main + 108 >> 32 java 0x000000010d9393f4 start + 52 >> 33 ??? 0x0000000000000008 0x0 + 8 >> ) >> 2012-01-07 14:28:36.391 java[17379:407] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil >> 2012-01-07 14:28:36.397 java[17379:407] ( >> 0 CoreFoundation 0x00007fff91e44286 __exceptionPreprocess + 198 >> 1 libobjc.A.dylib 0x00007fff9527cd5e objc_exception_throw + 43 >> 2 CoreFoundation 0x00007fff91deb108 -[__NSArrayM insertObject:atIndex:] + 296 >> 3 AppKit 0x00007fff895a4109 -[NSMenu insertItem:atIndex:] + 478 >> 4 liblwawt.dylib 0x0000000113517c14 addMenuItem + 185 >> 5 liblwawt.dylib 0x0000000113517905 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 >> 6 liblwawt.dylib 0x0000000113517ee1 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 227 >> 7 JavaNativeFoundation 0x00000001127595fd +[JNFRunLoop _performCopiedBlock:] + 20 >> 8 CoreFoundation 0x00007fff91e6e0cd +[NSObject performSelector:withObject:] + 61 >> 9 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 >> 10 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >> 11 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 >> 12 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 >> 13 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 >> 14 HIToolbox 0x00007fff8dd6d3d3 RunCurrentEventLoopInMode + 277 >> 15 HIToolbox 0x00007fff8dd7458f ReceiveNextEventCommon + 181 >> 16 HIToolbox 0x00007fff8dd744ca BlockUntilNextEventMatchingListInMode + 62 >> 17 AppKit 0x00007fff8958d3f1 _DPSNextEvent + 659 >> 18 AppKit 0x00007fff8958ccf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 >> 19 libosxapp.dylib 0x000000011327882c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 >> 20 AppKit 0x00007fff8958962d -[NSApplication run] + 470 >> 21 libosxapp.dylib 0x000000011327874b +[NSApplicationAWT runAWTLoopWithApp:] + 156 >> 22 liblwawt.dylib 0x0000000113515dad -[AWTStarter starter:] + 1616 >> 23 CoreFoundation 0x00007fff91e33a1d -[NSObject performSelector:withObject:] + 61 >> 24 Foundation 0x00007fff93b3de44 __NSThreadPerformPerform + 214 >> 25 CoreFoundation 0x00007fff91db2b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >> 26 CoreFoundation 0x00007fff91db23bd __CFRunLoopDoSources0 + 253 >> 27 CoreFoundation 0x00007fff91dd91a9 __CFRunLoopRun + 905 >> 28 CoreFoundation 0x00007fff91dd8ae6 CFRunLoopRunSpecific + 230 >> 29 java 0x000000010d93dcb4 CreateExecutionEnvironment + 841 >> 30 java 0x000000010d93b7b8 JLI_Launch + 1933 >> 31 java 0x000000010d93fa30 main + 108 >> 32 java 0x000000010d9393f4 start + 52 >> 33 ??? 0x0000000000000008 0x0 + 8 >> ) > > This seems like a straightforward bug in the AWT/Cocoa menu handling code that could be solved with a nil check. Have you filed a bug at? > >> Additionally, I saw that the accelerators are displayed as Meta instead of the Command symbol (⌘ ). >> It also appears like something is wrong with java.util.preferences, i.e. it just doesn't work/save preferences. > > This should be another bug filed at. Apple's Java SE 6 has slightly different awt.properties files that have the unicode values instead of the full textual names of the key shortcuts. > > > > > > > Cheers, > ~Mike From leonid.romanov at oracle.com Wed Jan 11 09:48:18 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 11 Jan 2012 21:48:18 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F0DA940.7040203@oracle.com> References: <4F0DA940.7040203@oracle.com> Message-ID: Just wondering: what would happen if you simply set oldChildlevel without that "if" check? On 11.01.2012, at 19:22, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: > > http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ > > Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. > > A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. > > I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. > > -- > best regards, > Anthony From swingler at apple.com Wed Jan 11 10:39:54 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 11 Jan 2012 10:39:54 -0800 Subject: [REVIEW] Update paths in JavaAppLauncher.xcodeproj In-Reply-To: References: Message-ID: On Jan 11, 2012, at 5:51 AM, Greg Brown wrote: > Also, apologies if the format/process is not correct for this review request - I wasn't sure if this change required a bug # or not. If so, let me know and I'll file one. > Thanks, > Greg This change looks fine to me, but you should also note the version of Xcode you used to edit the project file. You will need a bug ID for this to be integrated. Regards, Mike Swingler Apple Inc. From scott.kovatch at oracle.com Wed Jan 11 10:43:40 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 11 Jan 2012 10:43:40 -0800 Subject: Review request: 7129152 -- multiple calls to System.setProperties(null) crash VM Message-ID: Hello, I finally put together a proper review package for 7129152, originally MACOSX_PORT-515. Please see: http://cr.openjdk.java.net/~skovatch/7129152/webrev.00/ We need to NULL out the proxy property storage so the next call won't attempt to free a bad pointer. Thanks, Scott K. From greg.x.brown at oracle.com Wed Jan 11 10:44:53 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 11 Jan 2012 13:44:53 -0500 Subject: [REVIEW] Update paths in JavaAppLauncher.xcodeproj In-Reply-To: References: Message-ID: <1D61DD82-81C9-44DC-9883-54EF4570C073@oracle.com> Thanks for the review - I'm using XCode 4.2. I'll create a ticket for this and re-send the review request. On Jan 11, 2012, at 1:39 PM, Mike Swingler wrote: > On Jan 11, 2012, at 5:51 AM, Greg Brown wrote: > >> Also, apologies if the format/process is not correct for this review request - I wasn't sure if this change required a bug # or not. If so, let me know and I'll file one. >> Thanks, >> Greg > > > This change looks fine to me, but you should also note the version of Xcode you used to edit the project file. You will need a bug ID for this to be integrated. > > Regards, > Mike Swingler > Apple Inc. > From swingler at apple.com Wed Jan 11 10:52:49 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 11 Jan 2012 10:52:49 -0800 Subject: Review request: 7129152 -- multiple calls to System.setProperties(null) crash VM In-Reply-To: References: Message-ID: On Jan 11, 2012, at 10:43 AM, Scott Kovatch wrote: > Hello, > > I finally put together a proper review package for 7129152, originally MACOSX_PORT-515. > > Please see: > > http://cr.openjdk.java.net/~skovatch/7129152/webrev.00/ > > We need to NULL out the proxy property storage so the next call won't attempt to free a bad pointer. > > Thanks, > Scott K. I approve: looks like good hygiene to NULL those out. Cheers, Mike Swingler Apple Inc. From kurchi.subhra.hazra at oracle.com Wed Jan 11 11:15:59 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 11 Jan 2012 11:15:59 -0800 Subject: Code Review Request: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X Message-ID: <4F0DDFEF.4000908@oracle.com> Hi, For IPv6 on solaris or linux, setting the traffic class option is handled in the java layer. The native calls to set socket option simply returns a success and get socket option returns a dummy -1 value. test/java/net/Socket/TrafficClass.java was failing on Mac OS X when using the IPv6 stack with an Invalid Argument Socket Exception since this native handling was missing when setting socket option. The following change incorporates the required native behavior for Mac OS. Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127771 (Not available yet) Webrev : http://cr.openjdk.java.net/~khazra/7127771/webrev.00/ Thanks, Kurchi From jason.uh at oracle.com Wed Jan 11 14:27:09 2012 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 11 Jan 2012 14:27:09 -0800 Subject: Review request: 7127448 Regression test scripts for policytool need to recognize macosx Message-ID: <4F0E0CBD.9070205@oracle.com> http://cr.openjdk.java.net/~juh/7127448/webrev.00/ Could I get the above change reviewed please? A simple addition for tests to recognize Darwin. Thanks, Jason From jason.uh at oracle.com Wed Jan 11 14:34:46 2012 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 11 Jan 2012 14:34:46 -0800 Subject: Review request: 7127874 Add handling of macosx env variables to ProcessBuilder regression test Message-ID: <4F0E0E86.3090200@oracle.com> Hi, Could I please get the following change reviewed? http://cr.openjdk.java.net/~juh/7127874/webrev.00/ This change to the test of ProcessBuilder adds handling of Mac OS and the environment variables that it adds -- namely, __CF_USER_TEXT_ENCODING and JAVA_MAIN_CLASS_. Thanks, Jason From swingler at apple.com Wed Jan 11 14:51:29 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 11 Jan 2012 14:51:29 -0800 Subject: Review request: 7127448 Regression test scripts for policytool need to recognize macosx In-Reply-To: <4F0E0CBD.9070205@oracle.com> References: <4F0E0CBD.9070205@oracle.com> Message-ID: On Jan 11, 2012, at 2:27 PM, Jason Uh wrote: > http://cr.openjdk.java.net/~juh/7127448/webrev.00/ > > Could I get the above change reviewed please? A simple addition for tests to recognize Darwin. Looks good to me. Regards, Mike Swingler Apple Inc. From swingler at apple.com Wed Jan 11 16:47:43 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 11 Jan 2012 16:47:43 -0800 Subject: Can't log onto wiki Message-ID: <70F5028E-D111-42DD-90CA-F3C2019A74CD@apple.com> Can anyone else log into the wiki ? Seems to be immediately signing me out as soon as I log in. There are no apparent links on the site or on the other OTN pages to report issues with the site. Any suggestions? Mike Swingler Apple Inc. From swingler at apple.com Wed Jan 11 16:47:43 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 11 Jan 2012 16:47:43 -0800 Subject: Can't log onto wiki Message-ID: <70F5028E-D111-42DD-90CA-F3C2019A74CD@apple.com> Can anyone else log into the wiki ? Seems to be immediately signing me out as soon as I log in. There are no apparent links on the site or on the other OTN pages to report issues with the site. Any suggestions? Mike Swingler Apple Inc. From jason.uh at oracle.com Wed Jan 11 17:25:29 2012 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 11 Jan 2012 17:25:29 -0800 Subject: Review request: 7129308 Handle OperatingSystemMXBean.getSystemLoadAverage() output on macosx Message-ID: <4F0E3689.3030204@oracle.com> Hi, This change handles the difference in the output text of /usr/bin/uptime on Mac OS X from that on Unix/Linux. Please see: http://cr.openjdk.java.net/~juh/7129308/webrev.00/ Note that output = output.substring(output.lastIndexOf(LOAD_AVERAGE_TEXT) + - LOAD_AVERAGE_TEXT.length()); + LOAD_AVERAGE_TEXT.length() + 1); serves to simply strip a space on all platforms. Thanks, Jason From scott.kovatch at oracle.com Wed Jan 11 17:25:57 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 11 Jan 2012 17:25:57 -0800 Subject: Can't log onto wiki In-Reply-To: <70F5028E-D111-42DD-90CA-F3C2019A74CD@apple.com> References: <70F5028E-D111-42DD-90CA-F3C2019A74CD@apple.com> Message-ID: <01EA399D-F492-4289-A39F-CCC392EAB74A@oracle.com> I just logged in with my Oracle ID. Today was also the first day I didn't get a complaint about the site certificate having a different domain than the one I was connecting to, so I guess there was another server update recently. Maybe you need to re-register? When I click on 'swingler' I get a user not found page. -- Scott K. On Jan 11, 2012, at 4:47 PM, Mike Swingler wrote: > Can anyone else log into the wiki ? > > Seems to be immediately signing me out as soon as I log in. > > There are no apparent links on the site or on the other OTN pages to report issues with the site. > > Any suggestions? > Mike Swingler > Apple Inc. > From johnyeary at gmail.com Wed Jan 11 17:28:38 2012 From: johnyeary at gmail.com (John Yeary) Date: Wed, 11 Jan 2012 20:28:38 -0500 Subject: Can't log onto wiki In-Reply-To: <70F5028E-D111-42DD-90CA-F3C2019A74CD@apple.com> References: <70F5028E-D111-42DD-90CA-F3C2019A74CD@apple.com> Message-ID: Hello Mike, I can log in, but it did prompt me with terms and conditions which it has not done before. John ____________________________ John Yeary ____________________________ ____________________________ "Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to take rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows not victory nor defeat." -- Theodore Roosevelt On Wed, Jan 11, 2012 at 7:47 PM, Mike Swingler wrote: > Can anyone else log into the wiki < > https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port>? > > Seems to be immediately signing me out as soon as I log in. > > There are no apparent links on the site or on the other OTN pages to > report issues with the site. > > Any suggestions? > Mike Swingler > Apple Inc. > > From jason.uh at oracle.com Wed Jan 11 17:56:23 2012 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 11 Jan 2012 17:56:23 -0800 Subject: Review request: 7127874 Add handling of macosx env variables to ProcessBuilder regression test In-Reply-To: <4F0E0E86.3090200@oracle.com> References: <4F0E0E86.3090200@oracle.com> Message-ID: <4F0E3DC7.70603@oracle.com> Sorry, please see instead: http://cr.openjdk.java.net/~juh/7127874/webrev.01/ I've changed + private static final boolean is = osName.startsWith("Mac OS X"); to + private static final boolean is = osName.startsWith("Mac OS"); Thanks, Jason On 1/11/12 2:34 PM, Jason Uh wrote: > Hi, > > Could I please get the following change reviewed? > > http://cr.openjdk.java.net/~juh/7127874/webrev.00/ > > > This change to the test of ProcessBuilder adds handling of Mac OS and > the environment > variables that it adds -- namely, __CF_USER_TEXT_ENCODING and > JAVA_MAIN_CLASS_. > > Thanks, > Jason From swingler at apple.com Wed Jan 11 18:04:45 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 11 Jan 2012 18:04:45 -0800 Subject: Can't log onto wiki In-Reply-To: <01EA399D-F492-4289-A39F-CCC392EAB74A@oracle.com> References: <70F5028E-D111-42DD-90CA-F3C2019A74CD@apple.com> <01EA399D-F492-4289-A39F-CCC392EAB74A@oracle.com> Message-ID: I did end up re-registering under a different identity, but now I can't edit anything (probably a time restriction to avoid spam bots). Ugh, Mike Swingler Apple Inc. On Jan 11, 2012, at 5:25 PM, Scott Kovatch wrote: > I just logged in with my Oracle ID. Today was also the first day I didn't get a complaint about the site certificate having a different domain than the one I was connecting to, so I guess there was another server update recently. > > Maybe you need to re-register? When I click on 'swingler' I get a user not found page. > > -- Scott K. > > > On Jan 11, 2012, at 4:47 PM, Mike Swingler wrote: > >> Can anyone else log into the wiki ? >> >> Seems to be immediately signing me out as soon as I log in. >> >> There are no apparent links on the site or on the other OTN pages to report issues with the site. >> >> Any suggestions? >> Mike Swingler >> Apple Inc. >> > From weijun.wang at oracle.com Thu Jan 12 00:35:58 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 12 Jan 2012 16:35:58 +0800 Subject: Review request: 7127448 Regression test scripts for policytool need to recognize macosx In-Reply-To: <4F0E0CBD.9070205@oracle.com> References: <4F0E0CBD.9070205@oracle.com> Message-ID: <4F0E9B6E.9070706@oracle.com> On 01/12/2012 06:27 AM, Jason Uh wrote: > http://cr.openjdk.java.net/~juh/7127448/webrev.00/ > > > Could I get the above change reviewed please? A simple addition for > tests to recognize Darwin. The code changes look fine. Thanks Max > > Thanks, > Jason From michael.x.mcmahon at oracle.com Thu Jan 12 03:22:08 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 12 Jan 2012 11:22:08 +0000 Subject: Code review: 7126979 (props) JCK test java_lang/System/GetProperties.java failing [macosx] Message-ID: <4F0EC260.1050605@oracle.com> Could I get the following change for jdk7u-osx reviewed please? http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/ The freeProps() call added by mac port can only be called once. Issue seen if System.setProperties(null) is called. GetJavaProperties() called a second time, which is supposed to return the statically populated information from first call. But some of it has been freed already. Fix is to remove the freeProps() code added in the original port changeset. The fix reverts the mac specific code to the original version. - Michael From michael.x.mcmahon at oracle.com Thu Jan 12 03:24:42 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 12 Jan 2012 11:24:42 +0000 Subject: Code Review: JVMTI Test DemoRun.java doesn't understand macosx .dylibs [macosx] Message-ID: <4F0EC2FA.3070508@oracle.com> Can I get the following test case change reviewed please? The test case needs to know about platform dynamic library suffixes. http://cr.openjdk.java.net/~michaelm/7122780/webrev.1/ Thanks, Michael. From Alan.Bateman at oracle.com Thu Jan 12 03:35:02 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Jan 2012 11:35:02 +0000 Subject: Code review: 7126979 (props) JCK test java_lang/System/GetProperties.java failing [macosx] In-Reply-To: <4F0EC260.1050605@oracle.com> References: <4F0EC260.1050605@oracle.com> Message-ID: <4F0EC566.4070407@oracle.com> On 12/01/2012 11:22, Michael McMahon wrote: > Could I get the following change for jdk7u-osx reviewed please? > > http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/ > > The freeProps() call added by mac port can only be called once. Issue > seen if System.setProperties(null) is called. > GetJavaProperties() called a second time, which is supposed to return > the statically populated information > from first call. But some of it has been freed already. > > Fix is to remove the freeProps() code added in the original port > changeset. The fix reverts the mac specific code > to the original version. > > - Michael I think this is the same issue that Scott Kovatch has under a different bugID; http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002148.html -Alan. From david.holmes at oracle.com Thu Jan 12 03:52:40 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Jan 2012 21:52:40 +1000 Subject: Code review: 7126979 (props) JCK test java_lang/System/GetProperties.java failing [macosx] In-Reply-To: <4F0EC260.1050605@oracle.com> References: <4F0EC260.1050605@oracle.com> Message-ID: <4F0EC988.5030405@oracle.com> Michael, There was a different patch for this posted earlier today where the props fields were all nulled out so they didn't reference the freed locations amy more. (I didn't keep the email) ??? David On 12/01/2012 9:22 PM, Michael McMahon wrote: > Could I get the following change for jdk7u-osx reviewed please? > > http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/ > > The freeProps() call added by mac port can only be called once. Issue > seen if System.setProperties(null) is called. > GetJavaProperties() called a second time, which is supposed to return > the statically populated information > from first call. But some of it has been freed already. > > Fix is to remove the freeProps() code added in the original port > changeset. The fix reverts the mac specific code > to the original version. > > - Michael > From sergey.bylokhov at oracle.com Thu Jan 12 04:24:15 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Jan 2012 16:24:15 +0400 Subject: [7u4] Request for approval for 7124530 - What is background color of AWT component? (And foreground, for that matter) Message-ID: <4F0ED0EF.90208@oracle.com> Hello, This is a request to push the following changes to jdk7u-osx. The fix has been reviewed on macosx-port-dev mailing list by Alexander Potochkin. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124530/webrev.00/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002143.html -- Best regards, Sergey. From michael.x.mcmahon at oracle.com Thu Jan 12 04:49:00 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 12 Jan 2012 12:49:00 +0000 Subject: Code review: 7126979 (props) JCK test java_lang/System/GetProperties.java failing [macosx] In-Reply-To: <4F0EC988.5030405@oracle.com> References: <4F0EC260.1050605@oracle.com> <4F0EC988.5030405@oracle.com> Message-ID: <4F0ED6BC.3070405@oracle.com> Thanks David. Just found it now (Alan noticed it too). Scott sent his webrev yesterday. It looks like both solutions fix the problem. The difference is that Scott's re-initializes the properties from native code each time System.initProperties() is called. On the other platforms, we only call it once. So, do we want Macos to diverge slightly from the other platforms in this respect? My preference is to keep the platforms as similar as possible, minimising the changes with jdk7u ... - Michael. On 12/01/12 11:52, David Holmes wrote: > Michael, > > There was a different patch for this posted earlier today where the > props fields were all nulled out so they didn't reference the freed > locations amy more. (I didn't keep the email) > > ??? > > David > > On 12/01/2012 9:22 PM, Michael McMahon wrote: >> Could I get the following change for jdk7u-osx reviewed please? >> >> http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/ >> >> The freeProps() call added by mac port can only be called once. Issue >> seen if System.setProperties(null) is called. >> GetJavaProperties() called a second time, which is supposed to return >> the statically populated information >> from first call. But some of it has been freed already. >> >> Fix is to remove the freeProps() code added in the original port >> changeset. The fix reverts the mac specific code >> to the original version. >> >> - Michael >> From david.holmes at oracle.com Thu Jan 12 05:02:29 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Jan 2012 23:02:29 +1000 Subject: Code review: 7126979 (props) JCK test java_lang/System/GetProperties.java failing [macosx] In-Reply-To: <4F0ED6BC.3070405@oracle.com> References: <4F0EC260.1050605@oracle.com> <4F0EC988.5030405@oracle.com> <4F0ED6BC.3070405@oracle.com> Message-ID: <4F0ED9E5.9070800@oracle.com> On 12/01/2012 10:49 PM, Michael McMahon wrote: > Thanks David. Just found it now (Alan noticed it too). Scott sent his > webrev yesterday. > > It looks like both solutions fix the problem. The difference is that > Scott's re-initializes > the properties from native code each time System.initProperties() is > called. > On the other platforms, we only call it once. > > So, do we want Macos to diverge slightly from the other platforms in > this respect? I haven't compared things in detail but If there is no need to diverge then I would not diverge. David ----- > My preference is to keep the platforms as similar as possible, > minimising the changes > with jdk7u ... > > - Michael. > > On 12/01/12 11:52, David Holmes wrote: >> Michael, >> >> There was a different patch for this posted earlier today where the >> props fields were all nulled out so they didn't reference the freed >> locations amy more. (I didn't keep the email) >> >> ??? >> >> David >> >> On 12/01/2012 9:22 PM, Michael McMahon wrote: >>> Could I get the following change for jdk7u-osx reviewed please? >>> >>> http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/ >>> >>> The freeProps() call added by mac port can only be called once. Issue >>> seen if System.setProperties(null) is called. >>> GetJavaProperties() called a second time, which is supposed to return >>> the statically populated information >>> from first call. But some of it has been freed already. >>> >>> Fix is to remove the freeProps() code added in the original port >>> changeset. The fix reverts the mac specific code >>> to the original version. >>> >>> - Michael >>> > From anthony.petrov at oracle.com Thu Jan 12 05:06:51 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 12 Jan 2012 17:06:51 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: References: <4F0DA940.7040203@oracle.com> Message-ID: <4F0EDAEB.7090404@oracle.com> Hi Leonid, Thanks for taking a look at the fix. The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. -- best regards, Anthony On 01/11/12 21:48, Leonid Romanov wrote: > Just wondering: what would happen if you simply set oldChildlevel without that "if" check? > > On 11.01.2012, at 19:22, Anthony Petrov wrote: > >> Hello, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >> >> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >> >> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >> >> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >> >> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >> >> -- >> best regards, >> Anthony > From leonid.romanov at oracle.com Thu Jan 12 05:23:37 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 12 Jan 2012 17:23:37 +0400 Subject: [7u4] Request for approval for CR 7124368: UnsupportedOperationException is thown on getLockingKeyState() Message-ID: Hi, This a request to push the following changes to jdk7u-osx. CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124368 Webrev: http://cr.openjdk.java.net/~leonidr/7124368/webrev.01/ The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. Thanks, Leonid. From leonid.romanov at oracle.com Thu Jan 12 05:44:20 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 12 Jan 2012 17:44:20 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F0EDAEB.7090404@oracle.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> Message-ID: <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? On 12.01.2012, at 17:06, Anthony Petrov wrote: > Hi Leonid, > > Thanks for taking a look at the fix. > > The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. > > Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. > > -- > best regards, > Anthony > > On 01/11/12 21:48, Leonid Romanov wrote: >> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >> >> On 11.01.2012, at 19:22, Anthony Petrov wrote: >> >>> Hello, >>> >>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>> >>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>> >>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>> >>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>> >>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>> >>> -- >>> best regards, >>> Anthony >> From artem.ananiev at oracle.com Thu Jan 12 05:46:13 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 12 Jan 2012 17:46:13 +0400 Subject: [7u4] Request for approval for CR 7124515 [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items) In-Reply-To: <4F0D97D9.5090104@oracle.com> References: <4F0D97D9.5090104@oracle.com> Message-ID: <4F0EE425.9080306@oracle.com> Hi, Alexander, the fix looks fine and corresponds to what we do on other platforms. Thanks, Artem On 1/11/2012 6:08 PM, Alexander Scherbatiy wrote: > Hello, > > Please review a fix for > 7124515 [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException > pressing ENTER after removing items) > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124515 > > webrev: http://cr.openjdk.java.net/~alexsch/7124515/webrev.00/ > > To avoid the IOBE the fix > - Gets the selected value by the getSelectedValue() method and checks it > to null instead of using the getSelectedIndex() index in the > processKeyEvent() method > - Checks the selected index bounds in the processMouseEvent() method > > The attached to the bug test is added to the repository. > Mouse double click checking is added to the test. > > > Thanks, > Alexandr. > From anthony.petrov at oracle.com Thu Jan 12 05:52:52 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 12 Jan 2012 17:52:52 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> Message-ID: <4F0EE5B4.4090607@oracle.com> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. -- best regards, Anthony On 01/12/12 17:44, Leonid Romanov wrote: > I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. > Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? > > On 12.01.2012, at 17:06, Anthony Petrov wrote: > >> Hi Leonid, >> >> Thanks for taking a look at the fix. >> >> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >> >> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >> >> -- >> best regards, >> Anthony >> >> On 01/11/12 21:48, Leonid Romanov wrote: >>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>> >>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>> >>>> Hello, >>>> >>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>> >>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>> >>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>> >>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>> >>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>> >>>> -- >>>> best regards, >>>> Anthony >>> > From artem.ananiev at oracle.com Thu Jan 12 06:01:47 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 12 Jan 2012 18:01:47 +0400 Subject: [7u4] Request for approval for CR 7124217 - [macosx] key events are posted to the event queue twice In-Reply-To: <4F0DA1FC.6090000@oracle.com> References: <4F0DA1FC.6090000@oracle.com> Message-ID: <4F0EE7CB.2080306@oracle.com> Approved. On 1/11/2012 6:51 PM, Anton V. Tarasov wrote: > Hello, > > This is a request to push the following changes to jdk7u-osx. > The fix has been reviewed on macosx-port-dev mailing list by Artem Ananiev. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124217 > Webrev can be found at: http://cr.openjdk.java.net/~ant/7124217/webrev.0/ > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002131.html > > > Thanks, > Anton. From alexandr.scherbatiy at oracle.com Thu Jan 12 06:14:19 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 12 Jan 2012 06:14:19 -0800 (PST) Subject: [7u4] Request for approval for CR 7124515 - [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items) Message-ID: <4F0EEABB.9000301@oracle.com> Hello, This a request to push the following changes to jdk7u-osx. CR 7124515 [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124515 Webrev: http://cr.openjdk.java.net/~alexsch/7124515/webrev.00/ The fix has been reviewed on macosx-port-dev mailing list by Artem Ananiev. Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002173.html Thanks, Alexandr. From leonid.romanov at oracle.com Thu Jan 12 06:21:01 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 12 Jan 2012 18:21:01 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F0EE5B4.4090607@oracle.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> Message-ID: Yep, you are right. I'm just not comfortable with hardcoded window levels array. But it seems there is no way around it, unfortunately. On 12.01.2012, at 17:52, Anthony Petrov wrote: > The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. > > -- > best regards, > Anthony > > On 01/12/12 17:44, Leonid Romanov wrote: >> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >> >> On 12.01.2012, at 17:06, Anthony Petrov wrote: >> >>> Hi Leonid, >>> >>> Thanks for taking a look at the fix. >>> >>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>> >>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 01/11/12 21:48, Leonid Romanov wrote: >>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>> >>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>> >>>>> Hello, >>>>> >>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>> >>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>> >>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>> >>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>> >> From leonid.romanov at oracle.com Thu Jan 12 06:34:33 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 12 Jan 2012 18:34:33 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F0EE5B4.4090607@oracle.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> Message-ID: Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. On 12.01.2012, at 17:52, Anthony Petrov wrote: > The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. > > -- > best regards, > Anthony > > On 01/12/12 17:44, Leonid Romanov wrote: >> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >> >> On 12.01.2012, at 17:06, Anthony Petrov wrote: >> >>> Hi Leonid, >>> >>> Thanks for taking a look at the fix. >>> >>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>> >>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 01/11/12 21:48, Leonid Romanov wrote: >>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>> >>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>> >>>>> Hello, >>>>> >>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>> >>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>> >>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>> >>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>> >> From daniel.daugherty at oracle.com Thu Jan 12 07:11:47 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 12 Jan 2012 08:11:47 -0700 Subject: Code Review: JVMTI Test DemoRun.java doesn't understand macosx .dylibs [macosx] In-Reply-To: <4F0EC2FA.3070508@oracle.com> References: <4F0EC2FA.3070508@oracle.com> Message-ID: <4F0EF833.5050909@oracle.com> In another review, I think I saw "startsWith("Mac OS") being recommended... Dan On 1/12/12 4:24 AM, Michael McMahon wrote: > Can I get the following test case change reviewed please? > > The test case needs to know about platform dynamic library suffixes. > > http://cr.openjdk.java.net/~michaelm/7122780/webrev.1/ > > Thanks, > Michael. > > From michael.x.mcmahon at oracle.com Thu Jan 12 08:29:00 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 12 Jan 2012 16:29:00 +0000 Subject: Code Review: JVMTI Test DemoRun.java doesn't understand macosx .dylibs [macosx] In-Reply-To: <4F0EF833.5050909@oracle.com> References: <4F0EC2FA.3070508@oracle.com> <4F0EF833.5050909@oracle.com> Message-ID: <4F0F0A4C.3050501@oracle.com> On 12/01/12 15:11, Daniel D. Daugherty wrote: > In another review, I think I saw "startsWith("Mac OS") being > recommended... > Yes, there was, although I think the alternative was "Mac OS X Server". But I don't see any harm in using "Mac OS" either. So, I'll change it. Thanks Michael > Dan > > > On 1/12/12 4:24 AM, Michael McMahon wrote: >> Can I get the following test case change reviewed please? >> >> The test case needs to know about platform dynamic library suffixes. >> >> http://cr.openjdk.java.net/~michaelm/7122780/webrev.1/ >> >> Thanks, >> Michael. >> >> From swingler at apple.com Thu Jan 12 11:17:38 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 12 Jan 2012 11:17:38 -0800 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> Message-ID: <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. Regards, Mike Swingler Apple Inc. On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: > Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. > > > On 12.01.2012, at 17:52, Anthony Petrov wrote: > >> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >> >> -- >> best regards, >> Anthony >> >> On 01/12/12 17:44, Leonid Romanov wrote: >>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>> >>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>> >>>> Hi Leonid, >>>> >>>> Thanks for taking a look at the fix. >>>> >>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>> >>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>> >>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>> >>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>> >>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>> >>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>> >>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>> >>> > From anthony.petrov at oracle.com Thu Jan 12 11:57:31 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 12 Jan 2012 23:57:31 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> Message-ID: <4F0F3B2B.7040101@oracle.com> Hi Mike, I recall we've discussed this issue with you back in 2010. Unfortunately, I wasn't able to implement anything like this that would work reliably back then (and I tried hard, really), that's why we ended up with -addChildWindow:. Note that JCK is very happy with this implementation, and so are we, I presume. As long as child windows receive their respective MOVE events, it seems that everything is all right. Besides, such behavior is very Mac-friendly, making Java apps behave like native apps. I realize that for some developers this behavior may be inconvenient. But then again, why not listen to MOVE events on the parent frame and compensate for its movement repositioning all its children? ( :) yeah, yeah, I know, sounds weird, but... as Steve says, you gotta do what you gotta do... I mean, there's a workaround at least!) So, if you or anyone else wish to contribute an alternative implementation for owned windows, that would be greatly appreciated. Otherwise I'm afraid we have to stick with using -addChildWindow: for now since we simply don't have a better solution. -- best regards, Anthony On 1/12/2012 11:17 PM, Mike Swingler wrote: > Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). > > In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. > > Regards, > Mike Swingler > Apple Inc. > > On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: > >> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. >> >> >> On 12.01.2012, at 17:52, Anthony Petrov wrote: >> >>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 01/12/12 17:44, Leonid Romanov wrote: >>>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>>> >>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>> >>>>> Hi Leonid, >>>>> >>>>> Thanks for taking a look at the fix. >>>>> >>>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>> >>>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>>> >>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>> >>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>>> >>>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>>> >>>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony > From steve.x.northover at oracle.com Thu Jan 12 14:13:51 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 12 Jan 2012 17:13:51 -0500 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F0F3B2B.7040101@oracle.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> Message-ID: <4F0F5B1F.5070601@oracle.com> We fought this one in SWT and ended up going with the puppy route. Steve On 12/01/2012 2:57 PM, Anthony Petrov wrote: > Hi Mike, > > I recall we've discussed this issue with you back in 2010. > Unfortunately, I wasn't able to implement anything like this that > would work reliably back then (and I tried hard, really), that's why > we ended up with -addChildWindow:. Note that JCK is very happy with > this implementation, and so are we, I presume. As long as child > windows receive their respective MOVE events, it seems that everything > is all right. Besides, such behavior is very Mac-friendly, making Java > apps behave like native apps. > > I realize that for some developers this behavior may be inconvenient. > But then again, why not listen to MOVE events on the parent frame and > compensate for its movement repositioning all its children? ( :) yeah, > yeah, I know, sounds weird, but... as Steve says, you gotta do what > you gotta do... I mean, there's a workaround at least!) > > So, if you or anyone else wish to contribute an alternative > implementation for owned windows, that would be greatly appreciated. > Otherwise I'm afraid we have to stick with using -addChildWindow: for > now since we simply don't have a better solution. > > -- > best regards, > Anthony > > On 1/12/2012 11:17 PM, Mike Swingler wrote: >> Also, you should not use -addChildWindow:, because you also get added >> to the movement group of the parent (moving the parent moves all it's >> children). This is *highly* undesirable behavior for Java's general >> use (and you can see it in Eclipse when the find window follows >> around the IDE window like a puppy). >> >> In the Java SE 6 AWT we manually restack every Java window in native >> with -orderFront: every time a Java window changes it's level to >> correctly handle it's children and the relationships between them. >> This actually works out ok, since all the changes happen at once, and >> when the next turn of the event loop happens, the new stacking order >> only has one new window moving to the background and one new window >> becoming key/main. >> >> Regards, >> Mike Swingler >> Apple Inc. >> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >> >>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it >>> was a wrong suggestion to rely on it. Sorry for wasting your time. >>> >>> >>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>> >>>> The values of the NS*WindowLevel macros are not a part of the >>>> contract for Cocoa API. Therefore, we shouldn't rely on their >>>> current numerical values. The names, however, and their relative >>>> z-order are clearly specified in the documentation, and as such we >>>> may use them. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>> I see? It looks like the higher window level is, the higher is the >>>>> value of corresponding NS*WindowLevel macro. >>>>> Wouldn't it be better to implement compareWindowLevels() by simply >>>>> subtracting one value from another? >>>>> >>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>> >>>>>> Hi Leonid, >>>>>> >>>>>> Thanks for taking a look at the fix. >>>>>> >>>>>> The if check is needed for the following case. If the parent >>>>>> window is an always-on-top window, its level is >>>>>> NSFloatingWindowLevel. Suppose a child window being added to it >>>>>> hasn't been assigned any level explicitly, so its default level >>>>>> is NSNormalWindowLevel. >>>>>> >>>>>> Now, when we call -addChildWindow:, we really want to update the >>>>>> level of the child window so that both the parent and the child >>>>>> share the same window level. The if check ensures that we don't >>>>>> reset the level of the child window back to normal in this case. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>> Just wondering: what would happen if you simply set >>>>>>> oldChildlevel without that "if" check? >>>>>>> >>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review a fix for >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>> >>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. >>>>>>>> I'm just going to integrate it into the repository. >>>>>>>> >>>>>>>> A JWindow object is always a child window with either an >>>>>>>> explicit parent, or a shared invisible owner frame. Therefore, >>>>>>>> we always call NSWindow -addChildWindow: when showing a JWindow >>>>>>>> object. The root cause of the issue is that the >>>>>>>> -addChildWindow: resets the level of the child window to match >>>>>>>> that of the parent window. With this fix we restore the level >>>>>>>> back to its original value after the -addChildWindow: call, and >>>>>>>> as such preserve the always-on-top state of the child window. >>>>>>>> >>>>>>>> I've verified the fix with a test app attached to the original >>>>>>>> issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it >>>>>>>> works fine. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >> From swingler at apple.com Thu Jan 12 18:30:02 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 12 Jan 2012 18:30:02 -0800 Subject: [7u4] Request for approval for 7124530 - What is background color of AWT component? (And foreground, for that matter) In-Reply-To: <4F0ED0EF.90208@oracle.com> References: <4F0ED0EF.90208@oracle.com> Message-ID: On Jan 12, 2012, at 4:24 AM, Sergey Bylokhov wrote: > Hello, > This is a request to push the following changes to jdk7u-osx. > The fix has been reviewed on macosx-port-dev mailing list by Alexander Potochkin. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124530/webrev.00/ > Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002143.html I don't understand this part: --- old/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 19:02:19.913935900 +0400 +++ new/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 19:02:19.557915600 +0400 @@ -81,7 +81,8 @@ sColors[java_awt_SystemColor_INACTIVE_CAPTION] = [NSColor grayColor]; sColors[java_awt_SystemColor_INACTIVE_CAPTION_TEXT] = [NSColor grayColor]; sColors[java_awt_SystemColor_INACTIVE_CAPTION_BORDER] = [NSColor grayColor]; - sColors[java_awt_SystemColor_WINDOW] = [NSColor grayColor]; + const CGFloat color = (CGFloat)0xEE/(CGFloat)0xFF; + sColors[java_awt_SystemColor_WINDOW] = [NSColor colorWithCalibratedRed:color green:color blue:color alpha:1.0f]; sColors[java_awt_SystemColor_WINDOW_BORDER] = [NSColor windowFrameColor]; sColors[java_awt_SystemColor_WINDOW_TEXT] = [NSColor windowFrameTextColor]; sColors[java_awt_SystemColor_MENU] = [NSColor controlBackgroundColor]; Why aren't you just using [NSColor windowBackgroundColor]? Regards, Mike Swingler Apple Inc. From david.katleman at sun.com Thu Jan 12 20:24:06 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 13 Jan 2012 04:24:06 +0000 Subject: hg: jdk7u/jdk7u-osx: Added tag jdk7u4-b225 for changeset 2fea92d741b7 Message-ID: <20120113042406.9B2E847950@hg.openjdk.java.net> Changeset: 78bada8c9399 Author: katleman Date: 2012-01-12 14:22 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/rev/78bada8c9399 Added tag jdk7u4-b225 for changeset 2fea92d741b7 ! .hgtags From david.katleman at sun.com Thu Jan 12 20:24:13 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 13 Jan 2012 04:24:13 +0000 Subject: hg: jdk7u/jdk7u-osx/corba: Added tag jdk7u4-b225 for changeset 48ac2f190ad1 Message-ID: <20120113042414.55E2D47951@hg.openjdk.java.net> Changeset: c5196709389f Author: katleman Date: 2012-01-12 14:22 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/c5196709389f Added tag jdk7u4-b225 for changeset 48ac2f190ad1 ! .hgtags From david.katleman at sun.com Thu Jan 12 20:24:52 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 13 Jan 2012 04:24:52 +0000 Subject: hg: jdk7u/jdk7u-osx/hotspot: Added tag jdk7u4-b225 for changeset 2a7035cd6540 Message-ID: <20120113042454.B44F147952@hg.openjdk.java.net> Changeset: baf93bc2ac8e Author: katleman Date: 2012-01-12 14:22 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/baf93bc2ac8e Added tag jdk7u4-b225 for changeset 2a7035cd6540 ! .hgtags From david.katleman at sun.com Thu Jan 12 20:26:25 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 13 Jan 2012 04:26:25 +0000 Subject: hg: jdk7u/jdk7u-osx/jaxp: Added tag jdk7u4-b225 for changeset a7da5cf6decb Message-ID: <20120113042625.34DEB47953@hg.openjdk.java.net> Changeset: 7ef24eef3d3b Author: katleman Date: 2012-01-12 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/7ef24eef3d3b Added tag jdk7u4-b225 for changeset a7da5cf6decb ! .hgtags From david.katleman at sun.com Thu Jan 12 20:26:39 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 13 Jan 2012 04:26:39 +0000 Subject: hg: jdk7u/jdk7u-osx/jaxws: Added tag jdk7u4-b225 for changeset 596322b0a046 Message-ID: <20120113042639.7E68947954@hg.openjdk.java.net> Changeset: ad0ae0931945 Author: katleman Date: 2012-01-12 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxws/rev/ad0ae0931945 Added tag jdk7u4-b225 for changeset 596322b0a046 ! .hgtags From david.katleman at sun.com Thu Jan 12 20:27:02 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 13 Jan 2012 04:27:02 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: Added tag jdk7u4-b225 for changeset ac2948107df1 Message-ID: <20120113042713.534D147955@hg.openjdk.java.net> Changeset: 08f0789e1c0b Author: katleman Date: 2012-01-12 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/08f0789e1c0b Added tag jdk7u4-b225 for changeset ac2948107df1 ! .hgtags From david.katleman at sun.com Thu Jan 12 20:28:30 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 13 Jan 2012 04:28:30 +0000 Subject: hg: jdk7u/jdk7u-osx/langtools: Added tag jdk7u4-b225 for changeset c864786394dc Message-ID: <20120113042832.7919A47956@hg.openjdk.java.net> Changeset: f05c7e7ceea6 Author: katleman Date: 2012-01-12 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/f05c7e7ceea6 Added tag jdk7u4-b225 for changeset c864786394dc ! .hgtags From artem.ananiev at oracle.com Fri Jan 13 03:32:18 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 13 Jan 2012 15:32:18 +0400 Subject: [7u4] Request for approval for CR 7124368: UnsupportedOperationException is thown on getLockingKeyState() In-Reply-To: References: Message-ID: <4F101642.2010009@oracle.com> Approved. On 1/12/2012 5:23 PM, Leonid Romanov wrote: > Hi, > This a request to push the following changes to jdk7u-osx. > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124368 > Webrev: http://cr.openjdk.java.net/~leonidr/7124368/webrev.01/ > > The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. > > Thanks, > Leonid. > From artem.ananiev at oracle.com Fri Jan 13 03:32:36 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 13 Jan 2012 15:32:36 +0400 Subject: [7u4] Request for approval for CR 7124515 - [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items) In-Reply-To: <4F0EEABB.9000301@oracle.com> References: <4F0EEABB.9000301@oracle.com> Message-ID: <4F101654.5090907@oracle.com> Approved. On 1/12/2012 6:14 PM, Alexander Scherbatiy wrote: > Hello, > > This a request to push the following changes to jdk7u-osx. > > CR 7124515 [macosx] Test fail like 6366126 > (ArrayIndexOutOfBoundException pressing ENTER after removing items) > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124515 > > Webrev: http://cr.openjdk.java.net/~alexsch/7124515/webrev.00/ > > The fix has been reviewed on macosx-port-dev mailing list by Artem Ananiev. > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002173.html > > > Thanks, > Alexandr. > From anthony.petrov at oracle.com Fri Jan 13 05:23:45 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 13 Jan 2012 17:23:45 +0400 Subject: [7u4-osx] Request for approval for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property Message-ID: <4F103061.1040607@oracle.com> [ resending and CC'ing macosx-port-dev@ this time ] This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124554 Webrev: http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002139.html -- best regards, Anthony From anton.tarasov at oracle.com Fri Jan 13 06:36:11 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 13 Jan 2012 17:36:11 +0300 Subject: Review request for 7124430: [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet Message-ID: <4F10415B.8010904@oracle.com> Hello, Please review a fix for 7124430. webrev: http://cr.openjdk.java.net/~ant/7124430/webrev.1/ UngrabEvent dispatching is implemented according to the cases mentioned in the UngrabEvent class description, except for the case of clicking in an owner frame's title. The latter, as I found, can't be implemented on Mac OS X platform. Along with the implementation, a regression test is proposed. Thanks, Anton. From anthony.petrov at oracle.com Fri Jan 13 05:58:06 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 13 Jan 2012 17:58:06 +0400 Subject: Review request for 7124430: [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet In-Reply-To: <4F10415B.8010904@oracle.com> References: <4F10415B.8010904@oracle.com> Message-ID: <4F10386E.3060504@oracle.com> Hi Anton, You want to override NSWindow -sendEvent: in order to catch clicks on the titlebar of windows on the Mac. -- best regards, Anthony On 1/13/2012 6:36 PM, Anton V. Tarasov wrote: > Hello, > > Please review a fix for 7124430. > > webrev: http://cr.openjdk.java.net/~ant/7124430/webrev.1/ > > UngrabEvent dispatching is implemented according to the cases mentioned > in the UngrabEvent class description, except for the case of clicking > in an owner frame's title. The latter, as I found, can't be implemented > on Mac OS X platform. Along with the implementation, a regression test > is proposed. > > Thanks, > Anton. > > From sergey.bylokhov at oracle.com Fri Jan 13 06:27:52 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 13 Jan 2012 18:27:52 +0400 Subject: [7u4] Request for approval for 7124530 - What is background color of AWT component? (And foreground, for that matter) In-Reply-To: References: <4F0ED0EF.90208@oracle.com> Message-ID: <4F103F68.9040806@oracle.com> 13.01.2012 6:30, Mike Swingler wrote: > On Jan 12, 2012, at 4:24 AM, Sergey Bylokhov wrote: > >> Hello, >> This is a request to push the following changes to jdk7u-osx. >> The fix has been reviewed on macosx-port-dev mailing list by Alexander Potochkin. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 >> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124530/webrev.00/ >> Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002143.html > I don't understand this part: > > --- old/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 19:02:19.913935900 +0400 > +++ new/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 19:02:19.557915600 +0400 > @@ -81,7 +81,8 @@ > sColors[java_awt_SystemColor_INACTIVE_CAPTION] = [NSColor grayColor]; > sColors[java_awt_SystemColor_INACTIVE_CAPTION_TEXT] = [NSColor grayColor]; > sColors[java_awt_SystemColor_INACTIVE_CAPTION_BORDER] = [NSColor grayColor]; > - sColors[java_awt_SystemColor_WINDOW] = [NSColor grayColor]; > + const CGFloat color = (CGFloat)0xEE/(CGFloat)0xFF; > + sColors[java_awt_SystemColor_WINDOW] = [NSColor colorWithCalibratedRed:color green:color blue:color alpha:1.0f]; > sColors[java_awt_SystemColor_WINDOW_BORDER] = [NSColor windowFrameColor]; > sColors[java_awt_SystemColor_WINDOW_TEXT] = [NSColor windowFrameTextColor]; > sColors[java_awt_SystemColor_MENU] = [NSColor controlBackgroundColor]; > > Why aren't you just using [NSColor windowBackgroundColor]? Only selectedControlColor and selectedTextBackgroundColor are supported. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DrawColor/Tasks/SystemColors.html#//apple_ref/doc/uid/20000790 As I understand that`s why swing didn`t use this color. After the fix awt and swing use one color (before the fix this color was used by swing). If this color is wrong, now it`s possible to change it in one place. > > Regards, > Mike Swingler > Apple Inc. > -- Best regards, Sergey. From anton.tarasov at oracle.com Fri Jan 13 07:49:59 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 13 Jan 2012 18:49:59 +0300 Subject: Review request for 7124430: [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet In-Reply-To: <4F10386E.3060504@oracle.com> References: <4F10415B.8010904@oracle.com> <4F10386E.3060504@oracle.com> Message-ID: <4F1052A7.70908@oracle.com> Hi Anthony, Thanks for the tip. Though I did look through some forum discussions where people asked question "is it possible to catch a mouse down event in a frame's titlebar?" The answer was "not a direct way". Commonly, a suggestion is to workaround it by means of -windowWillMove usage, but this looks quite odd to me... For instance: http://www.cocoabuilder.com/archive/cocoa/6725-catching-mousedown-in-an-nswindow-titlebar.html "PS: I have tried to overiding -sendEvent in the instance of a subclass of NSApplication object to see what events are going thru, mouseDown and mouseUp events in the titlebar don't go thru. It's seem that the windows are moved directly by the WindowServer, as you explained me." Did you have an experience of trying it yourself? Thanks, Anton. On 1/13/12 4:58 PM, Anthony Petrov wrote: > Hi Anton, > > You want to override NSWindow -sendEvent: in order to catch clicks on > the titlebar of windows on the Mac. > > -- > best regards, > Anthony > > On 1/13/2012 6:36 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please review a fix for 7124430. >> >> webrev: http://cr.openjdk.java.net/~ant/7124430/webrev.1/ >> >> UngrabEvent dispatching is implemented according to the cases mentioned >> in the UngrabEvent class description, except for the case of clicking >> in an owner frame's title. The latter, as I found, can't be implemented >> on Mac OS X platform. Along with the implementation, a regression test >> is proposed. >> >> Thanks, >> Anton. >> >> From michael.x.mcmahon at oracle.com Fri Jan 13 09:22:04 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 13 Jan 2012 17:22:04 +0000 Subject: [jdk7u-osx] Request for approval for CR 7122780: (macosx) JVMTI Test DemoRun.java doesn't understand macosx .dylibs Message-ID: <4F10683C.8070404@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122780 Webrev: http://cr.openjdk.java.net/~michaelm/7122780/webrev.2/ Reviewed by: dcubed Thanks, Michael. From swingler at apple.com Fri Jan 13 09:27:09 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 13 Jan 2012 09:27:09 -0800 Subject: [7u4-osx] Request for approval for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F103061.1040607@oracle.com> References: <4F103061.1040607@oracle.com> Message-ID: <61A2370B-D186-4244-9D69-1A2D7AA08393@apple.com> On Jan 13, 2012, at 5:23 AM, Anthony Petrov wrote: > [ resending and CC'ing macosx-port-dev@ this time ] > > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124554 > > Webrev: http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002139.html I don't agree that this fix should be integrated. You are allowing ordinary windows to go way above the popup, menu bar, modal window, and even the dock...you should simply use the NSNormalWIndowLevel and add single integral values to it. Otherwise you Java windows are going to be floating on top over everything else on the desktop. The named constants are only for when you need to make some windows float just above or just below one of those named levels. Please do not integrate this fix as is, Mike Swingler Apple Inc. From paul.hohensee at oracle.com Fri Jan 13 09:31:39 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 13 Jan 2012 12:31:39 -0500 Subject: [jdk7u-osx] Request for approval for CR 7122780: (macosx) JVMTI Test DemoRun.java doesn't understand macosx .dylibs In-Reply-To: <4F10683C.8070404@oracle.com> References: <4F10683C.8070404@oracle.com> Message-ID: <4F106A7B.2090300@oracle.com> Approved. Paul On 1/13/12 12:22 PM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122780 > > Webrev: http://cr.openjdk.java.net/~michaelm/7122780/webrev.2/ > > Reviewed by: dcubed > > Thanks, > Michael. From swingler at apple.com Fri Jan 13 09:31:03 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 13 Jan 2012 09:31:03 -0800 Subject: [7u4] Request for approval for 7124530 - What is background color of AWT component? (And foreground, for that matter) In-Reply-To: <4F103F68.9040806@oracle.com> References: <4F0ED0EF.90208@oracle.com> <4F103F68.9040806@oracle.com> Message-ID: <9716158E-63E1-4554-B07C-2772A35F82E7@apple.com> On Jan 13, 2012, at 6:27 AM, Sergey Bylokhov wrote: > 13.01.2012 6:30, Mike Swingler wrote: > >> On Jan 12, 2012, at 4:24 AM, Sergey Bylokhov wrote: >> >>> Hello, >>> This is a request to push the following changes to jdk7u-osx. >>> The fix has been reviewed on macosx-port-dev mailing list by Alexander Potochkin. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 >>> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124530/webrev.00/ >>> Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002143.html >> I don't understand this part: >> >> --- old/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 19:02:19.913935900 +0400 >> +++ new/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 19:02:19.557915600 +0400 >> @@ -81,7 +81,8 @@ >> sColors[java_awt_SystemColor_INACTIVE_CAPTION] = [NSColor grayColor]; >> sColors[java_awt_SystemColor_INACTIVE_CAPTION_TEXT] = [NSColor grayColor]; >> sColors[java_awt_SystemColor_INACTIVE_CAPTION_BORDER] = [NSColor grayColor]; >> - sColors[java_awt_SystemColor_WINDOW] = [NSColor grayColor]; >> + const CGFloat color = (CGFloat)0xEE/(CGFloat)0xFF; >> + sColors[java_awt_SystemColor_WINDOW] = [NSColor colorWithCalibratedRed:color green:color blue:color alpha:1.0f]; >> sColors[java_awt_SystemColor_WINDOW_BORDER] = [NSColor windowFrameColor]; >> sColors[java_awt_SystemColor_WINDOW_TEXT] = [NSColor windowFrameTextColor]; >> sColors[java_awt_SystemColor_MENU] = [NSColor controlBackgroundColor]; >> >> Why aren't you just using [NSColor windowBackgroundColor]? > Only selectedControlColor and selectedTextBackgroundColor are supported. > http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DrawColor/Tasks/SystemColors.html#//apple_ref/doc/uid/20000790 > As I understand that`s why swing didn`t use this color. After the fix awt and swing use one color (before the fix this color was used by swing). > If this color is wrong, now it`s possible to change it in one place. I can assure you that the window background color reports the correct RGB value, even when the background color has changed between OS versions. You static constant will not. We use it today in Java SE 6. Regards, Mike Swingler Apple Inc. From michael.x.mcmahon at oracle.com Fri Jan 13 09:33:38 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Fri, 13 Jan 2012 17:33:38 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7122780: (macosx) JVMTI Test DemoRun.java doesn't understand macosx .dylibs Message-ID: <20120113173353.79FA247963@hg.openjdk.java.net> Changeset: e6af2dd87c5b Author: michaelm Date: 2012-01-13 09:25 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/e6af2dd87c5b 7122780: (macosx) JVMTI Test DemoRun.java doesn't understand macosx .dylibs Reviewed-by: dcubed ! test/demo/jvmti/DemoRun.java From swingler at apple.com Fri Jan 13 09:34:26 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 13 Jan 2012 09:34:26 -0800 Subject: Review request for 7124430: [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet In-Reply-To: <4F1052A7.70908@oracle.com> References: <4F10415B.8010904@oracle.com> <4F10386E.3060504@oracle.com> <4F1052A7.70908@oracle.com> Message-ID: <9DB24422-FB27-429B-BDEF-FD5E741E3C08@apple.com> Don't worry about trying to catch the window title bar frame, you really can't, and you shouldn't try. The titlebar/toolbar area is specially marked so that the WindowServer will still allow the window to be movable, even if the app is spinning and non-responsive. Due to this fact, the app is infrequently notified when it's window is being moved, because that app isn't even involved. Regards, Mike Swingler Apple Inc. On Jan 13, 2012, at 7:49 AM, Anton V. Tarasov wrote: > Hi Anthony, > > Thanks for the tip. Though I did look through some forum discussions where people asked question > "is it possible to catch a mouse down event in a frame's titlebar?" The answer was "not a direct way". > Commonly, a suggestion is to workaround it by means of -windowWillMove usage, but this looks quite > odd to me... > > For instance: > > http://www.cocoabuilder.com/archive/cocoa/6725-catching-mousedown-in-an-nswindow-titlebar.html > > "PS: I have tried to overiding -sendEvent in the instance of a subclass > of NSApplication object to see what events are going thru, mouseDown > and mouseUp events in the titlebar don't go thru. It's seem that the > windows are moved directly by the WindowServer, as you explained me." > > Did you have an experience of trying it yourself? > > Thanks, > Anton. > > On 1/13/12 4:58 PM, Anthony Petrov wrote: >> Hi Anton, >> >> You want to override NSWindow -sendEvent: in order to catch clicks on the titlebar of windows on the Mac. >> >> -- >> best regards, >> Anthony >> >> On 1/13/2012 6:36 PM, Anton V. Tarasov wrote: >>> Hello, >>> >>> Please review a fix for 7124430. >>> >>> webrev: http://cr.openjdk.java.net/~ant/7124430/webrev.1/ >>> >>> UngrabEvent dispatching is implemented according to the cases mentioned >>> in the UngrabEvent class description, except for the case of clicking >>> in an owner frame's title. The latter, as I found, can't be implemented >>> on Mac OS X platform. Along with the implementation, a regression test >>> is proposed. >>> >>> Thanks, >>> Anton. >>> >>> > From anthony.petrov at oracle.com Fri Jan 13 10:08:29 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 13 Jan 2012 22:08:29 +0400 Subject: [7u4-osx] Request for approval for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <61A2370B-D186-4244-9D69-1A2D7AA08393@apple.com> References: <4F103061.1040607@oracle.com> <61A2370B-D186-4244-9D69-1A2D7AA08393@apple.com> Message-ID: <4F10731D.7090706@oracle.com> [ BCC'ing jdk7u-dev at . I'll resend the request once we settle down all technical issues. ] Hi Mike, I'm sorry but I don't see this claim valid. Please let me explain: 1. AWT puts always-on-top windows on the NSFloatingWindowLevel level. This is done in AWTWindow.m. Please note that: a) this fix does not alter this file in any way. I.e. I'm not changing the way this feature is already implemented. b) the NSFloatingWindowLevel isn't above anything but the NSNormalWindowLevel only (on which all non-always-on-top Java windows reside). In other words, the floating level is well below the dock, menus, and everything else you've listed. Please see [1] for details. 2. This fix deals with a particular case when an owned window is made an always-on-top window. The -addChildWindow: would reset the level of such a window back to normal, and with this fix we just set it back to the original value (floating) since the window should be always-on-top according to Java specification. Note that the fix doesn't changes the level to any arbitrary value, but simply restores it to what it already was set just before the -addChildWindow: call. Please see my original review request message at [2] which explains this in more details. Please clarify whether you still have an issue with this particular fix. I would appreciate to see more specific details on what exactly (line numbers/code snippets of the parts that are modified) is wrong with the fix at [3]. [1] http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Window_Levels [2] http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002139.html [3] http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ -- best regards, Anthony On 1/13/2012 9:27 PM, Mike Swingler wrote: > On Jan 13, 2012, at 5:23 AM, Anthony Petrov wrote: > >> [ resending and CC'ing macosx-port-dev@ this time ] >> >> This is a request to push the following fix to jdk7u-osx: >> >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124554 >> >> Webrev: http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >> >> Technical review: >> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002139.html > > I don't agree that this fix should be integrated. You are allowing ordinary windows to go way above the popup, menu bar, modal window, and even the dock...you should simply use the NSNormalWIndowLevel and add single integral values to it. Otherwise you Java windows are going to be floating on top over everything else on the desktop. > > The named constants are only for when you need to make some windows float just above or just below one of those named levels. > > Please do not integrate this fix as is, > Mike Swingler > Apple Inc. > From anthony.petrov at oracle.com Fri Jan 13 10:17:21 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 13 Jan 2012 22:17:21 +0400 Subject: Review request for 7124430: [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet In-Reply-To: <9DB24422-FB27-429B-BDEF-FD5E741E3C08@apple.com> References: <4F10415B.8010904@oracle.com> <4F10386E.3060504@oracle.com> <4F1052A7.70908@oracle.com> <9DB24422-FB27-429B-BDEF-FD5E741E3C08@apple.com> Message-ID: <4F107531.3080503@oracle.com> Overriding NSWindow -sendEvent: does allow one to catch mouse click events on the Mac. We use this technique in JavaFX for grab/ungrab functionality, and everything works smoothly. Anton was just trying to override NSApplication -sendEvent: which indeed won't help in that case (note the class name difference). -- best regards, Anthony On 1/13/2012 9:34 PM, Mike Swingler wrote: > Don't worry about trying to catch the window title bar frame, you really can't, and you shouldn't try. The titlebar/toolbar area is specially marked so that the WindowServer will still allow the window to be movable, even if the app is spinning and non-responsive. Due to this fact, the app is infrequently notified when it's window is being moved, because that app isn't even involved. > > Regards, > Mike Swingler > Apple Inc. > > On Jan 13, 2012, at 7:49 AM, Anton V. Tarasov wrote: > >> Hi Anthony, >> >> Thanks for the tip. Though I did look through some forum discussions where people asked question >> "is it possible to catch a mouse down event in a frame's titlebar?" The answer was "not a direct way". >> Commonly, a suggestion is to workaround it by means of -windowWillMove usage, but this looks quite >> odd to me... >> >> For instance: >> >> http://www.cocoabuilder.com/archive/cocoa/6725-catching-mousedown-in-an-nswindow-titlebar.html >> >> "PS: I have tried to overiding -sendEvent in the instance of a subclass >> of NSApplication object to see what events are going thru, mouseDown >> and mouseUp events in the titlebar don't go thru. It's seem that the >> windows are moved directly by the WindowServer, as you explained me." >> >> Did you have an experience of trying it yourself? >> >> Thanks, >> Anton. >> >> On 1/13/12 4:58 PM, Anthony Petrov wrote: >>> Hi Anton, >>> >>> You want to override NSWindow -sendEvent: in order to catch clicks on the titlebar of windows on the Mac. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/13/2012 6:36 PM, Anton V. Tarasov wrote: >>>> Hello, >>>> >>>> Please review a fix for 7124430. >>>> >>>> webrev: http://cr.openjdk.java.net/~ant/7124430/webrev.1/ >>>> >>>> UngrabEvent dispatching is implemented according to the cases mentioned >>>> in the UngrabEvent class description, except for the case of clicking >>>> in an owner frame's title. The latter, as I found, can't be implemented >>>> on Mac OS X platform. Along with the implementation, a regression test >>>> is proposed. >>>> >>>> Thanks, >>>> Anton. >>>> >>>> > From sergey.bylokhov at oracle.com Fri Jan 13 10:52:03 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 13 Jan 2012 22:52:03 +0400 Subject: [7u4] Request for approval for 7124530 - What is background color of AWT component? (And foreground, for that matter) In-Reply-To: <9716158E-63E1-4554-B07C-2772A35F82E7@apple.com> References: <4F0ED0EF.90208@oracle.com> <4F103F68.9040806@oracle.com> <9716158E-63E1-4554-B07C-2772A35F82E7@apple.com> Message-ID: <4F107D53.9060600@oracle.com> 13.01.2012 21:31, Mike Swingler ?????: > On Jan 13, 2012, at 6:27 AM, Sergey Bylokhov wrote: > >> 13.01.2012 6:30, Mike Swingler wrote: >> >>> On Jan 12, 2012, at 4:24 AM, Sergey Bylokhov wrote: >>> >>>> Hello, >>>> This is a request to push the following changes to jdk7u-osx. >>>> The fix has been reviewed on macosx-port-dev mailing list by Alexander Potochkin. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 >>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124530/webrev.00/ >>>> Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002143.html >>> I don't understand this part: >>> >>> --- old/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 19:02:19.913935900 +0400 >>> +++ new/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 19:02:19.557915600 +0400 >>> @@ -81,7 +81,8 @@ >>> sColors[java_awt_SystemColor_INACTIVE_CAPTION] = [NSColor grayColor]; >>> sColors[java_awt_SystemColor_INACTIVE_CAPTION_TEXT] = [NSColor grayColor]; >>> sColors[java_awt_SystemColor_INACTIVE_CAPTION_BORDER] = [NSColor grayColor]; >>> - sColors[java_awt_SystemColor_WINDOW] = [NSColor grayColor]; >>> + const CGFloat color = (CGFloat)0xEE/(CGFloat)0xFF; >>> + sColors[java_awt_SystemColor_WINDOW] = [NSColor colorWithCalibratedRed:color green:color blue:color alpha:1.0f]; >>> sColors[java_awt_SystemColor_WINDOW_BORDER] = [NSColor windowFrameColor]; >>> sColors[java_awt_SystemColor_WINDOW_TEXT] = [NSColor windowFrameTextColor]; >>> sColors[java_awt_SystemColor_MENU] = [NSColor controlBackgroundColor]; >>> >>> Why aren't you just using [NSColor windowBackgroundColor]? >> Only selectedControlColor and selectedTextBackgroundColor are supported. >> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DrawColor/Tasks/SystemColors.html#//apple_ref/doc/uid/20000790 >> As I understand that`s why swing didn`t use this color. After the fix awt and swing use one color (before the fix this color was used by swing). >> If this color is wrong, now it`s possible to change it in one place. > I can assure you that the window background color reports the correct RGB value, even when the background color has changed between OS versions. You static constant will not. > > We use it today in Java SE 6. jdk6 on my system reports white color which is wrong. Can you please check it(testcase attached). > > Regards, > Mike Swingler > Apple Inc. -- Best regards, Sergey. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Test.java Url: http://mail.openjdk.java.net/pipermail/macosx-port-dev/attachments/20120113/bf70ee07/Test.java From kurchi.subhra.hazra at oracle.com Fri Jan 13 12:05:45 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Fri, 13 Jan 2012 12:05:45 -0800 Subject: Code Review Request: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X In-Reply-To: <4F0DDFEF.4000908@oracle.com> References: <4F0DDFEF.4000908@oracle.com> Message-ID: <4F108E99.7030903@oracle.com> Resending this request - Kurchi On 1/11/2012 11:15 AM, Kurchi Hazra wrote: > > Hi, > > For IPv6 on solaris or linux, setting the traffic class option is > handled in the java layer. > The native calls to set socket option simply returns a success and get > socket option > returns a dummy -1 value. test/java/net/Socket/TrafficClass.java > was failing on Mac OS X when using the IPv6 stack with an Invalid > Argument Socket > Exception since this native handling was missing when setting socket > option. > > The following change incorporates the required native behavior for Mac > OS. > > Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127771 > Webrev : http://cr.openjdk.java.net/~khazra/7127771/webrev.00/ > > Thanks, > Kurchi > -- -Kurchi From Alan.Bateman at oracle.com Fri Jan 13 12:14:56 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Jan 2012 20:14:56 +0000 Subject: Code Review Request: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X In-Reply-To: <4F108E99.7030903@oracle.com> References: <4F0DDFEF.4000908@oracle.com> <4F108E99.7030903@oracle.com> Message-ID: <4F1090C0.10501@oracle.com> >> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127771 >> Webrev : http://cr.openjdk.java.net/~khazra/7127771/webrev.00/ What you have is fine although you could combine with the Solaris code? Should the __ALLBSD_SOURCE XXX be removed while you are there? -Alan From kurchi.subhra.hazra at oracle.com Fri Jan 13 13:02:26 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Fri, 13 Jan 2012 13:02:26 -0800 Subject: Code Review Request: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X In-Reply-To: <4F1090C0.10501@oracle.com> References: <4F0DDFEF.4000908@oracle.com> <4F108E99.7030903@oracle.com> <4F1090C0.10501@oracle.com> Message-ID: <4F109BE2.9000101@oracle.com> How does this look: http://cr.openjdk.java.net/~khazra/7127771/webrev.01/ - Kurchi On 1/13/2012 12:14 PM, Alan Bateman wrote: > >>> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127771 >>> Webrev : http://cr.openjdk.java.net/~khazra/7127771/webrev.00/ > What you have is fine although you could combine with the Solaris > code? Should the __ALLBSD_SOURCE XXX be removed while you are there? > > -Alan -- -Kurchi From henri.gomez at gmail.com Sat Jan 14 01:18:26 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sat, 14 Jan 2012 10:18:26 +0100 Subject: tag boucing again Message-ID: It seems we're back to b2xx in tags : jdk7u4-b225 398:2fea92d741b7 jdk7u4-b05 396:a15712a2304e jdk7u4-b200 392:25457f672756 jdk7u4-b04 391:bcc37b8ac1b0 jdk7u2-b21 389:e30fd289f001 Is it a QA tag or something else ? Cheers From daniel.daugherty at oracle.com Sat Jan 14 10:23:57 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 14 Jan 2012 11:23:57 -0700 Subject: tag boucing again In-Reply-To: References: Message-ID: <4F11C83D.1010602@oracle.com> That's a tag for an internal build. Dan On 1/14/12 2:18 AM, Henri Gomez wrote: > It seems we're back to b2xx in tags : > > jdk7u4-b225 398:2fea92d741b7 > jdk7u4-b05 396:a15712a2304e > jdk7u4-b200 392:25457f672756 > jdk7u4-b04 391:bcc37b8ac1b0 > jdk7u2-b21 389:e30fd289f001 > > Is it a QA tag or something else ? > > Cheers From swingler at apple.com Sat Jan 14 19:40:07 2012 From: swingler at apple.com (Mike Swingler) Date: Sat, 14 Jan 2012 19:40:07 -0800 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F0F5B1F.5070601@oracle.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> Message-ID: <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> In the course of preparing to contribute our current window stacking algorithm, I realized that there was a pair of internal SPI calls it was making. In the next revision we ship of the JavaRuntimeSupport.framework we can provide cover methods of these SPI, however that is of little benefit to the OpenJDK port in the immediate here-and-now. For now, using -addChildWindow: will be sufficient, however, we can provide an alternate implementation that uses a new pair of category methods on NSWindow if -respondsToSelector: shows that they are available: - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; These functions will allow the window server to move each child window with respect to it's parent's level, but without being added to it's movement group. Once customers get an updated JavaNativeFoundation.framework by either Java update or OS update, the implementation will switch over dynamically at runtime. How does this sound for a plan? Regards, Mike Swingler Apple Inc. On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com wrote: > We fought this one in SWT and ended up going with the puppy route. > > Steve > > On 12/01/2012 2:57 PM, Anthony Petrov wrote: >> Hi Mike, >> >> I recall we've discussed this issue with you back in 2010. Unfortunately, I wasn't able to implement anything like this that would work reliably back then (and I tried hard, really), that's why we ended up with -addChildWindow:. Note that JCK is very happy with this implementation, and so are we, I presume. As long as child windows receive their respective MOVE events, it seems that everything is all right. Besides, such behavior is very Mac-friendly, making Java apps behave like native apps. >> >> I realize that for some developers this behavior may be inconvenient. But then again, why not listen to MOVE events on the parent frame and compensate for its movement repositioning all its children? ( :) yeah, yeah, I know, sounds weird, but... as Steve says, you gotta do what you gotta do... I mean, there's a workaround at least!) >> >> So, if you or anyone else wish to contribute an alternative implementation for owned windows, that would be greatly appreciated. Otherwise I'm afraid we have to stick with using -addChildWindow: for now since we simply don't have a better solution. >> >> -- >> best regards, >> Anthony >> >> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). >>> >>> In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>> >>>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. >>>> >>>> >>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>> >>>>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>>>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>>>>> >>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>> >>>>>>> Hi Leonid, >>>>>>> >>>>>>> Thanks for taking a look at the fix. >>>>>>> >>>>>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>>> >>>>>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>>>>> >>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>> >>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>>>>> >>>>>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>>>>> >>>>>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> best regards, >>>>>>>>> Anthony >>> From Alan.Bateman at oracle.com Mon Jan 16 02:02:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Jan 2012 10:02:25 +0000 Subject: Code Review Request: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X In-Reply-To: <4F109BE2.9000101@oracle.com> References: <4F0DDFEF.4000908@oracle.com> <4F108E99.7030903@oracle.com> <4F1090C0.10501@oracle.com> <4F109BE2.9000101@oracle.com> Message-ID: <4F13F5B1.5060001@oracle.com> On 13/01/2012 21:02, Kurchi Hazra wrote: > How does this look: http://cr.openjdk.java.net/~khazra/7127771/webrev.01/ > > - Kurchi > This looks fine to me. -Alan From michael.x.mcmahon at oracle.com Mon Jan 16 02:43:55 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 16 Jan 2012 10:43:55 +0000 Subject: Code Review Request: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X In-Reply-To: <4F109BE2.9000101@oracle.com> References: <4F0DDFEF.4000908@oracle.com> <4F108E99.7030903@oracle.com> <4F1090C0.10501@oracle.com> <4F109BE2.9000101@oracle.com> Message-ID: <4F13FF6B.7080403@oracle.com> Yes, looks fine to me too. I would just update the comment above this code to add Mac OS to the Solaris case. Thanks Michael On 13/01/12 21:02, Kurchi Hazra wrote: > How does this look: http://cr.openjdk.java.net/~khazra/7127771/webrev.01/ > > - Kurchi > > > > On 1/13/2012 12:14 PM, Alan Bateman wrote: >> >>>> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127771 >>>> Webrev : http://cr.openjdk.java.net/~khazra/7127771/webrev.00/ >> What you have is fine although you could combine with the Solaris >> code? Should the __ALLBSD_SOURCE XXX be removed while you are there? >> >> -Alan > From alexander.zuev at oracle.com Mon Jan 16 03:48:24 2012 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Mon, 16 Jan 2012 11:48:24 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124368: UnsupportedOperationException is thown on getLockingKeyState() Message-ID: <20120116114841.ADB5B47987@hg.openjdk.java.net> Changeset: 53427895abd7 Author: leonidr Date: 2012-01-16 15:49 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/53427895abd7 7124368: UnsupportedOperationException is thown on getLockingKeyState() Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/LWCToolkit.m From martijnverburg at gmail.com Mon Jan 16 04:21:39 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 16 Jan 2012 12:21:39 +0000 Subject: Should I enter this as a bug? (Groovy Console startup on b223) Message-ID: Hi all, Starting the Groovy Console using b223 I get the following stack trace. I'm running Mac OS X 10.7.2. I saw lots of fixes go in for jdk7u4/b22x, so wasn't sure if this is a duplicate. 2012-01-16 12:18:54.086 java[39364:c07] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil 2012-01-16 12:18:54.095 java[39364:c07] ( 0 CoreFoundation 0x00007fff889a2286 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x00007fff90583d5e objc_exception_throw + 43 2 CoreFoundation 0x00007fff88949108 -[__NSArrayM insertObject:atIndex:] + 296 3 AppKit 0x00007fff8ad1a109 -[NSMenu insertItem:atIndex:] + 478 4 liblwawt.dylib 0x00000001110bac14 addMenuItem + 185 5 liblwawt.dylib 0x00000001110ba905 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 6 liblwawt.dylib 0x00000001110baee1 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 227 7 JavaNativeFoundation 0x00000001100855fd +[JNFRunLoop _performCopiedBlock:] + 20 8 CoreFoundation 0x00007fff889cc0cd +[NSObject performSelector:withObject:] + 61 9 Foundation 0x00007fff8e225e44 __NSThreadPerformPerform + 214 10 CoreFoundation 0x00007fff88910b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 11 CoreFoundation 0x00007fff889103bd __CFRunLoopDoSources0 + 253 12 CoreFoundation 0x00007fff889371a9 __CFRunLoopRun + 905 13 CoreFoundation 0x00007fff88936ae6 CFRunLoopRunSpecific + 230 14 HIToolbox 0x00007fff89e493d3 RunCurrentEventLoopInMode + 277 15 HIToolbox 0x00007fff89e5063d ReceiveNextEventCommon + 355 16 HIToolbox 0x00007fff89e504ca BlockUntilNextEventMatchingListInMode + 62 17 AppKit 0x00007fff8ad033f1 _DPSNextEvent + 659 18 AppKit 0x00007fff8ad02cf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 19 libosxapp.dylib 0x0000000110e1b82c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 20 AppKit 0x00007fff8acff62d -[NSApplication run] + 470 21 libosxapp.dylib 0x0000000110e1b74b +[NSApplicationAWT runAWTLoopWithApp:] + 156 22 liblwawt.dylib 0x00000001110b8dad -[AWTStarter starter:] + 1616 23 CoreFoundation 0x00007fff88991a1d -[NSObject performSelector:withObject:] + 61 24 Foundation 0x00007fff8e225e44 __NSThreadPerformPerform + 214 25 CoreFoundation 0x00007fff88910b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 26 CoreFoundation 0x00007fff889103bd __CFRunLoopDoSources0 + 253 27 CoreFoundation 0x00007fff889371a9 __CFRunLoopRun + 905 28 CoreFoundation 0x00007fff88936ae6 CFRunLoopRunSpecific + 230 29 java 0x000000010aee7cb4 CreateExecutionEnvironment + 841 30 java 0x000000010aee57b8 JLI_Launch + 1933 31 java 0x000000010aee9a30 main + 108 32 java 0x000000010aee33f4 start + 52 33 ??? 0x0000000000000011 0x0 + 17 ) 2012-01-16 12:18:54.096 java[39364:c07] *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil 2012-01-16 12:18:54.097 java[39364:c07] ( 0 CoreFoundation 0x00007fff889a2286 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x00007fff90583d5e objc_exception_throw + 43 2 CoreFoundation 0x00007fff88949108 -[__NSArrayM insertObject:atIndex:] + 296 3 AppKit 0x00007fff8ad1a109 -[NSMenu insertItem:atIndex:] + 478 4 liblwawt.dylib 0x00000001110bac14 addMenuItem + 185 5 liblwawt.dylib 0x00000001110ba905 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 6 liblwawt.dylib 0x00000001110baee1 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 227 7 JavaNativeFoundation 0x00000001100855fd +[JNFRunLoop _performCopiedBlock:] + 20 8 CoreFoundation 0x00007fff889cc0cd +[NSObject performSelector:withObject:] + 61 9 Foundation 0x00007fff8e225e44 __NSThreadPerformPerform + 214 10 CoreFoundation 0x00007fff88910b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 11 CoreFoundation 0x00007fff889103bd __CFRunLoopDoSources0 + 253 12 CoreFoundation 0x00007fff889371a9 __CFRunLoopRun + 905 13 CoreFoundation 0x00007fff88936ae6 CFRunLoopRunSpecific + 230 14 HIToolbox 0x00007fff89e493d3 RunCurrentEventLoopInMode + 277 15 HIToolbox 0x00007fff89e5058f ReceiveNextEventCommon + 181 16 HIToolbox 0x00007fff89e504ca BlockUntilNextEventMatchingListInMode + 62 17 AppKit 0x00007fff8ad033f1 _DPSNextEvent + 659 18 AppKit 0x00007fff8ad02cf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 19 libosxapp.dylib 0x0000000110e1b82c -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 20 AppKit 0x00007fff8acff62d -[NSApplication run] + 470 21 libosxapp.dylib 0x0000000110e1b74b +[NSApplicationAWT runAWTLoopWithApp:] + 156 22 liblwawt.dylib 0x00000001110b8dad -[AWTStarter starter:] + 1616 23 CoreFoundation 0x00007fff88991a1d -[NSObject performSelector:withObject:] + 61 24 Foundation 0x00007fff8e225e44 __NSThreadPerformPerform + 214 25 CoreFoundation 0x00007fff88910b51 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 26 CoreFoundation 0x00007fff889103bd __CFRunLoopDoSources0 + 253 27 CoreFoundation 0x00007fff889371a9 __CFRunLoopRun + 905 28 CoreFoundation 0x00007fff88936ae6 CFRunLoopRunSpecific + 230 29 java 0x000000010aee7cb4 CreateExecutionEnvironment + 841 30 java 0x000000010aee57b8 JLI_Launch + 1933 31 java 0x000000010aee9a30 main + 108 32 java 0x000000010aee33f4 start + 52 33 ??? 0x0000000000000011 0x0 + 17 ) From anthony.petrov at oracle.com Mon Jan 16 06:06:20 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 16 Jan 2012 18:06:20 +0400 Subject: Should I enter this as a bug? (Groovy Console startup on b223) In-Reply-To: References: Message-ID: <4F142EDC.8070807@oracle.com> Hi Martijn, I've just filed the issue at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130377 (may take some time to become visible) Could you please provide some more detailed instruction on how to reproduce the issue? What software should be installed and what exactly needs to be launched? Would it be possible for you to provide a simple test case that reproduces the issue and post it here to the mailing list? Thanks in advance! -- best regards, Anthony On 01/16/12 16:21, Martijn Verburg wrote: > 2012-01-16 12:18:54.086 java[39364:c07] *** -[__NSArrayM > insertObject:atIndex:]: object cannot be nil > 2012-01-16 12:18:54.095 java[39364:c07] ( > 0 CoreFoundation 0x00007fff889a2286 > __exceptionPreprocess + 198 > 1 libobjc.A.dylib 0x00007fff90583d5e > objc_exception_throw + 43 > 2 CoreFoundation 0x00007fff88949108 > -[__NSArrayM insertObject:atIndex:] + 296 > 3 AppKit 0x00007fff8ad1a109 -[NSMenu > insertItem:atIndex:] + 478 > 4 liblwawt.dylib 0x00000001110bac14 addMenuItem + 185 > 5 liblwawt.dylib 0x00000001110ba905 > -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 > 6 liblwawt.dylib 0x00000001110baee1 > __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 > + 227 > 7 JavaNativeFoundation 0x00000001100855fd > +[JNFRunLoop _performCopiedBlock:] + 20 > 8 CoreFoundation 0x00007fff889cc0cd +[NSObject > performSelector:withObject:] + 61 > 9 Foundation 0x00007fff8e225e44 > __NSThreadPerformPerform + 214 > 10 CoreFoundation 0x00007fff88910b51 > __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 11 CoreFoundation 0x00007fff889103bd > __CFRunLoopDoSources0 + 253 > 12 CoreFoundation 0x00007fff889371a9 __CFRunLoopRun + 905 > 13 CoreFoundation 0x00007fff88936ae6 > CFRunLoopRunSpecific + 230 > 14 HIToolbox 0x00007fff89e493d3 > RunCurrentEventLoopInMode + 277 > 15 HIToolbox 0x00007fff89e5063d > ReceiveNextEventCommon + 355 > 16 HIToolbox 0x00007fff89e504ca > BlockUntilNextEventMatchingListInMode + 62 > 17 AppKit 0x00007fff8ad033f1 _DPSNextEvent + 659 > 18 AppKit 0x00007fff8ad02cf5 > -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 > 19 libosxapp.dylib 0x0000000110e1b82c > -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + > 124 > 20 AppKit 0x00007fff8acff62d > -[NSApplication run] + 470 > 21 libosxapp.dylib 0x0000000110e1b74b > +[NSApplicationAWT runAWTLoopWithApp:] + 156 > 22 liblwawt.dylib 0x00000001110b8dad > -[AWTStarter starter:] + 1616 > 23 CoreFoundation 0x00007fff88991a1d -[NSObject > performSelector:withObject:] + 61 > 24 Foundation 0x00007fff8e225e44 > __NSThreadPerformPerform + 214 > 25 CoreFoundation 0x00007fff88910b51 > __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 26 CoreFoundation 0x00007fff889103bd > __CFRunLoopDoSources0 + 253 > 27 CoreFoundation 0x00007fff889371a9 __CFRunLoopRun + 905 > 28 CoreFoundation 0x00007fff88936ae6 > CFRunLoopRunSpecific + 230 > 29 java 0x000000010aee7cb4 > CreateExecutionEnvironment + 841 > 30 java 0x000000010aee57b8 JLI_Launch + 1933 > 31 java 0x000000010aee9a30 main + 108 > 32 java 0x000000010aee33f4 start + 52 > 33 ??? 0x0000000000000011 0x0 + 17 > ) > 2012-01-16 12:18:54.096 java[39364:c07] *** -[__NSArrayM > insertObject:atIndex:]: object cannot be nil > 2012-01-16 12:18:54.097 java[39364:c07] ( > 0 CoreFoundation 0x00007fff889a2286 > __exceptionPreprocess + 198 > 1 libobjc.A.dylib 0x00007fff90583d5e > objc_exception_throw + 43 > 2 CoreFoundation 0x00007fff88949108 > -[__NSArrayM insertObject:atIndex:] + 296 > 3 AppKit 0x00007fff8ad1a109 -[NSMenu > insertItem:atIndex:] + 478 > 4 liblwawt.dylib 0x00000001110bac14 addMenuItem + 185 > 5 liblwawt.dylib 0x00000001110ba905 > -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 > 6 liblwawt.dylib 0x00000001110baee1 > __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 > + 227 > 7 JavaNativeFoundation 0x00000001100855fd > +[JNFRunLoop _performCopiedBlock:] + 20 > 8 CoreFoundation 0x00007fff889cc0cd +[NSObject > performSelector:withObject:] + 61 > 9 Foundation 0x00007fff8e225e44 > __NSThreadPerformPerform + 214 > 10 CoreFoundation 0x00007fff88910b51 > __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 11 CoreFoundation 0x00007fff889103bd > __CFRunLoopDoSources0 + 253 > 12 CoreFoundation 0x00007fff889371a9 __CFRunLoopRun + 905 > 13 CoreFoundation 0x00007fff88936ae6 > CFRunLoopRunSpecific + 230 > 14 HIToolbox 0x00007fff89e493d3 > RunCurrentEventLoopInMode + 277 > 15 HIToolbox 0x00007fff89e5058f > ReceiveNextEventCommon + 181 > 16 HIToolbox 0x00007fff89e504ca > BlockUntilNextEventMatchingListInMode + 62 > 17 AppKit 0x00007fff8ad033f1 _DPSNextEvent + 659 > 18 AppKit 0x00007fff8ad02cf5 > -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 > 19 libosxapp.dylib 0x0000000110e1b82c > -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + > 124 > 20 AppKit 0x00007fff8acff62d > -[NSApplication run] + 470 > 21 libosxapp.dylib 0x0000000110e1b74b > +[NSApplicationAWT runAWTLoopWithApp:] + 156 > 22 liblwawt.dylib 0x00000001110b8dad > -[AWTStarter starter:] + 1616 > 23 CoreFoundation 0x00007fff88991a1d -[NSObject > performSelector:withObject:] + 61 > 24 Foundation 0x00007fff8e225e44 > __NSThreadPerformPerform + 214 > 25 CoreFoundation 0x00007fff88910b51 > __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 26 CoreFoundation 0x00007fff889103bd > __CFRunLoopDoSources0 + 253 > 27 CoreFoundation 0x00007fff889371a9 __CFRunLoopRun + 905 > 28 CoreFoundation 0x00007fff88936ae6 > CFRunLoopRunSpecific + 230 > 29 java 0x000000010aee7cb4 > CreateExecutionEnvironment + 841 > 30 java 0x000000010aee57b8 JLI_Launch + 1933 > 31 java 0x000000010aee9a30 main + 108 > 32 java 0x000000010aee33f4 start + 52 > 33 ??? 0x0000000000000011 0x0 + 17 > ) From martijnverburg at gmail.com Mon Jan 16 06:18:13 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 16 Jan 2012 14:18:13 +0000 Subject: Should I enter this as a bug? (Groovy Console startup on b223) In-Reply-To: <4F142EDC.8070807@oracle.com> References: <4F142EDC.8070807@oracle.com> Message-ID: Hi Anthony, Thanks for raising the bug for me. Steps to reproduce are: 1.) Install Java 7 developer preview b223 on Mac OS X 10.7.2 2.) Download Groovy 1.8.5 from http://groovy.codehaus.org/Download 3.) Unzip contents to folder of your choice (e.g. /Applications/groovy-1.8.5) 4.) Open up Terminal 5.) cd /Applications/groovy-1.8.5/bin 6.) export JAVA_HOME= (e.g. /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home) 7.) java -version (i.e. To make sure you're using b223) 8.) ./groovyConsole The groovy console does come up but you'll see the stacktrace in the background. This does not occur with the latest jdk 1.6.0_29 bundled with Mac OS X Is there anything further I can send you guys? Let me know! Cheers, Martijn On 16 January 2012 14:06, Anthony Petrov wrote: > Hi Martijn, > > I've just filed the issue at: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130377 (may take some > time to become visible) > > Could you please provide some more detailed instruction on how to reproduce > the issue? What software should be installed and what exactly needs to be > launched? > > Would it be possible for you to provide a simple test case that reproduces > the issue and post it here to the mailing list? > > Thanks in advance! > > -- > best regards, > Anthony > > > On 01/16/12 16:21, Martijn Verburg wrote: >> >> 2012-01-16 12:18:54.086 java[39364:c07] *** -[__NSArrayM >> insertObject:atIndex:]: object cannot be nil >> 2012-01-16 12:18:54.095 java[39364:c07] ( >> ? ? ? ?0 ? CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff889a2286 >> __exceptionPreprocess + 198 >> ? ? ? ?1 ? libobjc.A.dylib ? ? ? ? ? ? ? ? ? ? 0x00007fff90583d5e >> objc_exception_throw + 43 >> ? ? ? ?2 ? CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff88949108 >> -[__NSArrayM insertObject:atIndex:] + 296 >> ? ? ? ?3 ? AppKit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00007fff8ad1a109 -[NSMenu >> insertItem:atIndex:] + 478 >> ? ? ? ?4 ? liblwawt.dylib ? ? ? ? ? ? ? ? ? ? ?0x00000001110bac14 >> addMenuItem + 185 >> ? ? ? ?5 ? liblwawt.dylib ? ? ? ? ? ? ? ? ? ? ?0x00000001110ba905 >> -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 >> ? ? ? ?6 ? liblwawt.dylib ? ? ? ? ? ? ? ? ? ? ?0x00000001110baee1 >> >> __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 >> + 227 >> ? ? ? ?7 ? JavaNativeFoundation ? ? ? ? ? ? ? ?0x00000001100855fd >> +[JNFRunLoop _performCopiedBlock:] + 20 >> ? ? ? ?8 ? CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff889cc0cd >> +[NSObject >> performSelector:withObject:] + 61 >> ? ? ? ?9 ? Foundation ? ? ? ? ? ? ? ? ? ? ? ? ?0x00007fff8e225e44 >> __NSThreadPerformPerform + 214 >> ? ? ? ?10 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff88910b51 >> __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >> ? ? ? ?11 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff889103bd >> __CFRunLoopDoSources0 + 253 >> ? ? ? ?12 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff889371a9 >> __CFRunLoopRun + 905 >> ? ? ? ?13 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff88936ae6 >> CFRunLoopRunSpecific + 230 >> ? ? ? ?14 ?HIToolbox ? ? ? ? ? ? ? ? ? ? ? ? ? 0x00007fff89e493d3 >> RunCurrentEventLoopInMode + 277 >> ? ? ? ?15 ?HIToolbox ? ? ? ? ? ? ? ? ? ? ? ? ? 0x00007fff89e5063d >> ReceiveNextEventCommon + 355 >> ? ? ? ?16 ?HIToolbox ? ? ? ? ? ? ? ? ? ? ? ? ? 0x00007fff89e504ca >> BlockUntilNextEventMatchingListInMode + 62 >> ? ? ? ?17 ?AppKit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00007fff8ad033f1 >> _DPSNextEvent + 659 >> ? ? ? ?18 ?AppKit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00007fff8ad02cf5 >> -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 >> ? ? ? ?19 ?libosxapp.dylib ? ? ? ? ? ? ? ? ? ? 0x0000000110e1b82c >> -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + >> 124 >> ? ? ? ?20 ?AppKit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00007fff8acff62d >> -[NSApplication run] + 470 >> ? ? ? ?21 ?libosxapp.dylib ? ? ? ? ? ? ? ? ? ? 0x0000000110e1b74b >> +[NSApplicationAWT runAWTLoopWithApp:] + 156 >> ? ? ? ?22 ?liblwawt.dylib ? ? ? ? ? ? ? ? ? ? ?0x00000001110b8dad >> -[AWTStarter starter:] + 1616 >> ? ? ? ?23 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff88991a1d >> -[NSObject >> performSelector:withObject:] + 61 >> ? ? ? ?24 ?Foundation ? ? ? ? ? ? ? ? ? ? ? ? ?0x00007fff8e225e44 >> __NSThreadPerformPerform + 214 >> ? ? ? ?25 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff88910b51 >> __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >> ? ? ? ?26 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff889103bd >> __CFRunLoopDoSources0 + 253 >> ? ? ? ?27 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff889371a9 >> __CFRunLoopRun + 905 >> ? ? ? ?28 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff88936ae6 >> CFRunLoopRunSpecific + 230 >> ? ? ? ?29 ?java ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x000000010aee7cb4 >> CreateExecutionEnvironment + 841 >> ? ? ? ?30 ?java ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x000000010aee57b8 >> JLI_Launch + 1933 >> ? ? ? ?31 ?java ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x000000010aee9a30 main + >> 108 >> ? ? ? ?32 ?java ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x000000010aee33f4 start + >> 52 >> ? ? ? ?33 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x0000000000000011 0x0 + 17 >> ) >> 2012-01-16 12:18:54.096 java[39364:c07] *** -[__NSArrayM >> insertObject:atIndex:]: object cannot be nil >> 2012-01-16 12:18:54.097 java[39364:c07] ( >> ? ? ? ?0 ? CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff889a2286 >> __exceptionPreprocess + 198 >> ? ? ? ?1 ? libobjc.A.dylib ? ? ? ? ? ? ? ? ? ? 0x00007fff90583d5e >> objc_exception_throw + 43 >> ? ? ? ?2 ? CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff88949108 >> -[__NSArrayM insertObject:atIndex:] + 296 >> ? ? ? ?3 ? AppKit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00007fff8ad1a109 -[NSMenu >> insertItem:atIndex:] + 478 >> ? ? ? ?4 ? liblwawt.dylib ? ? ? ? ? ? ? ? ? ? ?0x00000001110bac14 >> addMenuItem + 185 >> ? ? ? ?5 ? liblwawt.dylib ? ? ? ? ? ? ? ? ? ? ?0x00000001110ba905 >> -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 >> ? ? ? ?6 ? liblwawt.dylib ? ? ? ? ? ? ? ? ? ? ?0x00000001110baee1 >> >> __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 >> + 227 >> ? ? ? ?7 ? JavaNativeFoundation ? ? ? ? ? ? ? ?0x00000001100855fd >> +[JNFRunLoop _performCopiedBlock:] + 20 >> ? ? ? ?8 ? CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff889cc0cd >> +[NSObject >> performSelector:withObject:] + 61 >> ? ? ? ?9 ? Foundation ? ? ? ? ? ? ? ? ? ? ? ? ?0x00007fff8e225e44 >> __NSThreadPerformPerform + 214 >> ? ? ? ?10 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff88910b51 >> __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >> ? ? ? ?11 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff889103bd >> __CFRunLoopDoSources0 + 253 >> ? ? ? ?12 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff889371a9 >> __CFRunLoopRun + 905 >> ? ? ? ?13 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff88936ae6 >> CFRunLoopRunSpecific + 230 >> ? ? ? ?14 ?HIToolbox ? ? ? ? ? ? ? ? ? ? ? ? ? 0x00007fff89e493d3 >> RunCurrentEventLoopInMode + 277 >> ? ? ? ?15 ?HIToolbox ? ? ? ? ? ? ? ? ? ? ? ? ? 0x00007fff89e5058f >> ReceiveNextEventCommon + 181 >> ? ? ? ?16 ?HIToolbox ? ? ? ? ? ? ? ? ? ? ? ? ? 0x00007fff89e504ca >> BlockUntilNextEventMatchingListInMode + 62 >> ? ? ? ?17 ?AppKit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00007fff8ad033f1 >> _DPSNextEvent + 659 >> ? ? ? ?18 ?AppKit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00007fff8ad02cf5 >> -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 >> ? ? ? ?19 ?libosxapp.dylib ? ? ? ? ? ? ? ? ? ? 0x0000000110e1b82c >> -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + >> 124 >> ? ? ? ?20 ?AppKit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00007fff8acff62d >> -[NSApplication run] + 470 >> ? ? ? ?21 ?libosxapp.dylib ? ? ? ? ? ? ? ? ? ? 0x0000000110e1b74b >> +[NSApplicationAWT runAWTLoopWithApp:] + 156 >> ? ? ? ?22 ?liblwawt.dylib ? ? ? ? ? ? ? ? ? ? ?0x00000001110b8dad >> -[AWTStarter starter:] + 1616 >> ? ? ? ?23 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff88991a1d >> -[NSObject >> performSelector:withObject:] + 61 >> ? ? ? ?24 ?Foundation ? ? ? ? ? ? ? ? ? ? ? ? ?0x00007fff8e225e44 >> __NSThreadPerformPerform + 214 >> ? ? ? ?25 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff88910b51 >> __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 >> ? ? ? ?26 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff889103bd >> __CFRunLoopDoSources0 + 253 >> ? ? ? ?27 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff889371a9 >> __CFRunLoopRun + 905 >> ? ? ? ?28 ?CoreFoundation ? ? ? ? ? ? ? ? ? ? ?0x00007fff88936ae6 >> CFRunLoopRunSpecific + 230 >> ? ? ? ?29 ?java ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x000000010aee7cb4 >> CreateExecutionEnvironment + 841 >> ? ? ? ?30 ?java ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x000000010aee57b8 >> JLI_Launch + 1933 >> ? ? ? ?31 ?java ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x000000010aee9a30 main + >> 108 >> ? ? ? ?32 ?java ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x000000010aee33f4 start + >> 52 >> ? ? ? ?33 ???? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x0000000000000011 0x0 + 17 >> ) From anthony.petrov at oracle.com Mon Jan 16 06:37:16 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 16 Jan 2012 18:37:16 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> Message-ID: <4F14361C.70106@oracle.com> Hi Mike, Sounds good to me. Thanks! In the meantime could you please Reply All to the message I've sent last week and state that you're OK with the patch that fixes the levels issue? As I've explained, it doesn't really change any already existing behavior but only helps maintain the always-on-top property for child windows. -- best regards, Anthony On 01/15/12 07:40, Mike Swingler wrote: > In the course of preparing to contribute our current window stacking algorithm, I realized that there was a pair of internal SPI calls it was making. In the next revision we ship of the JavaRuntimeSupport.framework we can provide cover methods of these SPI, however that is of little benefit to the OpenJDK port in the immediate here-and-now. > > For now, using -addChildWindow: will be sufficient, however, we can provide an alternate implementation that uses a new pair of category methods on NSWindow if -respondsToSelector: shows that they are available: > - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; > - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; > > These functions will allow the window server to move each child window with respect to it's parent's level, but without being added to it's movement group. > > Once customers get an updated JavaNativeFoundation.framework by either Java update or OS update, the implementation will switch over dynamically at runtime. > > How does this sound for a plan? > > Regards, > Mike Swingler > Apple Inc. > > On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com wrote: > >> We fought this one in SWT and ended up going with the puppy route. >> >> Steve >> >> On 12/01/2012 2:57 PM, Anthony Petrov wrote: >>> Hi Mike, >>> >>> I recall we've discussed this issue with you back in 2010. Unfortunately, I wasn't able to implement anything like this that would work reliably back then (and I tried hard, really), that's why we ended up with -addChildWindow:. Note that JCK is very happy with this implementation, and so are we, I presume. As long as child windows receive their respective MOVE events, it seems that everything is all right. Besides, such behavior is very Mac-friendly, making Java apps behave like native apps. >>> >>> I realize that for some developers this behavior may be inconvenient. But then again, why not listen to MOVE events on the parent frame and compensate for its movement repositioning all its children? ( :) yeah, yeah, I know, sounds weird, but... as Steve says, you gotta do what you gotta do... I mean, there's a workaround at least!) >>> >>> So, if you or anyone else wish to contribute an alternative implementation for owned windows, that would be greatly appreciated. Otherwise I'm afraid we have to stick with using -addChildWindow: for now since we simply don't have a better solution. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>>> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). >>>> >>>> In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. >>>> >>>> Regards, >>>> Mike Swingler >>>> Apple Inc. >>>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>>> >>>>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. >>>>> >>>>> >>>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>>> >>>>>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>>>>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>>>>>> >>>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>>> >>>>>>>> Hi Leonid, >>>>>>>> >>>>>>>> Thanks for taking a look at the fix. >>>>>>>> >>>>>>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>>>> >>>>>>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>>>>>> >>>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>>> >>>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>>>>>> >>>>>>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>>>>>> >>>>>>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> best regards, >>>>>>>>>> Anthony >>>> > From michael.x.mcmahon at oracle.com Mon Jan 16 07:09:30 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 16 Jan 2012 15:09:30 +0000 Subject: hg: jdk7u/jdk7u-osx/jaxp: 3 new changesets Message-ID: <20120116150934.CF14B47989@hg.openjdk.java.net> Changeset: d9891683fc16 Author: joehw Date: 2011-12-22 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/d9891683fc16 7121110: JAXP 1.4.5 update 1 for 7u4 Reviewed-by: ohair - build-defs.xml - build-drop-template.xml ! build.properties ! build.xml - jaxp.properties + nbproject/genfiles.properties + nbproject/jdk.xml + nbproject/nbjdk.properties + nbproject/nbjdk.xml ! nbproject/project.xml - patches/jaxp_src/README + src/com/sun/java_cup/internal/runtime/Scanner.java + src/com/sun/java_cup/internal/runtime/Symbol.java + src/com/sun/java_cup/internal/runtime/lr_parser.java + src/com/sun/java_cup/internal/runtime/virtual_parse_stack.java + src/com/sun/org/apache/bcel/internal/Constants.java + src/com/sun/org/apache/bcel/internal/ExceptionConstants.java + src/com/sun/org/apache/bcel/internal/Repository.java + src/com/sun/org/apache/bcel/internal/classfile/AccessFlags.java + src/com/sun/org/apache/bcel/internal/classfile/Attribute.java + src/com/sun/org/apache/bcel/internal/classfile/AttributeReader.java + src/com/sun/org/apache/bcel/internal/classfile/ClassFormatException.java + src/com/sun/org/apache/bcel/internal/classfile/ClassParser.java + src/com/sun/org/apache/bcel/internal/classfile/Code.java + src/com/sun/org/apache/bcel/internal/classfile/CodeException.java + src/com/sun/org/apache/bcel/internal/classfile/Constant.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantCP.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantClass.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantDouble.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantFieldref.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantFloat.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantInteger.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantInterfaceMethodref.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantMethodref.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantNameAndType.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantObject.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantPool.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantString.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantUtf8.java + src/com/sun/org/apache/bcel/internal/classfile/ConstantValue.java + src/com/sun/org/apache/bcel/internal/classfile/Deprecated.java + src/com/sun/org/apache/bcel/internal/classfile/DescendingVisitor.java + src/com/sun/org/apache/bcel/internal/classfile/EmptyVisitor.java + src/com/sun/org/apache/bcel/internal/classfile/ExceptionTable.java + src/com/sun/org/apache/bcel/internal/classfile/Field.java + src/com/sun/org/apache/bcel/internal/classfile/FieldOrMethod.java + src/com/sun/org/apache/bcel/internal/classfile/InnerClass.java + src/com/sun/org/apache/bcel/internal/classfile/InnerClasses.java + src/com/sun/org/apache/bcel/internal/classfile/JavaClass.java + src/com/sun/org/apache/bcel/internal/classfile/LineNumber.java + src/com/sun/org/apache/bcel/internal/classfile/LineNumberTable.java + src/com/sun/org/apache/bcel/internal/classfile/LocalVariable.java + src/com/sun/org/apache/bcel/internal/classfile/LocalVariableTable.java + src/com/sun/org/apache/bcel/internal/classfile/Method.java + src/com/sun/org/apache/bcel/internal/classfile/Node.java + src/com/sun/org/apache/bcel/internal/classfile/PMGClass.java + src/com/sun/org/apache/bcel/internal/classfile/Signature.java + src/com/sun/org/apache/bcel/internal/classfile/SourceFile.java + src/com/sun/org/apache/bcel/internal/classfile/StackMap.java + src/com/sun/org/apache/bcel/internal/classfile/StackMapEntry.java + src/com/sun/org/apache/bcel/internal/classfile/StackMapType.java + src/com/sun/org/apache/bcel/internal/classfile/Synthetic.java + src/com/sun/org/apache/bcel/internal/classfile/Unknown.java + src/com/sun/org/apache/bcel/internal/classfile/Utility.java + src/com/sun/org/apache/bcel/internal/classfile/Visitor.java + src/com/sun/org/apache/bcel/internal/classfile/package.html + src/com/sun/org/apache/bcel/internal/generic/AALOAD.java + src/com/sun/org/apache/bcel/internal/generic/AASTORE.java + src/com/sun/org/apache/bcel/internal/generic/ACONST_NULL.java + src/com/sun/org/apache/bcel/internal/generic/ALOAD.java + src/com/sun/org/apache/bcel/internal/generic/ANEWARRAY.java + src/com/sun/org/apache/bcel/internal/generic/ARETURN.java + src/com/sun/org/apache/bcel/internal/generic/ARRAYLENGTH.java + src/com/sun/org/apache/bcel/internal/generic/ASTORE.java + src/com/sun/org/apache/bcel/internal/generic/ATHROW.java + src/com/sun/org/apache/bcel/internal/generic/AllocationInstruction.java + src/com/sun/org/apache/bcel/internal/generic/ArithmeticInstruction.java + src/com/sun/org/apache/bcel/internal/generic/ArrayInstruction.java + src/com/sun/org/apache/bcel/internal/generic/ArrayType.java + src/com/sun/org/apache/bcel/internal/generic/BALOAD.java + src/com/sun/org/apache/bcel/internal/generic/BASTORE.java + src/com/sun/org/apache/bcel/internal/generic/BIPUSH.java + src/com/sun/org/apache/bcel/internal/generic/BREAKPOINT.java + src/com/sun/org/apache/bcel/internal/generic/BasicType.java + src/com/sun/org/apache/bcel/internal/generic/BranchHandle.java + src/com/sun/org/apache/bcel/internal/generic/BranchInstruction.java + src/com/sun/org/apache/bcel/internal/generic/CALOAD.java + src/com/sun/org/apache/bcel/internal/generic/CASTORE.java + src/com/sun/org/apache/bcel/internal/generic/CHECKCAST.java + src/com/sun/org/apache/bcel/internal/generic/CPInstruction.java + src/com/sun/org/apache/bcel/internal/generic/ClassGen.java + src/com/sun/org/apache/bcel/internal/generic/ClassGenException.java + src/com/sun/org/apache/bcel/internal/generic/ClassObserver.java + src/com/sun/org/apache/bcel/internal/generic/CodeExceptionGen.java + src/com/sun/org/apache/bcel/internal/generic/CompoundInstruction.java + src/com/sun/org/apache/bcel/internal/generic/ConstantPoolGen.java + src/com/sun/org/apache/bcel/internal/generic/ConstantPushInstruction.java + src/com/sun/org/apache/bcel/internal/generic/ConversionInstruction.java + src/com/sun/org/apache/bcel/internal/generic/D2F.java + src/com/sun/org/apache/bcel/internal/generic/D2I.java + src/com/sun/org/apache/bcel/internal/generic/D2L.java + src/com/sun/org/apache/bcel/internal/generic/DADD.java + src/com/sun/org/apache/bcel/internal/generic/DALOAD.java + src/com/sun/org/apache/bcel/internal/generic/DASTORE.java + src/com/sun/org/apache/bcel/internal/generic/DCMPG.java + src/com/sun/org/apache/bcel/internal/generic/DCMPL.java + src/com/sun/org/apache/bcel/internal/generic/DCONST.java + src/com/sun/org/apache/bcel/internal/generic/DDIV.java + src/com/sun/org/apache/bcel/internal/generic/DLOAD.java + src/com/sun/org/apache/bcel/internal/generic/DMUL.java + src/com/sun/org/apache/bcel/internal/generic/DNEG.java + src/com/sun/org/apache/bcel/internal/generic/DREM.java + src/com/sun/org/apache/bcel/internal/generic/DRETURN.java + src/com/sun/org/apache/bcel/internal/generic/DSTORE.java + src/com/sun/org/apache/bcel/internal/generic/DSUB.java + src/com/sun/org/apache/bcel/internal/generic/DUP.java + src/com/sun/org/apache/bcel/internal/generic/DUP2.java + src/com/sun/org/apache/bcel/internal/generic/DUP2_X1.java + src/com/sun/org/apache/bcel/internal/generic/DUP2_X2.java + src/com/sun/org/apache/bcel/internal/generic/DUP_X1.java + src/com/sun/org/apache/bcel/internal/generic/DUP_X2.java + src/com/sun/org/apache/bcel/internal/generic/EmptyVisitor.java + src/com/sun/org/apache/bcel/internal/generic/ExceptionThrower.java + src/com/sun/org/apache/bcel/internal/generic/F2D.java + src/com/sun/org/apache/bcel/internal/generic/F2I.java + src/com/sun/org/apache/bcel/internal/generic/F2L.java + src/com/sun/org/apache/bcel/internal/generic/FADD.java + src/com/sun/org/apache/bcel/internal/generic/FALOAD.java + src/com/sun/org/apache/bcel/internal/generic/FASTORE.java + src/com/sun/org/apache/bcel/internal/generic/FCMPG.java + src/com/sun/org/apache/bcel/internal/generic/FCMPL.java + src/com/sun/org/apache/bcel/internal/generic/FCONST.java + src/com/sun/org/apache/bcel/internal/generic/FDIV.java + src/com/sun/org/apache/bcel/internal/generic/FLOAD.java + src/com/sun/org/apache/bcel/internal/generic/FMUL.java + src/com/sun/org/apache/bcel/internal/generic/FNEG.java + src/com/sun/org/apache/bcel/internal/generic/FREM.java + src/com/sun/org/apache/bcel/internal/generic/FRETURN.java + src/com/sun/org/apache/bcel/internal/generic/FSTORE.java + src/com/sun/org/apache/bcel/internal/generic/FSUB.java + src/com/sun/org/apache/bcel/internal/generic/FieldGen.java + src/com/sun/org/apache/bcel/internal/generic/FieldGenOrMethodGen.java + src/com/sun/org/apache/bcel/internal/generic/FieldInstruction.java + src/com/sun/org/apache/bcel/internal/generic/FieldObserver.java + src/com/sun/org/apache/bcel/internal/generic/FieldOrMethod.java + src/com/sun/org/apache/bcel/internal/generic/GETFIELD.java + src/com/sun/org/apache/bcel/internal/generic/GETSTATIC.java + src/com/sun/org/apache/bcel/internal/generic/GOTO.java + src/com/sun/org/apache/bcel/internal/generic/GOTO_W.java + src/com/sun/org/apache/bcel/internal/generic/GotoInstruction.java + src/com/sun/org/apache/bcel/internal/generic/I2B.java + src/com/sun/org/apache/bcel/internal/generic/I2C.java + src/com/sun/org/apache/bcel/internal/generic/I2D.java + src/com/sun/org/apache/bcel/internal/generic/I2F.java + src/com/sun/org/apache/bcel/internal/generic/I2L.java + src/com/sun/org/apache/bcel/internal/generic/I2S.java + src/com/sun/org/apache/bcel/internal/generic/IADD.java + src/com/sun/org/apache/bcel/internal/generic/IALOAD.java + src/com/sun/org/apache/bcel/internal/generic/IAND.java + src/com/sun/org/apache/bcel/internal/generic/IASTORE.java + src/com/sun/org/apache/bcel/internal/generic/ICONST.java + src/com/sun/org/apache/bcel/internal/generic/IDIV.java + src/com/sun/org/apache/bcel/internal/generic/IFEQ.java + src/com/sun/org/apache/bcel/internal/generic/IFGE.java + src/com/sun/org/apache/bcel/internal/generic/IFGT.java + src/com/sun/org/apache/bcel/internal/generic/IFLE.java + src/com/sun/org/apache/bcel/internal/generic/IFLT.java + src/com/sun/org/apache/bcel/internal/generic/IFNE.java + src/com/sun/org/apache/bcel/internal/generic/IFNONNULL.java + src/com/sun/org/apache/bcel/internal/generic/IFNULL.java + src/com/sun/org/apache/bcel/internal/generic/IF_ACMPEQ.java + src/com/sun/org/apache/bcel/internal/generic/IF_ACMPNE.java + src/com/sun/org/apache/bcel/internal/generic/IF_ICMPEQ.java + src/com/sun/org/apache/bcel/internal/generic/IF_ICMPGE.java + src/com/sun/org/apache/bcel/internal/generic/IF_ICMPGT.java + src/com/sun/org/apache/bcel/internal/generic/IF_ICMPLE.java + src/com/sun/org/apache/bcel/internal/generic/IF_ICMPLT.java + src/com/sun/org/apache/bcel/internal/generic/IF_ICMPNE.java + src/com/sun/org/apache/bcel/internal/generic/IINC.java + src/com/sun/org/apache/bcel/internal/generic/ILOAD.java + src/com/sun/org/apache/bcel/internal/generic/IMPDEP1.java + src/com/sun/org/apache/bcel/internal/generic/IMPDEP2.java + src/com/sun/org/apache/bcel/internal/generic/IMUL.java + src/com/sun/org/apache/bcel/internal/generic/INEG.java + src/com/sun/org/apache/bcel/internal/generic/INSTANCEOF.java + src/com/sun/org/apache/bcel/internal/generic/INVOKEINTERFACE.java + src/com/sun/org/apache/bcel/internal/generic/INVOKESPECIAL.java + src/com/sun/org/apache/bcel/internal/generic/INVOKESTATIC.java + src/com/sun/org/apache/bcel/internal/generic/INVOKEVIRTUAL.java + src/com/sun/org/apache/bcel/internal/generic/IOR.java + src/com/sun/org/apache/bcel/internal/generic/IREM.java + src/com/sun/org/apache/bcel/internal/generic/IRETURN.java + src/com/sun/org/apache/bcel/internal/generic/ISHL.java + src/com/sun/org/apache/bcel/internal/generic/ISHR.java + src/com/sun/org/apache/bcel/internal/generic/ISTORE.java + src/com/sun/org/apache/bcel/internal/generic/ISUB.java + src/com/sun/org/apache/bcel/internal/generic/IUSHR.java + src/com/sun/org/apache/bcel/internal/generic/IXOR.java + src/com/sun/org/apache/bcel/internal/generic/IfInstruction.java + src/com/sun/org/apache/bcel/internal/generic/IndexedInstruction.java + src/com/sun/org/apache/bcel/internal/generic/Instruction.java + src/com/sun/org/apache/bcel/internal/generic/InstructionComparator.java + src/com/sun/org/apache/bcel/internal/generic/InstructionConstants.java + src/com/sun/org/apache/bcel/internal/generic/InstructionFactory.java + src/com/sun/org/apache/bcel/internal/generic/InstructionHandle.java + src/com/sun/org/apache/bcel/internal/generic/InstructionList.java + src/com/sun/org/apache/bcel/internal/generic/InstructionListObserver.java + src/com/sun/org/apache/bcel/internal/generic/InstructionTargeter.java + src/com/sun/org/apache/bcel/internal/generic/InvokeInstruction.java + src/com/sun/org/apache/bcel/internal/generic/JSR.java + src/com/sun/org/apache/bcel/internal/generic/JSR_W.java + src/com/sun/org/apache/bcel/internal/generic/JsrInstruction.java + src/com/sun/org/apache/bcel/internal/generic/L2D.java + src/com/sun/org/apache/bcel/internal/generic/L2F.java + src/com/sun/org/apache/bcel/internal/generic/L2I.java + src/com/sun/org/apache/bcel/internal/generic/LADD.java + src/com/sun/org/apache/bcel/internal/generic/LALOAD.java + src/com/sun/org/apache/bcel/internal/generic/LAND.java + src/com/sun/org/apache/bcel/internal/generic/LASTORE.java + src/com/sun/org/apache/bcel/internal/generic/LCMP.java + src/com/sun/org/apache/bcel/internal/generic/LCONST.java + src/com/sun/org/apache/bcel/internal/generic/LDC.java + src/com/sun/org/apache/bcel/internal/generic/LDC2_W.java + src/com/sun/org/apache/bcel/internal/generic/LDC_W.java + src/com/sun/org/apache/bcel/internal/generic/LDIV.java + src/com/sun/org/apache/bcel/internal/generic/LLOAD.java + src/com/sun/org/apache/bcel/internal/generic/LMUL.java + src/com/sun/org/apache/bcel/internal/generic/LNEG.java + src/com/sun/org/apache/bcel/internal/generic/LOOKUPSWITCH.java + src/com/sun/org/apache/bcel/internal/generic/LOR.java + src/com/sun/org/apache/bcel/internal/generic/LREM.java + src/com/sun/org/apache/bcel/internal/generic/LRETURN.java + src/com/sun/org/apache/bcel/internal/generic/LSHL.java + src/com/sun/org/apache/bcel/internal/generic/LSHR.java + src/com/sun/org/apache/bcel/internal/generic/LSTORE.java + src/com/sun/org/apache/bcel/internal/generic/LSUB.java + src/com/sun/org/apache/bcel/internal/generic/LUSHR.java + src/com/sun/org/apache/bcel/internal/generic/LXOR.java + src/com/sun/org/apache/bcel/internal/generic/LineNumberGen.java + src/com/sun/org/apache/bcel/internal/generic/LoadClass.java + src/com/sun/org/apache/bcel/internal/generic/LoadInstruction.java + src/com/sun/org/apache/bcel/internal/generic/LocalVariableGen.java + src/com/sun/org/apache/bcel/internal/generic/LocalVariableInstruction.java + src/com/sun/org/apache/bcel/internal/generic/MONITORENTER.java + src/com/sun/org/apache/bcel/internal/generic/MONITOREXIT.java + src/com/sun/org/apache/bcel/internal/generic/MULTIANEWARRAY.java + src/com/sun/org/apache/bcel/internal/generic/MethodGen.java + src/com/sun/org/apache/bcel/internal/generic/MethodObserver.java + src/com/sun/org/apache/bcel/internal/generic/NEW.java + src/com/sun/org/apache/bcel/internal/generic/NEWARRAY.java + src/com/sun/org/apache/bcel/internal/generic/NOP.java + src/com/sun/org/apache/bcel/internal/generic/NamedAndTyped.java + src/com/sun/org/apache/bcel/internal/generic/ObjectType.java + src/com/sun/org/apache/bcel/internal/generic/POP.java + src/com/sun/org/apache/bcel/internal/generic/POP2.java + src/com/sun/org/apache/bcel/internal/generic/PUSH.java + src/com/sun/org/apache/bcel/internal/generic/PUTFIELD.java + src/com/sun/org/apache/bcel/internal/generic/PUTSTATIC.java + src/com/sun/org/apache/bcel/internal/generic/PopInstruction.java + src/com/sun/org/apache/bcel/internal/generic/PushInstruction.java + src/com/sun/org/apache/bcel/internal/generic/RET.java + src/com/sun/org/apache/bcel/internal/generic/RETURN.java + src/com/sun/org/apache/bcel/internal/generic/ReferenceType.java + src/com/sun/org/apache/bcel/internal/generic/ReturnInstruction.java + src/com/sun/org/apache/bcel/internal/generic/ReturnaddressType.java + src/com/sun/org/apache/bcel/internal/generic/SALOAD.java + src/com/sun/org/apache/bcel/internal/generic/SASTORE.java + src/com/sun/org/apache/bcel/internal/generic/SIPUSH.java + src/com/sun/org/apache/bcel/internal/generic/SWAP.java + src/com/sun/org/apache/bcel/internal/generic/SWITCH.java + src/com/sun/org/apache/bcel/internal/generic/Select.java + src/com/sun/org/apache/bcel/internal/generic/StackConsumer.java + src/com/sun/org/apache/bcel/internal/generic/StackInstruction.java + src/com/sun/org/apache/bcel/internal/generic/StackProducer.java + src/com/sun/org/apache/bcel/internal/generic/StoreInstruction.java + src/com/sun/org/apache/bcel/internal/generic/TABLESWITCH.java + src/com/sun/org/apache/bcel/internal/generic/TargetLostException.java + src/com/sun/org/apache/bcel/internal/generic/Type.java + src/com/sun/org/apache/bcel/internal/generic/TypedInstruction.java + src/com/sun/org/apache/bcel/internal/generic/UnconditionalBranch.java + src/com/sun/org/apache/bcel/internal/generic/VariableLengthInstruction.java + src/com/sun/org/apache/bcel/internal/generic/Visitor.java + src/com/sun/org/apache/bcel/internal/generic/package.html + src/com/sun/org/apache/bcel/internal/package.html + src/com/sun/org/apache/bcel/internal/util/AttributeHTML.java + src/com/sun/org/apache/bcel/internal/util/BCELFactory.java + src/com/sun/org/apache/bcel/internal/util/BCELifier.java + src/com/sun/org/apache/bcel/internal/util/ByteSequence.java + src/com/sun/org/apache/bcel/internal/util/Class2HTML.java + src/com/sun/org/apache/bcel/internal/util/ClassLoader.java + src/com/sun/org/apache/bcel/internal/util/ClassLoaderRepository.java + src/com/sun/org/apache/bcel/internal/util/ClassPath.java + src/com/sun/org/apache/bcel/internal/util/ClassQueue.java + src/com/sun/org/apache/bcel/internal/util/ClassSet.java + src/com/sun/org/apache/bcel/internal/util/ClassStack.java + src/com/sun/org/apache/bcel/internal/util/ClassVector.java + src/com/sun/org/apache/bcel/internal/util/CodeHTML.java + src/com/sun/org/apache/bcel/internal/util/ConstantHTML.java + src/com/sun/org/apache/bcel/internal/util/InstructionFinder.java + src/com/sun/org/apache/bcel/internal/util/JavaWrapper.java + src/com/sun/org/apache/bcel/internal/util/MethodHTML.java + src/com/sun/org/apache/bcel/internal/util/Repository.java + src/com/sun/org/apache/bcel/internal/util/SyntheticRepository.java + src/com/sun/org/apache/bcel/internal/util/package.html + src/com/sun/org/apache/regexp/internal/CharacterArrayCharacterIterator.java + src/com/sun/org/apache/regexp/internal/CharacterIterator.java + src/com/sun/org/apache/regexp/internal/RE.java + src/com/sun/org/apache/regexp/internal/RECompiler.java + src/com/sun/org/apache/regexp/internal/REDebugCompiler.java + src/com/sun/org/apache/regexp/internal/REProgram.java + src/com/sun/org/apache/regexp/internal/RESyntaxException.java + src/com/sun/org/apache/regexp/internal/RETest.java + src/com/sun/org/apache/regexp/internal/REUtil.java + src/com/sun/org/apache/regexp/internal/ReaderCharacterIterator.java + src/com/sun/org/apache/regexp/internal/StreamCharacterIterator.java + src/com/sun/org/apache/regexp/internal/StringCharacterIterator.java + src/com/sun/org/apache/regexp/internal/recompile.java + src/com/sun/org/apache/xalan/META-INF/services/javax.xml.transform.TransformerFactory + src/com/sun/org/apache/xalan/META-INF/services/javax.xml.xpath.XPathFactory + src/com/sun/org/apache/xalan/META-INF/services/org.apache.xml.dtm.DTMManager + src/com/sun/org/apache/xalan/internal/Version.java + src/com/sun/org/apache/xalan/internal/XalanConstants.java + src/com/sun/org/apache/xalan/internal/extensions/ExpressionContext.java + src/com/sun/org/apache/xalan/internal/extensions/package.html + src/com/sun/org/apache/xalan/internal/lib/ExsltBase.java + src/com/sun/org/apache/xalan/internal/lib/ExsltCommon.java + src/com/sun/org/apache/xalan/internal/lib/ExsltDatetime.java + src/com/sun/org/apache/xalan/internal/lib/ExsltDynamic.java + src/com/sun/org/apache/xalan/internal/lib/ExsltMath.java + src/com/sun/org/apache/xalan/internal/lib/ExsltSets.java + src/com/sun/org/apache/xalan/internal/lib/ExsltStrings.java + src/com/sun/org/apache/xalan/internal/lib/Extensions.java + src/com/sun/org/apache/xalan/internal/lib/NodeInfo.java + src/com/sun/org/apache/xalan/internal/lib/ObjectFactory.java + src/com/sun/org/apache/xalan/internal/lib/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/lib/SecuritySupport12.java + src/com/sun/org/apache/xalan/internal/lib/package.html + src/com/sun/org/apache/xalan/internal/res/XSLMessages.java + src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java + src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java + src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_en.java + src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java + src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java + src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java + src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java + src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java + src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java + src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java + src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java + src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java + src/com/sun/org/apache/xalan/internal/res/XSLTInfo.properties + src/com/sun/org/apache/xalan/internal/res/package.html + src/com/sun/org/apache/xalan/internal/templates/Constants.java + src/com/sun/org/apache/xalan/internal/templates/package.html + src/com/sun/org/apache/xalan/internal/utils/ConfigurationError.java + src/com/sun/org/apache/xalan/internal/utils/FactoryImpl.java + src/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java + src/com/sun/org/apache/xalan/internal/utils/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java + src/com/sun/org/apache/xalan/internal/xslt/ObjectFactory.java + src/com/sun/org/apache/xalan/internal/xslt/Process.java + src/com/sun/org/apache/xalan/internal/xslt/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/xslt/SecuritySupport12.java + src/com/sun/org/apache/xalan/internal/xslt/package.html + src/com/sun/org/apache/xalan/internal/xsltc/CollatorFactory.java + src/com/sun/org/apache/xalan/internal/xsltc/DOM.java + src/com/sun/org/apache/xalan/internal/xsltc/DOMCache.java + src/com/sun/org/apache/xalan/internal/xsltc/DOMEnhancedForDTM.java + src/com/sun/org/apache/xalan/internal/xsltc/NodeIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/ProcessorVersion.java + src/com/sun/org/apache/xalan/internal/xsltc/StripFilter.java + src/com/sun/org/apache/xalan/internal/xsltc/Translet.java + src/com/sun/org/apache/xalan/internal/xsltc/TransletException.java + src/com/sun/org/apache/xalan/internal/xsltc/cmdline/Compile.java + src/com/sun/org/apache/xalan/internal/xsltc/cmdline/ObjectFactory.java + src/com/sun/org/apache/xalan/internal/xsltc/cmdline/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/xsltc/cmdline/SecuritySupport12.java + src/com/sun/org/apache/xalan/internal/xsltc/cmdline/Transform.java + src/com/sun/org/apache/xalan/internal/xsltc/cmdline/getopt/GetOpt.java + src/com/sun/org/apache/xalan/internal/xsltc/cmdline/getopt/GetOptsException.java + src/com/sun/org/apache/xalan/internal/xsltc/cmdline/getopt/IllegalArgumentException.java + src/com/sun/org/apache/xalan/internal/xsltc/cmdline/getopt/MissingOptArgException.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/AbsoluteLocationPath.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/AbsolutePathPattern.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/AlternativePattern.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/AncestorPattern.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyImports.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyTemplates.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ArgumentList.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Attribute.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeSet.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValue.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValueTemplate.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/BinOpExpr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/BooleanCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/BooleanExpr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/CallTemplate.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/CastCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/CastExpr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/CeilingCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Choose.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Closure.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Comment.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/CompilerException.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ConcatCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Constants.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ContainsCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Copy.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/CopyOf.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/CurrentCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/DecimalFormatting.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/DocumentCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ElementAvailableCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/EqualityExpr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Expression.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Fallback.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/FilterExpr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/FilterParentPath.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/FilteredAbsoluteLocationPath.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/FloorCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/FlowList.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ForEach.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/FormatNumberCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionAvailableCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/GenerateIdCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/IdKeyPattern.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/IdPattern.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/If.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/IllegalCharException.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Instruction.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/IntExpr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Key.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/KeyCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/KeyPattern.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/LangCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/LastCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralAttribute.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralExpr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/LocalNameCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/LocationPathPattern.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/LogicalExpr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Makefile.inc + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Message.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Mode.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/NameBase.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/NameCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/NamespaceAlias.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/NamespaceUriCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/NodeTest.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/NotCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Number.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/NumberCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ObjectFactory.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Otherwise.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Output.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Param.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ParameterRef.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ParentLocationPath.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ParentPattern.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Pattern.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/PositionCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Predicate.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ProcessingInstruction.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ProcessingInstructionPattern.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/QName.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/RealExpr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/RelationalExpr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/RelativeLocationPath.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/RelativePathPattern.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/RoundCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/SecuritySupport12.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/SimpleAttributeValue.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Sort.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/SourceLoader.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/StartsWithCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Step.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/StepPattern.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/StringCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/StringLengthCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Stylesheet.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/SymbolTable.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/SyntaxTreeNode.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Template.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/TestSeq.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Text.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/TopLevelElement.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/TransletOutput.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/UnaryOpExpr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/UnionPathExpr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/UnparsedEntityUriCall.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/UnresolvedRef.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/UnsupportedElement.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/UseAttributeSets.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/ValueOf.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Variable.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableBase.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableRef.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableRefBase.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/When.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/Whitespace.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/WithParam.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/XPathLexer.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/XPathParser.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/XslAttribute.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/XslElement.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/sym.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/AttributeSetMethodGenerator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/BooleanType.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ClassGenerator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/CompareGenerator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ca.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_cs.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sk.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/FilterGenerator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/IntType.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/InternalError.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MarkerInstruction.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MatchGenerator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodGenerator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodType.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MultiHashtable.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NamedMethodGenerator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeCounterGenerator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeSetType.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeSortRecordFactGenerator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeSortRecordGenerator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeType.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NumberType.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ObjectFactory.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ObjectType.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/OutlineableChunkEnd.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/OutlineableChunkStart.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/RealType.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ReferenceType.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ResultTreeType.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/RtMethodGenerator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/SecuritySupport12.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/SlotAllocator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/StringStack.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/StringType.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/TestGenerator.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Type.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/TypeCheckError.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Util.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/VoidType.java + src/com/sun/org/apache/xalan/internal/xsltc/compiler/xpath.cup + src/com/sun/org/apache/xalan/internal/xsltc/compiler/xpath.lex + src/com/sun/org/apache/xalan/internal/xsltc/dom/AbsoluteIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/AdaptiveResultTreeImpl.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/AnyNodeCounter.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/ArrayNodeListIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/BitArray.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/CachedNodeListIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/ClonedNodeListIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/CollatorFactoryBase.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/CurrentNodeListFilter.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/CurrentNodeListIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/DOMAdapter.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/DOMBuilder.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/DOMWSFilter.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/DupFilterIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/EmptyFilter.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/ExtendedSAX.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/Filter.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/FilterIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/FilteredStepIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/ForwardPositionIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/KeyIndex.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/LoadDocument.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/MatchingIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/MultiDOM.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/MultiValuedNodeHeapIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/MultipleNodeCounter.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/NodeCounter.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/NodeIteratorBase.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecord.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecordFactory.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/NthIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/ObjectFactory.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/SAXImpl.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/SecuritySupport12.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/SimpleResultTreeImpl.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/SingleNodeCounter.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/SingletonIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/SortSettings.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/SortingIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/StepIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/StripWhitespaceFilter.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/UnionIterator.java + src/com/sun/org/apache/xalan/internal/xsltc/dom/XSLTCDTMManager.java + src/com/sun/org/apache/xalan/internal/xsltc/javax.xml.transform.TransformerFactory + src/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/Attributes.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/Constants.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ca.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_cs.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_de.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_es.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_fr.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_it.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ja.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ko.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sk.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_TW.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/InternalRuntimeError.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/MessageHandler.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/Node.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/ObjectFactory.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/Operators.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/Parameter.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/SecuritySupport12.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/StringValueHandler.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/output/OutputBuffer.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/output/StringOutputBuffer.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/output/TransletOutputHandlerFactory.java + src/com/sun/org/apache/xalan/internal/xsltc/runtime/output/WriterOutputBuffer.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2TO.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/ObjectFactory.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/OutputSettings.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2DOM.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2StAXBaseWriter.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2StAXEventWriter.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2StAXStreamWriter.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/SecuritySupport12.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/SmartTransformerFactoryImpl.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/StAXEvent2SAX.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/StAXStream2SAX.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/TrAXFilter.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerHandlerImpl.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java + src/com/sun/org/apache/xalan/internal/xsltc/trax/XSLTCSource.java + src/com/sun/org/apache/xalan/internal/xsltc/util/IntegerArray.java + src/com/sun/org/apache/xerces/internal/dom/AttrImpl.java + src/com/sun/org/apache/xerces/internal/dom/AttrNSImpl.java + src/com/sun/org/apache/xerces/internal/dom/AttributeMap.java + src/com/sun/org/apache/xerces/internal/dom/CDATASectionImpl.java + src/com/sun/org/apache/xerces/internal/dom/CharacterDataImpl.java + src/com/sun/org/apache/xerces/internal/dom/ChildNode.java + src/com/sun/org/apache/xerces/internal/dom/CommentImpl.java + src/com/sun/org/apache/xerces/internal/dom/CoreDOMImplementationImpl.java + src/com/sun/org/apache/xerces/internal/dom/CoreDocumentImpl.java + src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java + src/com/sun/org/apache/xerces/internal/dom/DOMErrorImpl.java + src/com/sun/org/apache/xerces/internal/dom/DOMImplementationImpl.java + src/com/sun/org/apache/xerces/internal/dom/DOMImplementationListImpl.java + src/com/sun/org/apache/xerces/internal/dom/DOMImplementationSourceImpl.java + src/com/sun/org/apache/xerces/internal/dom/DOMInputImpl.java + src/com/sun/org/apache/xerces/internal/dom/DOMLocatorImpl.java + src/com/sun/org/apache/xerces/internal/dom/DOMMessageFormatter.java + src/com/sun/org/apache/xerces/internal/dom/DOMNormalizer.java + src/com/sun/org/apache/xerces/internal/dom/DOMOutputImpl.java + src/com/sun/org/apache/xerces/internal/dom/DOMStringListImpl.java + src/com/sun/org/apache/xerces/internal/dom/DOMXSImplementationSourceImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeepNodeListImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredAttrImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredAttrNSImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredCDATASectionImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredCommentImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredDOMImplementationImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredDocumentImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredDocumentTypeImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredElementDefinitionImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredElementImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredElementNSImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredEntityImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredEntityReferenceImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredNode.java + src/com/sun/org/apache/xerces/internal/dom/DeferredNotationImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredProcessingInstructionImpl.java + src/com/sun/org/apache/xerces/internal/dom/DeferredTextImpl.java + src/com/sun/org/apache/xerces/internal/dom/DocumentFragmentImpl.java + src/com/sun/org/apache/xerces/internal/dom/DocumentImpl.java + src/com/sun/org/apache/xerces/internal/dom/DocumentTypeImpl.java + src/com/sun/org/apache/xerces/internal/dom/ElementDefinitionImpl.java + src/com/sun/org/apache/xerces/internal/dom/ElementImpl.java + src/com/sun/org/apache/xerces/internal/dom/ElementNSImpl.java + src/com/sun/org/apache/xerces/internal/dom/EntityImpl.java + src/com/sun/org/apache/xerces/internal/dom/EntityReferenceImpl.java + src/com/sun/org/apache/xerces/internal/dom/LCount.java + src/com/sun/org/apache/xerces/internal/dom/NamedNodeMapImpl.java + src/com/sun/org/apache/xerces/internal/dom/NodeImpl.java + src/com/sun/org/apache/xerces/internal/dom/NodeIteratorImpl.java + src/com/sun/org/apache/xerces/internal/dom/NodeListCache.java + src/com/sun/org/apache/xerces/internal/dom/NotationImpl.java + src/com/sun/org/apache/xerces/internal/dom/ObjectFactory.java + src/com/sun/org/apache/xerces/internal/dom/PSVIAttrNSImpl.java + src/com/sun/org/apache/xerces/internal/dom/PSVIDOMImplementationImpl.java + src/com/sun/org/apache/xerces/internal/dom/PSVIDocumentImpl.java + src/com/sun/org/apache/xerces/internal/dom/PSVIElementNSImpl.java + src/com/sun/org/apache/xerces/internal/dom/ParentNode.java + src/com/sun/org/apache/xerces/internal/dom/ProcessingInstructionImpl.java + src/com/sun/org/apache/xerces/internal/dom/RangeExceptionImpl.java + src/com/sun/org/apache/xerces/internal/dom/RangeImpl.java + src/com/sun/org/apache/xerces/internal/dom/SecuritySupport.java + src/com/sun/org/apache/xerces/internal/dom/TextImpl.java + src/com/sun/org/apache/xerces/internal/dom/TreeWalkerImpl.java + src/com/sun/org/apache/xerces/internal/dom/events/EventImpl.java + src/com/sun/org/apache/xerces/internal/dom/events/MutationEventImpl.java + src/com/sun/org/apache/xerces/internal/dom/org.apache.xerces.dom.DOMImplementationSourceImpl + src/com/sun/org/apache/xerces/internal/dom/org.w3c.dom.DOMImplementationSourceList + src/com/sun/org/apache/xerces/internal/impl/Constants.java + src/com/sun/org/apache/xerces/internal/impl/ExternalSubsetResolver.java + src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java + src/com/sun/org/apache/xerces/internal/impl/RevalidationHandler.java + src/com/sun/org/apache/xerces/internal/impl/Version.java + src/com/sun/org/apache/xerces/internal/impl/XML11DTDScannerImpl.java + src/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java + src/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java + src/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java + src/com/sun/org/apache/xerces/internal/impl/XML11NamespaceBinder.java + src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java + src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java + src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java + src/com/sun/org/apache/xerces/internal/impl/XMLEntityDescription.java + src/com/sun/org/apache/xerces/internal/impl/XMLEntityHandler.java + src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java + src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java + src/com/sun/org/apache/xerces/internal/impl/XMLErrorReporter.java + src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java + src/com/sun/org/apache/xerces/internal/impl/XMLNamespaceBinder.java + src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java + src/com/sun/org/apache/xerces/internal/impl/XMLStreamFilterImpl.java + src/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java + src/com/sun/org/apache/xerces/internal/impl/XMLVersionDetector.java + src/com/sun/org/apache/xerces/internal/impl/dtd/BalancedDTDGrammar.java + src/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java + src/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammarBucket.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XML11DTDProcessor.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XML11DTDValidator.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XML11NSDTDValidator.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XMLAttributeDecl.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XMLContentSpec.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDDescription.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDLoader.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDProcessor.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDValidator.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDValidatorFilter.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XMLElementDecl.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XMLEntityDecl.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XMLNSDTDValidator.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XMLNotationDecl.java + src/com/sun/org/apache/xerces/internal/impl/dtd/XMLSimpleType.java + src/com/sun/org/apache/xerces/internal/impl/dtd/models/CMAny.java + src/com/sun/org/apache/xerces/internal/impl/dtd/models/CMBinOp.java + src/com/sun/org/apache/xerces/internal/impl/dtd/models/CMLeaf.java + src/com/sun/org/apache/xerces/internal/impl/dtd/models/CMNode.java + src/com/sun/org/apache/xerces/internal/impl/dtd/models/CMStateSet.java + src/com/sun/org/apache/xerces/internal/impl/dtd/models/CMUniOp.java + src/com/sun/org/apache/xerces/internal/impl/dtd/models/ContentModelValidator.java + src/com/sun/org/apache/xerces/internal/impl/dtd/models/DFAContentModel.java + src/com/sun/org/apache/xerces/internal/impl/dtd/models/MixedContentModel.java + src/com/sun/org/apache/xerces/internal/impl/dtd/models/SimpleContentModel.java + src/com/sun/org/apache/xerces/internal/impl/dv/DTDDVFactory.java + src/com/sun/org/apache/xerces/internal/impl/dv/DVFactoryException.java + src/com/sun/org/apache/xerces/internal/impl/dv/DatatypeException.java + src/com/sun/org/apache/xerces/internal/impl/dv/DatatypeValidator.java + src/com/sun/org/apache/xerces/internal/impl/dv/InvalidDatatypeFacetException.java + src/com/sun/org/apache/xerces/internal/impl/dv/InvalidDatatypeValueException.java + src/com/sun/org/apache/xerces/internal/impl/dv/ObjectFactory.java + src/com/sun/org/apache/xerces/internal/impl/dv/SchemaDVFactory.java + src/com/sun/org/apache/xerces/internal/impl/dv/SecuritySupport.java + src/com/sun/org/apache/xerces/internal/impl/dv/ValidatedInfo.java + src/com/sun/org/apache/xerces/internal/impl/dv/ValidationContext.java + src/com/sun/org/apache/xerces/internal/impl/dv/XSFacets.java + src/com/sun/org/apache/xerces/internal/impl/dv/XSSimpleType.java + src/com/sun/org/apache/xerces/internal/impl/dv/dtd/DTDDVFactoryImpl.java + src/com/sun/org/apache/xerces/internal/impl/dv/dtd/ENTITYDatatypeValidator.java + src/com/sun/org/apache/xerces/internal/impl/dv/dtd/IDDatatypeValidator.java + src/com/sun/org/apache/xerces/internal/impl/dv/dtd/IDREFDatatypeValidator.java + src/com/sun/org/apache/xerces/internal/impl/dv/dtd/ListDatatypeValidator.java + src/com/sun/org/apache/xerces/internal/impl/dv/dtd/NMTOKENDatatypeValidator.java + src/com/sun/org/apache/xerces/internal/impl/dv/dtd/NOTATIONDatatypeValidator.java + src/com/sun/org/apache/xerces/internal/impl/dv/dtd/StringDatatypeValidator.java + src/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11DTDDVFactoryImpl.java + src/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11IDDatatypeValidator.java + src/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11IDREFDatatypeValidator.java + src/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11NMTOKENDatatypeValidator.java + src/com/sun/org/apache/xerces/internal/impl/dv/util/Base64.java + src/com/sun/org/apache/xerces/internal/impl/dv/util/ByteListImpl.java + src/com/sun/org/apache/xerces/internal/impl/dv/util/HexBin.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/AbstractDateTimeDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyAtomicDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/AnySimpleDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyURIDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/Base64BinaryDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/BaseDVFactory.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/BaseSchemaDVFactory.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/BooleanDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/DateDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/DateTimeDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/DayDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/DayTimeDurationDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/DecimalDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/DoubleDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/DurationDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/EntityDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/ExtendedSchemaDVFactoryImpl.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/FloatDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/FullDVFactory.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/HexBinaryDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/IDDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/IDREFDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/IntegerDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/ListDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/MonthDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/MonthDayDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/PrecisionDecimalDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/QNameDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/SchemaDVFactoryImpl.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/SchemaDateTimeException.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/StringDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/TimeDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/TypeValidator.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/UnionDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/XSSimpleTypeDecl.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/XSSimpleTypeDelegate.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/YearDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/YearMonthDV.java + src/com/sun/org/apache/xerces/internal/impl/dv/xs/YearMonthDurationDV.java + src/com/sun/org/apache/xerces/internal/impl/io/ASCIIReader.java + src/com/sun/org/apache/xerces/internal/impl/io/MalformedByteSequenceException.java + src/com/sun/org/apache/xerces/internal/impl/io/UCSReader.java + src/com/sun/org/apache/xerces/internal/impl/io/UTF8Reader.java + src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_TW.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_de.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_es.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_fr.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_it.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ja.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ko.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_pt_BR.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_sv.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_CN.properties + src/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_TW.properties + src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages.properties + src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties + src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_es.properties + src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_fr.properties + src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties + src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ja.properties + src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ko.properties + src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_pt_BR.properties + src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_sv.properties + src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_CN.properties + src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_TW.properties + src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages.properties + src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties + src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties + src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties + src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties + src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties + src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties + src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties + src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties + src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties + src/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_TW.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter.java + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_de.java + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_es.java + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_fr.java + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_it.java + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ja.java + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ko.java + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_pt_BR.java + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_sv.java + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_CN.java + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_TW.java + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_es.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_fr.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_it.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ko.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_pt_BR.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_sv.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_TW.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties + src/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_TW.properties + src/com/sun/org/apache/xerces/internal/impl/validation/EntityState.java + src/com/sun/org/apache/xerces/internal/impl/validation/ValidationManager.java + src/com/sun/org/apache/xerces/internal/impl/validation/ValidationState.java + src/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java + src/com/sun/org/apache/xerces/internal/impl/xpath/XPathException.java + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/BMPattern.java + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/CaseInsensitiveMap.java + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/Match.java + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/Op.java + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/ParseException.java + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/ParserForXMLSchema.java + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/REUtil.java + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/RangeToken.java + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegexParser.java + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegularExpression.java + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/Token.java + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message.properties + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_fr.properties + src/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ja.properties + src/com/sun/org/apache/xerces/internal/impl/xs/AttributePSVImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/ElementPSVImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/SchemaGrammar.java + src/com/sun/org/apache/xerces/internal/impl/xs/SchemaNamespaceSupport.java + src/com/sun/org/apache/xerces/internal/impl/xs/SchemaSymbols.java + src/com/sun/org/apache/xerces/internal/impl/xs/SubstitutionGroupHandler.java + src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaException.java + src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java + src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSAnnotationImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSAttributeDecl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSAttributeGroupDecl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSAttributeUseImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSComplexTypeDecl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSConstraints.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSDDescription.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSDeclarationPool.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSElementDecl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSGrammarBucket.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSGroupDecl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSImplementationImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSLoaderImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSMessageFormatter.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSModelGroupImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSModelImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSNotationDecl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSParticleDecl.java + src/com/sun/org/apache/xerces/internal/impl/xs/XSWildcardDecl.java + src/com/sun/org/apache/xerces/internal/impl/xs/identity/Field.java + src/com/sun/org/apache/xerces/internal/impl/xs/identity/FieldActivator.java + src/com/sun/org/apache/xerces/internal/impl/xs/identity/IdentityConstraint.java + src/com/sun/org/apache/xerces/internal/impl/xs/identity/KeyRef.java + src/com/sun/org/apache/xerces/internal/impl/xs/identity/Selector.java + src/com/sun/org/apache/xerces/internal/impl/xs/identity/UniqueOrKey.java + src/com/sun/org/apache/xerces/internal/impl/xs/identity/ValueStore.java + src/com/sun/org/apache/xerces/internal/impl/xs/identity/XPathMatcher.java + src/com/sun/org/apache/xerces/internal/impl/xs/models/CMBuilder.java + src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java + src/com/sun/org/apache/xerces/internal/impl/xs/models/XSAllCM.java + src/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMBinOp.java + src/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMLeaf.java + src/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMRepeatingLeaf.java + src/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMUniOp.java + src/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMValidator.java + src/com/sun/org/apache/xerces/internal/impl/xs/models/XSDFACM.java + src/com/sun/org/apache/xerces/internal/impl/xs/models/XSEmptyCM.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/AttrImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultDocument.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultElement.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultNode.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultText.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultXMLDocumentHandler.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/ElementImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/NamedNodeMapImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/NodeImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOM.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOMImplementation.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOMParser.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaParsingConfig.java + src/com/sun/org/apache/xerces/internal/impl/xs/opti/TextImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/SchemaContentHandler.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/StAXSchemaParser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAnnotationInfo.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractIDConstraintTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractParticleTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAttributeGroupTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAttributeTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDComplexTypeTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDElementTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDGroupTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDKeyrefTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDNotationTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDSimpleTypeTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDUniqueOrKeyTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDWildcardTraverser.java + src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDocumentInfo.java + src/com/sun/org/apache/xerces/internal/impl/xs/util/LSInputListImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/util/ObjectListImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/util/ShortListImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/util/SimpleLocator.java + src/com/sun/org/apache/xerces/internal/impl/xs/util/StringListImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/util/XInt.java + src/com/sun/org/apache/xerces/internal/impl/xs/util/XIntPool.java + src/com/sun/org/apache/xerces/internal/impl/xs/util/XSGrammarPool.java + src/com/sun/org/apache/xerces/internal/impl/xs/util/XSInputSource.java + src/com/sun/org/apache/xerces/internal/impl/xs/util/XSNamedMap4Types.java + src/com/sun/org/apache/xerces/internal/impl/xs/util/XSNamedMapImpl.java + src/com/sun/org/apache/xerces/internal/impl/xs/util/XSObjectListImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/DefaultValidationErrorHandler.java + src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/JAXPConstants.java + src/com/sun/org/apache/xerces/internal/jaxp/JAXPValidatorComponent.java + src/com/sun/org/apache/xerces/internal/jaxp/SAXParserFactoryImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/SchemaValidatorConfiguration.java + src/com/sun/org/apache/xerces/internal/jaxp/TeeXMLDocumentFilterImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/UnparsedEntityHandler.java + src/com/sun/org/apache/xerces/internal/jaxp/datatype/DatatypeFactoryImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/datatype/javax.xml.datatype.DatatypeFactory + src/com/sun/org/apache/xerces/internal/jaxp/javax.xml.parsers.DocumentBuilderFactory + src/com/sun/org/apache/xerces/internal/jaxp/javax.xml.parsers.SAXParserFactory + src/com/sun/org/apache/xerces/internal/jaxp/validation/AbstractXMLSchema.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/DOMDocumentHandler.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/DOMResultAugmentor.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/DOMResultBuilder.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/DOMValidatorHelper.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/DraconianErrorHandler.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/EmptyXMLSchema.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/ErrorHandlerAdaptor.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/JAXPValidationMessageFormatter.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/ReadOnlyGrammarPool.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/SimpleXMLSchema.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/SoftReferenceGrammarPool.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/Util.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHelper.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorImpl.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/WeakReferenceXMLSchema.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/WrappedSAXException.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchema.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/XSGrammarPoolContainer.java + src/com/sun/org/apache/xerces/internal/jaxp/validation/javax.xml.validation.SchemaFactory + src/com/sun/org/apache/xerces/internal/parsers/AbstractDOMParser.java + src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java + src/com/sun/org/apache/xerces/internal/parsers/AbstractXMLDocumentParser.java + src/com/sun/org/apache/xerces/internal/parsers/BasicParserConfiguration.java + src/com/sun/org/apache/xerces/internal/parsers/CachingParserPool.java + src/com/sun/org/apache/xerces/internal/parsers/DOMParser.java + src/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java + src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java + src/com/sun/org/apache/xerces/internal/parsers/DTDParser.java + src/com/sun/org/apache/xerces/internal/parsers/IntegratedParserConfiguration.java + src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java + src/com/sun/org/apache/xerces/internal/parsers/ObjectFactory.java + src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java + src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java + src/com/sun/org/apache/xerces/internal/parsers/SecuritySupport.java + src/com/sun/org/apache/xerces/internal/parsers/StandardParserConfiguration.java + src/com/sun/org/apache/xerces/internal/parsers/XIncludeAwareParserConfiguration.java + src/com/sun/org/apache/xerces/internal/parsers/XIncludeParserConfiguration.java + src/com/sun/org/apache/xerces/internal/parsers/XML11Configurable.java + src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java + src/com/sun/org/apache/xerces/internal/parsers/XML11DTDConfiguration.java + src/com/sun/org/apache/xerces/internal/parsers/XML11NonValidatingConfiguration.java + src/com/sun/org/apache/xerces/internal/parsers/XMLDocumentParser.java + src/com/sun/org/apache/xerces/internal/parsers/XMLGrammarCachingConfiguration.java + src/com/sun/org/apache/xerces/internal/parsers/XMLGrammarParser.java + src/com/sun/org/apache/xerces/internal/parsers/XMLGrammarPreparser.java + src/com/sun/org/apache/xerces/internal/parsers/XMLParser.java + src/com/sun/org/apache/xerces/internal/parsers/XPointerParserConfiguration.java + src/com/sun/org/apache/xerces/internal/parsers/org.apache.xerces.xni.parser.DTDConfiguration + src/com/sun/org/apache/xerces/internal/parsers/org.apache.xerces.xni.parser.XML11Configuration + src/com/sun/org/apache/xerces/internal/parsers/org.apache.xerces.xni.parser.XMLParserConfiguration + src/com/sun/org/apache/xerces/internal/parsers/org.xml.sax.driver + src/com/sun/org/apache/xerces/internal/util/AttributesProxy.java + src/com/sun/org/apache/xerces/internal/util/AugmentationsImpl.java + src/com/sun/org/apache/xerces/internal/util/DOMEntityResolverWrapper.java + src/com/sun/org/apache/xerces/internal/util/DOMErrorHandlerWrapper.java + src/com/sun/org/apache/xerces/internal/util/DOMInputSource.java + src/com/sun/org/apache/xerces/internal/util/DOMUtil.java + src/com/sun/org/apache/xerces/internal/util/DatatypeMessageFormatter.java + src/com/sun/org/apache/xerces/internal/util/DefaultErrorHandler.java + src/com/sun/org/apache/xerces/internal/util/DraconianErrorHandler.java + src/com/sun/org/apache/xerces/internal/util/EncodingMap.java + src/com/sun/org/apache/xerces/internal/util/EntityResolver2Wrapper.java + src/com/sun/org/apache/xerces/internal/util/EntityResolverWrapper.java + src/com/sun/org/apache/xerces/internal/util/ErrorHandlerProxy.java + src/com/sun/org/apache/xerces/internal/util/ErrorHandlerWrapper.java + src/com/sun/org/apache/xerces/internal/util/FeatureState.java + src/com/sun/org/apache/xerces/internal/util/HTTPInputSource.java + src/com/sun/org/apache/xerces/internal/util/IntStack.java + src/com/sun/org/apache/xerces/internal/util/JAXPNamespaceContextWrapper.java + src/com/sun/org/apache/xerces/internal/util/LocatorProxy.java + src/com/sun/org/apache/xerces/internal/util/LocatorWrapper.java + src/com/sun/org/apache/xerces/internal/util/MessageFormatter.java + src/com/sun/org/apache/xerces/internal/util/NamespaceContextWrapper.java + src/com/sun/org/apache/xerces/internal/util/NamespaceSupport.java + src/com/sun/org/apache/xerces/internal/util/ParserConfigurationSettings.java + src/com/sun/org/apache/xerces/internal/util/PropertyState.java + src/com/sun/org/apache/xerces/internal/util/SAX2XNI.java + src/com/sun/org/apache/xerces/internal/util/SAXInputSource.java + src/com/sun/org/apache/xerces/internal/util/SAXLocatorWrapper.java + src/com/sun/org/apache/xerces/internal/util/SAXMessageFormatter.java + src/com/sun/org/apache/xerces/internal/util/SecurityManager.java + src/com/sun/org/apache/xerces/internal/util/ShadowedSymbolTable.java + src/com/sun/org/apache/xerces/internal/util/StAXInputSource.java + src/com/sun/org/apache/xerces/internal/util/StAXLocationWrapper.java + src/com/sun/org/apache/xerces/internal/util/Status.java + src/com/sun/org/apache/xerces/internal/util/SymbolHash.java + src/com/sun/org/apache/xerces/internal/util/SymbolTable.java + src/com/sun/org/apache/xerces/internal/util/SynchronizedSymbolTable.java + src/com/sun/org/apache/xerces/internal/util/TeeXMLDocumentFilterImpl.java + src/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java + src/com/sun/org/apache/xerces/internal/util/URI.java + src/com/sun/org/apache/xerces/internal/util/XML11Char.java + src/com/sun/org/apache/xerces/internal/util/XMLAttributesImpl.java + src/com/sun/org/apache/xerces/internal/util/XMLAttributesIteratorImpl.java + src/com/sun/org/apache/xerces/internal/util/XMLCatalogResolver.java + src/com/sun/org/apache/xerces/internal/util/XMLChar.java + src/com/sun/org/apache/xerces/internal/util/XMLDocumentFilterImpl.java + src/com/sun/org/apache/xerces/internal/util/XMLEntityDescriptionImpl.java + src/com/sun/org/apache/xerces/internal/util/XMLErrorCode.java + src/com/sun/org/apache/xerces/internal/util/XMLGrammarPoolImpl.java + src/com/sun/org/apache/xerces/internal/util/XMLInputSourceAdaptor.java + src/com/sun/org/apache/xerces/internal/util/XMLResourceIdentifierImpl.java + src/com/sun/org/apache/xerces/internal/util/XMLStringBuffer.java + src/com/sun/org/apache/xerces/internal/util/XMLSymbols.java + src/com/sun/org/apache/xerces/internal/utils/ConfigurationError.java + src/com/sun/org/apache/xerces/internal/utils/ObjectFactory.java + src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java + src/com/sun/org/apache/xerces/internal/xinclude/MultipleScopeNamespaceSupport.java + src/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java + src/com/sun/org/apache/xerces/internal/xinclude/SecuritySupport.java + src/com/sun/org/apache/xerces/internal/xinclude/XInclude11TextReader.java + src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java + src/com/sun/org/apache/xerces/internal/xinclude/XIncludeMessageFormatter.java + src/com/sun/org/apache/xerces/internal/xinclude/XIncludeNamespaceSupport.java + src/com/sun/org/apache/xerces/internal/xinclude/XIncludeTextReader.java + src/com/sun/org/apache/xerces/internal/xinclude/XPointerElementHandler.java + src/com/sun/org/apache/xerces/internal/xinclude/XPointerFramework.java + src/com/sun/org/apache/xerces/internal/xinclude/XPointerSchema.java + src/com/sun/org/apache/xerces/internal/xni/Augmentations.java + src/com/sun/org/apache/xerces/internal/xni/NamespaceContext.java + src/com/sun/org/apache/xerces/internal/xni/QName.java + src/com/sun/org/apache/xerces/internal/xni/XMLAttributes.java + src/com/sun/org/apache/xerces/internal/xni/XMLDTDContentModelHandler.java + src/com/sun/org/apache/xerces/internal/xni/XMLDTDHandler.java + src/com/sun/org/apache/xerces/internal/xni/XMLDocumentFragmentHandler.java + src/com/sun/org/apache/xerces/internal/xni/XMLDocumentHandler.java + src/com/sun/org/apache/xerces/internal/xni/XMLLocator.java + src/com/sun/org/apache/xerces/internal/xni/XMLResourceIdentifier.java + src/com/sun/org/apache/xerces/internal/xni/XMLString.java + src/com/sun/org/apache/xerces/internal/xni/XNIException.java + src/com/sun/org/apache/xerces/internal/xni/grammars/Grammar.java + src/com/sun/org/apache/xerces/internal/xni/grammars/XMLDTDDescription.java + src/com/sun/org/apache/xerces/internal/xni/grammars/XMLGrammarDescription.java + src/com/sun/org/apache/xerces/internal/xni/grammars/XMLGrammarLoader.java + src/com/sun/org/apache/xerces/internal/xni/grammars/XMLGrammarPool.java + src/com/sun/org/apache/xerces/internal/xni/grammars/XMLSchemaDescription.java + src/com/sun/org/apache/xerces/internal/xni/grammars/XSGrammar.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLComponent.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLComponentManager.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLConfigurationException.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDContentModelFilter.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDContentModelSource.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDFilter.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDScanner.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDSource.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLDocumentFilter.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLDocumentScanner.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLDocumentSource.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLEntityResolver.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLErrorHandler.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLInputSource.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLParseException.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLParserConfiguration.java + src/com/sun/org/apache/xerces/internal/xni/parser/XMLPullParserConfiguration.java + src/com/sun/org/apache/xerces/internal/xpointer/ElementSchemePointer.java + src/com/sun/org/apache/xerces/internal/xpointer/ShortHandPointer.java + src/com/sun/org/apache/xerces/internal/xpointer/XPointerErrorHandler.java + src/com/sun/org/apache/xerces/internal/xpointer/XPointerHandler.java + src/com/sun/org/apache/xerces/internal/xpointer/XPointerMessageFormatter.java + src/com/sun/org/apache/xerces/internal/xpointer/XPointerPart.java + src/com/sun/org/apache/xerces/internal/xpointer/XPointerProcessor.java + src/com/sun/org/apache/xerces/internal/xs/AttributePSVI.java + src/com/sun/org/apache/xerces/internal/xs/ElementPSVI.java + src/com/sun/org/apache/xerces/internal/xs/ItemPSVI.java + src/com/sun/org/apache/xerces/internal/xs/LSInputList.java + src/com/sun/org/apache/xerces/internal/xs/PSVIProvider.java + src/com/sun/org/apache/xerces/internal/xs/ShortList.java + src/com/sun/org/apache/xerces/internal/xs/StringList.java + src/com/sun/org/apache/xerces/internal/xs/XSAnnotation.java + src/com/sun/org/apache/xerces/internal/xs/XSAttributeDeclaration.java + src/com/sun/org/apache/xerces/internal/xs/XSAttributeGroupDefinition.java + src/com/sun/org/apache/xerces/internal/xs/XSAttributeUse.java + src/com/sun/org/apache/xerces/internal/xs/XSComplexTypeDefinition.java + src/com/sun/org/apache/xerces/internal/xs/XSConstants.java + src/com/sun/org/apache/xerces/internal/xs/XSElementDeclaration.java + src/com/sun/org/apache/xerces/internal/xs/XSException.java + src/com/sun/org/apache/xerces/internal/xs/XSFacet.java + src/com/sun/org/apache/xerces/internal/xs/XSIDCDefinition.java + src/com/sun/org/apache/xerces/internal/xs/XSImplementation.java + src/com/sun/org/apache/xerces/internal/xs/XSLoader.java + src/com/sun/org/apache/xerces/internal/xs/XSModel.java + src/com/sun/org/apache/xerces/internal/xs/XSModelGroup.java + src/com/sun/org/apache/xerces/internal/xs/XSModelGroupDefinition.java + src/com/sun/org/apache/xerces/internal/xs/XSMultiValueFacet.java + src/com/sun/org/apache/xerces/internal/xs/XSNamedMap.java + src/com/sun/org/apache/xerces/internal/xs/XSNamespaceItem.java + src/com/sun/org/apache/xerces/internal/xs/XSNamespaceItemList.java + src/com/sun/org/apache/xerces/internal/xs/XSNotationDeclaration.java + src/com/sun/org/apache/xerces/internal/xs/XSObject.java + src/com/sun/org/apache/xerces/internal/xs/XSObjectList.java + src/com/sun/org/apache/xerces/internal/xs/XSParticle.java + src/com/sun/org/apache/xerces/internal/xs/XSSimpleTypeDefinition.java + src/com/sun/org/apache/xerces/internal/xs/XSTerm.java + src/com/sun/org/apache/xerces/internal/xs/XSTypeDefinition.java + src/com/sun/org/apache/xerces/internal/xs/XSWildcard.java + src/com/sun/org/apache/xerces/internal/xs/datatypes/ByteList.java + src/com/sun/org/apache/xerces/internal/xs/datatypes/ObjectList.java + src/com/sun/org/apache/xerces/internal/xs/datatypes/XSDateTime.java + src/com/sun/org/apache/xerces/internal/xs/datatypes/XSDecimal.java + src/com/sun/org/apache/xerces/internal/xs/datatypes/XSDouble.java + src/com/sun/org/apache/xerces/internal/xs/datatypes/XSFloat.java + src/com/sun/org/apache/xerces/internal/xs/datatypes/XSQName.java + src/com/sun/org/apache/xerces/internal/xs/datatypes/package.html + src/com/sun/org/apache/xml/internal/dtm/Axis.java + src/com/sun/org/apache/xml/internal/dtm/DTM.java + src/com/sun/org/apache/xml/internal/dtm/DTMAxisIterator.java + src/com/sun/org/apache/xml/internal/dtm/DTMAxisTraverser.java + src/com/sun/org/apache/xml/internal/dtm/DTMConfigurationException.java + src/com/sun/org/apache/xml/internal/dtm/DTMDOMException.java + src/com/sun/org/apache/xml/internal/dtm/DTMException.java + src/com/sun/org/apache/xml/internal/dtm/DTMFilter.java + src/com/sun/org/apache/xml/internal/dtm/DTMIterator.java + src/com/sun/org/apache/xml/internal/dtm/DTMManager.java + src/com/sun/org/apache/xml/internal/dtm/DTMWSFilter.java + src/com/sun/org/apache/xml/internal/dtm/ObjectFactory.java + src/com/sun/org/apache/xml/internal/dtm/SecuritySupport.java + src/com/sun/org/apache/xml/internal/dtm/SecuritySupport12.java + src/com/sun/org/apache/xml/internal/dtm/ref/ChunkedIntArray.java + src/com/sun/org/apache/xml/internal/dtm/ref/CoroutineManager.java + src/com/sun/org/apache/xml/internal/dtm/ref/CoroutineParser.java + src/com/sun/org/apache/xml/internal/dtm/ref/CustomStringPool.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIterNodeList.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIteratorBase.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMChildIterNodeList.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMDefaultBase.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMDefaultBaseIterators.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMDefaultBaseTraversers.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMDocumentImpl.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMManagerDefault.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMNamedNodeMap.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeIterator.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeList.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeListBase.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeProxy.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMSafeStringPool.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMStringPool.java + src/com/sun/org/apache/xml/internal/dtm/ref/DTMTreeWalker.java + src/com/sun/org/apache/xml/internal/dtm/ref/EmptyIterator.java + src/com/sun/org/apache/xml/internal/dtm/ref/ExpandedNameTable.java + src/com/sun/org/apache/xml/internal/dtm/ref/ExtendedType.java + src/com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource.java + src/com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Filter.java + src/com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Xerces.java + src/com/sun/org/apache/xml/internal/dtm/ref/NodeLocator.java + src/com/sun/org/apache/xml/internal/dtm/ref/ObjectFactory.java + src/com/sun/org/apache/xml/internal/dtm/ref/SecuritySupport.java + src/com/sun/org/apache/xml/internal/dtm/ref/SecuritySupport12.java + src/com/sun/org/apache/xml/internal/dtm/ref/dom2dtm/DOM2DTM.java + src/com/sun/org/apache/xml/internal/dtm/ref/dom2dtm/DOM2DTMdefaultNamespaceDeclarationNode.java + src/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM.java + src/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.java + src/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2RTFDTM.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ca.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_cs.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_en.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sk.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_tr.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_HK.java + src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java + src/com/sun/org/apache/xml/internal/res/XMLMessages.java + src/com/sun/org/apache/xml/internal/resolver/Catalog.java + src/com/sun/org/apache/xml/internal/resolver/CatalogEntry.java + src/com/sun/org/apache/xml/internal/resolver/CatalogException.java + src/com/sun/org/apache/xml/internal/resolver/CatalogManager.java + src/com/sun/org/apache/xml/internal/resolver/Resolver.java + src/com/sun/org/apache/xml/internal/resolver/helpers/BootstrapResolver.java + src/com/sun/org/apache/xml/internal/resolver/helpers/Debug.java + src/com/sun/org/apache/xml/internal/resolver/helpers/FileURL.java + src/com/sun/org/apache/xml/internal/resolver/helpers/Namespaces.java + src/com/sun/org/apache/xml/internal/resolver/helpers/PublicId.java + src/com/sun/org/apache/xml/internal/resolver/readers/CatalogReader.java + src/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogParser.java + src/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader.java + src/com/sun/org/apache/xml/internal/resolver/readers/ExtendedXMLCatalogReader.java + src/com/sun/org/apache/xml/internal/resolver/readers/OASISXMLCatalogReader.java + src/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogParser.java + src/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader.java + src/com/sun/org/apache/xml/internal/resolver/readers/SAXParserHandler.java + src/com/sun/org/apache/xml/internal/resolver/readers/TR9401CatalogReader.java + src/com/sun/org/apache/xml/internal/resolver/readers/TextCatalogReader.java + src/com/sun/org/apache/xml/internal/resolver/readers/XCatalogReader.java + src/com/sun/org/apache/xml/internal/resolver/tools/CatalogResolver.java + src/com/sun/org/apache/xml/internal/resolver/tools/ResolvingParser.java + src/com/sun/org/apache/xml/internal/resolver/tools/ResolvingXMLFilter.java + src/com/sun/org/apache/xml/internal/resolver/tools/ResolvingXMLReader.java + src/com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java + src/com/sun/org/apache/xml/internal/serialize/DOMSerializer.java + src/com/sun/org/apache/xml/internal/serialize/DOMSerializerImpl.java + src/com/sun/org/apache/xml/internal/serialize/ElementState.java + src/com/sun/org/apache/xml/internal/serialize/EncodingInfo.java + src/com/sun/org/apache/xml/internal/serialize/Encodings.java + src/com/sun/org/apache/xml/internal/serialize/HTMLEntities.res + src/com/sun/org/apache/xml/internal/serialize/HTMLSerializer.java + src/com/sun/org/apache/xml/internal/serialize/HTMLdtd.java + src/com/sun/org/apache/xml/internal/serialize/IndentPrinter.java + src/com/sun/org/apache/xml/internal/serialize/LineSeparator.java + src/com/sun/org/apache/xml/internal/serialize/Method.java + src/com/sun/org/apache/xml/internal/serialize/ObjectFactory.java + src/com/sun/org/apache/xml/internal/serialize/OutputFormat.java + src/com/sun/org/apache/xml/internal/serialize/Printer.java + src/com/sun/org/apache/xml/internal/serialize/SecuritySupport.java + src/com/sun/org/apache/xml/internal/serialize/Serializer.java + src/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java + src/com/sun/org/apache/xml/internal/serialize/SerializerFactoryImpl.java + src/com/sun/org/apache/xml/internal/serialize/TextSerializer.java + src/com/sun/org/apache/xml/internal/serialize/XHTMLSerializer.java + src/com/sun/org/apache/xml/internal/serialize/XML11Serializer.java + src/com/sun/org/apache/xml/internal/serialize/XMLSerializer.java + src/com/sun/org/apache/xml/internal/serializer/AttributesImplSerializer.java + src/com/sun/org/apache/xml/internal/serializer/CharInfo.java + src/com/sun/org/apache/xml/internal/serializer/DOMSerializer.java + src/com/sun/org/apache/xml/internal/serializer/ElemContext.java + src/com/sun/org/apache/xml/internal/serializer/ElemDesc.java + src/com/sun/org/apache/xml/internal/serializer/EmptySerializer.java + src/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java + src/com/sun/org/apache/xml/internal/serializer/Encodings.java + src/com/sun/org/apache/xml/internal/serializer/Encodings.properties + src/com/sun/org/apache/xml/internal/serializer/ExtendedContentHandler.java + src/com/sun/org/apache/xml/internal/serializer/ExtendedLexicalHandler.java + src/com/sun/org/apache/xml/internal/serializer/HTMLEntities.properties + src/com/sun/org/apache/xml/internal/serializer/Method.java + src/com/sun/org/apache/xml/internal/serializer/NamespaceMappings.java + src/com/sun/org/apache/xml/internal/serializer/ObjectFactory.java + src/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java + src/com/sun/org/apache/xml/internal/serializer/OutputPropertyUtils.java + src/com/sun/org/apache/xml/internal/serializer/SecuritySupport.java + src/com/sun/org/apache/xml/internal/serializer/SecuritySupport12.java + src/com/sun/org/apache/xml/internal/serializer/SerializationHandler.java + src/com/sun/org/apache/xml/internal/serializer/Serializer.java + src/com/sun/org/apache/xml/internal/serializer/SerializerBase.java + src/com/sun/org/apache/xml/internal/serializer/SerializerConstants.java + src/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java + src/com/sun/org/apache/xml/internal/serializer/SerializerTrace.java + src/com/sun/org/apache/xml/internal/serializer/SerializerTraceWriter.java + src/com/sun/org/apache/xml/internal/serializer/ToHTMLSAXHandler.java + src/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java + src/com/sun/org/apache/xml/internal/serializer/ToSAXHandler.java + src/com/sun/org/apache/xml/internal/serializer/ToStream.java + src/com/sun/org/apache/xml/internal/serializer/ToTextSAXHandler.java + src/com/sun/org/apache/xml/internal/serializer/ToTextStream.java + src/com/sun/org/apache/xml/internal/serializer/ToUnknownStream.java + src/com/sun/org/apache/xml/internal/serializer/ToXMLSAXHandler.java + src/com/sun/org/apache/xml/internal/serializer/ToXMLStream.java + src/com/sun/org/apache/xml/internal/serializer/TransformStateSetter.java + src/com/sun/org/apache/xml/internal/serializer/TreeWalker.java + src/com/sun/org/apache/xml/internal/serializer/Utils.java + src/com/sun/org/apache/xml/internal/serializer/Version.java + src/com/sun/org/apache/xml/internal/serializer/WriterChain.java + src/com/sun/org/apache/xml/internal/serializer/WriterToASCI.java + src/com/sun/org/apache/xml/internal/serializer/WriterToUTF8Buffered.java + src/com/sun/org/apache/xml/internal/serializer/XMLEntities.properties + src/com/sun/org/apache/xml/internal/serializer/XSLOutputAttributes.java + src/com/sun/org/apache/xml/internal/serializer/output_html.properties + src/com/sun/org/apache/xml/internal/serializer/output_text.properties + src/com/sun/org/apache/xml/internal/serializer/output_unknown.properties + src/com/sun/org/apache/xml/internal/serializer/output_xml.properties + src/com/sun/org/apache/xml/internal/serializer/package.html + src/com/sun/org/apache/xml/internal/serializer/utils/AttList.java + src/com/sun/org/apache/xml/internal/serializer/utils/BoolStack.java + src/com/sun/org/apache/xml/internal/serializer/utils/DOM2Helper.java + src/com/sun/org/apache/xml/internal/serializer/utils/Messages.java + src/com/sun/org/apache/xml/internal/serializer/utils/MsgKey.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ca.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_cs.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_de.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_en.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_fr.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_it.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ja.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ko.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_sv.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_CN.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_TW.java + src/com/sun/org/apache/xml/internal/serializer/utils/StringToIntTable.java + src/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java + src/com/sun/org/apache/xml/internal/serializer/utils/URI.java + src/com/sun/org/apache/xml/internal/serializer/utils/Utils.java + src/com/sun/org/apache/xml/internal/serializer/utils/WrappedRuntimeException.java + src/com/sun/org/apache/xml/internal/utils/AttList.java + src/com/sun/org/apache/xml/internal/utils/BoolStack.java + src/com/sun/org/apache/xml/internal/utils/CharKey.java + src/com/sun/org/apache/xml/internal/utils/Constants.java + src/com/sun/org/apache/xml/internal/utils/DOM2Helper.java + src/com/sun/org/apache/xml/internal/utils/DOMBuilder.java + src/com/sun/org/apache/xml/internal/utils/DOMHelper.java + src/com/sun/org/apache/xml/internal/utils/DOMOrder.java + src/com/sun/org/apache/xml/internal/utils/DefaultErrorHandler.java + src/com/sun/org/apache/xml/internal/utils/ElemDesc.java + src/com/sun/org/apache/xml/internal/utils/FastStringBuffer.java + src/com/sun/org/apache/xml/internal/utils/Hashtree2Node.java + src/com/sun/org/apache/xml/internal/utils/IntStack.java + src/com/sun/org/apache/xml/internal/utils/IntVector.java + src/com/sun/org/apache/xml/internal/utils/ListingErrorHandler.java + src/com/sun/org/apache/xml/internal/utils/LocaleUtility.java + src/com/sun/org/apache/xml/internal/utils/MutableAttrListImpl.java + src/com/sun/org/apache/xml/internal/utils/NSInfo.java + src/com/sun/org/apache/xml/internal/utils/NameSpace.java + src/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java + src/com/sun/org/apache/xml/internal/utils/NodeConsumer.java + src/com/sun/org/apache/xml/internal/utils/NodeVector.java + src/com/sun/org/apache/xml/internal/utils/ObjectFactory.java + src/com/sun/org/apache/xml/internal/utils/ObjectPool.java + src/com/sun/org/apache/xml/internal/utils/ObjectStack.java + src/com/sun/org/apache/xml/internal/utils/ObjectVector.java + src/com/sun/org/apache/xml/internal/utils/PrefixResolver.java + src/com/sun/org/apache/xml/internal/utils/PrefixResolverDefault.java + src/com/sun/org/apache/xml/internal/utils/QName.java + src/com/sun/org/apache/xml/internal/utils/RawCharacterHandler.java + src/com/sun/org/apache/xml/internal/utils/SAXSourceLocator.java + src/com/sun/org/apache/xml/internal/utils/SecuritySupport.java + src/com/sun/org/apache/xml/internal/utils/SecuritySupport12.java + src/com/sun/org/apache/xml/internal/utils/SerializableLocatorImpl.java + src/com/sun/org/apache/xml/internal/utils/StopParseException.java + src/com/sun/org/apache/xml/internal/utils/StringBufferPool.java + src/com/sun/org/apache/xml/internal/utils/StringComparable.java + src/com/sun/org/apache/xml/internal/utils/StringToIntTable.java + src/com/sun/org/apache/xml/internal/utils/StringToStringTable.java + src/com/sun/org/apache/xml/internal/utils/StringToStringTableVector.java + src/com/sun/org/apache/xml/internal/utils/StringVector.java + src/com/sun/org/apache/xml/internal/utils/StylesheetPIHandler.java + src/com/sun/org/apache/xml/internal/utils/SuballocatedByteVector.java + src/com/sun/org/apache/xml/internal/utils/SuballocatedIntVector.java + src/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java + src/com/sun/org/apache/xml/internal/utils/ThreadControllerWrapper.java + src/com/sun/org/apache/xml/internal/utils/TreeWalker.java + src/com/sun/org/apache/xml/internal/utils/Trie.java + src/com/sun/org/apache/xml/internal/utils/URI.java + src/com/sun/org/apache/xml/internal/utils/UnImplNode.java + src/com/sun/org/apache/xml/internal/utils/WrappedRuntimeException.java + src/com/sun/org/apache/xml/internal/utils/WrongParserException.java + src/com/sun/org/apache/xml/internal/utils/XML11Char.java + src/com/sun/org/apache/xml/internal/utils/XMLChar.java + src/com/sun/org/apache/xml/internal/utils/XMLCharacterRecognizer.java + src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java + src/com/sun/org/apache/xml/internal/utils/XMLString.java + src/com/sun/org/apache/xml/internal/utils/XMLStringDefault.java + src/com/sun/org/apache/xml/internal/utils/XMLStringFactory.java + src/com/sun/org/apache/xml/internal/utils/XMLStringFactoryDefault.java + src/com/sun/org/apache/xml/internal/utils/package.html + src/com/sun/org/apache/xml/internal/utils/res/CharArrayWrapper.java + src/com/sun/org/apache/xml/internal/utils/res/IntArrayWrapper.java + src/com/sun/org/apache/xml/internal/utils/res/LongArrayWrapper.java + src/com/sun/org/apache/xml/internal/utils/res/StringArrayWrapper.java + src/com/sun/org/apache/xml/internal/utils/res/XResourceBundle.java + src/com/sun/org/apache/xml/internal/utils/res/XResourceBundleBase.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_de.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_en.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_es.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_fr.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_it.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_ja_JP_A.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_ja_JP_HA.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_ja_JP_HI.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_ja_JP_I.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_ko.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_sv.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_zh_CN.java + src/com/sun/org/apache/xml/internal/utils/res/XResources_zh_TW.java + src/com/sun/org/apache/xpath/internal/Arg.java + src/com/sun/org/apache/xpath/internal/CachedXPathAPI.java + src/com/sun/org/apache/xpath/internal/Expression.java + src/com/sun/org/apache/xpath/internal/ExpressionNode.java + src/com/sun/org/apache/xpath/internal/ExpressionOwner.java + src/com/sun/org/apache/xpath/internal/ExtensionsProvider.java + src/com/sun/org/apache/xpath/internal/FoundIndex.java + src/com/sun/org/apache/xpath/internal/NodeSet.java + src/com/sun/org/apache/xpath/internal/NodeSetDTM.java + src/com/sun/org/apache/xpath/internal/SourceTree.java + src/com/sun/org/apache/xpath/internal/SourceTreeManager.java + src/com/sun/org/apache/xpath/internal/VariableStack.java + src/com/sun/org/apache/xpath/internal/WhitespaceStrippingElementMatcher.java + src/com/sun/org/apache/xpath/internal/XPath.java + src/com/sun/org/apache/xpath/internal/XPathAPI.java + src/com/sun/org/apache/xpath/internal/XPathContext.java + src/com/sun/org/apache/xpath/internal/XPathException.java + src/com/sun/org/apache/xpath/internal/XPathFactory.java + src/com/sun/org/apache/xpath/internal/XPathProcessorException.java + src/com/sun/org/apache/xpath/internal/XPathVisitable.java + src/com/sun/org/apache/xpath/internal/XPathVisitor.java + src/com/sun/org/apache/xpath/internal/axes/AttributeIterator.java + src/com/sun/org/apache/xpath/internal/axes/AxesWalker.java + src/com/sun/org/apache/xpath/internal/axes/BasicTestIterator.java + src/com/sun/org/apache/xpath/internal/axes/ChildIterator.java + src/com/sun/org/apache/xpath/internal/axes/ChildTestIterator.java + src/com/sun/org/apache/xpath/internal/axes/ContextNodeList.java + src/com/sun/org/apache/xpath/internal/axes/DescendantIterator.java + src/com/sun/org/apache/xpath/internal/axes/FilterExprIterator.java + src/com/sun/org/apache/xpath/internal/axes/FilterExprIteratorSimple.java + src/com/sun/org/apache/xpath/internal/axes/FilterExprWalker.java + src/com/sun/org/apache/xpath/internal/axes/HasPositionalPredChecker.java + src/com/sun/org/apache/xpath/internal/axes/IteratorPool.java + src/com/sun/org/apache/xpath/internal/axes/LocPathIterator.java + src/com/sun/org/apache/xpath/internal/axes/MatchPatternIterator.java + src/com/sun/org/apache/xpath/internal/axes/NodeSequence.java + src/com/sun/org/apache/xpath/internal/axes/OneStepIterator.java + src/com/sun/org/apache/xpath/internal/axes/OneStepIteratorForward.java + src/com/sun/org/apache/xpath/internal/axes/PathComponent.java + src/com/sun/org/apache/xpath/internal/axes/PredicatedNodeTest.java + src/com/sun/org/apache/xpath/internal/axes/RTFIterator.java + src/com/sun/org/apache/xpath/internal/axes/ReverseAxesWalker.java + src/com/sun/org/apache/xpath/internal/axes/SelfIteratorNoPredicate.java + src/com/sun/org/apache/xpath/internal/axes/SubContextList.java + src/com/sun/org/apache/xpath/internal/axes/UnionChildIterator.java + src/com/sun/org/apache/xpath/internal/axes/UnionPathIterator.java + src/com/sun/org/apache/xpath/internal/axes/WalkerFactory.java + src/com/sun/org/apache/xpath/internal/axes/WalkingIterator.java + src/com/sun/org/apache/xpath/internal/axes/WalkingIteratorSorted.java + src/com/sun/org/apache/xpath/internal/axes/package.html + src/com/sun/org/apache/xpath/internal/compiler/Compiler.java + src/com/sun/org/apache/xpath/internal/compiler/FuncLoader.java + src/com/sun/org/apache/xpath/internal/compiler/FunctionTable.java + src/com/sun/org/apache/xpath/internal/compiler/Keywords.java + src/com/sun/org/apache/xpath/internal/compiler/Lexer.java + src/com/sun/org/apache/xpath/internal/compiler/ObjectFactory.java + src/com/sun/org/apache/xpath/internal/compiler/OpCodes.java + src/com/sun/org/apache/xpath/internal/compiler/OpMap.java + src/com/sun/org/apache/xpath/internal/compiler/OpMapVector.java + src/com/sun/org/apache/xpath/internal/compiler/PsuedoNames.java + src/com/sun/org/apache/xpath/internal/compiler/SecuritySupport.java + src/com/sun/org/apache/xpath/internal/compiler/SecuritySupport12.java + src/com/sun/org/apache/xpath/internal/compiler/XPathDumper.java + src/com/sun/org/apache/xpath/internal/compiler/XPathParser.java + src/com/sun/org/apache/xpath/internal/compiler/package.html + src/com/sun/org/apache/xpath/internal/domapi/XPathEvaluatorImpl.java + src/com/sun/org/apache/xpath/internal/domapi/XPathExpressionImpl.java + src/com/sun/org/apache/xpath/internal/domapi/XPathNSResolverImpl.java + src/com/sun/org/apache/xpath/internal/domapi/XPathNamespaceImpl.java + src/com/sun/org/apache/xpath/internal/domapi/XPathResultImpl.java + src/com/sun/org/apache/xpath/internal/domapi/XPathStylesheetDOM3Exception.java + src/com/sun/org/apache/xpath/internal/domapi/package.html + src/com/sun/org/apache/xpath/internal/functions/FuncBoolean.java + src/com/sun/org/apache/xpath/internal/functions/FuncCeiling.java + src/com/sun/org/apache/xpath/internal/functions/FuncConcat.java + src/com/sun/org/apache/xpath/internal/functions/FuncContains.java + src/com/sun/org/apache/xpath/internal/functions/FuncCount.java + src/com/sun/org/apache/xpath/internal/functions/FuncCurrent.java + src/com/sun/org/apache/xpath/internal/functions/FuncDoclocation.java + src/com/sun/org/apache/xpath/internal/functions/FuncExtElementAvailable.java + src/com/sun/org/apache/xpath/internal/functions/FuncExtFunction.java + src/com/sun/org/apache/xpath/internal/functions/FuncExtFunctionAvailable.java + src/com/sun/org/apache/xpath/internal/functions/FuncFalse.java + src/com/sun/org/apache/xpath/internal/functions/FuncFloor.java + src/com/sun/org/apache/xpath/internal/functions/FuncGenerateId.java + src/com/sun/org/apache/xpath/internal/functions/FuncId.java + src/com/sun/org/apache/xpath/internal/functions/FuncLang.java + src/com/sun/org/apache/xpath/internal/functions/FuncLast.java + src/com/sun/org/apache/xpath/internal/functions/FuncLocalPart.java + src/com/sun/org/apache/xpath/internal/functions/FuncNamespace.java + src/com/sun/org/apache/xpath/internal/functions/FuncNormalizeSpace.java + src/com/sun/org/apache/xpath/internal/functions/FuncNot.java + src/com/sun/org/apache/xpath/internal/functions/FuncNumber.java + src/com/sun/org/apache/xpath/internal/functions/FuncPosition.java + src/com/sun/org/apache/xpath/internal/functions/FuncQname.java + src/com/sun/org/apache/xpath/internal/functions/FuncRound.java + src/com/sun/org/apache/xpath/internal/functions/FuncStartsWith.java + src/com/sun/org/apache/xpath/internal/functions/FuncString.java + src/com/sun/org/apache/xpath/internal/functions/FuncStringLength.java + src/com/sun/org/apache/xpath/internal/functions/FuncSubstring.java + src/com/sun/org/apache/xpath/internal/functions/FuncSubstringAfter.java + src/com/sun/org/apache/xpath/internal/functions/FuncSubstringBefore.java + src/com/sun/org/apache/xpath/internal/functions/FuncSum.java + src/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java + src/com/sun/org/apache/xpath/internal/functions/FuncTranslate.java + src/com/sun/org/apache/xpath/internal/functions/FuncTrue.java + src/com/sun/org/apache/xpath/internal/functions/FuncUnparsedEntityURI.java + src/com/sun/org/apache/xpath/internal/functions/Function.java + src/com/sun/org/apache/xpath/internal/functions/Function2Args.java + src/com/sun/org/apache/xpath/internal/functions/Function3Args.java + src/com/sun/org/apache/xpath/internal/functions/FunctionDef1Arg.java + src/com/sun/org/apache/xpath/internal/functions/FunctionMultiArgs.java + src/com/sun/org/apache/xpath/internal/functions/FunctionOneArg.java + src/com/sun/org/apache/xpath/internal/functions/ObjectFactory.java + src/com/sun/org/apache/xpath/internal/functions/SecuritySupport.java + src/com/sun/org/apache/xpath/internal/functions/SecuritySupport12.java + src/com/sun/org/apache/xpath/internal/functions/WrongNumberArgsException.java + src/com/sun/org/apache/xpath/internal/functions/package.html + src/com/sun/org/apache/xpath/internal/jaxp/JAXPExtensionsProvider.java + src/com/sun/org/apache/xpath/internal/jaxp/JAXPPrefixResolver.java + src/com/sun/org/apache/xpath/internal/jaxp/JAXPVariableStack.java + src/com/sun/org/apache/xpath/internal/jaxp/XPathExpressionImpl.java + src/com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java + src/com/sun/org/apache/xpath/internal/jaxp/XPathImpl.java + src/com/sun/org/apache/xpath/internal/objects/DTMXRTreeFrag.java + src/com/sun/org/apache/xpath/internal/objects/XBoolean.java + src/com/sun/org/apache/xpath/internal/objects/XBooleanStatic.java + src/com/sun/org/apache/xpath/internal/objects/XMLStringFactoryImpl.java + src/com/sun/org/apache/xpath/internal/objects/XNodeSet.java + src/com/sun/org/apache/xpath/internal/objects/XNodeSetForDOM.java + src/com/sun/org/apache/xpath/internal/objects/XNull.java + src/com/sun/org/apache/xpath/internal/objects/XNumber.java + src/com/sun/org/apache/xpath/internal/objects/XObject.java + src/com/sun/org/apache/xpath/internal/objects/XObjectFactory.java + src/com/sun/org/apache/xpath/internal/objects/XRTreeFrag.java + src/com/sun/org/apache/xpath/internal/objects/XRTreeFragSelectWrapper.java + src/com/sun/org/apache/xpath/internal/objects/XString.java + src/com/sun/org/apache/xpath/internal/objects/XStringForChars.java + src/com/sun/org/apache/xpath/internal/objects/XStringForFSB.java + src/com/sun/org/apache/xpath/internal/objects/package.html + src/com/sun/org/apache/xpath/internal/operations/And.java + src/com/sun/org/apache/xpath/internal/operations/Bool.java + src/com/sun/org/apache/xpath/internal/operations/Div.java + src/com/sun/org/apache/xpath/internal/operations/Equals.java + src/com/sun/org/apache/xpath/internal/operations/Gt.java + src/com/sun/org/apache/xpath/internal/operations/Gte.java + src/com/sun/org/apache/xpath/internal/operations/Lt.java + src/com/sun/org/apache/xpath/internal/operations/Lte.java + src/com/sun/org/apache/xpath/internal/operations/Minus.java + src/com/sun/org/apache/xpath/internal/operations/Mod.java + src/com/sun/org/apache/xpath/internal/operations/Mult.java + src/com/sun/org/apache/xpath/internal/operations/Neg.java + src/com/sun/org/apache/xpath/internal/operations/NotEquals.java + src/com/sun/org/apache/xpath/internal/operations/Number.java + src/com/sun/org/apache/xpath/internal/operations/Operation.java + src/com/sun/org/apache/xpath/internal/operations/Or.java + src/com/sun/org/apache/xpath/internal/operations/Plus.java + src/com/sun/org/apache/xpath/internal/operations/Quo.java + src/com/sun/org/apache/xpath/internal/operations/String.java + src/com/sun/org/apache/xpath/internal/operations/UnaryOperation.java + src/com/sun/org/apache/xpath/internal/operations/Variable.java + src/com/sun/org/apache/xpath/internal/operations/VariableSafeAbsRef.java + src/com/sun/org/apache/xpath/internal/operations/package.html + src/com/sun/org/apache/xpath/internal/package.html + src/com/sun/org/apache/xpath/internal/patterns/ContextMatchStepPattern.java + src/com/sun/org/apache/xpath/internal/patterns/FunctionPattern.java + src/com/sun/org/apache/xpath/internal/patterns/NodeTest.java + src/com/sun/org/apache/xpath/internal/patterns/NodeTestFilter.java + src/com/sun/org/apache/xpath/internal/patterns/StepPattern.java + src/com/sun/org/apache/xpath/internal/patterns/UnionPattern.java + src/com/sun/org/apache/xpath/internal/patterns/package.html + src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java + src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_de.java + src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_en.java + src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java + src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_fr.java + src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_it.java + src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java + src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ko.java + src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java + src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java + src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_CN.java + src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_TW.java + src/com/sun/org/apache/xpath/internal/res/XPATHMessages.java + src/com/sun/org/apache/xpath/internal/res/package.html + src/com/sun/xml/internal/stream/Entity.java + src/com/sun/xml/internal/stream/EventFilterSupport.java + src/com/sun/xml/internal/stream/StaxEntityResolverWrapper.java + src/com/sun/xml/internal/stream/StaxErrorReporter.java + src/com/sun/xml/internal/stream/StaxXMLInputSource.java + src/com/sun/xml/internal/stream/XMLBufferListener.java + src/com/sun/xml/internal/stream/XMLEntityReader.java + src/com/sun/xml/internal/stream/XMLEntityStorage.java + src/com/sun/xml/internal/stream/XMLEventReaderImpl.java + src/com/sun/xml/internal/stream/XMLInputFactoryImpl.java + src/com/sun/xml/internal/stream/XMLOutputFactoryImpl.java + src/com/sun/xml/internal/stream/dtd/DTDGrammarUtil.java + src/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java + src/com/sun/xml/internal/stream/dtd/nonvalidating/XMLAttributeDecl.java + src/com/sun/xml/internal/stream/dtd/nonvalidating/XMLElementDecl.java + src/com/sun/xml/internal/stream/dtd/nonvalidating/XMLNotationDecl.java + src/com/sun/xml/internal/stream/dtd/nonvalidating/XMLSimpleType.java + src/com/sun/xml/internal/stream/events/AttributeImpl.java + src/com/sun/xml/internal/stream/events/CharacterEvent.java + src/com/sun/xml/internal/stream/events/CommentEvent.java + src/com/sun/xml/internal/stream/events/DTDEvent.java + src/com/sun/xml/internal/stream/events/DummyEvent.java + src/com/sun/xml/internal/stream/events/EndDocumentEvent.java + src/com/sun/xml/internal/stream/events/EndElementEvent.java + src/com/sun/xml/internal/stream/events/EntityDeclarationImpl.java + src/com/sun/xml/internal/stream/events/EntityReferenceEvent.java + src/com/sun/xml/internal/stream/events/LocationImpl.java + src/com/sun/xml/internal/stream/events/NamedEvent.java + src/com/sun/xml/internal/stream/events/NamespaceImpl.java + src/com/sun/xml/internal/stream/events/NotationDeclarationImpl.java + src/com/sun/xml/internal/stream/events/ProcessingInstructionEvent.java + src/com/sun/xml/internal/stream/events/StartDocumentEvent.java + src/com/sun/xml/internal/stream/events/StartElementEvent.java + src/com/sun/xml/internal/stream/events/XMLEventAllocatorImpl.java + src/com/sun/xml/internal/stream/events/XMLEventFactoryImpl.java + src/com/sun/xml/internal/stream/javax.xml.stream.XMLEventFactory + src/com/sun/xml/internal/stream/javax.xml.stream.XMLInputFactory + src/com/sun/xml/internal/stream/javax.xml.stream.XMLOutputFactory + src/com/sun/xml/internal/stream/util/BufferAllocator.java + src/com/sun/xml/internal/stream/util/ReadOnlyIterator.java + src/com/sun/xml/internal/stream/util/ThreadLocalBufferAllocator.java + src/com/sun/xml/internal/stream/writers/UTF8OutputStreamWriter.java + src/com/sun/xml/internal/stream/writers/WriterUtility.java + src/com/sun/xml/internal/stream/writers/XMLDOMWriterImpl.java + src/com/sun/xml/internal/stream/writers/XMLEventWriterImpl.java + src/com/sun/xml/internal/stream/writers/XMLOutputSource.java + src/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java + src/com/sun/xml/internal/stream/writers/XMLWriter.java + src/javax/xml/XMLConstants.java + src/javax/xml/datatype/DatatypeConfigurationException.java + src/javax/xml/datatype/DatatypeConstants.java + src/javax/xml/datatype/DatatypeFactory.java + src/javax/xml/datatype/Duration.java + src/javax/xml/datatype/FactoryFinder.java + src/javax/xml/datatype/SecuritySupport.java + src/javax/xml/datatype/XMLGregorianCalendar.java + src/javax/xml/datatype/package.html + src/javax/xml/namespace/NamespaceContext.java + src/javax/xml/namespace/QName.java + src/javax/xml/namespace/package.html + src/javax/xml/parsers/DocumentBuilder.java + src/javax/xml/parsers/DocumentBuilderFactory.java + src/javax/xml/parsers/FactoryConfigurationError.java + src/javax/xml/parsers/FactoryFinder.java + src/javax/xml/parsers/ParserConfigurationException.java + src/javax/xml/parsers/SAXParser.java + src/javax/xml/parsers/SAXParserFactory.java + src/javax/xml/parsers/SecuritySupport.java + src/javax/xml/parsers/package.html + src/javax/xml/stream/EventFilter.java + src/javax/xml/stream/FactoryConfigurationError.java + src/javax/xml/stream/FactoryFinder.java + src/javax/xml/stream/Location.java + src/javax/xml/stream/SecuritySupport.java + src/javax/xml/stream/StreamFilter.java + src/javax/xml/stream/XMLEventFactory.java + src/javax/xml/stream/XMLEventReader.java + src/javax/xml/stream/XMLEventWriter.java + src/javax/xml/stream/XMLInputFactory.java + src/javax/xml/stream/XMLOutputFactory.java + src/javax/xml/stream/XMLReporter.java + src/javax/xml/stream/XMLResolver.java + src/javax/xml/stream/XMLStreamConstants.java + src/javax/xml/stream/XMLStreamException.java + src/javax/xml/stream/XMLStreamReader.java + src/javax/xml/stream/XMLStreamWriter.java + src/javax/xml/stream/events/Attribute.java + src/javax/xml/stream/events/Characters.java + src/javax/xml/stream/events/Comment.java + src/javax/xml/stream/events/DTD.java + src/javax/xml/stream/events/EndDocument.java + src/javax/xml/stream/events/EndElement.java + src/javax/xml/stream/events/EntityDeclaration.java + src/javax/xml/stream/events/EntityReference.java + src/javax/xml/stream/events/Namespace.java + src/javax/xml/stream/events/NotationDeclaration.java + src/javax/xml/stream/events/ProcessingInstruction.java + src/javax/xml/stream/events/StartDocument.java + src/javax/xml/stream/events/StartElement.java + src/javax/xml/stream/events/XMLEvent.java + src/javax/xml/stream/util/EventReaderDelegate.java + src/javax/xml/stream/util/StreamReaderDelegate.java + src/javax/xml/stream/util/XMLEventAllocator.java + src/javax/xml/stream/util/XMLEventConsumer.java + src/javax/xml/transform/ErrorListener.java + src/javax/xml/transform/FactoryFinder.java + src/javax/xml/transform/OutputKeys.java + src/javax/xml/transform/Result.java + src/javax/xml/transform/SecuritySupport.java + src/javax/xml/transform/Source.java + src/javax/xml/transform/SourceLocator.java + src/javax/xml/transform/Templates.java + src/javax/xml/transform/Transformer.java + src/javax/xml/transform/TransformerConfigurationException.java + src/javax/xml/transform/TransformerException.java + src/javax/xml/transform/TransformerFactory.java + src/javax/xml/transform/TransformerFactoryConfigurationError.java + src/javax/xml/transform/URIResolver.java + src/javax/xml/transform/dom/DOMLocator.java + src/javax/xml/transform/dom/DOMResult.java + src/javax/xml/transform/dom/DOMSource.java + src/javax/xml/transform/dom/package.html + src/javax/xml/transform/overview.html + src/javax/xml/transform/package.html + src/javax/xml/transform/sax/SAXResult.java + src/javax/xml/transform/sax/SAXSource.java + src/javax/xml/transform/sax/SAXTransformerFactory.java + src/javax/xml/transform/sax/TemplatesHandler.java + src/javax/xml/transform/sax/TransformerHandler.java + src/javax/xml/transform/sax/package.html + src/javax/xml/transform/stax/StAXResult.java + src/javax/xml/transform/stax/StAXSource.java + src/javax/xml/transform/stax/package.html + src/javax/xml/transform/stream/StreamResult.java + src/javax/xml/transform/stream/StreamSource.java + src/javax/xml/transform/stream/package.html + src/javax/xml/validation/Schema.java + src/javax/xml/validation/SchemaFactory.java + src/javax/xml/validation/SchemaFactoryFinder.java + src/javax/xml/validation/SchemaFactoryLoader.java + src/javax/xml/validation/SecuritySupport.java + src/javax/xml/validation/TypeInfoProvider.java + src/javax/xml/validation/Validator.java + src/javax/xml/validation/ValidatorHandler.java + src/javax/xml/validation/package.html + src/javax/xml/xpath/SecuritySupport.java + src/javax/xml/xpath/XPath.java + src/javax/xml/xpath/XPathConstants.java + src/javax/xml/xpath/XPathException.java + src/javax/xml/xpath/XPathExpression.java + src/javax/xml/xpath/XPathExpressionException.java + src/javax/xml/xpath/XPathFactory.java + src/javax/xml/xpath/XPathFactoryConfigurationException.java + src/javax/xml/xpath/XPathFactoryFinder.java + src/javax/xml/xpath/XPathFunction.java + src/javax/xml/xpath/XPathFunctionException.java + src/javax/xml/xpath/XPathFunctionResolver.java + src/javax/xml/xpath/XPathVariableResolver.java + src/javax/xml/xpath/package.html + src/org/w3c/dom/Attr.java + src/org/w3c/dom/CDATASection.java + src/org/w3c/dom/CharacterData.java + src/org/w3c/dom/Comment.java + src/org/w3c/dom/DOMConfiguration.java + src/org/w3c/dom/DOMError.java + src/org/w3c/dom/DOMErrorHandler.java + src/org/w3c/dom/DOMException.java + src/org/w3c/dom/DOMImplementation.java + src/org/w3c/dom/DOMImplementationList.java + src/org/w3c/dom/DOMImplementationSource.java + src/org/w3c/dom/DOMLocator.java + src/org/w3c/dom/DOMStringList.java + src/org/w3c/dom/Document.java + src/org/w3c/dom/DocumentFragment.java + src/org/w3c/dom/DocumentType.java + src/org/w3c/dom/Element.java + src/org/w3c/dom/Entity.java + src/org/w3c/dom/EntityReference.java + src/org/w3c/dom/NameList.java + src/org/w3c/dom/NamedNodeMap.java + src/org/w3c/dom/Node.java + src/org/w3c/dom/NodeList.java + src/org/w3c/dom/Notation.java + src/org/w3c/dom/ProcessingInstruction.java + src/org/w3c/dom/Text.java + src/org/w3c/dom/TypeInfo.java + src/org/w3c/dom/UserDataHandler.java + src/org/w3c/dom/bootstrap/DOMImplementationRegistry.java + src/org/w3c/dom/css/CSS2Properties.java + src/org/w3c/dom/css/CSSCharsetRule.java + src/org/w3c/dom/css/CSSFontFaceRule.java + src/org/w3c/dom/css/CSSImportRule.java + src/org/w3c/dom/css/CSSMediaRule.java + src/org/w3c/dom/css/CSSPageRule.java + src/org/w3c/dom/css/CSSPrimitiveValue.java + src/org/w3c/dom/css/CSSRule.java + src/org/w3c/dom/css/CSSRuleList.java + src/org/w3c/dom/css/CSSStyleDeclaration.java + src/org/w3c/dom/css/CSSStyleRule.java + src/org/w3c/dom/css/CSSStyleSheet.java + src/org/w3c/dom/css/CSSUnknownRule.java + src/org/w3c/dom/css/CSSValue.java + src/org/w3c/dom/css/CSSValueList.java + src/org/w3c/dom/css/Counter.java + src/org/w3c/dom/css/DOMImplementationCSS.java + src/org/w3c/dom/css/DocumentCSS.java + src/org/w3c/dom/css/ElementCSSInlineStyle.java + src/org/w3c/dom/css/RGBColor.java + src/org/w3c/dom/css/Rect.java + src/org/w3c/dom/css/ViewCSS.java + src/org/w3c/dom/events/DocumentEvent.java + src/org/w3c/dom/events/Event.java + src/org/w3c/dom/events/EventException.java + src/org/w3c/dom/events/EventListener.java + src/org/w3c/dom/events/EventTarget.java + src/org/w3c/dom/events/MouseEvent.java + src/org/w3c/dom/events/MutationEvent.java + src/org/w3c/dom/events/UIEvent.java + src/org/w3c/dom/html/HTMLAnchorElement.java + src/org/w3c/dom/html/HTMLAppletElement.java + src/org/w3c/dom/html/HTMLAreaElement.java + src/org/w3c/dom/html/HTMLBRElement.java + src/org/w3c/dom/html/HTMLBaseElement.java + src/org/w3c/dom/html/HTMLBaseFontElement.java + src/org/w3c/dom/html/HTMLBodyElement.java + src/org/w3c/dom/html/HTMLButtonElement.java + src/org/w3c/dom/html/HTMLCollection.java + src/org/w3c/dom/html/HTMLDListElement.java + src/org/w3c/dom/html/HTMLDOMImplementation.java + src/org/w3c/dom/html/HTMLDirectoryElement.java + src/org/w3c/dom/html/HTMLDivElement.java + src/org/w3c/dom/html/HTMLDocument.java + src/org/w3c/dom/html/HTMLElement.java + src/org/w3c/dom/html/HTMLFieldSetElement.java + src/org/w3c/dom/html/HTMLFontElement.java + src/org/w3c/dom/html/HTMLFormElement.java + src/org/w3c/dom/html/HTMLFrameElement.java + src/org/w3c/dom/html/HTMLFrameSetElement.java + src/org/w3c/dom/html/HTMLHRElement.java + src/org/w3c/dom/html/HTMLHeadElement.java + src/org/w3c/dom/html/HTMLHeadingElement.java + src/org/w3c/dom/html/HTMLHtmlElement.java + src/org/w3c/dom/html/HTMLIFrameElement.java + src/org/w3c/dom/html/HTMLImageElement.java + src/org/w3c/dom/html/HTMLInputElement.java + src/org/w3c/dom/html/HTMLIsIndexElement.java + src/org/w3c/dom/html/HTMLLIElement.java + src/org/w3c/dom/html/HTMLLabelElement.java + src/org/w3c/dom/html/HTMLLegendElement.java + src/org/w3c/dom/html/HTMLLinkElement.java + src/org/w3c/dom/html/HTMLMapElement.java + src/org/w3c/dom/html/HTMLMenuElement.java + src/org/w3c/dom/html/HTMLMetaElement.java + src/org/w3c/dom/html/HTMLModElement.java + src/org/w3c/dom/html/HTMLOListElement.java + src/org/w3c/dom/html/HTMLObjectElement.java + src/org/w3c/dom/html/HTMLOptGroupElement.java + src/org/w3c/dom/html/HTMLOptionElement.java + src/org/w3c/dom/html/HTMLParagraphElement.java + src/org/w3c/dom/html/HTMLParamElement.java + src/org/w3c/dom/html/HTMLPreElement.java + src/org/w3c/dom/html/HTMLQuoteElement.java + src/org/w3c/dom/html/HTMLScriptElement.java + src/org/w3c/dom/html/HTMLSelectElement.java + src/org/w3c/dom/html/HTMLStyleElement.java + src/org/w3c/dom/html/HTMLTableCaptionElement.java + src/org/w3c/dom/html/HTMLTableCellElement.java + src/org/w3c/dom/html/HTMLTableColElement.java + src/org/w3c/dom/html/HTMLTableElement.java + src/org/w3c/dom/html/HTMLTableRowElement.java + src/org/w3c/dom/html/HTMLTableSectionElement.java + src/org/w3c/dom/html/HTMLTextAreaElement.java + src/org/w3c/dom/html/HTMLTitleElement.java + src/org/w3c/dom/html/HTMLUListElement.java + src/org/w3c/dom/ls/DOMImplementationLS.java + src/org/w3c/dom/ls/LSException.java + src/org/w3c/dom/ls/LSInput.java + src/org/w3c/dom/ls/LSLoadEvent.java + src/org/w3c/dom/ls/LSOutput.java + src/org/w3c/dom/ls/LSParser.java + src/org/w3c/dom/ls/LSParserFilter.java + src/org/w3c/dom/ls/LSProgressEvent.java + src/org/w3c/dom/ls/LSResourceResolver.java + src/org/w3c/dom/ls/LSSerializer.java + src/org/w3c/dom/ls/LSSerializerFilter.java + src/org/w3c/dom/package.html + src/org/w3c/dom/ranges/DocumentRange.java + src/org/w3c/dom/ranges/Range.java + src/org/w3c/dom/ranges/RangeException.java + src/org/w3c/dom/ranges/package.html + src/org/w3c/dom/stylesheets/DocumentStyle.java + src/org/w3c/dom/stylesheets/LinkStyle.java + src/org/w3c/dom/stylesheets/MediaList.java + src/org/w3c/dom/stylesheets/StyleSheet.java + src/org/w3c/dom/stylesheets/StyleSheetList.java + src/org/w3c/dom/traversal/DocumentTraversal.java + src/org/w3c/dom/traversal/NodeFilter.java + src/org/w3c/dom/traversal/NodeIterator.java + src/org/w3c/dom/traversal/TreeWalker.java + src/org/w3c/dom/views/AbstractView.java + src/org/w3c/dom/views/DocumentView.java + src/org/w3c/dom/xpath/COPYRIGHT.html + src/org/w3c/dom/xpath/XPathEvaluator.java + src/org/w3c/dom/xpath/XPathException.java + src/org/w3c/dom/xpath/XPathExpression.java + src/org/w3c/dom/xpath/XPathNSResolver.java + src/org/w3c/dom/xpath/XPathNamespace.java + src/org/w3c/dom/xpath/XPathResult.java + src/org/xml/sax/AttributeList.java + src/org/xml/sax/Attributes.java + src/org/xml/sax/COPYING + src/org/xml/sax/COPYING.txt + src/org/xml/sax/ContentHandler.java + src/org/xml/sax/DTDHandler.java + src/org/xml/sax/DocumentHandler.java + src/org/xml/sax/EntityResolver.java + src/org/xml/sax/ErrorHandler.java + src/org/xml/sax/HandlerBase.java + src/org/xml/sax/InputSource.java + src/org/xml/sax/Locator.java + src/org/xml/sax/Parser.java + src/org/xml/sax/SAXException.java + src/org/xml/sax/SAXNotRecognizedException.java + src/org/xml/sax/SAXNotSupportedException.java + src/org/xml/sax/SAXParseException.java + src/org/xml/sax/XMLFilter.java + src/org/xml/sax/XMLReader.java + src/org/xml/sax/ext/Attributes2.java + src/org/xml/sax/ext/Attributes2Impl.java + src/org/xml/sax/ext/DeclHandler.java + src/org/xml/sax/ext/DefaultHandler2.java + src/org/xml/sax/ext/EntityResolver2.java + src/org/xml/sax/ext/LexicalHandler.java + src/org/xml/sax/ext/Locator2.java + src/org/xml/sax/ext/Locator2Impl.java + src/org/xml/sax/ext/package.html + src/org/xml/sax/helpers/AttributeListImpl.java + src/org/xml/sax/helpers/AttributesImpl.java + src/org/xml/sax/helpers/DefaultHandler.java + src/org/xml/sax/helpers/LocatorImpl.java + src/org/xml/sax/helpers/NamespaceSupport.java + src/org/xml/sax/helpers/NewInstance.java + src/org/xml/sax/helpers/ParserAdapter.java + src/org/xml/sax/helpers/ParserFactory.java + src/org/xml/sax/helpers/XMLFilterImpl.java + src/org/xml/sax/helpers/XMLReaderAdapter.java + src/org/xml/sax/helpers/XMLReaderFactory.java + src/org/xml/sax/helpers/package.html + src/org/xml/sax/package.html Changeset: f87295ac2665 Author: joehw Date: 2012-01-11 13:19 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/f87295ac2665 Merge Changeset: d2f2281a8c93 Author: michaelm Date: 2012-01-16 14:26 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/d2f2281a8c93 Merge - build-defs.xml - build-drop-template.xml ! build.xml - jaxp.properties - patches/jaxp_src/README From michael.x.mcmahon at oracle.com Mon Jan 16 07:10:03 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 16 Jan 2012 15:10:03 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 18 new changesets Message-ID: <20120116151302.264B74798A@hg.openjdk.java.net> Changeset: e5b699ef3c77 Author: ohair Date: 2012-01-04 17:44 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/e5b699ef3c77 7127104: Build issue with prtconf and zones, also using := to avoid extra execs Reviewed-by: katleman ! make/common/shared/Platform.gmk Changeset: 0bb7ab40ab76 Author: mbankal Date: 2011-12-30 04:51 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/0bb7ab40ab76 7115586: (so) Suppress creation of SocketImpl in SocketAdaptor's constructor Reviewed-by: chegar ! src/share/classes/sun/nio/ch/SocketAdaptor.java Changeset: f56205750512 Author: weijun Date: 2011-09-09 11:18 +0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/f56205750512 7047200: keytool safe store Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/keytool/trystore.sh Changeset: 30bd4016f243 Author: alexsch Date: 2012-01-11 17:22 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/30bd4016f243 7110815: closed/javax/swing/JSplitPane/4885629/bug4885629.java unstable on MacOS Reviewed-by: kizune + test/javax/swing/JSplitPane/4885629/bug4885629.java Changeset: 9a2c591758d8 Author: naoto Date: 2012-01-11 10:18 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/9a2c591758d8 7027061: Testcase failure: java/util/Locale/Bug6989440.java - java.util.ConcurrentModificationException Reviewed-by: naoto Contributed-by: edvard.wendelin at oracle.com ! src/share/classes/sun/util/LocaleServiceProviderPool.java ! test/java/util/Locale/Bug6989440.java Changeset: 9cd372de83b1 Author: naoto Date: 2012-01-11 10:25 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/9cd372de83b1 7117469: Warning cleanup for j.u.Currency and j.u.Locale related classes Reviewed-by: naoto Contributed-by: edvard.wendelin at oracle.com ! src/share/classes/java/util/Currency.java ! src/share/classes/sun/util/LocaleServiceProviderPool.java ! src/share/classes/sun/util/resources/LocaleData.java Changeset: d7450b1e436d Author: chegar Date: 2012-01-12 09:29 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d7450b1e436d 7095980: Ensure HttpURLConnection (and supporting APIs) don't expose HttpOnly cookies Reviewed-by: michaelm ! src/share/classes/java/net/HttpCookie.java + src/share/classes/sun/misc/JavaNetHttpCookieAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/HttpOnly.java Changeset: 2c7531274a53 Author: chegar Date: 2012-01-12 09:33 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/2c7531274a53 7128648: HttpURLConnection.getHeaderFields should return an unmodifiable Map Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLConnection/UnmodifiableMaps.java Changeset: fd2dbc4d28e1 Author: alexsch Date: 2012-01-12 17:34 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/fd2dbc4d28e1 6505523: NullPointerException in BasicTreeUI when a node is removed by expansion listener Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/6505523/bug6505523.java Changeset: 9f9912af74d4 Author: alexsch Date: 2012-01-12 17:42 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/9f9912af74d4 7115357: closed/javax/swing/JTable/6263446/bug6263446Table.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JTable/6263446/bug6263446.java Changeset: 9b6020fe2a16 Author: alexsch Date: 2012-01-13 17:02 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/9b6020fe2a16 7121765: closed/javax/swing/JTextArea/4697612/bug4697612.java fails on MacOS on Aqua L&F Reviewed-by: rupashka + test/javax/swing/JTextArea/4697612/bug4697612.java + test/javax/swing/JTextArea/4697612/bug4697612.txt Changeset: 7617df64c231 Author: mullan Date: 2012-01-13 09:47 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/7617df64c231 7094155: JSR105 code throws javax.xml.crypto.URIReferenceException when running into Java 7 VM Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java ! test/javax/xml/crypto/dsig/GenerationTests.java Changeset: d57776c3ab22 Author: mullan Date: 2012-01-13 09:49 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d57776c3ab22 Merge Changeset: 5af6820a0847 Author: xuelei Date: 2012-01-15 19:33 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5af6820a0847 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java + src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/Length.java ! src/windows/classes/sun/security/mscapi/Key.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSASignature.java + test/sun/security/mscapi/ShortRSAKey1024.sh + test/sun/security/mscapi/ShortRSAKey512.sh + test/sun/security/mscapi/ShortRSAKey768.sh + test/sun/security/mscapi/ShortRSAKeyWithinTLS.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java Changeset: 6e94688e622d Author: weijun Date: 2012-01-13 12:46 +0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/6e94688e622d 7118809: rcache deadlock Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/ReplayCache.java Changeset: b5074ea960b9 Author: twisti Date: 2012-01-16 01:47 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/b5074ea960b9 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Reviewed-by: jrose, never ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 40037f37550d Author: twisti Date: 2012-01-16 01:48 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/40037f37550d 7109063: JSR 292: fix for 7085860 is incomplete Reviewed-by: iveresov, alanb, jrose ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/ProblemList.txt ! test/java/lang/invoke/InvokeDynamicPrintArgs.java Changeset: ffe93c01d5be Author: michaelm Date: 2012-01-16 14:26 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/ffe93c01d5be Merge ! make/common/shared/Platform.gmk ! test/ProblemList.txt From michael.x.mcmahon at oracle.com Mon Jan 16 07:13:13 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 16 Jan 2012 15:13:13 +0000 Subject: hg: jdk7u/jdk7u-osx/langtools: 3 new changesets Message-ID: <20120116151320.78A1D4798B@hg.openjdk.java.net> Changeset: 592c30109bbe Author: dmeetry Date: 2012-01-11 18:49 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/592c30109bbe 7046929: tools/javac/api/T6397104.java fails Reviewed-by: jjh ! test/tools/javac/api/T6397104.java Changeset: 13ee9a9a3abb Author: mbankal Date: 2012-01-12 08:06 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/13ee9a9a3abb 7121961: javadoc is missing a resource property Reviewed-by: jjg, ewendeli ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties Changeset: a22181f71ac3 Author: michaelm Date: 2012-01-16 14:26 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/a22181f71ac3 Merge From swingler at apple.com Mon Jan 16 08:24:07 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 16 Jan 2012 08:24:07 -0800 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> Message-ID: I still don't understand why the list of hardcoded window levels needs to be included. Can't you just compare the window levels by their NSInteger numeric values? Regards, Mike Swingler Apple Inc. On Jan 14, 2012, at 7:40 PM, Mike Swingler wrote: > In the course of preparing to contribute our current window stacking algorithm, I realized that there was a pair of internal SPI calls it was making. In the next revision we ship of the JavaRuntimeSupport.framework we can provide cover methods of these SPI, however that is of little benefit to the OpenJDK port in the immediate here-and-now. > > For now, using -addChildWindow: will be sufficient, however, we can provide an alternate implementation that uses a new pair of category methods on NSWindow if -respondsToSelector: shows that they are available: > - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; > - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; > > These functions will allow the window server to move each child window with respect to it's parent's level, but without being added to it's movement group. > > Once customers get an updated JavaNativeFoundation.framework by either Java update or OS update, the implementation will switch over dynamically at runtime. > > How does this sound for a plan? > > Regards, > Mike Swingler > Apple Inc. > > On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com wrote: > >> We fought this one in SWT and ended up going with the puppy route. >> >> Steve >> >> On 12/01/2012 2:57 PM, Anthony Petrov wrote: >>> Hi Mike, >>> >>> I recall we've discussed this issue with you back in 2010. Unfortunately, I wasn't able to implement anything like this that would work reliably back then (and I tried hard, really), that's why we ended up with -addChildWindow:. Note that JCK is very happy with this implementation, and so are we, I presume. As long as child windows receive their respective MOVE events, it seems that everything is all right. Besides, such behavior is very Mac-friendly, making Java apps behave like native apps. >>> >>> I realize that for some developers this behavior may be inconvenient. But then again, why not listen to MOVE events on the parent frame and compensate for its movement repositioning all its children? ( :) yeah, yeah, I know, sounds weird, but... as Steve says, you gotta do what you gotta do... I mean, there's a workaround at least!) >>> >>> So, if you or anyone else wish to contribute an alternative implementation for owned windows, that would be greatly appreciated. Otherwise I'm afraid we have to stick with using -addChildWindow: for now since we simply don't have a better solution. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>>> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). >>>> >>>> In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. >>>> >>>> Regards, >>>> Mike Swingler >>>> Apple Inc. >>>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>>> >>>>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. >>>>> >>>>> >>>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>>> >>>>>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>>>>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>>>>>> >>>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>>> >>>>>>>> Hi Leonid, >>>>>>>> >>>>>>>> Thanks for taking a look at the fix. >>>>>>>> >>>>>>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>>>> >>>>>>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>>>>>> >>>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>>> >>>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>>>>>> >>>>>>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>>>>>> >>>>>>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> best regards, >>>>>>>>>> Anthony >>>> > From jcpalmer at rochester.rr.com Mon Jan 16 11:46:38 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Mon, 16 Jan 2012 14:46:38 -0500 Subject: Can proguard be used to build deployment bundle for JWS? Message-ID: Hello: Looking at the status page, I find that the MacOSX version of JWS needs to include a RJE. If this is the case, is there going to be a way to make rt.jar & the others as inputs to proguard, not just libraries? This would greatly reduce bandwidth. I recall a conversation on a xmlvm thread which indicated 150 base classes get dragged in no matter what. If proguard is used that might not only be less, but only the methods required by the application would be in any. Further, I would really prefer this embedding be optional. Thank you, Jeff Palmer WhatIf Squared LLC From jcpalmer at rochester.rr.com Mon Jan 16 12:12:56 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Mon, 16 Jan 2012 15:12:56 -0500 Subject: Can proguard be used to build deployment bundle for JWS? In-Reply-To: Message-ID: Tried an experiment changing rt.jar & jce.jar from libraries to injars on windows 1.6.29 & got 630 warnings. Did not go so far as to set ignore warnings to true, but this is not looking that feasible. Thanks, Jeff Palmer WhatIf Squared LLC On 1/16/12 2:46 PM, "Jeff Palmer" wrote: > Hello: > > Looking at the status page, I find that the MacOSX version of JWS needs to > include a RJE. If this is the case, is there going to be a way to make > rt.jar & the others as inputs to proguard, not just libraries? > > This would greatly reduce bandwidth. I recall a conversation on a xmlvm > thread which indicated 150 base classes get dragged in no matter what. If > proguard is used that might not only be less, but only the methods required > by the application would be in any. > > Further, I would really prefer this embedding be optional. > > Thank you, > > Jeff Palmer > WhatIf Squared LLC > > > From scott.kovatch at oracle.com Mon Jan 16 13:56:23 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 16 Jan 2012 13:56:23 -0800 Subject: Can proguard be used to build deployment bundle for JWS? In-Reply-To: References: Message-ID: <82962A3D-1F56-418C-9207-96ED41F954A7@oracle.com> On Jan 16, 2012, at 11:46 AM, Jeff Palmer wrote: > Hello: > > Looking at the status page, I find that the MacOSX version of JWS needs to > include a RJE. If this is the case, is there going to be a way to make > rt.jar & the others as inputs to proguard, not just libraries? That's not the case at all. If you saw something on the status page that led you to believe that I should edit it. Only standalone applications that will be distributed through the app store will need to bundle a JRE. End users will get a JRE, which includes Web Start and the Java plugin. Shortcuts will not need to embed a JRE, but they will need to be smart enough to detect if a Java runtime is installed and direct the user to java.com if it isn't. That work isn't done yet, but it's next on my list. -- Scott K. ------------------------ Scott Kovatch Oracle Pleasanton, CA From jcpalmer at rochester.rr.com Mon Jan 16 15:16:46 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Mon, 16 Jan 2012 18:16:46 -0500 Subject: Can proguard be used to build deployment bundle for JWS? In-Reply-To: <82962A3D-1F56-418C-9207-96ED41F954A7@oracle.com> Message-ID: That is good to hear. That line uses the word bundle & thought it must mean embed. Might be too much information for just followers. I am assuming now that putting deploy.createWebStartLaunchButton("my_app.jnlp", "1.7.0") of deployJava.js in html page is all that I need to do. Also am assuming Java.com is only gone to for runtime checking of subsequent launches. FYI, java.com seems stuck on installing 1.6. Jeff Palmer On 1/16/12 4:56 PM, "Scott Kovatch" wrote: > > On Jan 16, 2012, at 11:46 AM, Jeff Palmer wrote: > >> Hello: >> >> Looking at the status page, I find that the MacOSX version of JWS needs to >> include a RJE. If this is the case, is there going to be a way to make >> rt.jar & the others as inputs to proguard, not just libraries? > > That's not the case at all. If you saw something on the status page that led > you to believe that I should edit it. Only standalone applications that will > be distributed through the app store will need to bundle a JRE. > > End users will get a JRE, which includes Web Start and the Java plugin. > Shortcuts will not need to embed a JRE, but they will need to be smart enough > to detect if a Java runtime is installed and direct the user to java.com if it > isn't. That work isn't done yet, but it's next on my list. > > -- Scott K. > > ------------------------ > Scott Kovatch > Oracle > Pleasanton, CA > > From swingler at apple.com Mon Jan 16 15:37:16 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 16 Jan 2012 15:37:16 -0800 Subject: Can't log onto wiki In-Reply-To: References: <70F5028E-D111-42DD-90CA-F3C2019A74CD@apple.com> Message-ID: After consenting to the terms and conditions, are you able to make any edits to the page content, or only comment? Regards, Mike Swingler Apple Inc. On Jan 11, 2012, at 5:28 PM, John Yeary wrote: > Hello Mike, > > I can log in, but it did prompt me with terms and conditions which it has not done before. > > John > ____________________________ > > John Yeary > ____________________________ > > > ____________________________ > > "Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to take rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows not victory nor defeat." > -- Theodore Roosevelt > > > > On Wed, Jan 11, 2012 at 7:47 PM, Mike Swingler wrote: > Can anyone else log into the wiki ? > > Seems to be immediately signing me out as soon as I log in. > > There are no apparent links on the site or on the other OTN pages to report issues with the site. > > Any suggestions? > Mike Swingler > Apple Inc. > > From kumar.x.srinivasan at oracle.COM Mon Jan 16 19:30:58 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 16 Jan 2012 19:30:58 -0800 Subject: Please review: 7124089: launcher refactoring Message-ID: <4F14EB72.5010203@oracle.COM> Hi, Please review the launcher refactoring work, the webrev is here: http://cr.openjdk.java.net/~ksrini/7124089/webrev.0/ Notes: 1. Moves the majority of the launcher code into platform specific directories/files, removed redundant conditionals. 2. The solaris/linux code co-exists together as before. 3. On MacOSX, "java -client" will launch the server VM, for compatibility reasons, and dual mode is left in the macosx's java_md.c, this will enable experiments with universal libraries, quite easily. Also the mac ergonomics will always return server. Testing: Tested splash screen on all platforms and launcher regression tests. Thanks Kumar From kumar.x.srinivasan at oracle.COM Mon Jan 16 19:33:26 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 16 Jan 2012 19:33:26 -0800 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F14EB72.5010203@oracle.COM> References: <4F14EB72.5010203@oracle.COM> Message-ID: <4F14EC06.4040909@oracle.COM> oops missed setting the subject line to 7ux-osx. Kumar > Hi, > > Please review the launcher refactoring work, the webrev is here: > http://cr.openjdk.java.net/~ksrini/7124089/webrev.0/ > > Notes: > 1. Moves the majority of the launcher code into platform specific > directories/files, > removed redundant conditionals. > > 2. The solaris/linux code co-exists together as before. > > 3. On MacOSX, "java -client" will launch the server VM, for > compatibility reasons, > and dual mode is left in the macosx's java_md.c, this will > enable experiments > with universal libraries, quite easily. Also the mac ergonomics > will always return > server. > > Testing: > Tested splash screen on all platforms and launcher regression tests. > > Thanks > Kumar > > > From anton.tarasov at oracle.com Mon Jan 16 23:30:54 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 17 Jan 2012 10:30:54 +0300 Subject: Review request for 7124430: [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet In-Reply-To: <4F107531.3080503@oracle.com> References: <4F10415B.8010904@oracle.com> <4F10386E.3060504@oracle.com> <4F1052A7.70908@oracle.com> <9DB24422-FB27-429B-BDEF-FD5E741E3C08@apple.com> <4F107531.3080503@oracle.com> Message-ID: <4F1523AE.4060000@oracle.com> Anthony was right (thanks for the persistence! :) Please review the new version, with -[NSWindow sendEvent:] overridden: http://cr.openjdk.java.net/~ant/7124430/webrev.2/ Thanks, Anton. On 1/13/12 9:17 PM, Anthony Petrov wrote: > Overriding NSWindow -sendEvent: does allow one to catch mouse click > events on the Mac. We use this technique in JavaFX for grab/ungrab > functionality, and everything works smoothly. > > Anton was just trying to override NSApplication -sendEvent: which > indeed won't help in that case (note the class name difference). > > -- > best regards, > Anthony > > On 1/13/2012 9:34 PM, Mike Swingler wrote: >> Don't worry about trying to catch the window title bar frame, you >> really can't, and you shouldn't try. The titlebar/toolbar area is >> specially marked so that the WindowServer will still allow the window >> to be movable, even if the app is spinning and non-responsive. Due to >> this fact, the app is infrequently notified when it's window is being >> moved, because that app isn't even involved. >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Jan 13, 2012, at 7:49 AM, Anton V. Tarasov wrote: >> >>> Hi Anthony, >>> >>> Thanks for the tip. Though I did look through some forum discussions >>> where people asked question >>> "is it possible to catch a mouse down event in a frame's titlebar?" >>> The answer was "not a direct way". >>> Commonly, a suggestion is to workaround it by means of >>> -windowWillMove usage, but this looks quite >>> odd to me... >>> >>> For instance: >>> >>> http://www.cocoabuilder.com/archive/cocoa/6725-catching-mousedown-in-an-nswindow-titlebar.html >>> >>> >>> "PS: I have tried to overiding -sendEvent in the instance of a subclass >>> of NSApplication object to see what events are going thru, mouseDown >>> and mouseUp events in the titlebar don't go thru. It's seem that the >>> windows are moved directly by the WindowServer, as you explained me." >>> >>> Did you have an experience of trying it yourself? >>> >>> Thanks, >>> Anton. >>> >>> On 1/13/12 4:58 PM, Anthony Petrov wrote: >>>> Hi Anton, >>>> >>>> You want to override NSWindow -sendEvent: in order to catch clicks >>>> on the titlebar of windows on the Mac. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 1/13/2012 6:36 PM, Anton V. Tarasov wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for 7124430. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ant/7124430/webrev.1/ >>>>> >>>>> UngrabEvent dispatching is implemented according to the cases >>>>> mentioned >>>>> in the UngrabEvent class description, except for the case of clicking >>>>> in an owner frame's title. The latter, as I found, can't be >>>>> implemented >>>>> on Mac OS X platform. Along with the implementation, a regression >>>>> test >>>>> is proposed. >>>>> >>>>> Thanks, >>>>> Anton. >>>>> >>>>> >> From Alexander.Potochkin at oracle.com Tue Jan 17 02:26:54 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 17 Jan 2012 14:26:54 +0400 Subject: Review request for 7125456: [macosx] Programmatically selecting List item triggers an ItemEvent Message-ID: <4F154CEE.7030303@oracle.com> Hello Please review the following fix: http://cr.openjdk.java.net/~alexp/7125456/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125456 Thanks alexp From artem.ananiev at oracle.com Tue Jan 17 02:34:33 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 17 Jan 2012 14:34:33 +0400 Subject: Review request for 7124430: [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet In-Reply-To: <4F1523AE.4060000@oracle.com> References: <4F10415B.8010904@oracle.com> <4F10386E.3060504@oracle.com> <4F1052A7.70908@oracle.com> <9DB24422-FB27-429B-BDEF-FD5E741E3C08@apple.com> <4F107531.3080503@oracle.com> <4F1523AE.4060000@oracle.com> Message-ID: <4F154EB9.90503@oracle.com> Hi, Anton, as we discussed offline, the fix looks fine with except the code in LWWindowPeer.notifyNCMouseDown(): it doesn't send ungrab events when user clicks on a title of a frame, that is not related (neither owner nor child) to the current grabbing window. So waiting for the next version of the fix. Thanks, Artem On 1/17/2012 11:30 AM, Anton V. Tarasov wrote: > Anthony was right (thanks for the persistence! :) > > Please review the new version, with -[NSWindow sendEvent:] overridden: > > http://cr.openjdk.java.net/~ant/7124430/webrev.2/ > > Thanks, > Anton. > > On 1/13/12 9:17 PM, Anthony Petrov wrote: >> Overriding NSWindow -sendEvent: does allow one to catch mouse click >> events on the Mac. We use this technique in JavaFX for grab/ungrab >> functionality, and everything works smoothly. >> >> Anton was just trying to override NSApplication -sendEvent: which >> indeed won't help in that case (note the class name difference). >> >> -- >> best regards, >> Anthony >> >> On 1/13/2012 9:34 PM, Mike Swingler wrote: >>> Don't worry about trying to catch the window title bar frame, you >>> really can't, and you shouldn't try. The titlebar/toolbar area is >>> specially marked so that the WindowServer will still allow the window >>> to be movable, even if the app is spinning and non-responsive. Due to >>> this fact, the app is infrequently notified when it's window is being >>> moved, because that app isn't even involved. >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> >>> On Jan 13, 2012, at 7:49 AM, Anton V. Tarasov wrote: >>> >>>> Hi Anthony, >>>> >>>> Thanks for the tip. Though I did look through some forum discussions >>>> where people asked question >>>> "is it possible to catch a mouse down event in a frame's titlebar?" >>>> The answer was "not a direct way". >>>> Commonly, a suggestion is to workaround it by means of >>>> -windowWillMove usage, but this looks quite >>>> odd to me... >>>> >>>> For instance: >>>> >>>> http://www.cocoabuilder.com/archive/cocoa/6725-catching-mousedown-in-an-nswindow-titlebar.html >>>> >>>> >>>> "PS: I have tried to overiding -sendEvent in the instance of a subclass >>>> of NSApplication object to see what events are going thru, mouseDown >>>> and mouseUp events in the titlebar don't go thru. It's seem that the >>>> windows are moved directly by the WindowServer, as you explained me." >>>> >>>> Did you have an experience of trying it yourself? >>>> >>>> Thanks, >>>> Anton. >>>> >>>> On 1/13/12 4:58 PM, Anthony Petrov wrote: >>>>> Hi Anton, >>>>> >>>>> You want to override NSWindow -sendEvent: in order to catch clicks >>>>> on the titlebar of windows on the Mac. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 1/13/2012 6:36 PM, Anton V. Tarasov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for 7124430. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ant/7124430/webrev.1/ >>>>>> >>>>>> UngrabEvent dispatching is implemented according to the cases >>>>>> mentioned >>>>>> in the UngrabEvent class description, except for the case of clicking >>>>>> in an owner frame's title. The latter, as I found, can't be >>>>>> implemented >>>>>> on Mac OS X platform. Along with the implementation, a regression >>>>>> test >>>>>> is proposed. >>>>>> >>>>>> Thanks, >>>>>> Anton. >>>>>> >>>>>> >>> > From artem.ananiev at oracle.com Tue Jan 17 02:39:23 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 17 Jan 2012 14:39:23 +0400 Subject: [7u4] Request for approval for CR 7124303 - [macosx] SwingSet2 - Control + Spacebar causes hang. In-Reply-To: <4F144F42.1090400@oracle.com> References: <4F144F42.1090400@oracle.com> Message-ID: <4F154FDB.5060500@oracle.com> On 1/16/2012 8:24 PM, Pete Brunet wrote: > The fix has been reviewed on macosx-port-dev mailing list and approved > by Kevin Miller (kmiller), Mike Swingler (?), and Alexander Zuev > (kizune). (Sorry but I don't have Mike's id.) -Pete I guess the webrev is available here: http://cr.openjdk.java.net/~art/macosx-port/mac_voiceover_hangs/ right? If yes, it's approved to push into the jdk7u-osx workspace. Thanks, Artem From michael.x.mcmahon at oracle.com Tue Jan 17 03:08:19 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 17 Jan 2012 11:08:19 +0000 Subject: Review request: 7127448 Regression test scripts for policytool need to recognize macosx In-Reply-To: <4F0E0CBD.9070205@oracle.com> References: <4F0E0CBD.9070205@oracle.com> Message-ID: <4F1556A3.7040206@oracle.com> On 11/01/12 22:27, Jason Uh wrote: > http://cr.openjdk.java.net/~juh/7127448/webrev.00/ > > > Could I get the above change reviewed please? A simple addition for > tests to recognize Darwin. > > Thanks, > Jason Sorry for the delay in reviewing this Jason. It looks fine. Can you send the approval request, and I will push it? Thanks, Michael From michael.x.mcmahon at oracle.com Tue Jan 17 03:12:49 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 17 Jan 2012 11:12:49 +0000 Subject: Review request: 7127874 Add handling of macosx env variables to ProcessBuilder regression test In-Reply-To: <4F0E0E86.3090200@oracle.com> References: <4F0E0E86.3090200@oracle.com> Message-ID: <4F1557B1.7090806@oracle.com> On 11/01/12 22:34, Jason Uh wrote: > Hi, > > Could I please get the following change reviewed? > > http://cr.openjdk.java.net/~juh/7127874/webrev.00/ > > > This change to the test of ProcessBuilder adds handling of Mac OS and > the environment > variables that it adds -- namely, __CF_USER_TEXT_ENCODING and > JAVA_MAIN_CLASS_. > > Thanks, > Jason Jason, This change is fine, so long as it remains the case that these environment variables will be set by the runtime on Mac OS. I understand the JAVA_MAIN_CLASS_ variable is used by AWT. Can any AWT experts comment on whether that will continue to be the case? Thanks Michael. From michael.x.mcmahon at oracle.com Tue Jan 17 03:27:27 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 17 Jan 2012 11:27:27 +0000 Subject: Review request: 7129308 Handle OperatingSystemMXBean.getSystemLoadAverage() output on macosx In-Reply-To: <4F0E3689.3030204@oracle.com> References: <4F0E3689.3030204@oracle.com> Message-ID: <4F155B1F.5070104@oracle.com> Jason, Good to see this one being taken care of. What is the implication of stripping the space? Thanks, Michael. On 12/01/12 01:25, Jason Uh wrote: > Hi, > > This change handles the difference in the output text of > /usr/bin/uptime on Mac OS X from that on Unix/Linux. > > Please see: http://cr.openjdk.java.net/~juh/7129308/webrev.00/ > > Note that > > output = > output.substring(output.lastIndexOf(LOAD_AVERAGE_TEXT) + > - LOAD_AVERAGE_TEXT.length()); > + LOAD_AVERAGE_TEXT.length() + 1); > > > serves to simply strip a space on all platforms. > > Thanks, > Jason From michael.x.mcmahon at oracle.com Tue Jan 17 03:29:56 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 17 Jan 2012 11:29:56 +0000 Subject: Review request: 7129308 Handle OperatingSystemMXBean.getSystemLoadAverage() output on macosx In-Reply-To: <4F155B1F.5070104@oracle.com> References: <4F0E3689.3030204@oracle.com> <4F155B1F.5070104@oracle.com> Message-ID: <4F155BB4.6050908@oracle.com> On 17/01/12 11:27, Michael McMahon wrote: > What is the implication of stripping the space? > Never mind. I didn't notice that this was a test. So long as it passes on all platforms then it should be fine. - Michael. > Thanks, > Michael. > > On 12/01/12 01:25, Jason Uh wrote: >> Hi, >> >> This change handles the difference in the output text of >> /usr/bin/uptime on Mac OS X from that on Unix/Linux. >> >> Please see: http://cr.openjdk.java.net/~juh/7129308/webrev.00/ >> >> Note that >> >> output = >> output.substring(output.lastIndexOf(LOAD_AVERAGE_TEXT) + >> - LOAD_AVERAGE_TEXT.length()); >> + LOAD_AVERAGE_TEXT.length() + 1); >> >> >> serves to simply strip a space on all platforms. >> >> Thanks, >> Jason > From anthony.petrov at oracle.com Tue Jan 17 03:54:31 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 17 Jan 2012 15:54:31 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> Message-ID: <4F156177.9050007@oracle.com> Hi Mike, On 1/16/2012 8:24 PM, Mike Swingler wrote: > I still don't understand why the list of hardcoded window levels needs to be included. Can't you just compare the window levels by their NSInteger numeric values? There are two reasons for not using the numeric values directly, or comparing them directly: 1. Cocoa specification doesn't define the numeric values for the NS*WindowLevel constants. They may (theoretically) change in the future. As long as they aren't specified, we don't want to rely on their current values. 2. There's a reference to the Quartz spec that defines the kCG*WindowLevel constants as a enum. The NS*WindowLevel macros are defined using these constants. However, if you take a look at the order of the constants in that enum [1] (and therefore their relative numerical order), you may notice that they don't exactly reflect the relative visual z-order between the levels as defined in the Cocoa spec [2]. E.g. kCGModalPanelWindowLevelKey is greater than kCGDockWindowLevelKey, while NSDockWindowLevel is defined being visually above the NSModalPanelWindowLevel. As such, a direct numeric comparison of window levels produces incorrect results. The array of hardcoded window levels allows us to convert between window levels ordered arbitrarily and integer values ordered according to their visual z-order. This allows us to compare windows level with respect to their relative z-order as specified by Cocoa documentation. Does this clarify the need for the array of window levels? Do you have any other concerns regarding the fix? [1] http://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/tdef/CGWindowLevelKey [2] http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Window_Levels -- best regards, Anthony > > Regards, > Mike Swingler > Apple Inc. > > On Jan 14, 2012, at 7:40 PM, Mike Swingler wrote: > >> In the course of preparing to contribute our current window stacking algorithm, I realized that there was a pair of internal SPI calls it was making. In the next revision we ship of the JavaRuntimeSupport.framework we can provide cover methods of these SPI, however that is of little benefit to the OpenJDK port in the immediate here-and-now. >> >> For now, using -addChildWindow: will be sufficient, however, we can provide an alternate implementation that uses a new pair of category methods on NSWindow if -respondsToSelector: shows that they are available: >> - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; >> - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; >> >> These functions will allow the window server to move each child window with respect to it's parent's level, but without being added to it's movement group. >> >> Once customers get an updated JavaNativeFoundation.framework by either Java update or OS update, the implementation will switch over dynamically at runtime. >> >> How does this sound for a plan? >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com wrote: >> >>> We fought this one in SWT and ended up going with the puppy route. >>> >>> Steve >>> >>> On 12/01/2012 2:57 PM, Anthony Petrov wrote: >>>> Hi Mike, >>>> >>>> I recall we've discussed this issue with you back in 2010. Unfortunately, I wasn't able to implement anything like this that would work reliably back then (and I tried hard, really), that's why we ended up with -addChildWindow:. Note that JCK is very happy with this implementation, and so are we, I presume. As long as child windows receive their respective MOVE events, it seems that everything is all right. Besides, such behavior is very Mac-friendly, making Java apps behave like native apps. >>>> >>>> I realize that for some developers this behavior may be inconvenient. But then again, why not listen to MOVE events on the parent frame and compensate for its movement repositioning all its children? ( :) yeah, yeah, I know, sounds weird, but... as Steve says, you gotta do what you gotta do... I mean, there's a workaround at least!) >>>> >>>> So, if you or anyone else wish to contribute an alternative implementation for owned windows, that would be greatly appreciated. Otherwise I'm afraid we have to stick with using -addChildWindow: for now since we simply don't have a better solution. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>>>> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). >>>>> >>>>> In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. >>>>> >>>>> Regards, >>>>> Mike Swingler >>>>> Apple Inc. >>>>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>>>> >>>>>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. >>>>>> >>>>>> >>>>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>>>> >>>>>>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>>>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>>>>>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>>>>>>> >>>>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>>>> >>>>>>>>> Hi Leonid, >>>>>>>>> >>>>>>>>> Thanks for taking a look at the fix. >>>>>>>>> >>>>>>>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>>>>> >>>>>>>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> best regards, >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>>>>>>> >>>>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>>>> >>>>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>>>>>>> >>>>>>>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>>>>>>> >>>>>>>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> best regards, >>>>>>>>>>> Anthony > From sergey.bylokhov at oracle.com Tue Jan 17 05:02:53 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Jan 2012 17:02:53 +0400 Subject: Request for review: 7124524 - OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer Message-ID: <4F15717D.5090105@oracle.com> Hi Everyone, This is a fix for 4 memory leaks. 1. LWWindowPeer does not destroy backbuffer in disposeImpl(). 2. LWToolkit stores unused links to Peer. 3. Local references were not deleted in the AWTWindow.m, but according JNFJObjectWrapper.jObjectWithEnv documentation "returns a new local-ref, must be released with DeleteLocalRef". 4. OGLContext in some cases can cache CGLSurfaceData in this case our LWWindowPeer was not collected. Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124524/webrev.00/ -- Best regards, Sergey. From johnyeary at gmail.com Tue Jan 17 05:18:06 2012 From: johnyeary at gmail.com (John Yeary) Date: Tue, 17 Jan 2012 08:18:06 -0500 Subject: Can't log onto wiki In-Reply-To: References: <70F5028E-D111-42DD-90CA-F3C2019A74CD@apple.com> Message-ID: Hello Mike, You are correct. I can only add comments. I can no longer edit the page(s). John ____________________________ John Yeary ____________________________ ____________________________ "Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to take rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows not victory nor defeat." -- Theodore Roosevelt On Mon, Jan 16, 2012 at 6:37 PM, Mike Swingler wrote: > After consenting to the terms and conditions, are you able to make any > edits to the page content, or only comment? > > Regards, > Mike Swingler > Apple Inc. > > On Jan 11, 2012, at 5:28 PM, John Yeary wrote: > > Hello Mike, > > I can log in, but it did prompt me with terms and conditions which it has > not done before. > > John > ____________________________ > > John Yeary > ____________________________ > > > > > > ____________________________ > > "Far better it is to dare mighty things, to win glorious triumphs, even > though checkered by failure, than to take rank with those poor spirits who > neither enjoy much nor suffer much, because they live in the gray twilight > that knows not victory nor defeat." > -- Theodore Roosevelt > > > > On Wed, Jan 11, 2012 at 7:47 PM, Mike Swingler wrote: > >> Can anyone else log into the wiki < >> https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port>? >> >> Seems to be immediately signing me out as soon as I log in. >> >> There are no apparent links on the site or on the other OTN pages to >> report issues with the site. >> >> Any suggestions? >> Mike Swingler >> Apple Inc. >> >> > > From anthony.petrov at oracle.com Tue Jan 17 05:21:56 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 17 Jan 2012 17:21:56 +0400 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F14EC06.4040909@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> Message-ID: <4F1575F4.3060104@oracle.com> Hi Kumar, src/share/bin/java.c > 987 } else if (IsMacOSX() && JLI_StrCmp(arg, "-XstartOnFirstThread") == 0) { > 988 ProcessSpecialArg(arg); > 989 } else if (IsMacOSX() && JLI_StrCCmp(arg, "-Xdock:") == 0) { > 990 ProcessSpecialArg(arg); > 1595 if (IsMacOSX()) { If the initial goal was to get rid of mentioning a platform name in the java.c, then "if (IsMacOSX())" instead of "#ifdef MACOSX" doesn't make sense as well. Also, what justifies replacing the compile time checks with run-time checks in these two occurrences? I realize that in both cases the code itself is completely correct, but I don't see why it should be even present/executed in the launcher for platforms other than the Mac. Generally, the fix looks good. Lots of #ifdef MACOSX looked very confusing before. However, I feel uncomfortable with having so much code duplicated between src/solaris/bin/java_md.c and src/macosx/bin/java_md.c. This seems to increase launcher code maintenance cost. Is there any possibility to fold the code up in a common source file that is shared between solaris/linux and macosx, and only define really specific parts of the code in separate files? The simplest way to accomplish this would be to leave exactly one #ifdef MACOSX in the shared file and #include a platform specific part there. Or we could tweak the make files to compile an additional file. Also, the major part of the JVMInit() function is identical on all three platforms - solaris/linux, macosx, and windows. It makes sense to define a function containing that code in the java.c and call it by platform-specific JVMInit() implementations where needed. -- best regards, Anthony On 1/17/2012 7:33 AM, Kumar Srinivasan wrote: > oops missed setting the subject line to 7ux-osx. > > Kumar > >> Hi, >> >> Please review the launcher refactoring work, the webrev is here: >> http://cr.openjdk.java.net/~ksrini/7124089/webrev.0/ >> >> Notes: >> 1. Moves the majority of the launcher code into platform specific >> directories/files, >> removed redundant conditionals. >> >> 2. The solaris/linux code co-exists together as before. >> >> 3. On MacOSX, "java -client" will launch the server VM, for >> compatibility reasons, >> and dual mode is left in the macosx's java_md.c, this will >> enable experiments >> with universal libraries, quite easily. Also the mac ergonomics >> will always return >> server. >> >> Testing: >> Tested splash screen on all platforms and launcher regression tests. >> >> Thanks >> Kumar >> >> >> > From alexander.zuev at oracle.com Tue Jan 17 05:26:34 2012 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 17 Jan 2012 13:26:34 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124303: [macosx] SwingSet2 - Control + Spacebar causes hang. Message-ID: <20120117132656.988BE47993@hg.openjdk.java.net> Changeset: 534f984e18bc Author: ptbrunet Date: 2012-01-17 17:26 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/534f984e18bc 7124303: [macosx] SwingSet2 - Control + Spacebar causes hang. Reviewed-by: kmiller, swingler, kizune ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/JavaComponentAccessibility.m From artem.ananiev at oracle.com Tue Jan 17 06:09:00 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 17 Jan 2012 18:09:00 +0400 Subject: Request for review: 7124524 - OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer In-Reply-To: <4F15717D.5090105@oracle.com> References: <4F15717D.5090105@oracle.com> Message-ID: <4F1580FC.1020201@oracle.com> Hi, Sergey, see my comments inline. On 1/17/2012 5:02 PM, Sergey Bylokhov wrote: > Hi Everyone, > This is a fix for 4 memory leaks. > 1. LWWindowPeer does not destroy backbuffer in disposeImpl(). Should the old SurfaceData be flushed as well? > 2. LWToolkit stores unused links to Peer. > 3. Local references were not deleted in the AWTWindow.m, but according > JNFJObjectWrapper.jObjectWithEnv documentation "returns a new local-ref, > must be released with DeleteLocalRef". > 4. OGLContext in some cases can cache CGLSurfaceData in this case our > LWWindowPeer was not collected. I see the pView field is cleared in the invalidate() method of CGLWindowSurfaceData. There are other subclasses of CGLSurfaceData which may require changing as well. > Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124524/webrev.00/ Thanks, Artem From anton.tarasov at oracle.com Tue Jan 17 06:09:33 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 17 Jan 2012 18:09:33 +0400 Subject: Review request for 7124430: [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet In-Reply-To: <4F154EB9.90503@oracle.com> References: <4F10415B.8010904@oracle.com> <4F10386E.3060504@oracle.com> <4F1052A7.70908@oracle.com> <9DB24422-FB27-429B-BDEF-FD5E741E3C08@apple.com> <4F107531.3080503@oracle.com> <4F1523AE.4060000@oracle.com> <4F154EB9.90503@oracle.com> Message-ID: <4F15811D.6030902@oracle.com> Here's the new version: http://cr.openjdk.java.net/~ant/7124430/webrev.3/ Thanks for the catch! I've added the case to the test as well. Thanks, Anton. On 17.01.2012 14:34, Artem Ananiev wrote: > Hi, Anton, > > as we discussed offline, the fix looks fine with except the code in > LWWindowPeer.notifyNCMouseDown(): it doesn't send ungrab events when user clicks on a title of a > frame, that is not related (neither owner nor child) to the current grabbing window. > > So waiting for the next version of the fix. > > Thanks, > > Artem > > On 1/17/2012 11:30 AM, Anton V. Tarasov wrote: >> Anthony was right (thanks for the persistence! :) >> >> Please review the new version, with -[NSWindow sendEvent:] overridden: >> >> http://cr.openjdk.java.net/~ant/7124430/webrev.2/ >> >> Thanks, >> Anton. >> >> On 1/13/12 9:17 PM, Anthony Petrov wrote: >>> Overriding NSWindow -sendEvent: does allow one to catch mouse click >>> events on the Mac. We use this technique in JavaFX for grab/ungrab >>> functionality, and everything works smoothly. >>> >>> Anton was just trying to override NSApplication -sendEvent: which >>> indeed won't help in that case (note the class name difference). >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/13/2012 9:34 PM, Mike Swingler wrote: >>>> Don't worry about trying to catch the window title bar frame, you >>>> really can't, and you shouldn't try. The titlebar/toolbar area is >>>> specially marked so that the WindowServer will still allow the window >>>> to be movable, even if the app is spinning and non-responsive. Due to >>>> this fact, the app is infrequently notified when it's window is being >>>> moved, because that app isn't even involved. >>>> >>>> Regards, >>>> Mike Swingler >>>> Apple Inc. >>>> >>>> On Jan 13, 2012, at 7:49 AM, Anton V. Tarasov wrote: >>>> >>>>> Hi Anthony, >>>>> >>>>> Thanks for the tip. Though I did look through some forum discussions >>>>> where people asked question >>>>> "is it possible to catch a mouse down event in a frame's titlebar?" >>>>> The answer was "not a direct way". >>>>> Commonly, a suggestion is to workaround it by means of >>>>> -windowWillMove usage, but this looks quite >>>>> odd to me... >>>>> >>>>> For instance: >>>>> >>>>> http://www.cocoabuilder.com/archive/cocoa/6725-catching-mousedown-in-an-nswindow-titlebar.html >>>>> >>>>> >>>>> "PS: I have tried to overiding -sendEvent in the instance of a subclass >>>>> of NSApplication object to see what events are going thru, mouseDown >>>>> and mouseUp events in the titlebar don't go thru. It's seem that the >>>>> windows are moved directly by the WindowServer, as you explained me." >>>>> >>>>> Did you have an experience of trying it yourself? >>>>> >>>>> Thanks, >>>>> Anton. >>>>> >>>>> On 1/13/12 4:58 PM, Anthony Petrov wrote: >>>>>> Hi Anton, >>>>>> >>>>>> You want to override NSWindow -sendEvent: in order to catch clicks >>>>>> on the titlebar of windows on the Mac. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 1/13/2012 6:36 PM, Anton V. Tarasov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review a fix for 7124430. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~ant/7124430/webrev.1/ >>>>>>> >>>>>>> UngrabEvent dispatching is implemented according to the cases >>>>>>> mentioned >>>>>>> in the UngrabEvent class description, except for the case of clicking >>>>>>> in an owner frame's title. The latter, as I found, can't be >>>>>>> implemented >>>>>>> on Mac OS X platform. Along with the implementation, a regression >>>>>>> test >>>>>>> is proposed. >>>>>>> >>>>>>> Thanks, >>>>>>> Anton. >>>>>>> >>>>>>> >>>> >> From peter.brunet at oracle.com Tue Jan 17 06:13:13 2012 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 17 Jan 2012 08:13:13 -0600 Subject: [7u4] Request for approval for CR 7124303 - [macosx] SwingSet2 - Control + Spacebar causes hang. In-Reply-To: <4F154FDB.5060500@oracle.com> References: <4F144F42.1090400@oracle.com> <4F154FDB.5060500@oracle.com> Message-ID: <4F1581F9.4070207@oracle.com> On 1/17/12 4:39 AM, Artem Ananiev wrote: > > On 1/16/2012 8:24 PM, Pete Brunet wrote: >> The fix has been reviewed on macosx-port-dev mailing list and approved >> by Kevin Miller (kmiller), Mike Swingler (?), and Alexander Zuev >> (kizune). (Sorry but I don't have Mike's id.) -Pete > > I guess the webrev is available here: > > http://cr.openjdk.java.net/~art/macosx-port/mac_voiceover_hangs/ > > right? If yes, it's approved to push into the jdk7u-osx workspace. Yes, That is the correct patch. Thank you. > > Thanks, > > Artem From leonid.romanov at oracle.com Tue Jan 17 06:26:15 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 17 Jan 2012 18:26:15 +0400 Subject: NSDeleteFunctionKey question Message-ID: <01190A4E-665A-405E-8533-97D859D4C7B4@oracle.com> Hi! Apparently, pressing Delete key on a PC keyboard results in [event charactersIgnoringModifiers] having NSDeleteFunctionKey as a character, which seems to be from the unicode range reserved for Apple. This is not what AWT expects. Is it OK to simply replace NSDeleteFunctionKey with NSDeleteCharacter before passing it up to AWT, or there is some additional Cocoa-fu required? Thanks, Leonid. From sergey.bylokhov at oracle.com Tue Jan 17 06:56:17 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Jan 2012 18:56:17 +0400 Subject: Request for review: 7124524 - OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer In-Reply-To: <4F1580FC.1020201@oracle.com> References: <4F15717D.5090105@oracle.com> <4F1580FC.1020201@oracle.com> Message-ID: <4F158C11.30508@oracle.com> 17.01.2012 18:09, Artem Ananiev wrote: > Hi, Sergey, > > see my comments inline. > > On 1/17/2012 5:02 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> This is a fix for 4 memory leaks. >> 1. LWWindowPeer does not destroy backbuffer in disposeImpl(). > > Should the old SurfaceData be flushed as well? it is invalidated in disposeImpl(). It implemented in this way on Windows and Linux too. > >> 2. LWToolkit stores unused links to Peer. >> 3. Local references were not deleted in the AWTWindow.m, but according >> JNFJObjectWrapper.jObjectWithEnv documentation "returns a new local-ref, >> must be released with DeleteLocalRef". >> 4. OGLContext in some cases can cache CGLSurfaceData in this case our >> LWWindowPeer was not collected. > > I see the pView field is cleared in the invalidate() method of > CGLWindowSurfaceData. There are other subclasses of CGLSurfaceData > which may require changing as well. pView is not used there. > >> Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7124524/webrev.00/ > > Thanks, > > Artem -- Best regards, Sergey. From artem.ananiev at oracle.com Tue Jan 17 07:41:03 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 17 Jan 2012 19:41:03 +0400 Subject: Review request for 7124430: [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet In-Reply-To: <4F15811D.6030902@oracle.com> References: <4F10415B.8010904@oracle.com> <4F10386E.3060504@oracle.com> <4F1052A7.70908@oracle.com> <9DB24422-FB27-429B-BDEF-FD5E741E3C08@apple.com> <4F107531.3080503@oracle.com> <4F1523AE.4060000@oracle.com> <4F154EB9.90503@oracle.com> <4F15811D.6030902@oracle.com> Message-ID: <4F15968F.9010203@oracle.com> On 1/17/2012 6:09 PM, Anton V. Tarasov wrote: > Here's the new version: > > http://cr.openjdk.java.net/~ant/7124430/webrev.3/ I don't have any further comments. Anthony? Thanks, Artem > Thanks for the catch! I've added the case to the test as well. > > Thanks, > Anton. > > > On 17.01.2012 14:34, Artem Ananiev wrote: >> Hi, Anton, >> >> as we discussed offline, the fix looks fine with except the code in >> LWWindowPeer.notifyNCMouseDown(): it doesn't send ungrab events when >> user clicks on a title of a frame, that is not related (neither owner >> nor child) to the current grabbing window. >> >> So waiting for the next version of the fix. >> >> Thanks, >> >> Artem >> >> On 1/17/2012 11:30 AM, Anton V. Tarasov wrote: >>> Anthony was right (thanks for the persistence! :) >>> >>> Please review the new version, with -[NSWindow sendEvent:] overridden: >>> >>> http://cr.openjdk.java.net/~ant/7124430/webrev.2/ >>> >>> Thanks, >>> Anton. >>> >>> On 1/13/12 9:17 PM, Anthony Petrov wrote: >>>> Overriding NSWindow -sendEvent: does allow one to catch mouse click >>>> events on the Mac. We use this technique in JavaFX for grab/ungrab >>>> functionality, and everything works smoothly. >>>> >>>> Anton was just trying to override NSApplication -sendEvent: which >>>> indeed won't help in that case (note the class name difference). >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 1/13/2012 9:34 PM, Mike Swingler wrote: >>>>> Don't worry about trying to catch the window title bar frame, you >>>>> really can't, and you shouldn't try. The titlebar/toolbar area is >>>>> specially marked so that the WindowServer will still allow the window >>>>> to be movable, even if the app is spinning and non-responsive. Due to >>>>> this fact, the app is infrequently notified when it's window is being >>>>> moved, because that app isn't even involved. >>>>> >>>>> Regards, >>>>> Mike Swingler >>>>> Apple Inc. >>>>> >>>>> On Jan 13, 2012, at 7:49 AM, Anton V. Tarasov wrote: >>>>> >>>>>> Hi Anthony, >>>>>> >>>>>> Thanks for the tip. Though I did look through some forum discussions >>>>>> where people asked question >>>>>> "is it possible to catch a mouse down event in a frame's titlebar?" >>>>>> The answer was "not a direct way". >>>>>> Commonly, a suggestion is to workaround it by means of >>>>>> -windowWillMove usage, but this looks quite >>>>>> odd to me... >>>>>> >>>>>> For instance: >>>>>> >>>>>> http://www.cocoabuilder.com/archive/cocoa/6725-catching-mousedown-in-an-nswindow-titlebar.html >>>>>> >>>>>> >>>>>> >>>>>> "PS: I have tried to overiding -sendEvent in the instance of a >>>>>> subclass >>>>>> of NSApplication object to see what events are going thru, mouseDown >>>>>> and mouseUp events in the titlebar don't go thru. It's seem that the >>>>>> windows are moved directly by the WindowServer, as you explained me." >>>>>> >>>>>> Did you have an experience of trying it yourself? >>>>>> >>>>>> Thanks, >>>>>> Anton. >>>>>> >>>>>> On 1/13/12 4:58 PM, Anthony Petrov wrote: >>>>>>> Hi Anton, >>>>>>> >>>>>>> You want to override NSWindow -sendEvent: in order to catch clicks >>>>>>> on the titlebar of windows on the Mac. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 1/13/2012 6:36 PM, Anton V. Tarasov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review a fix for 7124430. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~ant/7124430/webrev.1/ >>>>>>>> >>>>>>>> UngrabEvent dispatching is implemented according to the cases >>>>>>>> mentioned >>>>>>>> in the UngrabEvent class description, except for the case of >>>>>>>> clicking >>>>>>>> in an owner frame's title. The latter, as I found, can't be >>>>>>>> implemented >>>>>>>> on Mac OS X platform. Along with the implementation, a regression >>>>>>>> test >>>>>>>> is proposed. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Anton. >>>>>>>> >>>>>>>> >>>>> >>> > From artem.ananiev at oracle.com Tue Jan 17 07:42:02 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 17 Jan 2012 19:42:02 +0400 Subject: [7u4] Request for approval for CR 7124303 - [macosx] SwingSet2 - Control + Spacebar causes hang. In-Reply-To: <4F1581F9.4070207@oracle.com> References: <4F144F42.1090400@oracle.com> <4F154FDB.5060500@oracle.com> <4F1581F9.4070207@oracle.com> Message-ID: <4F1596CA.3060305@oracle.com> On 1/17/2012 6:13 PM, Pete Brunet wrote: > On 1/17/12 4:39 AM, Artem Ananiev wrote: >> >> On 1/16/2012 8:24 PM, Pete Brunet wrote: >>> The fix has been reviewed on macosx-port-dev mailing list and approved >>> by Kevin Miller (kmiller), Mike Swingler (?), and Alexander Zuev >>> (kizune). (Sorry but I don't have Mike's id.) -Pete >> >> I guess the webrev is available here: >> >> http://cr.openjdk.java.net/~art/macosx-port/mac_voiceover_hangs/ >> >> right? If yes, it's approved to push into the jdk7u-osx workspace. > Yes, That is the correct patch. Thank you. Alex has just pushed the fix into jdk7u-osx: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/534f984e18bc Thanks, Artem >> Thanks, >> >> Artem From anthony.petrov at oracle.com Tue Jan 17 07:42:23 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 17 Jan 2012 19:42:23 +0400 Subject: Review request for 7124430: [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet In-Reply-To: <4F15968F.9010203@oracle.com> References: <4F10415B.8010904@oracle.com> <4F10386E.3060504@oracle.com> <4F1052A7.70908@oracle.com> <9DB24422-FB27-429B-BDEF-FD5E741E3C08@apple.com> <4F107531.3080503@oracle.com> <4F1523AE.4060000@oracle.com> <4F154EB9.90503@oracle.com> <4F15811D.6030902@oracle.com> <4F15968F.9010203@oracle.com> Message-ID: <4F1596DF.1070606@oracle.com> The fix looks fine. Thanks! -- best regards, Anthony On 1/17/2012 7:41 PM, Artem Ananiev wrote: > > On 1/17/2012 6:09 PM, Anton V. Tarasov wrote: >> Here's the new version: >> >> http://cr.openjdk.java.net/~ant/7124430/webrev.3/ > > I don't have any further comments. Anthony? > > Thanks, > > Artem > >> Thanks for the catch! I've added the case to the test as well. >> >> Thanks, >> Anton. >> >> >> On 17.01.2012 14:34, Artem Ananiev wrote: >>> Hi, Anton, >>> >>> as we discussed offline, the fix looks fine with except the code in >>> LWWindowPeer.notifyNCMouseDown(): it doesn't send ungrab events when >>> user clicks on a title of a frame, that is not related (neither owner >>> nor child) to the current grabbing window. >>> >>> So waiting for the next version of the fix. >>> >>> Thanks, >>> >>> Artem >>> >>> On 1/17/2012 11:30 AM, Anton V. Tarasov wrote: >>>> Anthony was right (thanks for the persistence! :) >>>> >>>> Please review the new version, with -[NSWindow sendEvent:] overridden: >>>> >>>> http://cr.openjdk.java.net/~ant/7124430/webrev.2/ >>>> >>>> Thanks, >>>> Anton. >>>> >>>> On 1/13/12 9:17 PM, Anthony Petrov wrote: >>>>> Overriding NSWindow -sendEvent: does allow one to catch mouse click >>>>> events on the Mac. We use this technique in JavaFX for grab/ungrab >>>>> functionality, and everything works smoothly. >>>>> >>>>> Anton was just trying to override NSApplication -sendEvent: which >>>>> indeed won't help in that case (note the class name difference). >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 1/13/2012 9:34 PM, Mike Swingler wrote: >>>>>> Don't worry about trying to catch the window title bar frame, you >>>>>> really can't, and you shouldn't try. The titlebar/toolbar area is >>>>>> specially marked so that the WindowServer will still allow the window >>>>>> to be movable, even if the app is spinning and non-responsive. Due to >>>>>> this fact, the app is infrequently notified when it's window is being >>>>>> moved, because that app isn't even involved. >>>>>> >>>>>> Regards, >>>>>> Mike Swingler >>>>>> Apple Inc. >>>>>> >>>>>> On Jan 13, 2012, at 7:49 AM, Anton V. Tarasov wrote: >>>>>> >>>>>>> Hi Anthony, >>>>>>> >>>>>>> Thanks for the tip. Though I did look through some forum discussions >>>>>>> where people asked question >>>>>>> "is it possible to catch a mouse down event in a frame's titlebar?" >>>>>>> The answer was "not a direct way". >>>>>>> Commonly, a suggestion is to workaround it by means of >>>>>>> -windowWillMove usage, but this looks quite >>>>>>> odd to me... >>>>>>> >>>>>>> For instance: >>>>>>> >>>>>>> http://www.cocoabuilder.com/archive/cocoa/6725-catching-mousedown-in-an-nswindow-titlebar.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> "PS: I have tried to overiding -sendEvent in the instance of a >>>>>>> subclass >>>>>>> of NSApplication object to see what events are going thru, mouseDown >>>>>>> and mouseUp events in the titlebar don't go thru. It's seem that the >>>>>>> windows are moved directly by the WindowServer, as you explained >>>>>>> me." >>>>>>> >>>>>>> Did you have an experience of trying it yourself? >>>>>>> >>>>>>> Thanks, >>>>>>> Anton. >>>>>>> >>>>>>> On 1/13/12 4:58 PM, Anthony Petrov wrote: >>>>>>>> Hi Anton, >>>>>>>> >>>>>>>> You want to override NSWindow -sendEvent: in order to catch clicks >>>>>>>> on the titlebar of windows on the Mac. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 1/13/2012 6:36 PM, Anton V. Tarasov wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review a fix for 7124430. >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~ant/7124430/webrev.1/ >>>>>>>>> >>>>>>>>> UngrabEvent dispatching is implemented according to the cases >>>>>>>>> mentioned >>>>>>>>> in the UngrabEvent class description, except for the case of >>>>>>>>> clicking >>>>>>>>> in an owner frame's title. The latter, as I found, can't be >>>>>>>>> implemented >>>>>>>>> on Mac OS X platform. Along with the implementation, a regression >>>>>>>>> test >>>>>>>>> is proposed. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Anton. >>>>>>>>> >>>>>>>>> >>>>>> >>>> >> From anthony.petrov at oracle.com Tue Jan 17 07:49:02 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 17 Jan 2012 19:49:02 +0400 Subject: Review request for 7125456: [macosx] Programmatically selecting List item triggers an ItemEvent In-Reply-To: <4F154CEE.7030303@oracle.com> References: <4F154CEE.7030303@oracle.com> Message-ID: <4F15986E.5000503@oracle.com> Hi Alex, The fix looks good to me. Optional improvement: a yet better version could use the following pattern: setSkip(true); try { // ... do whatever needed } finally { setSkip(flase); } to ensure that the delegate won't be left in the skip-event state even if any exceptions happen during processing the main operation. -- best regards, Anthony On 1/17/2012 2:26 PM, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7125456/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125456 > > Thanks > alexp > From anthony.petrov at oracle.com Tue Jan 17 07:59:36 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 17 Jan 2012 19:59:36 +0400 Subject: Request for review: 7124524 - OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer In-Reply-To: <4F15717D.5090105@oracle.com> References: <4F15717D.5090105@oracle.com> Message-ID: <4F159AE8.7020805@oracle.com> Hi Sergey, The fix looks good. Just one question: in LWWindowPeer.destroyBuffers() you're removing a call to replaceSurfaceData(). Are you sure that this is OK? -- best regards, Anthony On 1/17/2012 5:02 PM, Sergey Bylokhov wrote: > Hi Everyone, > This is a fix for 4 memory leaks. > 1. LWWindowPeer does not destroy backbuffer in disposeImpl(). > 2. LWToolkit stores unused links to Peer. > 3. Local references were not deleted in the AWTWindow.m, but according > JNFJObjectWrapper.jObjectWithEnv documentation "returns a new local-ref, > must be released with DeleteLocalRef". > 4. OGLContext in some cases can cache CGLSurfaceData in this case our > LWWindowPeer was not collected. > > Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124524/webrev.00/ > From swingler at apple.com Tue Jan 17 08:03:03 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 17 Jan 2012 08:03:03 -0800 Subject: Can't log onto wiki In-Reply-To: References: <70F5028E-D111-42DD-90CA-F3C2019A74CD@apple.com> Message-ID: Does someone here know of the best contact for someone who works on the wiki? There are no links to a maintainer of or other support staff for the OTN. I think the wiki is of questionable value if the community can't contribute content to it. Regards, Mike Swingler Apple Inc. On Jan 17, 2012, at 5:18 AM, John Yeary wrote: > Hello Mike, > > You are correct. I can only add comments. I can no longer edit the page(s). > > John > ____________________________ > > John Yeary > ____________________________ > > > ____________________________ > > "Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to take rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows not victory nor defeat." > -- Theodore Roosevelt > > > > On Mon, Jan 16, 2012 at 6:37 PM, Mike Swingler wrote: > After consenting to the terms and conditions, are you able to make any edits to the page content, or only comment? > > Regards, > Mike Swingler > Apple Inc. > > On Jan 11, 2012, at 5:28 PM, John Yeary wrote: > >> Hello Mike, >> >> I can log in, but it did prompt me with terms and conditions which it has not done before. >> >> John >> ____________________________ >> >> John Yeary >> ____________________________ >> >> >> ____________________________ >> >> "Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to take rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows not victory nor defeat." >> -- Theodore Roosevelt >> >> >> >> On Wed, Jan 11, 2012 at 7:47 PM, Mike Swingler wrote: >> Can anyone else log into the wiki ? >> >> Seems to be immediately signing me out as soon as I log in. >> >> There are no apparent links on the site or on the other OTN pages to report issues with the site. >> >> Any suggestions? >> Mike Swingler >> Apple Inc. >> >> > > From scott.kovatch at oracle.com Tue Jan 17 08:16:11 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 17 Jan 2012 08:16:11 -0800 Subject: Review request: 7127874 Add handling of macosx env variables to ProcessBuilder regression test In-Reply-To: <4F1557B1.7090806@oracle.com> References: <4F0E0E86.3090200@oracle.com> <4F1557B1.7090806@oracle.com> Message-ID: <500C05EB-0994-40FB-A231-3489443E2D62@oracle.com> On Jan 17, 2012, at 3:12 AM, Michael McMahon wrote: > On 11/01/12 22:34, Jason Uh wrote: >> Hi, >> >> Could I please get the following change reviewed? >> >> http://cr.openjdk.java.net/~juh/7127874/webrev.00/ >> >> This change to the test of ProcessBuilder adds handling of Mac OS and the environment >> variables that it adds -- namely, __CF_USER_TEXT_ENCODING and JAVA_MAIN_CLASS_. >> >> Thanks, >> Jason > > Jason, > > This change is fine, so long as it remains the case that these environment variables will be set > by the runtime on Mac OS. I understand the JAVA_MAIN_CLASS_ variable is used by AWT. > > Can any AWT experts comment on whether that will continue to be the case? Yes. This is a backstop for providing a default value for the name of the application to be used in the application menu. It could be removed if there another (better?) way to find out the name of the class whose main(String args[]) has been executed to start off the JVM. -- Scott From Alexander.Potochkin at oracle.com Tue Jan 17 08:30:43 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 17 Jan 2012 20:30:43 +0400 Subject: Review request for 7125456: [macosx] Programmatically selecting List item triggers an ItemEvent In-Reply-To: <4F15986E.5000503@oracle.com> References: <4F154CEE.7030303@oracle.com> <4F15986E.5000503@oracle.com> Message-ID: <4F15A233.7060300@oracle.com> Hello Anthony > Hi Alex, > > The fix looks good to me. > > Optional improvement: a yet better version could use the following > pattern: > > setSkip(true); > try { > // ... do whatever needed > } finally { > setSkip(flase); > } > > to ensure that the delegate won't be left in the skip-event state even > if any exceptions happen during processing the main operation. Using that pattern was my first idea but I decided to keep it simple since the delegate is 100% owned by the AWT and we don't ever expect setSelectedIndex() to throw any exceptions Thanks alexp > > -- > best regards, > Anthony > > On 1/17/2012 2:26 PM, Alexander Potochkin wrote: >> Hello >> >> Please review the following fix: >> http://cr.openjdk.java.net/~alexp/7125456/webrev.00/ >> >> the bug's description is here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125456 >> >> Thanks >> alexp >> From kumar.x.srinivasan at oracle.COM Tue Jan 17 08:35:31 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 17 Jan 2012 08:35:31 -0800 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F1575F4.3060104@oracle.com> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F1575F4.3060104@oracle.com> Message-ID: <4F15A353.7080802@oracle.COM> Hi Anthony, > > src/share/bin/java.c >> 987 } else if (IsMacOSX() && JLI_StrCmp(arg, >> "-XstartOnFirstThread") == 0) { >> 988 ProcessSpecialArg(arg); >> 989 } else if (IsMacOSX() && JLI_StrCCmp(arg, "-Xdock:") == >> 0) { >> 990 ProcessSpecialArg(arg); If we don't have those runtime checks then Windows, Linux and Solaris will accept those flags without a fuss, so what should the behavior be ? Was a specification (ccc) filed for these flags ? Will this be documented in the help section ? though X flags are unsupported, in the past we have documented them, both in the man pages as well as "java -X", if these will be left undocumented should we take the vm approach and mark it -XX ? > >> 1595 if (IsMacOSX()) { I can make this platform specific. > > Generally, the fix looks good. Lots of #ifdef MACOSX looked very > confusing before. However, I feel uncomfortable with having so much > code duplicated between src/solaris/bin/java_md.c and > src/macosx/bin/java_md.c. This seems to increase launcher code > maintenance cost. Is there any possibility to fold the code up in a > common source file that is shared between solaris/linux and macosx, > and only define really specific parts of the code in separate files? > The simplest way to accomplish this would be to leave exactly one > #ifdef MACOSX in the shared file and #include a platform specific part > there. Or we could tweak the make files to compile an additional file. Yes it is a lot more readable, and yes it increases duplication , but we already have some duplication between windows and unix. Since this is platform specific code, and 7uX will go into maintenance mode, the exposure will be limited. However, for jdk8 we need a hierarchical structure, as I heard some noise about restructuring the platform code, at that time it will be a good idea to coalesce these things, and remove the LD_LIBRARY_PATH cloaking in solaris/java_md.c which is not relevant to MacOSX. > > Also, the major part of the JVMInit() function is identical on all > three platforms - solaris/linux, macosx, and windows. It makes sense > to define a function containing that code in the java.c and call it by > platform-specific JVMInit() implementations where needed. Yes this can be done, I will look into it. Kumar > > -- > best regards, > Anthony > > On 1/17/2012 7:33 AM, Kumar Srinivasan wrote: >> oops missed setting the subject line to 7ux-osx. >> >> Kumar >> >>> Hi, >>> >>> Please review the launcher refactoring work, the webrev is here: >>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.0/ >>> >>> Notes: >>> 1. Moves the majority of the launcher code into platform specific >>> directories/files, >>> removed redundant conditionals. >>> >>> 2. The solaris/linux code co-exists together as before. >>> >>> 3. On MacOSX, "java -client" will launch the server VM, for >>> compatibility reasons, >>> and dual mode is left in the macosx's java_md.c, this will >>> enable experiments >>> with universal libraries, quite easily. Also the mac ergonomics >>> will always return >>> server. >>> >>> Testing: >>> Tested splash screen on all platforms and launcher regression tests. >>> >>> Thanks >>> Kumar >>> >>> >>> >> From swingler at apple.com Tue Jan 17 08:52:10 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 17 Jan 2012 08:52:10 -0800 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F156177.9050007@oracle.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> <4F156177.9050007@oracle.com> Message-ID: On Jan 17, 2012, at 3:54 AM, Anthony Petrov wrote: > Hi Mike, > > On 1/16/2012 8:24 PM, Mike Swingler wrote: >> I still don't understand why the list of hardcoded window levels needs to be included. Can't you just compare the window levels by their NSInteger numeric values? > > There are two reasons for not using the numeric values directly, or comparing them directly: > > 1. Cocoa specification doesn't define the numeric values for the NS*WindowLevel constants. They may (theoretically) change in the future. As long as they aren't specified, we don't want to rely on their current values. Why do you have to know the values at all? Couldn't you just reset the child window level if it's different after the parent/child operation? After I re-read what you are trying to accomplish, even numeric comparison seems inappropriate. > 2. There's a reference to the Quartz spec that defines the kCG*WindowLevel constants as a enum. The NS*WindowLevel macros are defined using these constants. However, if you take a look at the order of the constants in that enum [1] (and therefore their relative numerical order), you may notice that they don't exactly reflect the relative visual z-order between the levels as defined in the Cocoa spec [2]. E.g. kCGModalPanelWindowLevelKey is greater than kCGDockWindowLevelKey, while NSDockWindowLevel is defined being visually above the NSModalPanelWindowLevel. As such, a direct numeric comparison of window levels produces incorrect results. Have you tried setting something at the "dock" level? That level may have been true for the NextStep dock, but not the Mac. And BTW: the NSDockWindowLevel is deprecated. Don't use it. > The array of hardcoded window levels allows us to convert between window levels ordered arbitrarily and integer values ordered according to their visual z-order. This allows us to compare windows level with respect to their relative z-order as specified by Cocoa documentation. These constants are for assignment based on intention, not simple comparison of stacking level. They have behavioral meaning beyond just simple visual level ordering. Windows above the normal window level will disappear in Expos?/Mission Control, and certain levels will float in all Spaces. Other levels exclude the window from Cmd-~ keyboard window cycling, or showing up in the Dock window menu. Please, please, please test the side effects of these changes before just popping windows into different levels. The safest thing to do (if it works) is just to simply re-assign the window level after adding the child to the parent, but you will have to recursively descend into the child windows of the child, because setting the window level sets the level of all the children too (and changes their collection/spaces/cycle behavior). This may not be an issue if you never change a child window's parent. Regards, Mike Swingler Apple Inc. > Does this clarify the need for the array of window levels? Do you have any other concerns regarding the fix? > > [1] http://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/tdef/CGWindowLevelKey > > [2] http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Window_Levels > > -- > best regards, > Anthony > > >> Regards, >> Mike Swingler >> Apple Inc. >> On Jan 14, 2012, at 7:40 PM, Mike Swingler wrote: >>> In the course of preparing to contribute our current window stacking algorithm, I realized that there was a pair of internal SPI calls it was making. In the next revision we ship of the JavaRuntimeSupport.framework we can provide cover methods of these SPI, however that is of little benefit to the OpenJDK port in the immediate here-and-now. >>> >>> For now, using -addChildWindow: will be sufficient, however, we can provide an alternate implementation that uses a new pair of category methods on NSWindow if -respondsToSelector: shows that they are available: >>> - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; >>> - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; >>> >>> These functions will allow the window server to move each child window with respect to it's parent's level, but without being added to it's movement group. >>> >>> Once customers get an updated JavaNativeFoundation.framework by either Java update or OS update, the implementation will switch over dynamically at runtime. >>> >>> How does this sound for a plan? >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> >>> On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com wrote: >>> >>>> We fought this one in SWT and ended up going with the puppy route. >>>> >>>> Steve >>>> >>>> On 12/01/2012 2:57 PM, Anthony Petrov wrote: >>>>> Hi Mike, >>>>> >>>>> I recall we've discussed this issue with you back in 2010. Unfortunately, I wasn't able to implement anything like this that would work reliably back then (and I tried hard, really), that's why we ended up with -addChildWindow:. Note that JCK is very happy with this implementation, and so are we, I presume. As long as child windows receive their respective MOVE events, it seems that everything is all right. Besides, such behavior is very Mac-friendly, making Java apps behave like native apps. >>>>> >>>>> I realize that for some developers this behavior may be inconvenient. But then again, why not listen to MOVE events on the parent frame and compensate for its movement repositioning all its children? ( :) yeah, yeah, I know, sounds weird, but... as Steve says, you gotta do what you gotta do... I mean, there's a workaround at least!) >>>>> >>>>> So, if you or anyone else wish to contribute an alternative implementation for owned windows, that would be greatly appreciated. Otherwise I'm afraid we have to stick with using -addChildWindow: for now since we simply don't have a better solution. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>>>>> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). >>>>>> >>>>>> In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. >>>>>> >>>>>> Regards, >>>>>> Mike Swingler >>>>>> Apple Inc. >>>>>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>>>>> >>>>>>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. >>>>>>> >>>>>>> >>>>>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>>>>> >>>>>>>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>>>>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>>>>>>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>>>>>>>> >>>>>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>>>>> >>>>>>>>>> Hi Leonid, >>>>>>>>>> >>>>>>>>>> Thanks for taking a look at the fix. >>>>>>>>>> >>>>>>>>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>>>>>> >>>>>>>>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> best regards, >>>>>>>>>> Anthony >>>>>>>>>> >>>>>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>>>>>>>> >>>>>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>>>>> >>>>>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>>>>>>>> >>>>>>>>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>>>>>>>> >>>>>>>>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> best regards, >>>>>>>>>>>> Anthony From anthony.petrov at oracle.com Tue Jan 17 08:52:41 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 17 Jan 2012 20:52:41 +0400 Subject: Review request for 7125456: [macosx] Programmatically selecting List item triggers an ItemEvent In-Reply-To: <4F15A233.7060300@oracle.com> References: <4F154CEE.7030303@oracle.com> <4F15986E.5000503@oracle.com> <4F15A233.7060300@oracle.com> Message-ID: <4F15A759.1020000@oracle.com> On 1/17/2012 8:30 PM, Alexander Potochkin wrote: >> Optional improvement: a yet better version could use the following >> pattern: >> >> setSkip(true); >> try { >> // ... do whatever needed >> } finally { >> setSkip(flase); >> } >> >> to ensure that the delegate won't be left in the skip-event state even >> if any exceptions happen during processing the main operation. > > Using that pattern was my first idea > > but I decided to keep it simple since the delegate is 100% owned by the AWT > and we don't ever expect setSelectedIndex() to throw any exceptions That's OK. Thanks for clarifying the reasoning. -- best regards, Anthony > > Thanks > alexp >> >> -- >> best regards, >> Anthony >> >> On 1/17/2012 2:26 PM, Alexander Potochkin wrote: >>> Hello >>> >>> Please review the following fix: >>> http://cr.openjdk.java.net/~alexp/7125456/webrev.00/ >>> >>> the bug's description is here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125456 >>> >>> Thanks >>> alexp >>> > From sergey.bylokhov at oracle.com Tue Jan 17 08:56:51 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Jan 2012 20:56:51 +0400 Subject: Review request for 7125456: [macosx] Programmatically selecting List item triggers an ItemEvent In-Reply-To: <4F154CEE.7030303@oracle.com> References: <4F154CEE.7030303@oracle.com> Message-ID: <4F15A853.9060406@oracle.com> 17.01.2012 14:26, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7125456/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125456 Probably isSkipStateChangedEvent() should use getDelegateLock()? 182 public boolean isSkipStateChangedEvent() { 183 return skipStateChangedEvent; 184 } I mean that we setskipStateChangedEvent to false under delegateLock on main thread getDelegate().setSkipStateChangedEvent(false); but later we can read it on EDT without lock? public void valueChanged(final ListSelectionEvent e) { 192 if (!e.getValueIsAdjusting()&& !isSkipStateChangedEvent()) { > Thanks > alexp > -- Best regards, Sergey. From sergey.bylokhov at oracle.com Tue Jan 17 09:01:39 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Jan 2012 21:01:39 +0400 Subject: Request for review: 7124524 - OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer In-Reply-To: <4F159AE8.7020805@oracle.com> References: <4F15717D.5090105@oracle.com> <4F159AE8.7020805@oracle.com> Message-ID: <4F15A973.4000004@oracle.com> 17.01.2012 19:59, Anthony Petrov ?????: > Hi Sergey, > > The fix looks good. Just one question: in > LWWindowPeer.destroyBuffers() you're removing a call to > replaceSurfaceData(). Are you sure that this is OK? It is OK at least for current replaceSurfaceData implementation. > > -- > best regards, > Anthony > > On 1/17/2012 5:02 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> This is a fix for 4 memory leaks. >> 1. LWWindowPeer does not destroy backbuffer in disposeImpl(). >> 2. LWToolkit stores unused links to Peer. >> 3. Local references were not deleted in the AWTWindow.m, but >> according JNFJObjectWrapper.jObjectWithEnv documentation "returns a >> new local-ref, must be released with DeleteLocalRef". >> 4. OGLContext in some cases can cache CGLSurfaceData in this case our >> LWWindowPeer was not collected. >> >> Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7124524/webrev.00/ >> -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Jan 17 09:02:35 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 17 Jan 2012 21:02:35 +0400 Subject: Request for review: 7124524 - OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer In-Reply-To: <4F15A973.4000004@oracle.com> References: <4F15717D.5090105@oracle.com> <4F159AE8.7020805@oracle.com> <4F15A973.4000004@oracle.com> Message-ID: <4F15A9AB.4090006@oracle.com> Then I'm fine with the fix. -- best regards, Anthony On 1/17/2012 9:01 PM, Sergey Bylokhov wrote: > 17.01.2012 19:59, Anthony Petrov ?????: >> Hi Sergey, >> >> The fix looks good. Just one question: in >> LWWindowPeer.destroyBuffers() you're removing a call to >> replaceSurfaceData(). Are you sure that this is OK? > It is OK at least for current replaceSurfaceData implementation. >> >> -- >> best regards, >> Anthony >> >> On 1/17/2012 5:02 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> This is a fix for 4 memory leaks. >>> 1. LWWindowPeer does not destroy backbuffer in disposeImpl(). >>> 2. LWToolkit stores unused links to Peer. >>> 3. Local references were not deleted in the AWTWindow.m, but >>> according JNFJObjectWrapper.jObjectWithEnv documentation "returns a >>> new local-ref, must be released with DeleteLocalRef". >>> 4. OGLContext in some cases can cache CGLSurfaceData in this case our >>> LWWindowPeer was not collected. >>> >>> Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7124524/webrev.00/ >>> > > From Alexander.Potochkin at oracle.com Tue Jan 17 09:29:16 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 17 Jan 2012 21:29:16 +0400 Subject: Review request for 7125456: [macosx] Programmatically selecting List item triggers an ItemEvent In-Reply-To: <4F15A853.9060406@oracle.com> References: <4F154CEE.7030303@oracle.com> <4F15A853.9060406@oracle.com> Message-ID: <4F15AFEC.2040405@oracle.com> Hello Sergey valueChanged() can be called in two scenarios: 1) by LWLisetPeer itself, select() and initialize() methods - they use delegateLock 2) by the the user's action, LWComponentPeer.sendEventToDelegate() also posts events under the delegateLock Do you mean any other scenarios? Thanks alexp > Probably isSkipStateChangedEvent() should use getDelegateLock()? > > 182 public boolean isSkipStateChangedEvent() { > 183 return skipStateChangedEvent; > 184 } > I mean that we setskipStateChangedEvent to false under delegateLock > on main thread > getDelegate().setSkipStateChangedEvent(false); > > but later we can read it on EDT without lock? > > public void valueChanged(final ListSelectionEvent e) { > 192 if (!e.getValueIsAdjusting()&& > !isSkipStateChangedEvent()) { > > >> Thanks >> alexp >> > > From sergey.bylokhov at oracle.com Tue Jan 17 09:54:34 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Jan 2012 21:54:34 +0400 Subject: Review request for 7125456: [macosx] Programmatically selecting List item triggers an ItemEvent In-Reply-To: <4F15AFEC.2040405@oracle.com> References: <4F154CEE.7030303@oracle.com> <4F15A853.9060406@oracle.com> <4F15AFEC.2040405@oracle.com> Message-ID: <4F15B5DA.1020009@oracle.com> 17.01.2012 21:29, Alexander Potochkin ?????: > Hello Sergey > > valueChanged() can be called in two scenarios: > > 1) by LWLisetPeer itself, > select() and initialize() methods - they use delegateLock > > 2) by the the user's action, > LWComponentPeer.sendEventToDelegate() also posts events under the > delegateLock Yes. I overlooked lock in the sendEventToDelegate. The fix looks good to me. > > Do you mean any other scenarios? > > Thanks > alexp > >> Probably isSkipStateChangedEvent() should use getDelegateLock()? >> >> 182 public boolean isSkipStateChangedEvent() { >> 183 return skipStateChangedEvent; >> 184 } >> I mean that we setskipStateChangedEvent to false under delegateLock >> on main thread >> getDelegate().setSkipStateChangedEvent(false); >> >> but later we can read it on EDT without lock? >> >> public void valueChanged(final ListSelectionEvent e) { >> 192 if (!e.getValueIsAdjusting()&& !isSkipStateChangedEvent()) { >> >> >>> Thanks >>> alexp >>> >> >> > -- Best regards, Sergey. From Alexander.Potochkin at oracle.com Tue Jan 17 09:56:27 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 17 Jan 2012 21:56:27 +0400 Subject: Review request for 7125456: [macosx] Programmatically selecting List item triggers an ItemEvent In-Reply-To: <4F15B5DA.1020009@oracle.com> References: <4F154CEE.7030303@oracle.com> <4F15A853.9060406@oracle.com> <4F15AFEC.2040405@oracle.com> <4F15B5DA.1020009@oracle.com> Message-ID: <4F15B64B.3050801@oracle.com> Hello Sergey > Yes. I overlooked lock in the sendEventToDelegate. > The fix looks good to me. Thanks! alexp > >> >> Do you mean any other scenarios? >> >> Thanks >> alexp >> >>> Probably isSkipStateChangedEvent() should use getDelegateLock()? >>> >>> 182 public boolean isSkipStateChangedEvent() { >>> 183 return skipStateChangedEvent; >>> 184 } >>> I mean that we setskipStateChangedEvent to false under delegateLock >>> on main thread >>> getDelegate().setSkipStateChangedEvent(false); >>> >>> but later we can read it on EDT without lock? >>> >>> public void valueChanged(final ListSelectionEvent e) { >>> 192 if (!e.getValueIsAdjusting()&& !isSkipStateChangedEvent()) { >>> >>> >>>> Thanks >>>> alexp >>>> >>> >>> >> > > From sergey.bylokhov at oracle.com Tue Jan 17 10:24:20 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Jan 2012 22:24:20 +0400 Subject: [7u4] Request for approval for 7124530 - What is background color of AWT component? (And foreground, for that matter) In-Reply-To: <4F107D53.9060600@oracle.com> References: <4F0ED0EF.90208@oracle.com> <4F103F68.9040806@oracle.com> <9716158E-63E1-4554-B07C-2772A35F82E7@apple.com> <4F107D53.9060600@oracle.com> Message-ID: <4F15BCD4.80402@oracle.com> Hi Mike, Did you have a chance to check it? 13.01.2012 22:52, Sergey Bylokhov wrote: > 13.01.2012 21:31, Mike Swingler wrote: >> On Jan 13, 2012, at 6:27 AM, Sergey Bylokhov wrote: >> >>> 13.01.2012 6:30, Mike Swingler wrote: >>> >>>> On Jan 12, 2012, at 4:24 AM, Sergey Bylokhov wrote: >>>> >>>>> Hello, >>>>> This is a request to push the following changes to jdk7u-osx. >>>>> The fix has been reviewed on macosx-port-dev mailing list by >>>>> Alexander Potochkin. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/7124530/webrev.00/ >>>>> Technical review: >>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002143.html >>>> I don't understand this part: >>>> >>>> --- old/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 >>>> 19:02:19.913935900 +0400 >>>> +++ new/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 >>>> 19:02:19.557915600 +0400 >>>> @@ -81,7 +81,8 @@ >>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION] = >>>> [NSColor grayColor]; >>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION_TEXT] = >>>> [NSColor grayColor]; >>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION_BORDER] = >>>> [NSColor grayColor]; >>>> - sColors[java_awt_SystemColor_WINDOW] = >>>> [NSColor grayColor]; >>>> + const CGFloat color = (CGFloat)0xEE/(CGFloat)0xFF; >>>> + sColors[java_awt_SystemColor_WINDOW] = [NSColor >>>> colorWithCalibratedRed:color green:color blue:color alpha:1.0f]; >>>> sColors[java_awt_SystemColor_WINDOW_BORDER] = >>>> [NSColor windowFrameColor]; >>>> sColors[java_awt_SystemColor_WINDOW_TEXT] = >>>> [NSColor windowFrameTextColor]; >>>> sColors[java_awt_SystemColor_MENU] = >>>> [NSColor controlBackgroundColor]; >>>> >>>> Why aren't you just using [NSColor windowBackgroundColor]? >>> Only selectedControlColor and selectedTextBackgroundColor are >>> supported. >>> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DrawColor/Tasks/SystemColors.html#//apple_ref/doc/uid/20000790 >>> >>> As I understand that`s why swing didn`t use this color. After the >>> fix awt and swing use one color (before the fix this color was used >>> by swing). >>> If this color is wrong, now it`s possible to change it in one place. >> I can assure you that the window background color reports the correct >> RGB value, even when the background color has changed between OS >> versions. You static constant will not. >> >> We use it today in Java SE 6. > jdk6 on my system reports white color which is wrong. Can you please > check it(testcase attached). >> >> Regards, >> Mike Swingler >> Apple Inc. > > -- Best regards, Sergey. From Alexander.Potochkin at oracle.com Tue Jan 17 10:26:02 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 17 Jan 2012 22:26:02 +0400 Subject: [jdk7u-osx] Request for approval for 7125456: [macosx] Programmatically selecting List item triggers an ItemEvent Message-ID: <4F15BD3A.7030903@oracle.com> This is a request to push the following fix to jdk7u-osx: http://cr.openjdk.java.net/~alexp/7125456/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125456 the fix was approved by anthony.petrov and sergey.bylokhov Thanks alexp From roger.lewis at oracle.com Tue Jan 17 10:55:35 2012 From: roger.lewis at oracle.com (Roger Lewis) Date: Tue, 17 Jan 2012 10:55:35 -0800 Subject: Can't log onto wiki In-Reply-To: References: <70F5028E-D111-42DD-90CA-F3C2019A74CD@apple.com> Message-ID: <4F15C427.5000905@oracle.com> John, Mike, I have passed along the issue and was told that they are investigating. Hopefully this is resolved quickly. -Roger On 1/17/12 5:18 AM, John Yeary wrote: > Hello Mike, > > You are correct. I can only add comments. I can no longer edit the page(s). > > John > ____________________________ > > John Yeary > ____________________________ > > > > > > > > > ____________________________ > > "Far better it is to dare mighty things, to win glorious triumphs, even > though checkered by failure, than to take rank with those poor spirits who > neither enjoy much nor suffer much, because they live in the gray twilight > that knows not victory nor defeat." > -- Theodore Roosevelt > > > > On Mon, Jan 16, 2012 at 6:37 PM, Mike Swingler wrote: > >> After consenting to the terms and conditions, are you able to make any >> edits to the page content, or only comment? >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On Jan 11, 2012, at 5:28 PM, John Yeary wrote: >> >> Hello Mike, >> >> I can log in, but it did prompt me with terms and conditions which it has >> not done before. >> >> John >> ____________________________ >> >> John Yeary >> ____________________________ >> >> >> >> >> >> ____________________________ >> >> "Far better it is to dare mighty things, to win glorious triumphs, even >> though checkered by failure, than to take rank with those poor spirits who >> neither enjoy much nor suffer much, because they live in the gray twilight >> that knows not victory nor defeat." >> -- Theodore Roosevelt >> >> >> >> On Wed, Jan 11, 2012 at 7:47 PM, Mike Swingler wrote: >> >>> Can anyone else log into the wiki< >>> https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port>? >>> >>> Seems to be immediately signing me out as soon as I log in. >>> >>> There are no apparent links on the site or on the other OTN pages to >>> report issues with the site. >>> >>> Any suggestions? >>> Mike Swingler >>> Apple Inc. >>> >>> >> From kurchi.subhra.hazra at oracle.com Tue Jan 17 11:01:51 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 17 Jan 2012 11:01:51 -0800 Subject: Code Review Request: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X In-Reply-To: <4F13FF6B.7080403@oracle.com> References: <4F0DDFEF.4000908@oracle.com> <4F108E99.7030903@oracle.com> <4F1090C0.10501@oracle.com> <4F109BE2.9000101@oracle.com> <4F13FF6B.7080403@oracle.com> Message-ID: <4F15C59F.5000009@oracle.com> I updated the comment: http://cr.openjdk.java.net/~khazra/7127771/webrev.02/ - Kurchi On 1/16/2012 2:43 AM, Michael McMahon wrote: > Yes, looks fine to me too. I would just update the comment above this > code to add Mac OS to the Solaris case. > > Thanks > Michael > > On 13/01/12 21:02, Kurchi Hazra wrote: >> How does this look: >> http://cr.openjdk.java.net/~khazra/7127771/webrev.01/ >> >> - Kurchi >> >> >> >> On 1/13/2012 12:14 PM, Alan Bateman wrote: >>> >>>>> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127771 >>>>> Webrev : http://cr.openjdk.java.net/~khazra/7127771/webrev.00/ >>> What you have is fine although you could combine with the Solaris >>> code? Should the __ALLBSD_SOURCE XXX be removed while you are there? >>> >>> -Alan >> > -- -Kurchi From anthony.petrov at oracle.com Tue Jan 17 11:07:25 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 17 Jan 2012 23:07:25 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> <4F156177.9050007@oracle.com> Message-ID: <4F15C6ED.3000702@oracle.com> Hi Mike, On 1/17/2012 8:52 PM, Mike Swingler wrote: > On Jan 17, 2012, at 3:54 AM, Anthony Petrov wrote: >> On 1/16/2012 8:24 PM, Mike Swingler wrote: >>> I still don't understand why the list of hardcoded window levels >>> needs to be included. Can't you just compare the window levels by >>> their NSInteger numeric values? >> >> There are two reasons for not using the numeric values directly, or >> comparing them directly: >> >> 1. Cocoa specification doesn't define the numeric values for the >> NS*WindowLevel constants. They may (theoretically) change in the >> future. As long as they aren't specified, we don't want to rely on >> their current values. > > Why do you have to know the values at all? Couldn't you just reset the > child window level if it's different after the parent/child operation? > After I re-read what you are trying to accomplish, even numeric > comparison seems inappropriate. I've already answered this question to Leonid on Jan 12, but I'll copy my reply here for your convenience: If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >> 2. There's a reference to the Quartz spec that defines the >> kCG*WindowLevel constants as a enum. The NS*WindowLevel macros are >> defined using these constants. However, if you take a look at the >> order of the constants in that enum [1] (and therefore their relative >> numerical order), you may notice that they don't exactly reflect the >> relative visual z-order between the levels as defined in the Cocoa >> spec [2]. E.g. kCGModalPanelWindowLevelKey is greater than >> kCGDockWindowLevelKey, while NSDockWindowLevel is defined being >> visually above the NSModalPanelWindowLevel. As such, a direct numeric >> comparison of window levels produces incorrect results. > > Have you tried setting something at the "dock" level? That level may > have been true for the NextStep dock, but not the Mac. And BTW: > the NSDockWindowLevel is deprecated. Don't use it. Yes, this is a good tip. I've removed the NSDockWindowLevel from the array. An updated fix is available at: http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.1/ >> The array of hardcoded window levels allows us to convert between >> window levels ordered arbitrarily and integer values ordered according >> to their visual z-order. This allows us to compare windows level with >> respect to their relative z-order as specified by Cocoa documentation. > > These constants are for assignment based on intention, not simple > comparison of stacking level. They have behavioral meaning beyond just > simple visual level ordering. Windows above the normal window level will > disappear in Expos?/Mission Control, and certain levels will float in > all Spaces. Other levels exclude the window from Cmd-~ keyboard window > cycling, or showing up in the Dock window menu. Please, please, please > test the side effects of these changes before just popping windows into > different levels. Could you please clarify what exact "different levels" you're talking about here? AWT currently uses only two window levels: NSNormalWindowLevel is used for regular windows, and NSFloatingWindowLevel for always-on-top windows (see AWTWindow.m). This code is already in the repository, and tests for always-on-top windows do work OK. So back to the fix we're discussing, in reality the oldChildLevel in the CWrapper.addChildWindow() implementation can be either of these two levels, but not anything else. I guess we could simplify the fix and only include these two levels in the ORDERED_LEVELS{} array. I suppose Lubomir just wanted to provide a more generic and complete implementation that won't break if we ever start using any other levels in the future (or e.g. if OS temporarily puts our window on some other level). This is certainly unlikely, of course, however, I see absolutely no problems with an implementation of compareWindowLevels() that can work with all window levels officially supported by Cocoa, not just the two that we use currently. > The safest thing to do (if it works) is just to simply re-assign the > window level after adding the child to the parent, but you will have to > recursively descend into the child windows of the child, because setting > the window level sets the level of all the children too (and changes > their collection/spaces/cycle behavior). This may not be an issue if you > never change a child window's parent. I've clarified above why simple reassignment won't work well. -- best regards, Anthony > > Regards, > Mike Swingler > Apple Inc. > >> Does this clarify the need for the array of window levels? Do you have >> any other concerns regarding the fix? >> >> [1] >> http://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/tdef/CGWindowLevelKey >> >> [2] >> http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Window_Levels >> >> -- >> best regards, >> Anthony >> >> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> On Jan 14, 2012, at 7:40 PM, Mike Swingler wrote: >>>> In the course of preparing to contribute our current window stacking >>>> algorithm, I realized that there was a pair of internal SPI calls it >>>> was making. In the next revision we ship of the >>>> JavaRuntimeSupport.framework we can provide cover methods of these >>>> SPI, however that is of little benefit to the OpenJDK port in the >>>> immediate here-and-now. >>>> >>>> For now, using -addChildWindow: will be sufficient, however, we can >>>> provide an alternate implementation that uses a new pair of category >>>> methods on NSWindow if -respondsToSelector: shows that they are >>>> available: >>>> - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; >>>> - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; >>>> >>>> These functions will allow the window server to move each child >>>> window with respect to it's parent's level, but without being added >>>> to it's movement group. >>>> >>>> Once customers get an updated JavaNativeFoundation.framework by >>>> either Java update or OS update, the implementation will switch over >>>> dynamically at runtime. >>>> >>>> How does this sound for a plan? >>>> >>>> Regards, >>>> Mike Swingler >>>> Apple Inc. >>>> >>>> On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com >>>> wrote: >>>> >>>>> We fought this one in SWT and ended up going with the puppy route. >>>>> >>>>> Steve >>>>> >>>>> On 12/01/2012 2:57 PM, Anthony Petrov wrote: >>>>>> Hi Mike, >>>>>> >>>>>> I recall we've discussed this issue with you back in 2010. >>>>>> Unfortunately, I wasn't able to implement anything like this that >>>>>> would work reliably back then (and I tried hard, really), that's >>>>>> why we ended up with -addChildWindow:. Note that JCK is very happy >>>>>> with this implementation, and so are we, I presume. As long as >>>>>> child windows receive their respective MOVE events, it seems that >>>>>> everything is all right. Besides, such behavior is very >>>>>> Mac-friendly, making Java apps behave like native apps. >>>>>> >>>>>> I realize that for some developers this behavior may be >>>>>> inconvenient. But then again, why not listen to MOVE events on the >>>>>> parent frame and compensate for its movement repositioning all its >>>>>> children? ( :) yeah, yeah, I know, sounds weird, but... as Steve >>>>>> says, you gotta do what you gotta do... I mean, there's a >>>>>> workaround at least!) >>>>>> >>>>>> So, if you or anyone else wish to contribute an alternative >>>>>> implementation for owned windows, that would be greatly >>>>>> appreciated. Otherwise I'm afraid we have to stick with using >>>>>> -addChildWindow: for now since we simply don't have a better solution. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>>>>>> Also, you should not use -addChildWindow:, because you also get >>>>>>> added to the movement group of the parent (moving the parent >>>>>>> moves all it's children). This is *highly* undesirable behavior >>>>>>> for Java's general use (and you can see it in Eclipse when the >>>>>>> find window follows around the IDE window like a puppy). >>>>>>> >>>>>>> In the Java SE 6 AWT we manually restack every Java window in >>>>>>> native with -orderFront: every time a Java window changes it's >>>>>>> level to correctly handle it's children and the relationships >>>>>>> between them. This actually works out ok, since all the changes >>>>>>> happen at once, and when the next turn of the event loop happens, >>>>>>> the new stacking order only has one new window moving to the >>>>>>> background and one new window becoming key/main. >>>>>>> >>>>>>> Regards, >>>>>>> Mike Swingler >>>>>>> Apple Inc. >>>>>>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>>>>>> >>>>>>>> Bah, I was wrong. The value of NS*WindowLevel is really funky, >>>>>>>> it was a wrong suggestion to rely on it. Sorry for wasting your >>>>>>>> time. >>>>>>>> >>>>>>>> >>>>>>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>>>>>> >>>>>>>>> The values of the NS*WindowLevel macros are not a part of the >>>>>>>>> contract for Cocoa API. Therefore, we shouldn't rely on their >>>>>>>>> current numerical values. The names, however, and their >>>>>>>>> relative z-order are clearly specified in the documentation, >>>>>>>>> and as such we may use them. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> best regards, >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>>>>>> I see? It looks like the higher window level is, the higher is >>>>>>>>>> the value of corresponding NS*WindowLevel macro. >>>>>>>>>> Wouldn't it be better to implement compareWindowLevels() by >>>>>>>>>> simply subtracting one value from another? >>>>>>>>>> >>>>>>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>>>>>> >>>>>>>>>>> Hi Leonid, >>>>>>>>>>> >>>>>>>>>>> Thanks for taking a look at the fix. >>>>>>>>>>> >>>>>>>>>>> The if check is needed for the following case. If the parent >>>>>>>>>>> window is an always-on-top window, its level is >>>>>>>>>>> NSFloatingWindowLevel. Suppose a child window being added to >>>>>>>>>>> it hasn't been assigned any level explicitly, so its default >>>>>>>>>>> level is NSNormalWindowLevel. >>>>>>>>>>> >>>>>>>>>>> Now, when we call -addChildWindow:, we really want to update >>>>>>>>>>> the level of the child window so that both the parent and the >>>>>>>>>>> child share the same window level. The if check ensures that >>>>>>>>>>> we don't reset the level of the child window back to normal >>>>>>>>>>> in this case. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> best regards, >>>>>>>>>>> Anthony >>>>>>>>>>> >>>>>>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>>>>>> Just wondering: what would happen if you simply set >>>>>>>>>>>> oldChildlevel without that "if" check? >>>>>>>>>>>> >>>>>>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review a fix for >>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>>>>>> >>>>>>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix >>>>>>>>>>>>> itself. I'm just going to integrate it into the repository. >>>>>>>>>>>>> >>>>>>>>>>>>> A JWindow object is always a child window with either an >>>>>>>>>>>>> explicit parent, or a shared invisible owner frame. >>>>>>>>>>>>> Therefore, we always call NSWindow -addChildWindow: when >>>>>>>>>>>>> showing a JWindow object. The root cause of the issue is >>>>>>>>>>>>> that the -addChildWindow: resets the level of the child >>>>>>>>>>>>> window to match that of the parent window. With this fix we >>>>>>>>>>>>> restore the level back to its original value after the >>>>>>>>>>>>> -addChildWindow: call, and as such preserve the >>>>>>>>>>>>> always-on-top state of the child window. >>>>>>>>>>>>> >>>>>>>>>>>>> I've verified the fix with a test app attached to the >>>>>>>>>>>>> original issue at >>>>>>>>>>>>> http://java.net/jira/browse/MACOSX_PORT-158 , and it works >>>>>>>>>>>>> fine. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> best regards, >>>>>>>>>>>>> Anthony > From anthony.petrov at oracle.com Tue Jan 17 11:24:12 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 17 Jan 2012 23:24:12 +0400 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F15A353.7080802@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F1575F4.3060104@oracle.com> <4F15A353.7080802@oracle.COM> Message-ID: <4F15CADC.4020203@oracle.com> On 1/17/2012 8:35 PM, Kumar Srinivasan wrote: >> src/share/bin/java.c >>> 987 } else if (IsMacOSX() && JLI_StrCmp(arg, >>> "-XstartOnFirstThread") == 0) { >>> 988 ProcessSpecialArg(arg); >>> 989 } else if (IsMacOSX() && JLI_StrCCmp(arg, "-Xdock:") == >>> 0) { >>> 990 ProcessSpecialArg(arg); > If we don't have those runtime checks then Windows, > Linux and Solaris will accept those flags without a fuss, so what should > the behavior be ? I just thought that instead of the run-time conditional this could somehow be folded into a compile-type kind of check. This could be an #ifdef, or at the end of this chained if{}else{} block we could have something like: } else if (ProcessPlatformArg(arg)) { } else if (RemovableOption... and then have the ProcessPlatformArg() be defined in java_md.c. > Was a specification (ccc) filed for these flags ? Will this be > documented in the help > section ? though X flags are unsupported, in the past we have documented > them, both > in the man pages as well as "java -X", if these will be left > undocumented should we take > the vm approach and mark it -XX ? These flags are commonly recognized since Apple has introduced them ages ago, so developers expect these flags to work. I think it makes sense to document their usage. >> Generally, the fix looks good. Lots of #ifdef MACOSX looked very >> confusing before. However, I feel uncomfortable with having so much >> code duplicated between src/solaris/bin/java_md.c and >> src/macosx/bin/java_md.c. This seems to increase launcher code >> maintenance cost. Is there any possibility to fold the code up in a >> common source file that is shared between solaris/linux and macosx, >> and only define really specific parts of the code in separate files? >> The simplest way to accomplish this would be to leave exactly one >> #ifdef MACOSX in the shared file and #include a platform specific part >> there. Or we could tweak the make files to compile an additional file. > Yes it is a lot more readable, and yes it increases duplication , but we > already have some duplication between windows and unix. Since > this is platform specific code, and 7uX will go into maintenance mode, > the exposure will be limited. Ah, I didn't realize that this fix isn't going to be ported to JDK 8. In this case I guess I'm fine with this. But in JDK 8 we should certainly think of something more maintainable and less duplicating. BTW, adding comments to both java_md.c's for macosx and solaris stating that lots of the code is duplicated between the two would be great. -- best regards, Anthony > However, for jdk8 we need a hierarchical structure, as I heard some > noise about > restructuring the platform code, at that time it will be a good idea to > coalesce > these things, and remove the LD_LIBRARY_PATH cloaking in solaris/java_md.c > which is not relevant to MacOSX. > >> >> Also, the major part of the JVMInit() function is identical on all >> three platforms - solaris/linux, macosx, and windows. It makes sense >> to define a function containing that code in the java.c and call it by >> platform-specific JVMInit() implementations where needed. > Yes this can be done, I will look into it. > > Kumar > >> >> -- >> best regards, >> Anthony >> >> On 1/17/2012 7:33 AM, Kumar Srinivasan wrote: >>> oops missed setting the subject line to 7ux-osx. >>> >>> Kumar >>> >>>> Hi, >>>> >>>> Please review the launcher refactoring work, the webrev is here: >>>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.0/ >>>> >>>> Notes: >>>> 1. Moves the majority of the launcher code into platform specific >>>> directories/files, >>>> removed redundant conditionals. >>>> >>>> 2. The solaris/linux code co-exists together as before. >>>> >>>> 3. On MacOSX, "java -client" will launch the server VM, for >>>> compatibility reasons, >>>> and dual mode is left in the macosx's java_md.c, this will >>>> enable experiments >>>> with universal libraries, quite easily. Also the mac ergonomics >>>> will always return >>>> server. >>>> >>>> Testing: >>>> Tested splash screen on all platforms and launcher regression tests. >>>> >>>> Thanks >>>> Kumar >>>> >>>> >>>> >>> > From swingler at apple.com Tue Jan 17 12:29:37 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 17 Jan 2012 12:29:37 -0800 Subject: [7u4] Request for approval for 7124530 - What is background color of AWT component? (And foreground, for that matter) In-Reply-To: <4F107D53.9060600@oracle.com> References: <4F0ED0EF.90208@oracle.com> <4F103F68.9040806@oracle.com> <9716158E-63E1-4554-B07C-2772A35F82E7@apple.com> <4F107D53.9060600@oracle.com> Message-ID: <3BBD9C26-CA01-4EDD-8279-F6C87AB25E61@apple.com> On Jan 13, 2012, at 10:52 AM, Sergey Bylokhov wrote: > 13.01.2012 21:31, Mike Swingler ?????: >> On Jan 13, 2012, at 6:27 AM, Sergey Bylokhov wrote: >> >>> 13.01.2012 6:30, Mike Swingler wrote: >>> >>>> On Jan 12, 2012, at 4:24 AM, Sergey Bylokhov wrote: >>>> >>>>> Hello, >>>>> This is a request to push the following changes to jdk7u-osx. >>>>> The fix has been reviewed on macosx-port-dev mailing list by Alexander Potochkin. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 >>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124530/webrev.00/ >>>>> Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002143.html >>>> I don't understand this part: >>>> >>>> --- old/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 19:02:19.913935900 +0400 >>>> +++ new/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 19:02:19.557915600 +0400 >>>> @@ -81,7 +81,8 @@ >>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION] = [NSColor grayColor]; >>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION_TEXT] = [NSColor grayColor]; >>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION_BORDER] = [NSColor grayColor]; >>>> - sColors[java_awt_SystemColor_WINDOW] = [NSColor grayColor]; >>>> + const CGFloat color = (CGFloat)0xEE/(CGFloat)0xFF; >>>> + sColors[java_awt_SystemColor_WINDOW] = [NSColor colorWithCalibratedRed:color green:color blue:color alpha:1.0f]; >>>> sColors[java_awt_SystemColor_WINDOW_BORDER] = [NSColor windowFrameColor]; >>>> sColors[java_awt_SystemColor_WINDOW_TEXT] = [NSColor windowFrameTextColor]; >>>> sColors[java_awt_SystemColor_MENU] = [NSColor controlBackgroundColor]; >>>> >>>> Why aren't you just using [NSColor windowBackgroundColor]? >>> Only selectedControlColor and selectedTextBackgroundColor are supported. >>> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DrawColor/Tasks/SystemColors.html#//apple_ref/doc/uid/20000790 >>> As I understand that`s why swing didn`t use this color. After the fix awt and swing use one color (before the fix this color was used by swing). >>> If this color is wrong, now it`s possible to change it in one place. >> I can assure you that the window background color reports the correct RGB value, even when the background color has changed between OS versions. You static constant will not. >> >> We use it today in Java SE 6. > > jdk6 on my system reports white color which is wrong. Can you please check it(testcase attached). The test works fine in Java SE 6 with JFrames and other components. The bug where you are getting white from a pure AWT Frame is a side effect of something we call the "magic background color", which is not applicable to Java 7. Does +[NSColor windowBackgroundColor] not give you the correct RGB value? Regards, Mike Swingler Apple Inc. From kelly.ohair at oracle.com Tue Jan 17 14:00:41 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 17 Jan 2012 14:00:41 -0800 Subject: tag boucing again In-Reply-To: <4F11C83D.1010602@oracle.com> References: <4F11C83D.1010602@oracle.com> Message-ID: <6B253885-D687-4C31-A2EA-5D053874D689@oracle.com> Which, in my opinion, is a tag that should not be made external in an openjdk repository. It's very confusing to the openjdk community. It may be time to allow for an optional lettering scheme, so that you could have a jdk7u4-b05m1 or some such nonsense. Playing around with the build promotion number is not a good plan. :^( -kto On Jan 14, 2012, at 10:23 AM, Daniel D. Daugherty wrote: > That's a tag for an internal build. > > Dan > > > On 1/14/12 2:18 AM, Henri Gomez wrote: >> It seems we're back to b2xx in tags : >> >> jdk7u4-b225 398:2fea92d741b7 >> jdk7u4-b05 396:a15712a2304e >> jdk7u4-b200 392:25457f672756 >> jdk7u4-b04 391:bcc37b8ac1b0 >> jdk7u2-b21 389:e30fd289f001 >> >> Is it a QA tag or something else ? >> >> Cheers From jason.uh at oracle.com Tue Jan 17 14:23:40 2012 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 17 Jan 2012 14:23:40 -0800 Subject: Request for approval for 7127874: [macosx] Add handling of macosx env variables to ProcessBuilder regression test Message-ID: <4F15F4EC.8090102@oracle.com> Requesting approval to push this fix to jdk7u-osx: Change: http://cr.openjdk.java.net/~juh/7127874/webrev.01/ CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127874 The fix has been reviewed by: michaelm The changeset will be pushed for me by Michael McMahon (michaelm). Thanks, Jason From paul.hohensee at oracle.com Tue Jan 17 14:26:50 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 17 Jan 2012 17:26:50 -0500 Subject: Request for approval for 7127448: [macosx] Regression test scripts for policytool need to recognize macosx In-Reply-To: <4F15F359.10408@oracle.com> References: <4F15F359.10408@oracle.com> Message-ID: <4F15F5AA.8080006@oracle.com> Approved. Paul On 1/17/12 5:16 PM, Jason Uh wrote: > Requesting approval to push this fix to jdk7u-osx: > > Change: http://cr.openjdk.java.net/~juh/7127448/webrev.00/ > > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127448 > > The fix has been reviewed by: swingler, weijun, michaelm > > The changeset will be pushed for me by Michael McMahon (michaelm). > > Thanks, > Jason From swingler at apple.com Tue Jan 17 15:36:57 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 17 Jan 2012 15:36:57 -0800 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F15C6ED.3000702@oracle.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> <4F156177.9050007@oracle.com> <4F15C6ED.3000702@oracle.com> Message-ID: On Jan 17, 2012, at 11:07 AM, Anthony Petrov wrote: > Hi Mike, > > On 1/17/2012 8:52 PM, Mike Swingler wrote: >> On Jan 17, 2012, at 3:54 AM, Anthony Petrov wrote: >>> On 1/16/2012 8:24 PM, Mike Swingler wrote: >>>> I still don't understand why the list of hardcoded window levels needs to be included. Can't you just compare the window levels by their NSInteger numeric values? >>> >>> There are two reasons for not using the numeric values directly, or comparing them directly: >>> >>> 1. Cocoa specification doesn't define the numeric values for the NS*WindowLevel constants. They may (theoretically) change in the future. As long as they aren't specified, we don't want to rely on their current values. >> Why do you have to know the values at all? Couldn't you just reset the child window level if it's different after the parent/child operation? After I re-read what you are trying to accomplish, even numeric comparison seems inappropriate. > > I've already answered this question to Leonid on Jan 12, but I'll copy my reply here for your convenience: > > If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. > > Now, when we call -addChildWindow:, we really want to update the level > of the child window so that both the parent and the child share the same > window level. The if check ensures that we don't reset the level of the > child window back to normal in this case. I think what you really want to do here is check if the parent and the child are Always-On-Top, and then reset the window level of the child only when the child is AOT and the parent is not. -[NSWindow addChildWindow:order:] forces the child to the same level as the parent already. I'd avoid trying to infer if there is any "higher" vs. "lower" relationship between the parent based on the window level as seen from AppKit using that table. >>> 2. There's a reference to the Quartz spec that defines the kCG*WindowLevel constants as a enum. The NS*WindowLevel macros are defined using these constants. However, if you take a look at the order of the constants in that enum [1] (and therefore their relative numerical order), you may notice that they don't exactly reflect the relative visual z-order between the levels as defined in the Cocoa spec [2]. E.g. kCGModalPanelWindowLevelKey is greater than kCGDockWindowLevelKey, while NSDockWindowLevel is defined being visually above the NSModalPanelWindowLevel. As such, a direct numeric comparison of window levels produces incorrect results. >> Have you tried setting something at the "dock" level? That level may have been true for the NextStep dock, but not the Mac. And BTW: the NSDockWindowLevel is deprecated. Don't use it. > > Yes, this is a good tip. I've removed the NSDockWindowLevel from the array. An updated fix is available at: > > http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.1/ Also, NSSubmenuWindowLevel and NSTornOffMenuWindowLevel are synonyms for each other, and end up being the same value. The documentation for NSWindow [2] says "The constant NSTornOffMenuWindowLevel is preferable to its synonym, NSSubmenuWindowLevel.", but again, I'd recommend just removing the table and higher/lower comparison. >>> The array of hardcoded window levels allows us to convert between window levels ordered arbitrarily and integer values ordered according to their visual z-order. This allows us to compare windows level with respect to their relative z-order as specified by Cocoa documentation. >> These constants are for assignment based on intention, not simple comparison of stacking level. They have behavioral meaning beyond just simple visual level ordering. Windows above the normal window level will disappear in Expos?/Mission Control, and certain levels will float in all Spaces. Other levels exclude the window from Cmd-~ keyboard window cycling, or showing up in the Dock window menu. Please, please, please test the side effects of these changes before just popping windows into different levels. > > Could you please clarify what exact "different levels" you're talking about here? AWT currently uses only two window levels: NSNormalWindowLevel is used for regular windows, and NSFloatingWindowLevel for always-on-top windows (see AWTWindow.m). This code is already in the repository, and tests for always-on-top windows do work OK. The AWT will need to use more levels, and it's not clear how parent/child relationships need to affect these window levels. NSFloatingWindowLevel is used for palettes (like non-modal parented dialogs with small title bars), which do not participate in Expos?/Mission Control. NSModalPanelWindowLevel is what app-modal dialogs (like Open/Save) live at, which you might want "always on top" windows to be on top of too. Obviously popup menus should be at NSPopUpMenuWindowLevel. Another complication we encountered in Java SE 6 is full-screen exclusive windows, which still expect popups to be visible, so we had to push them above the NSScreenSaverWindowLevel as a gross hacky workaround. In your testing have you moved these windows between spaces? Can you separate them between spaces? Do the windows show as visible in Mission Control? When you right-click on the Dock icon, do they show in the window list? Should they? When you press Cmd-~, do they participate in the window cycle? These are the manual tests we do every time we futz with something like "window level" or "child windows" in Java SE 6, which can't easily be automated. > So back to the fix we're discussing, in reality the oldChildLevel in the CWrapper.addChildWindow() implementation can be either of these two levels, but not anything else. I guess we could simplify the fix and only include these two levels in the ORDERED_LEVELS{} array. I suppose Lubomir just wanted to provide a more generic and complete implementation that won't break if we ever start using any other levels in the future (or e.g. if OS temporarily puts our window on some other level). This is certainly unlikely, of course, however, I see absolutely no problems with an implementation of compareWindowLevels() that can work with all window levels officially supported by Cocoa, not just the two that we use currently. In the future, I agree, the existing child window level will have to be more than two values, but either it should be allowed to inherit from it's parent, or it should be reset to the original value. This is really a decision to be made based on the Java model state, and not an observed property in the AppKit model which is being changed behind your back and compared against a table. Right now the only decision hooks on if the AOT state of the parent and child, which is already present in the styleBits of the window. See the IS, SET, and MASK macro usage in AWTWindow.m for more info. You could make a simple accessor to report if ALWAYS_ON_TOP is set on both the parent and the child. >> The safest thing to do (if it works) is just to simply re-assign the window level after adding the child to the parent, but you will have to recursively descend into the child windows of the child, because setting the window level sets the level of all the children too (and changes their collection/spaces/cycle behavior). This may not be an issue if you never change a child window's parent. > > I've clarified above why simple reassignment won't work well. Got it. I think I've straightened out my thinking on this too, and paged back years of hacks and corner cases I would have preferred to have forgotten... Cheers, Mike Swingler Apple Inc. > -- > best regards, > Anthony > >> Regards, >> Mike Swingler >> Apple Inc. >>> Does this clarify the need for the array of window levels? Do you have any other concerns regarding the fix? >>> >>> [1] http://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/tdef/CGWindowLevelKey >>> >>> [2] http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Window_Levels >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>>> Regards, >>>> Mike Swingler >>>> Apple Inc. >>>> On Jan 14, 2012, at 7:40 PM, Mike Swingler wrote: >>>>> In the course of preparing to contribute our current window stacking algorithm, I realized that there was a pair of internal SPI calls it was making. In the next revision we ship of the JavaRuntimeSupport.framework we can provide cover methods of these SPI, however that is of little benefit to the OpenJDK port in the immediate here-and-now. >>>>> >>>>> For now, using -addChildWindow: will be sufficient, however, we can provide an alternate implementation that uses a new pair of category methods on NSWindow if -respondsToSelector: shows that they are available: >>>>> - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; >>>>> - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; >>>>> >>>>> These functions will allow the window server to move each child window with respect to it's parent's level, but without being added to it's movement group. >>>>> >>>>> Once customers get an updated JavaNativeFoundation.framework by either Java update or OS update, the implementation will switch over dynamically at runtime. >>>>> >>>>> How does this sound for a plan? >>>>> >>>>> Regards, >>>>> Mike Swingler >>>>> Apple Inc. >>>>> >>>>> On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com wrote: >>>>> >>>>>> We fought this one in SWT and ended up going with the puppy route. >>>>>> >>>>>> Steve >>>>>> >>>>>> On 12/01/2012 2:57 PM, Anthony Petrov wrote: >>>>>>> Hi Mike, >>>>>>> >>>>>>> I recall we've discussed this issue with you back in 2010. Unfortunately, I wasn't able to implement anything like this that would work reliably back then (and I tried hard, really), that's why we ended up with -addChildWindow:. Note that JCK is very happy with this implementation, and so are we, I presume. As long as child windows receive their respective MOVE events, it seems that everything is all right. Besides, such behavior is very Mac-friendly, making Java apps behave like native apps. >>>>>>> >>>>>>> I realize that for some developers this behavior may be inconvenient. But then again, why not listen to MOVE events on the parent frame and compensate for its movement repositioning all its children? ( :) yeah, yeah, I know, sounds weird, but... as Steve says, you gotta do what you gotta do... I mean, there's a workaround at least!) >>>>>>> >>>>>>> So, if you or anyone else wish to contribute an alternative implementation for owned windows, that would be greatly appreciated. Otherwise I'm afraid we have to stick with using -addChildWindow: for now since we simply don't have a better solution. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>>>>>>> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). >>>>>>>> >>>>>>>> In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Mike Swingler >>>>>>>> Apple Inc. >>>>>>>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>>>>>>> >>>>>>>>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>>>>>>> >>>>>>>>>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> best regards, >>>>>>>>>> Anthony >>>>>>>>>> >>>>>>>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>>>>>>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>>>>>>>>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>>>>>>>>>> >>>>>>>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for taking a look at the fix. >>>>>>>>>>>> >>>>>>>>>>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>>>>>>>> >>>>>>>>>>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> best regards, >>>>>>>>>>>> Anthony >>>>>>>>>>>> >>>>>>>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>>>>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>>>>>>>>>> >>>>>>>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>>>>>>>>>> >>>>>>>>>>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>> Anthony From dalibor.topic at oracle.com Tue Jan 17 16:09:31 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 18 Jan 2012 01:09:31 +0100 Subject: Fwd: OpenJDK wikis have moved In-Reply-To: <4F160D49.3090107@oracle.com> References: <4F160D49.3090107@oracle.com> Message-ID: <4F160DBB.8070204@oracle.com> -------- Original Message -------- Subject: OpenJDK wikis have moved Date: Wed, 18 Jan 2012 01:07:37 +0100 From: Dalibor Topic To: web-discuss at openjdk.java.net See http://robilad.livejournal.com/111187.html . cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From kumar.x.srinivasan at oracle.COM Tue Jan 17 16:30:52 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 17 Jan 2012 16:30:52 -0800 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F160CBD.7090905@oracle.com> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F1575F4.3060104@oracle.com> <4F15A353.7080802@oracle.COM> <4F160CBD.7090905@oracle.com> Message-ID: <4F1612BC.9000904@oracle.COM> Hi Joe, > Kumar, > > What is the general plan on getting this functionality into JDK 8 as > well as 7uX? Good question, I am hoping someone on this forum can answer about the timetable and also the merge into 7uX and jdk8. I am hoping when it is ready to be merge into 8, we will have to lay this out in a more sensible way. Kumar > > Like Anthony, I'm a bit concerned about the code duplications, > although generally the changes look good. > > -Joe > > On 1/17/2012 8:35 AM, Kumar Srinivasan wrote: >> Hi Anthony, >> >>> >>> src/share/bin/java.c >>>> 987 } else if (IsMacOSX() && JLI_StrCmp(arg, >>>> "-XstartOnFirstThread") == 0) { >>>> 988 ProcessSpecialArg(arg); >>>> 989 } else if (IsMacOSX() && JLI_StrCCmp(arg, "-Xdock:") >>>> == 0) { >>>> 990 ProcessSpecialArg(arg); >> If we don't have those runtime checks then Windows, >> Linux and Solaris will accept those flags without a fuss, so what >> should the behavior be ? >> >> Was a specification (ccc) filed for these flags ? Will this be >> documented in the help >> section ? though X flags are unsupported, in the past we have >> documented them, both >> in the man pages as well as "java -X", if these will be left >> undocumented should we take >> the vm approach and mark it -XX ? >>> >>>> 1595 if (IsMacOSX()) { >> >> I can make this platform specific. >> >> >>> >>> Generally, the fix looks good. Lots of #ifdef MACOSX looked very >>> confusing before. However, I feel uncomfortable with having so much >>> code duplicated between src/solaris/bin/java_md.c and >>> src/macosx/bin/java_md.c. This seems to increase launcher code >>> maintenance cost. Is there any possibility to fold the code up in a >>> common source file that is shared between solaris/linux and macosx, >>> and only define really specific parts of the code in separate files? >>> The simplest way to accomplish this would be to leave exactly one >>> #ifdef MACOSX in the shared file and #include a platform specific >>> part there. Or we could tweak the make files to compile an >>> additional file. >> Yes it is a lot more readable, and yes it increases duplication , but we >> already have some duplication between windows and unix. Since >> this is platform specific code, and 7uX will go into maintenance mode, >> the exposure will be limited. >> >> However, for jdk8 we need a hierarchical structure, as I heard some >> noise about >> restructuring the platform code, at that time it will be a good idea >> to coalesce >> these things, and remove the LD_LIBRARY_PATH cloaking in >> solaris/java_md.c >> which is not relevant to MacOSX. >> >>> >>> Also, the major part of the JVMInit() function is identical on all >>> three platforms - solaris/linux, macosx, and windows. It makes sense >>> to define a function containing that code in the java.c and call it >>> by platform-specific JVMInit() implementations where needed. >> Yes this can be done, I will look into it. >> >> Kumar >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/17/2012 7:33 AM, Kumar Srinivasan wrote: >>>> oops missed setting the subject line to 7ux-osx. >>>> >>>> Kumar >>>> >>>>> Hi, >>>>> >>>>> Please review the launcher refactoring work, the webrev is here: >>>>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.0/ >>>>> >>>>> Notes: >>>>> 1. Moves the majority of the launcher code into platform specific >>>>> directories/files, >>>>> removed redundant conditionals. >>>>> >>>>> 2. The solaris/linux code co-exists together as before. >>>>> >>>>> 3. On MacOSX, "java -client" will launch the server VM, for >>>>> compatibility reasons, >>>>> and dual mode is left in the macosx's java_md.c, this will >>>>> enable experiments >>>>> with universal libraries, quite easily. Also the mac >>>>> ergonomics will always return >>>>> server. >>>>> >>>>> Testing: >>>>> Tested splash screen on all platforms and launcher regression >>>>> tests. >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>> >>>>> >>>> >> From kumar.x.srinivasan at oracle.COM Tue Jan 17 16:33:14 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 17 Jan 2012 16:33:14 -0800 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F160C48.2070606@oracle.com> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F1575F4.3060104@oracle.com> <4F15A353.7080802@oracle.COM> <4F160C48.2070606@oracle.com> Message-ID: <4F16134A.2050207@oracle.COM> Hi Joe, Anthony, Please see inlined comments.... > Hello, > > On 1/17/2012 8:35 AM, Kumar Srinivasan wrote: >> Hi Anthony, >> >>> >>> src/share/bin/java.c >>>> 987 } else if (IsMacOSX() && JLI_StrCmp(arg, >>>> "-XstartOnFirstThread") == 0) { >>>> 988 ProcessSpecialArg(arg); >>>> 989 } else if (IsMacOSX() && JLI_StrCCmp(arg, "-Xdock:") >>>> == 0) { >>>> 990 ProcessSpecialArg(arg); >> If we don't have those runtime checks then Windows, >> Linux and Solaris will accept those flags without a fuss, so what >> should the behavior be ? >> >> Was a specification (ccc) filed for these flags ? Will this be >> documented in the help >> section ? though X flags are unsupported, in the past we have >> documented them, both >> in the man pages as well as "java -X", if these will be left >> undocumented should we take >> the vm approach and mark it -XX ? > > Yes, we should have ccc requests to cover any new flags and any > platform-specific flags. > > If a flag is generally sensible, I'd prefer to see the flag supported > across platforms. Yes I agree, a ccc needs to be filed asap, and IMO the awt team should be filing this, as they are aware of all the nuances of these flags. Thanks Kumar > > Cheers, > > -Joe > From david.holmes at oracle.com Tue Jan 17 18:52:14 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2012 12:52:14 +1000 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F15A353.7080802@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F1575F4.3060104@oracle.com> <4F15A353.7080802@oracle.COM> Message-ID: <4F1633DE.9030406@oracle.com> On 18/01/2012 2:35 AM, Kumar Srinivasan wrote: >> src/share/bin/java.c >>> 987 } else if (IsMacOSX() && JLI_StrCmp(arg, "-XstartOnFirstThread") >>> == 0) { >>> 988 ProcessSpecialArg(arg); >>> 989 } else if (IsMacOSX() && JLI_StrCCmp(arg, "-Xdock:") == 0) { >>> 990 ProcessSpecialArg(arg); > If we don't have those runtime checks then Windows, > Linux and Solaris will accept those flags without a fuss, so what should > the behavior be ? I think it should be possible to invoke a platform-specific argument parsing function to complement the shared options. Though for 7u leaving this ifdef'd to MACOSX should be fine. > Was a specification (ccc) filed for these flags ? Will this be > documented in the help > section ? though X flags are unsupported, in the past we have documented > them, both > in the man pages as well as "java -X", if these will be left > undocumented should we take > the vm approach and mark it -XX ? -XX should be reserved for VM flags > Yes it is a lot more readable, and yes it increases duplication , but we > already have some duplication between windows and unix. Since > this is platform specific code, and 7uX will go into maintenance mode, > the exposure will be limited. > > However, for jdk8 we need a hierarchical structure, as I heard some > noise about > restructuring the platform code, at that time it will be a good idea to > coalesce > these things, and remove the LD_LIBRARY_PATH cloaking in solaris/java_md.c > which is not relevant to MacOSX. In both the JDK and VM we have, in my opinion, reached the limits of how we handle multiple platforms without introducing (even more) excessive duplication. The main distinguishing factor for native code is "Windows or not-Windows", with some further distinctions arising in a few specific areas. To address that we need to refactor along those lines of difference. Unfortunately each time we add a new platform (OS or CPU) to the existing structure, we make that refactoring job in the future considerably more difficult and larger. David ----- >> >> Also, the major part of the JVMInit() function is identical on all >> three platforms - solaris/linux, macosx, and windows. It makes sense >> to define a function containing that code in the java.c and call it by >> platform-specific JVMInit() implementations where needed. > Yes this can be done, I will look into it. > > Kumar > >> >> -- >> best regards, >> Anthony >> >> On 1/17/2012 7:33 AM, Kumar Srinivasan wrote: >>> oops missed setting the subject line to 7ux-osx. >>> >>> Kumar >>> >>>> Hi, >>>> >>>> Please review the launcher refactoring work, the webrev is here: >>>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.0/ >>>> >>>> Notes: >>>> 1. Moves the majority of the launcher code into platform specific >>>> directories/files, >>>> removed redundant conditionals. >>>> >>>> 2. The solaris/linux code co-exists together as before. >>>> >>>> 3. On MacOSX, "java -client" will launch the server VM, for >>>> compatibility reasons, >>>> and dual mode is left in the macosx's java_md.c, this will enable >>>> experiments >>>> with universal libraries, quite easily. Also the mac ergonomics will >>>> always return >>>> server. >>>> >>>> Testing: >>>> Tested splash screen on all platforms and launcher regression tests. >>>> >>>> Thanks >>>> Kumar >>>> >>>> >>>> >>> > From peter.brunet at oracle.com Tue Jan 17 20:15:55 2012 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 17 Jan 2012 22:15:55 -0600 Subject: Please review patch for 7124306 Message-ID: <4F16477B.1050906@oracle.com> Regarding 628 == 7124306 http://java.net/jira/browse/MACOSX_PORT-628 http://monaco.us.oracle.com/detail.jsf?cr=7124306 Please review the fix that has been tested and is located here: http://cr.openjdk.java.net/~ptbrunet/7124306/webrev/ The fix is for this file: - JavaAccessibilityUtilities.m These two files only have changes to comments: - CGraphicsDevice.m - CMenuItem.m The webrev also contains the fix for 7124303 which has already been pushed so please ignore the patch to these two files: - AWTView.m - JavaComponentAccessibility.m From kumar.x.srinivasan at oracle.COM Tue Jan 17 20:25:32 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 17 Jan 2012 20:25:32 -0800 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F1633DE.9030406@oracle.com> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F1575F4.3060104@oracle.com> <4F15A353.7080802@oracle.COM> <4F1633DE.9030406@oracle.com> Message-ID: <4F1649BC.3090204@oracle.COM> > I think it should be possible to invoke a platform-specific argument > parsing function to complement the shared options. Though for 7u > leaving this ifdef'd to MACOSX should be fine. Yes I have addressed this in my repo, all runtime and compile time checks in java.c are history :). Will send a completed webrev after I am done with this. Thanks Kumar > >> Was a specification (ccc) filed for these flags ? Will this be >> documented in the help >> section ? though X flags are unsupported, in the past we have documented >> them, both >> in the man pages as well as "java -X", if these will be left >> undocumented should we take >> the vm approach and mark it -XX ? > > -XX should be reserved for VM flags > >> Yes it is a lot more readable, and yes it increases duplication , but we >> already have some duplication between windows and unix. Since >> this is platform specific code, and 7uX will go into maintenance mode, >> the exposure will be limited. >> >> However, for jdk8 we need a hierarchical structure, as I heard some >> noise about >> restructuring the platform code, at that time it will be a good idea to >> coalesce >> these things, and remove the LD_LIBRARY_PATH cloaking in >> solaris/java_md.c >> which is not relevant to MacOSX. > > In both the JDK and VM we have, in my opinion, reached the limits of > how we handle multiple platforms without introducing (even more) > excessive duplication. The main distinguishing factor for native code > is "Windows or not-Windows", with some further distinctions arising in > a few specific areas. To address that we need to refactor along those > lines of difference. Unfortunately each time we add a new platform (OS > or CPU) to the existing structure, we make that refactoring job in the > future considerably more difficult and larger. > > David > ----- > >>> >>> Also, the major part of the JVMInit() function is identical on all >>> three platforms - solaris/linux, macosx, and windows. It makes sense >>> to define a function containing that code in the java.c and call it by >>> platform-specific JVMInit() implementations where needed. >> Yes this can be done, I will look into it. >> >> Kumar >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/17/2012 7:33 AM, Kumar Srinivasan wrote: >>>> oops missed setting the subject line to 7ux-osx. >>>> >>>> Kumar >>>> >>>>> Hi, >>>>> >>>>> Please review the launcher refactoring work, the webrev is here: >>>>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.0/ >>>>> >>>>> Notes: >>>>> 1. Moves the majority of the launcher code into platform specific >>>>> directories/files, >>>>> removed redundant conditionals. >>>>> >>>>> 2. The solaris/linux code co-exists together as before. >>>>> >>>>> 3. On MacOSX, "java -client" will launch the server VM, for >>>>> compatibility reasons, >>>>> and dual mode is left in the macosx's java_md.c, this will enable >>>>> experiments >>>>> with universal libraries, quite easily. Also the mac ergonomics will >>>>> always return >>>>> server. >>>>> >>>>> Testing: >>>>> Tested splash screen on all platforms and launcher regression tests. >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>> >>>>> >>>> >> From lordpixel+openjdk at mac.com Tue Jan 17 20:28:20 2012 From: lordpixel+openjdk at mac.com (Andrew Thompson) Date: Tue, 17 Jan 2012 23:28:20 -0500 Subject: NSDeleteFunctionKey question In-Reply-To: <01190A4E-665A-405E-8533-97D859D4C7B4@oracle.com> References: <01190A4E-665A-405E-8533-97D859D4C7B4@oracle.com> Message-ID: <196BEAE4-23EA-424E-80D1-7B73F980666D@mac.com> On a Mac keyboard the 'delete' key acts like 'backspace' on a PC. The 'del' key over by the keypad (or fn+delete on a laptop) deletes to the *right* of the cursor. I assume this is the 'delete key on a PC keyboard' you mean? Ideally I think you want right-delete when this key is pressed. On Jan 17, 2012, at 9:26 AM, Leonid Romanov wrote: > Hi! > Apparently, pressing Delete key on a PC keyboard results in [event charactersIgnoringModifiers] having NSDeleteFunctionKey as a character, which seems to be from the unicode range reserved > for Apple. This is not what AWT expects. Is it OK to simply replace NSDeleteFunctionKey with NSDeleteCharacter before passing it up to AWT, or there is some additional Cocoa-fu required? > > Thanks, > Leonid. > From scott.kovatch at oracle.com Tue Jan 17 20:34:39 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 17 Jan 2012 20:34:39 -0800 Subject: Please review patch for 7124306 In-Reply-To: <4F16477B.1050906@oracle.com> References: <4F16477B.1050906@oracle.com> Message-ID: <28D354B2-A084-4C3F-A84E-F64BCB434477@oracle.com> This looks good to me. It was a simple typo/error in the process of converting from apple.awt to sun.lwawt.macosx. -- Scott On Jan 17, 2012, at 8:15 PM, Pete Brunet wrote: > Regarding 628 == 7124306 > http://java.net/jira/browse/MACOSX_PORT-628 > http://monaco.us.oracle.com/detail.jsf?cr=7124306 > > Please review the fix that has been tested and is located here: > http://cr.openjdk.java.net/~ptbrunet/7124306/webrev/ > > The fix is for this file: > - JavaAccessibilityUtilities.m > > These two files only have changes to comments: > - CGraphicsDevice.m > - CMenuItem.m > > The webrev also contains the fix for 7124303 which has already been > pushed so please ignore the patch to these two files: > - AWTView.m > - JavaComponentAccessibility.m From paul.hohensee at oracle.com Tue Jan 17 21:37:19 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Wed, 18 Jan 2012 05:37:19 +0000 Subject: hg: jdk7u/jdk7u-osx/hotspot: 78 new changesets Message-ID: <20120118053952.56131479B1@hg.openjdk.java.net> Changeset: 93189257531e Author: katleman Date: 2011-12-28 15:41 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/93189257531e Added tag jdk7u4-b06 for changeset b09b616c066f ! .hgtags Changeset: fe2c87649981 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/fe2c87649981 Added tag jdk8-b19 for changeset 9232e0ecbc2c ! .hgtags Changeset: 9952d1c439d6 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/9952d1c439d6 Added tag jdk8-b20 for changeset fe2c87649981 ! .hgtags Changeset: ed621d125d02 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/ed621d125d02 Added tag jdk8-b21 for changeset 9952d1c439d6 ! .hgtags Changeset: 0841c0ec2ed6 Author: amurillo Date: 2011-12-23 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/0841c0ec2ed6 7123810: new hotspot build - hs23-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3b2b58fb1425 Author: tonyp Date: 2011-12-20 12:59 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/3b2b58fb1425 7123165: G1: output during parallel verification can get messed up Summary: Serialize the worker threads that are generating output during parallel heap verification to make sure the output is consistent. Reviewed-by: brutisso, johnc, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: d15b458c4225 Author: jmasa Date: 2011-12-20 20:29 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/d15b458c4225 Merge Changeset: 67fdcb391461 Author: tonyp Date: 2011-12-21 07:53 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/67fdcb391461 7119027: G1: use atomics to update RS length / predict time of inc CSet Summary: Make sure that the updates to the RS length and inc CSet predicted time are updated in an MT-safe way. Reviewed-by: brutisso, iveresov ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 441e946dc1af Author: jmasa Date: 2011-12-14 13:34 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/441e946dc1af 7121618: Change type of number of GC workers to unsigned int. Summary: Change variables representing the number of GC workers to uint from int and size_t. Change the parameter in work(int i) to work(uint worker_id). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 1cbe7978b021 Author: brutisso Date: 2011-12-21 22:13 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/1cbe7978b021 7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx Summary: Use a percentage of -Xms as min and another percentage of -Xmx as max for the young gen size Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7faca6dfa2ed Author: jmasa Date: 2011-12-27 12:38 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/7faca6dfa2ed Merge ! src/share/vm/runtime/globals.hpp Changeset: 4ceaf61479fc Author: dcubed Date: 2011-12-22 12:50 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/4ceaf61479fc 7122253: Instrumentation.retransformClasses() leaks class bytes Summary: Change ClassFileParser::parseClassFile() to use the instanceKlass:_cached_class_file_bytes field to avoid leaking the cache. Reviewed-by: coleenp, acorn, poonam ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4ec93d767458 Author: vladidan Date: 2011-12-26 20:36 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/4ec93d767458 Merge Changeset: 3db6ea5ce021 Author: vladidan Date: 2011-12-29 20:09 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/3db6ea5ce021 Merge Changeset: 20bfb6d15a94 Author: iveresov Date: 2011-12-27 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/20bfb6d15a94 7124829: NUMA: memory leak on Linux with large pages Summary: In os::free_memory() use mmap with the same attributes as for the heap space Reviewed-by: kvn Contributed-by: Aleksey Ignatenko ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/runtime/os.hpp Changeset: 776173fc2df9 Author: stefank Date: 2011-12-29 07:37 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/776173fc2df9 7125516: G1: ~ConcurrentMark() frees incorrectly Summary: Replaced the code with a ShouldNotReachHere Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 5ee33ff9b1c4 Author: jmasa Date: 2012-01-03 10:22 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/5ee33ff9b1c4 Merge Changeset: 75c0a73eee98 Author: coleenp Date: 2011-11-17 12:53 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/75c0a73eee98 7102776: Pack instanceKlass boolean fields into single u1 field Summary: Reduce class runtime memory usage by packing 4 instanceKlass boolean fields into single u1 field. Save 4-byte for each loaded class. Reviewed-by: dholmes, bobv, phh, twisti, never, coleenp Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: da4dd142ea01 Author: bobv Date: 2011-11-29 14:44 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/da4dd142ea01 Merge ! src/share/vm/code/dependencies.cpp Changeset: 52b5d32fbfaf Author: coleenp Date: 2011-12-06 18:28 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/52b5d32fbfaf 7117052: instanceKlass::_init_state can be u1 type Summary: Change instanceKlass::_init_state field to u1 type. Reviewed-by: bdelsart, coleenp, dholmes, phh, never Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: eccc4b1f8945 Author: vladidan Date: 2011-12-07 16:47 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/eccc4b1f8945 7050298: ARM: SIGSEGV in JNIHandleBlock::allocate_handle Summary: missing release barrier in Monitor::IUnlock Reviewed-by: dholmes, dice ! src/share/vm/runtime/mutex.cpp Changeset: 2685ea97b89f Author: jiangli Date: 2011-12-09 11:29 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/2685ea97b89f Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: 8fdf463085e1 Author: jiangli Date: 2011-12-16 17:33 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/8fdf463085e1 Merge Changeset: dca455dea3a7 Author: bdelsart Date: 2011-12-20 12:33 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/dca455dea3a7 7116216: StackOverflow GC crash Summary: GC crash for explicit stack overflow checks after a C2I transition. Reviewed-by: coleenp, never Contributed-by: yang02.wang at sap.com, bertrand.delsart at oracle.com ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp + test/compiler/7116216/LargeFrame.java + test/compiler/7116216/StackOverflow.java Changeset: cd5d8cafcc84 Author: jiangli Date: 2011-12-28 12:15 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/cd5d8cafcc84 7123315: instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count should be u2 type. Summary: Change instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count to u2 type. Reviewed-by: never, bdelsart, dholmes Contributed-by: Jiangli Zhou ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 05de27e852c4 Author: jiangli Date: 2012-01-04 12:36 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/05de27e852c4 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: b6a04c79ccbc Author: stefank Date: 2012-01-02 10:01 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/b6a04c79ccbc 7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1 Summary: Used uintptr_t and void* for all the casts and checks in test_is_in. Reviewed-by: tonyp, jmasa ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 4753e3dda3c8 Author: jmasa Date: 2012-01-04 07:56 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/4753e3dda3c8 Merge Changeset: 2ee4167627a3 Author: jmasa Date: 2012-01-05 21:02 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/2ee4167627a3 Merge Changeset: 7ab5f6318694 Author: phh Date: 2012-01-01 11:17 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/7ab5f6318694 7125934: Add a fast unordered timestamp capability to Hotspot on x86/x64 Summary: Add rdtsc detection and inline generation. Reviewed-by: kamg, dholmes Contributed-by: karen.kinnear at oracle.com ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp + src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp + src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp + src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp + src/share/vm/runtime/os_ext.hpp Changeset: b16494a69d3d Author: phh Date: 2012-01-03 15:11 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/b16494a69d3d 7126185: Clean up lasterror handling, add os::get_last_error() Summary: Add os::get_last_error(), replace getLastErrorString() by os::lasterror() in os_windows.cpp. Reviewed-by: kamg, dholmes Contributed-by: erik.gahlin at oracle.com ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 5b58979183f9 Author: dcubed Date: 2012-01-05 06:24 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/5b58979183f9 7127032: fix for 7122253 adds a JvmtiThreadState earlier than necessary Summary: Use JavaThread::jvmti_thread_state() instead of JvmtiThreadState::state_for(). Reviewed-by: coleenp, poonam, acorn ! src/share/vm/classfile/classFileParser.cpp Changeset: 8a63c6323842 Author: fparain Date: 2012-01-05 07:26 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/8a63c6323842 7125594: C-heap growth issue in ThreadService::find_deadlocks_at_safepoint Reviewed-by: sspitsyn, dcubed, mchung, dholmes ! src/share/vm/services/threadService.cpp Changeset: 2e0ef19fc891 Author: phh Date: 2012-01-05 17:14 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/2e0ef19fc891 7126480: Make JVM start time in milliseconds since the Java epoch available Summary: Expose existing Management::_begin_vm_creation_time via new accessor Management::begin_vm_creation_time(). Reviewed-by: acorn, dcubed ! src/share/vm/services/management.hpp Changeset: 66259eca2bf7 Author: phh Date: 2012-01-05 17:16 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/66259eca2bf7 Merge Changeset: 2b3acb34791f Author: dcubed Date: 2012-01-06 16:18 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/2b3acb34791f Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/os.hpp Changeset: abcceac2f7cd Author: iveresov Date: 2011-12-12 12:44 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/abcceac2f7cd 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) Summary: Added handles for references to methods in select_task() Reviewed-by: twisti, kvn ! src/share/vm/runtime/advancedThresholdPolicy.cpp Changeset: 7bca37d28f32 Author: roland Date: 2011-12-13 10:54 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/7bca37d28f32 7114106: C1: assert(goto_state->is_same(sux_state)) failed: states must match now Summary: fix C1's CEE to take inlining into account when the stacks in states are compared. Reviewed-by: iveresov, never ! src/share/vm/c1/c1_Optimizer.cpp Changeset: d725f0affb1a Author: iveresov Date: 2011-12-13 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/d725f0affb1a 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler Summary: Exercise C2 more in tiered mode with Xcomp Reviewed-by: kvn, never ! src/share/vm/runtime/arguments.cpp Changeset: 127b3692c168 Author: kvn Date: 2011-12-14 14:54 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/127b3692c168 7116452: Add support for AVX instructions Summary: Added support for AVX extension to the x86 instruction set. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/runtime/globals.hpp Changeset: 669f6a7d5b70 Author: never Date: 2011-12-19 14:16 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/669f6a7d5b70 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type Reviewed-by: kvn ! src/share/vm/opto/compile.cpp Changeset: 65149e74c706 Author: kvn Date: 2011-12-20 00:55 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/65149e74c706 7121648: Use 3-operands SIMD instructions on x86 with AVX Summary: Use 3-operands SIMD instructions in C2 generated code for machines with AVX. Reviewed-by: never ! make/bsd/makefiles/adlc.make ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! make/windows/makefiles/adlc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp + src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/matcher.cpp Changeset: 069ab3f976d3 Author: stefank Date: 2011-12-07 11:35 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/069ab3f976d3 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions Summary: Moved sizeof(klassOopDesc), changed the return type to ByteSize and removed the _in_bytes suffix. Reviewed-by: never, bdelsart, coleenp, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 1dc233a8c7fe Author: roland Date: 2011-12-20 16:56 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/1dc233a8c7fe 7121140: Allocation paths require explicit memory synchronization operations for RMO systems Summary: adds store store barrier after initialization of header and body of objects. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp Changeset: e5ac210043cd Author: roland Date: 2011-12-22 10:55 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/e5ac210043cd 7123108: C1: assert(if_state != NULL) failed: states do not match up Summary: In CEE, ensure if and common successor state are at the same inline level Reviewed-by: never ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/7123108/Test7123108.java Changeset: b642b49f9738 Author: roland Date: 2011-12-23 09:36 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/b642b49f9738 7123253: C1: in store check code, usage of registers may be incorrect Summary: fix usage of input register in assembly code for store check. Reviewed-by: never ! src/share/vm/c1/c1_LIR.cpp Changeset: 40c2484c09e1 Author: kvn Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/40c2484c09e1 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM Summary: Distance is too large for one short branch in string_indexofC8(). Reviewed-by: iveresov ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: d12a66fa3820 Author: kvn Date: 2011-12-27 15:08 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/d12a66fa3820 7123954: Some CTW test crash with SIGSEGV Summary: Correct Allocate expansion code to preserve i_o when only slow call is generated. Reviewed-by: iveresov ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: 8940fd98d540 Author: kvn Date: 2011-12-29 11:37 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/8940fd98d540 Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9c87bcb3b4dd Author: kvn Date: 2011-12-30 11:43 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/9c87bcb3b4dd 7125879: assert(proj != NULL) failed: must be found Summary: Leave i_o attached to slow allocation call when there are no i_o users after the call. Reviewed-by: iveresov, twisti ! src/share/vm/opto/macro.cpp + test/compiler/7125879/Test7125879.java Changeset: 1cb50d7a9d95 Author: iveresov Date: 2012-01-05 17:25 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/1cb50d7a9d95 7119294: Two command line options cause JVM to crash Summary: Setup thread register in MacroAssembler::incr_allocated_bytes() on x64 Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 22cee0ee8927 Author: kvn Date: 2012-01-06 20:09 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/22cee0ee8927 Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp Changeset: 8f8b94305aff Author: dcubed Date: 2012-01-11 19:54 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/8f8b94305aff 7129240: backout fix for 7102776 until 7128770 is resolved Reviewed-by: phh, bobv, coleenp, dcubed Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 4f25538b54c9 Author: fparain Date: 2012-01-09 10:27 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/4f25538b54c9 7120511: Add diagnostic commands Reviewed-by: acorn, phh, dcubed, sspitsyn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp Changeset: 865e0817f32b Author: kamg Date: 2012-01-10 15:47 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/865e0817f32b Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: efdf6985a3a2 Author: kamg Date: 2012-01-12 09:59 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/efdf6985a3a2 Merge Changeset: 5da7201222d5 Author: kvn Date: 2012-01-07 10:39 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/5da7201222d5 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM Summary: Change yank_if_dead() to recursive method to remove all dead inputs. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: e9a5e0a812c8 Author: kvn Date: 2012-01-07 13:26 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/e9a5e0a812c8 7125896: Eliminate nested locks Summary: Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 35acf8f0a2e4 Author: kvn Date: 2012-01-10 18:05 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/35acf8f0a2e4 7128352: assert(obj_node == obj) failed Summary: Compare uncasted object nodes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/subnode.cpp ! test/compiler/7116216/StackOverflow.java Changeset: c8d8e124380c Author: kvn Date: 2012-01-12 12:28 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/c8d8e124380c 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app Summary: Don't split CMove node if it's control edge is different from split region. Reviewed-by: never ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 31a5b9aad4bc Author: jrose Date: 2012-01-13 00:27 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/31a5b9aad4bc Merge ! src/share/vm/runtime/arguments.cpp Changeset: bacb651cf5bf Author: tonyp Date: 2012-01-05 05:54 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/bacb651cf5bf 7113006: G1: excessive ergo output when an evac failure happens Summary: Introduce a flag that is set when a heap expansion attempt during a GC fails so that we do not consantly attempt to expand the heap when it's going to fail anyway. This not only prevents the excessive ergo output (which is generated when a region allocation fails) but also avoids excessive and ultimately unsuccessful expansion attempts. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 5fd354a959c5 Author: jmasa Date: 2012-01-05 21:21 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/5fd354a959c5 Merge Changeset: 023652e49ac0 Author: johnc Date: 2011-12-23 11:14 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/023652e49ac0 7121496: G1: do the per-region evacuation failure handling work in parallel Summary: Parallelize the removal of self forwarding pointers etc. by wrapping in a HeapRegion closure, which is then wrapped inside an AbstractGangTask. Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp + src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 02838862dec8 Author: tonyp Date: 2012-01-07 00:43 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/02838862dec8 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array Summary: Store the "next chunk start index" in the length field of the to-space object, instead of the from-space object, so that we can always reliably read the size of all from-space objects. Reviewed-by: johnc, ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 97c00e21fecb Author: tonyp Date: 2012-01-09 23:50 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/97c00e21fecb 7125281: G1: heap expansion code is replicated Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 1d6185f732aa Author: brutisso Date: 2012-01-10 20:02 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/1d6185f732aa 7128532: G1: Change default value of G1DefaultMaxNewGenPercent to 80 Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2ace1c4ee8da Author: tonyp Date: 2012-01-10 18:58 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/2ace1c4ee8da 6888336: G1: avoid explicitly marking and pushing objects in survivor spaces Summary: This change simplifies the interaction between GC and concurrent marking. By disabling survivor spaces during the initial-mark pause we don't need to propagate marks of objects we copy during each GC (since we never need to copy an explicitly marked object). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 9d4f4a1825e4 Author: brutisso Date: 2012-01-13 01:55 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/9d4f4a1825e4 Merge Changeset: 5acd82522540 Author: brutisso Date: 2012-01-13 06:18 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/5acd82522540 Merge Changeset: b0ff910edfc9 Author: kvn Date: 2012-01-12 14:45 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/b0ff910edfc9 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed Summary: Do not common BoxLock nodes and avoid creating phis of boxes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp Changeset: f4d8930a45b9 Author: jrose Date: 2012-01-13 00:51 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/f4d8930a45b9 Merge Changeset: 89d0a5d40008 Author: kvn Date: 2012-01-13 12:58 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/89d0a5d40008 7129618: assert(obj_node->eqv_uncast(obj),""); Summary: Relax verification and locks elimination checks for new implementation (EliminateNestedLocks). Reviewed-by: iveresov ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp Changeset: e504fd26c073 Author: kvn Date: 2012-01-13 14:21 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/e504fd26c073 Merge Changeset: 513351373923 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/513351373923 Merge Changeset: 24727fb37561 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/24727fb37561 Added tag hs23-b10 for changeset 513351373923 ! .hgtags Changeset: 3804879a5ea0 Author: amurillo Date: 2012-01-14 01:07 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/3804879a5ea0 Merge ! .hgtags ! make/hotspot_version ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp Changeset: 368b50d32f57 Author: phh Date: 2012-01-17 18:49 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/368b50d32f57 Merge ! .hgtags From anton.tarasov at oracle.com Wed Jan 18 00:53:05 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 18 Jan 2012 11:53:05 +0300 Subject: [7u-osx] Request for approval for CR 7124430 - [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet Message-ID: <4F168871.2050309@oracle.com> Hello, A request to push the changes to jdk7u-osx. Reviewed on macosx-port-dev by Anthony Petrov & Artem Ananiev. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124430 Webrev: http://cr.openjdk.java.net/~ant/7124430/webrev.3/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002252.html Thanks, Anton. From michael.x.mcmahon at oracle.com Wed Jan 18 02:55:20 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 18 Jan 2012 10:55:20 +0000 Subject: [jdk7u-osx] Review: 7130948 Kerberos and JGSS JCK tests failing [macosx] Message-ID: <4F16A518.6020101@oracle.com> Could I get the following change reviewed please? The code should be throwing an IOException which can be handled by the immediate caller, rather than higher up the stack as a KrbException. http://cr.openjdk.java.net/~michaelm/7130948/webrev.1/ Thanks, Michael. From artem.ananiev at oracle.com Wed Jan 18 03:05:50 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 18 Jan 2012 15:05:50 +0400 Subject: [7u-osx] Request for approval for CR 7124430 - [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet In-Reply-To: <4F168871.2050309@oracle.com> References: <4F168871.2050309@oracle.com> Message-ID: <4F16A78E.6000909@oracle.com> Approved. On 1/18/2012 12:53 PM, Anton V. Tarasov wrote: > Hello, > > A request to push the changes to jdk7u-osx. > Reviewed on macosx-port-dev by Anthony Petrov & Artem Ananiev. > > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124430 > Webrev: http://cr.openjdk.java.net/~ant/7124430/webrev.3/ > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002252.html > > > Thanks, > Anton. From artem.ananiev at oracle.com Wed Jan 18 03:18:20 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 18 Jan 2012 15:18:20 +0400 Subject: [jdk7u-osx] Request for approval for 7125456: [macosx] Programmatically selecting List item triggers an ItemEvent In-Reply-To: <4F15BD3A.7030903@oracle.com> References: <4F15BD3A.7030903@oracle.com> Message-ID: <4F16AA7C.1050308@oracle.com> Approved. On 1/17/2012 10:26 PM, Alexander Potochkin wrote: > This is a request to push the following fix to jdk7u-osx: > http://cr.openjdk.java.net/~alexp/7125456/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125456 > > the fix was approved by anthony.petrov and sergey.bylokhov > > Thanks > alexp From paul.hohensee at oracle.com Wed Jan 18 05:01:17 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 18 Jan 2012 08:01:17 -0500 Subject: sync: jdk7u-dev/hotspot => jdk7u-osx/hotspot Message-ID: <4F16C29D.20207@oracle.com> fyi, I've pulled the latest just-integrated-into-jdk7u-dev version of hotspot down from jdk7u-dev into jdk7u-osx. Paul From daniel.daugherty at oracle.com Wed Jan 18 06:47:37 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 18 Jan 2012 07:47:37 -0700 Subject: sync: jdk7u-dev/hotspot => jdk7u-osx/hotspot In-Reply-To: <4F16C29D.20207@oracle.com> References: <4F16C29D.20207@oracle.com> Message-ID: <4F16DB89.8010706@oracle.com> Thanks Paul! Dan On 1/18/12 6:01 AM, Paul Hohensee wrote: > fyi, I've pulled the latest just-integrated-into-jdk7u-dev version of > hotspot > down from jdk7u-dev into jdk7u-osx. > > Paul > > From anthony.petrov at oracle.com Wed Jan 18 07:02:04 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 18 Jan 2012 19:02:04 +0400 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F16134A.2050207@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F1575F4.3060104@oracle.com> <4F15A353.7080802@oracle.COM> <4F160C48.2070606@oracle.com> <4F16134A.2050207@oracle.COM> Message-ID: <4F16DEEC.6090107@oracle.com> On 1/18/2012 4:33 AM, Kumar Srinivasan wrote: >>> Was a specification (ccc) filed for these flags ? Will this be >>> documented in the help >>> section ? though X flags are unsupported, in the past we have >>> documented them, both >>> in the man pages as well as "java -X", if these will be left >>> undocumented should we take >>> the vm approach and mark it -XX ? >> >> Yes, we should have ccc requests to cover any new flags and any >> platform-specific flags. >> >> If a flag is generally sensible, I'd prefer to see the flag supported >> across platforms. > > Yes I agree, a ccc needs to be filed asap, and IMO the awt team should > be filing this, as they are aware of all the nuances of these flags. I've filed 7131038 to address this. Joe, do you think it absolutely needs an official -help output and a CCC approval in 7u4 time-frame, or could it wait till e.g. 7u6? -- best regards, Anthony > > Thanks > Kumar > >> >> Cheers, >> >> -Joe >> > From anthony.petrov at oracle.com Wed Jan 18 07:03:10 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 18 Jan 2012 19:03:10 +0400 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F160C48.2070606@oracle.com> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F1575F4.3060104@oracle.com> <4F15A353.7080802@oracle.COM> <4F160C48.2070606@oracle.com> Message-ID: <4F16DF2E.7040204@oracle.com> On 1/18/2012 4:03 AM, Joseph Darcy wrote: > If a flag is generally sensible, I'd prefer to see the flag supported > across platforms. Neither of the flags make sense on platforms other than the Mac at the moment. -- best regards, Anthony From michael.x.mcmahon at oracle.com Wed Jan 18 07:56:54 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 18 Jan 2012 15:56:54 +0000 Subject: Code Review Request: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X In-Reply-To: <4F15C59F.5000009@oracle.com> References: <4F0DDFEF.4000908@oracle.com> <4F108E99.7030903@oracle.com> <4F1090C0.10501@oracle.com> <4F109BE2.9000101@oracle.com> <4F13FF6B.7080403@oracle.com> <4F15C59F.5000009@oracle.com> Message-ID: <4F16EBC6.3070409@oracle.com> Looks fine. - Michael. On 17/01/12 19:01, Kurchi Hazra wrote: > I updated the comment: > http://cr.openjdk.java.net/~khazra/7127771/webrev.02/ > > - Kurchi > > > > On 1/16/2012 2:43 AM, Michael McMahon wrote: >> Yes, looks fine to me too. I would just update the comment above this >> code to add Mac OS to the Solaris case. >> >> Thanks >> Michael >> >> On 13/01/12 21:02, Kurchi Hazra wrote: >>> How does this look: >>> http://cr.openjdk.java.net/~khazra/7127771/webrev.01/ >>> >>> - Kurchi >>> >>> >>> >>> On 1/13/2012 12:14 PM, Alan Bateman wrote: >>>> >>>>>> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127771 >>>>>> Webrev : http://cr.openjdk.java.net/~khazra/7127771/webrev.00/ >>>> What you have is fine although you could combine with the Solaris >>>> code? Should the __ALLBSD_SOURCE XXX be removed while you are there? >>>> >>>> -Alan >>> >> > From michael.x.mcmahon at oracle.com Wed Jan 18 08:15:56 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 18 Jan 2012 16:15:56 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7127874: Add handling of MacOSX env variables to ProcessBuilder regression test Message-ID: <20120118161606.CDC28479BC@hg.openjdk.java.net> Changeset: d0a56328cb69 Author: juh Date: 2012-01-18 16:15 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d0a56328cb69 7127874: Add handling of MacOSX env variables to ProcessBuilder regression test Reviewed-by: michaelm ! test/java/lang/ProcessBuilder/Basic.java From michael.x.mcmahon at oracle.com Wed Jan 18 08:24:16 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 18 Jan 2012 16:24:16 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7127448: Regression test scripts for policytool need to recognize Mac OS X Message-ID: <20120118162426.9A893479BD@hg.openjdk.java.net> Changeset: dbd828ae28db Author: juh Date: 2012-01-18 16:23 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/dbd828ae28db 7127448: Regression test scripts for policytool need to recognize Mac OS X Reviewed-by: michaelm, swingler, weijun ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.sh From alexander.potochkin at sun.com Wed Jan 18 08:26:52 2012 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Wed, 18 Jan 2012 16:26:52 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7125456: [macosx] Programmatically selecting List item triggers an ItemEvent Message-ID: <20120118162702.94C74479BE@hg.openjdk.java.net> Changeset: dfa991721457 Author: alexp Date: 2012-01-18 20:49 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/dfa991721457 7125456: [macosx] Programmatically selecting List item triggers an ItemEvent Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/LWListPeer.java From roger.yeung at oracle.com Wed Jan 18 09:25:18 2012 From: roger.yeung at oracle.com (Roger Yeung) Date: Wed, 18 Jan 2012 09:25:18 -0800 Subject: JDK 7 Mac Port Preview b225 Available Message-ID: <4F17007E.9010306@oracle.com> Hi, The JDK 7 Mac Port Preview b225 is now available: http://jdk7.java.net/macportpreview/ Regards, Roger Y. From Alexander.Potochkin at oracle.com Wed Jan 18 09:55:55 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Wed, 18 Jan 2012 21:55:55 +0400 Subject: Review request for 7122246: [macosx] JCK swing test CaretTests fails in b205 Message-ID: <4F1707AB.60906@oracle.com> Hello Please review the following fix: http://cr.openjdk.java.net/~alexp/7122246/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122246 I removed the setter which ignores the parameter for multiline editors and made sure that I keep the selection when the focus is lost please refer to the javax.swing.DefaultCaret.focusLost() method Thanks alexp From michael.x.mcmahon at oracle.com Wed Jan 18 10:06:56 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 18 Jan 2012 18:06:56 +0000 Subject: Code review: 7126979 (props) JCK test java_lang/System/GetProperties.java failing [macosx] In-Reply-To: <4F0ED9E5.9070800@oracle.com> References: <4F0EC260.1050605@oracle.com> <4F0EC988.5030405@oracle.com> <4F0ED6BC.3070405@oracle.com> <4F0ED9E5.9070800@oracle.com> Message-ID: <4F170A40.3080004@oracle.com> On 12/01/12 13:02, David Holmes wrote: > On 12/01/2012 10:49 PM, Michael McMahon wrote: >> Thanks David. Just found it now (Alan noticed it too). Scott sent his >> webrev yesterday. >> >> It looks like both solutions fix the problem. The difference is that >> Scott's re-initializes >> the properties from native code each time System.initProperties() is >> called. >> On the other platforms, we only call it once. >> >> So, do we want Macos to diverge slightly from the other platforms in >> this respect? > > I haven't compared things in detail but If there is no need to diverge > then I would not diverge. > I've discussed this with Scott and we're agreed we will go with the minimal change to the shared code to begin with. I have created a CR (7131142) to track providing what the Apple code did originally, which was that it dynamically updates the system proxy properties. The best way to do this is through the DefaultProxySelector class rather than in the common property initialization code though. - Michael. > David > ----- > >> My preference is to keep the platforms as similar as possible, >> minimising the changes >> with jdk7u ... >> >> - Michael. >> >> On 12/01/12 11:52, David Holmes wrote: >>> Michael, >>> >>> There was a different patch for this posted earlier today where the >>> props fields were all nulled out so they didn't reference the freed >>> locations amy more. (I didn't keep the email) >>> >>> ??? >>> >>> David >>> >>> On 12/01/2012 9:22 PM, Michael McMahon wrote: >>>> Could I get the following change for jdk7u-osx reviewed please? >>>> >>>> http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/ >>>> >>>> The freeProps() call added by mac port can only be called once. Issue >>>> seen if System.setProperties(null) is called. >>>> GetJavaProperties() called a second time, which is supposed to return >>>> the statically populated information >>>> from first call. But some of it has been freed already. >>>> >>>> Fix is to remove the freeProps() code added in the original port >>>> changeset. The fix reverts the mac specific code >>>> to the original version. >>>> >>>> - Michael >>>> >> From kurchi.subhra.hazra at oracle.com Wed Jan 18 10:42:46 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 18 Jan 2012 10:42:46 -0800 Subject: [7u4-osx] Request for approval for 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X Message-ID: <4F1712A6.8010005@oracle.com> This is a request to push the following fix to jdk7u-osx: CR:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127771 Webrev:http://cr.openjdk.java.net/~khazra/7127771/webrev.02/ Reviewed by: alanb, michaelm This changeset will be pushed on my behalf by Michael McMahon (michaelm). Thanks, Kurchi From paul.hohensee at oracle.com Wed Jan 18 11:05:00 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 18 Jan 2012 14:05:00 -0500 Subject: [7u4-osx] Request for approval for 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X In-Reply-To: <4F1712A6.8010005@oracle.com> References: <4F1712A6.8010005@oracle.com> Message-ID: <4F1717DC.40103@oracle.com> In NET_Bind(), arg1 and len1 are newly defined, but there are no uses of arg1 beyond the new code, and no uses at all of len1. Perhaps there's a glitch in the webrev? Paul On 1/18/12 1:42 PM, Kurchi Hazra wrote: > > > This is a request to push the following fix to jdk7u-osx: > > CR:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127771 > > Webrev:http://cr.openjdk.java.net/~khazra/7127771/webrev.02/ > > Reviewed by: alanb, michaelm > > This changeset will be pushed on my behalf by Michael McMahon (michaelm). > > Thanks, > Kurchi > From sean.mullan at oracle.com Wed Jan 18 11:08:38 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 Jan 2012 14:08:38 -0500 Subject: [jdk7u-osx] Review: 7130948 Kerberos and JGSS JCK tests failing [macosx] In-Reply-To: <4F16A518.6020101@oracle.com> References: <4F16A518.6020101@oracle.com> Message-ID: <4F1718B6.7030502@oracle.com> On 01/18/2012 05:55 AM, Michael McMahon wrote: > Could I get the following change reviewed please? > > The code should be throwing an IOException which can be handled > by the immediate caller, rather than higher up the stack as a KrbException. > > http://cr.openjdk.java.net/~michaelm/7130948/webrev.1/ Looks fine, assuming sun.security.krb5.Config() is the only caller of this API - I didn't check. Also the syntax using parens around the new statement is obscure and doesn't seem to add anything: throw(new IOException("Could not load configuration from SCDynamicStore")); I'd suggest just: throw new IOException("Could not load configuration from SCDynamicStore"); --Sean From kurchi.subhra.hazra at oracle.com Wed Jan 18 11:20:14 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 18 Jan 2012 11:20:14 -0800 Subject: [7u4-osx] Request for approval for 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X In-Reply-To: <4F1717DC.40103@oracle.com> References: <4F1712A6.8010005@oracle.com> <4F1717DC.40103@oracle.com> Message-ID: <4F171B6E.5000404@oracle.com> Indeed. Thanks for pointing that out. Webrev: http://cr.openjdk.java.net/~khazra/7127771/webrev.03/ - Kurchi On 1/18/2012 11:05 AM, Paul Hohensee wrote: > In NET_Bind(), arg1 and len1 are newly defined, but there are no uses > of arg1 beyond the new code, and no uses at all of len1. > > Perhaps there's a glitch in the webrev? > > Paul > > On 1/18/12 1:42 PM, Kurchi Hazra wrote: >> >> >> This is a request to push the following fix to jdk7u-osx: >> >> CR:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127771 >> >> Webrev:http://cr.openjdk.java.net/~khazra/7127771/webrev.02/ >> >> Reviewed by: alanb, michaelm >> >> This changeset will be pushed on my behalf by Michael McMahon >> (michaelm). >> >> Thanks, >> Kurchi >> -- -Kurchi From paul.hohensee at oracle.com Wed Jan 18 11:20:41 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 18 Jan 2012 14:20:41 -0500 Subject: [7u4-osx] Request for approval for 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X In-Reply-To: <4F171B6E.5000404@oracle.com> References: <4F1712A6.8010005@oracle.com> <4F1717DC.40103@oracle.com> <4F171B6E.5000404@oracle.com> Message-ID: <4F171B89.5020605@oracle.com> Good to go. Approved. Paul On 1/18/12 2:20 PM, Kurchi Hazra wrote: > Indeed. Thanks for pointing that out. > > Webrev: http://cr.openjdk.java.net/~khazra/7127771/webrev.03/ > > > - Kurchi > > On 1/18/2012 11:05 AM, Paul Hohensee wrote: >> In NET_Bind(), arg1 and len1 are newly defined, but there are no uses >> of arg1 beyond the new code, and no uses at all of len1. >> >> Perhaps there's a glitch in the webrev? >> >> Paul >> >> On 1/18/12 1:42 PM, Kurchi Hazra wrote: >>> >>> >>> This is a request to push the following fix to jdk7u-osx: >>> >>> CR:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127771 >>> >>> Webrev:http://cr.openjdk.java.net/~khazra/7127771/webrev.02/ >>> >>> Reviewed by: alanb, michaelm >>> >>> This changeset will be pushed on my behalf by Michael McMahon >>> (michaelm). >>> >>> Thanks, >>> Kurchi >>> > From Alan.Bateman at oracle.com Wed Jan 18 11:25:15 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Jan 2012 19:25:15 +0000 Subject: [7u4-osx] Request for approval for 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X In-Reply-To: <4F1717DC.40103@oracle.com> References: <4F1712A6.8010005@oracle.com> <4F1717DC.40103@oracle.com> Message-ID: <4F171C9B.9000505@oracle.com> On 18/01/2012 19:05, Paul Hohensee wrote: > In NET_Bind(), arg1 and len1 are newly defined, but there are no uses > of arg1 beyond the new code, and no uses at all of len1. > > Perhaps there's a glitch in the webrev? > > Paul There wasn't any changes to NET_Bind in the original review so I suspect patches have got mixed up too. -Alan. From swingler at apple.com Wed Jan 18 11:35:05 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 18 Jan 2012 11:35:05 -0800 Subject: Review request for 7122246: [macosx] JCK swing test CaretTests fails in b205 In-Reply-To: <4F1707AB.60906@oracle.com> References: <4F1707AB.60906@oracle.com> Message-ID: <0114DF73-FF42-4390-B6B1-7AE7E4224B30@apple.com> On Jan 18, 2012, at 9:55 AM, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7122246/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122246 > > I removed the setter which ignores the parameter for multiline editors > and made sure that I keep the selection when the focus is lost > > please refer to the javax.swing.DefaultCaret.focusLost() method I've tested this fix and it looks good (the caret and selection behave as expected in both single-line and multi-line editors when the window transitions between the background and the foreground). Cheers, Mike Swingler Apple Inc. From bino at apple.com Wed Jan 18 12:54:59 2012 From: bino at apple.com (Bino George) Date: Wed, 18 Jan 2012 12:54:59 -0800 Subject: [jdk7u-osx] Review: 7130948 Kerberos and JGSS JCK tests failing [macosx] In-Reply-To: <4F16A518.6020101@oracle.com> References: <4F16A518.6020101@oracle.com> Message-ID: Hi Michael, The change looks fine to me. Thanks, Bino. On Jan 18, 2012, at 2:55 AM, Michael McMahon wrote: > Could I get the following change reviewed please? > > The code should be throwing an IOException which can be handled > by the immediate caller, rather than higher up the stack as a KrbException. > > http://cr.openjdk.java.net/~michaelm/7130948/webrev.1/ > > Thanks, > Michael. > > From anton.tarasov at oracle.com Thu Jan 19 02:58:28 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 19 Jan 2012 13:58:28 +0300 Subject: Review request for 7125491 - [macosx] Regression: A component can get unexpected keyTyped event. Message-ID: <4F17F754.4050501@oracle.com> Hello, Please review a simple fix for 7125491. webrev: http://cr.openjdk.java.net/~ant/7125491/webrev.0/ Synthesized KEY_TYPED event should have the same time stamp as its casual KEY_PRESSED event. Otherwise, KEY_TYPED may be dispatched to a component different from the one the key was pressed on. (Please, find the details in the Evaluation of the CR.) Thanks, Anton. From sergey.bylokhov at oracle.com Thu Jan 19 04:54:04 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 19 Jan 2012 16:54:04 +0400 Subject: [7u4-osx] Request for approval for 7124524 - OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer Message-ID: <4F18126C.6000401@oracle.com> Hello, This is a request to push the following changes to jdk7u-osx. The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124524/webrev.00/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002241.html -- Best regards, Sergey. From anthony.petrov at oracle.com Thu Jan 19 05:50:15 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 19 Jan 2012 17:50:15 +0400 Subject: Review request for 7125491 - [macosx] Regression: A component can get unexpected keyTyped event. In-Reply-To: <4F17F754.4050501@oracle.com> References: <4F17F754.4050501@oracle.com> Message-ID: <4F181F97.20708@oracle.com> Looks fine. -- best regards, Anthony On 01/19/12 14:58, Anton V. Tarasov wrote: > Hello, > > Please review a simple fix for 7125491. > > webrev: http://cr.openjdk.java.net/~ant/7125491/webrev.0/ > > Synthesized KEY_TYPED event should have the same time stamp > as its casual KEY_PRESSED event. Otherwise, KEY_TYPED may be > dispatched to a component different from the one the key was > pressed on. > > (Please, find the details in the Evaluation of the CR.) > > Thanks, > Anton. > > From leonid.romanov at oracle.com Thu Jan 19 06:45:08 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 19 Jan 2012 18:45:08 +0400 Subject: Review request for 7130751: [macosx] EventTest0020 test fails in JCK-runtime-7 interactive Message-ID: <78DA6865-EA96-47D2-8274-9DEA5E13E29E@oracle.com> Hi, Please review a small fix for http://monaco.us.oracle.com/detail.jsf?cr=7130751 The fix makes sure that key events for Fn and other non-printable keys have KeyEvent.CHAR_UNDEFINED as a character. webrev: http://cr.openjdk.java.net/~leonidr/7130751/webrev.00/ Thanks, Leonid. From michael.x.mcmahon at oracle.com Thu Jan 19 06:42:52 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 19 Jan 2012 14:42:52 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X Message-ID: <20120119144303.4D54F479EC@hg.openjdk.java.net> Changeset: d2494547f2d7 Author: khazra Date: 2012-01-19 14:42 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d2494547f2d7 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X Reviewed-by: michaelm, alanb, phh ! src/solaris/native/java/net/net_util_md.c From dmitry.cherepanov at oracle.com Thu Jan 19 08:15:33 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Thu, 19 Jan 2012 19:15:33 +0300 Subject: Review request for 7130751: [macosx] EventTest0020 test fails in JCK-runtime-7 interactive In-Reply-To: <78DA6865-EA96-47D2-8274-9DEA5E13E29E@oracle.com> References: <78DA6865-EA96-47D2-8274-9DEA5E13E29E@oracle.com> Message-ID: <4F1841A5.5030302@oracle.com> Looks fine to me. Thanks, Dmitry Leonid Romanov wrote: > Hi, > Please review a small fix for http://monaco.us.oracle.com/detail.jsf?cr=7130751 > > The fix makes sure that key events for Fn and other non-printable keys have KeyEvent.CHAR_UNDEFINED as a character. > > webrev: http://cr.openjdk.java.net/~leonidr/7130751/webrev.00/ > > Thanks, > Leonid. > > From artem.ananiev at oracle.com Thu Jan 19 09:12:00 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 19 Jan 2012 21:12:00 +0400 Subject: References to Apple JDK internal classes from other projects Message-ID: <4F184EE0.9090902@oracle.com> Hi, Mike et al., I'm often contacted from other teams and projects about JDK7 on Mac. At the current moment, at least two requests are about Apple classes that are missed in Oracle JDK: Java3D: they reference apple.awt.CGraphicsDevice SWT: they use apple.awt.CEmbeddedFrame to embed Swing content I would expect many other Mac OS X applications written in Java to rely on classes like these. Quick search for "import apple.awt" in Google shows at least 2 projects in top 10 results. There are several options, but none of them looks perfect: 1. Force application developers to fork their code to run with JDK6 and JDK7+ 2. Re-implement all the Apple classes in JDK7 (and place them to the same package?) It may be very hard, if possible at all, to preserve exactly the same behavior, though. 3. Add more APIs to com.apple.eawt both in JDK6 and JDK7 to use instead of direct references to Apple classes. What about classes that are not related to AWT? 4. Ignore such requests as all the applications relying on apple.*, or sun.*, or whatever else packages can be declared "unsupported". Your ideas? Thanks, Artem From leonid.romanov at oracle.com Thu Jan 19 08:13:41 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 19 Jan 2012 20:13:41 +0400 Subject: [7u-osx] Request for approval for CR 7130751: [macosx] EventTest0020 test fails in JCK-runtime-7 interactive Message-ID: Hi, This a request to push the following changes to jdk7u-osx. CR: http://monaco.us.oracle.com/detail.jsf?cr=7130751 Webrev: http://cr.openjdk.java.net/~leonidr/7130751/webrev.00 The fix has been reviewed on macosx-port-dev mailing list by Dmitry Cherepanov. Thanks, Leonid. From artem.ananiev at oracle.com Thu Jan 19 09:13:40 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 19 Jan 2012 21:13:40 +0400 Subject: [7u4-osx] Request for approval for 7124524 - OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer In-Reply-To: <4F18126C.6000401@oracle.com> References: <4F18126C.6000401@oracle.com> Message-ID: <4F184F44.3020204@oracle.com> Approved. On 1/19/2012 4:54 PM, Sergey Bylokhov wrote: > Hello, > This is a request to push the following changes to jdk7u-osx. > The fix has been reviewed on macosx-port-dev mailing list by Anthony > Petrov. > > Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124524/webrev.00/ > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002241.html > > From artem.ananiev at oracle.com Thu Jan 19 09:14:37 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 19 Jan 2012 21:14:37 +0400 Subject: Review request for 7125491 - [macosx] Regression: A component can get unexpected keyTyped event. In-Reply-To: <4F17F754.4050501@oracle.com> References: <4F17F754.4050501@oracle.com> Message-ID: <4F184F7D.5000300@oracle.com> Looks fine. Thanks, Artem On 1/19/2012 2:58 PM, Anton V. Tarasov wrote: > Hello, > > Please review a simple fix for 7125491. > > webrev: http://cr.openjdk.java.net/~ant/7125491/webrev.0/ > > Synthesized KEY_TYPED event should have the same time stamp > as its casual KEY_PRESSED event. Otherwise, KEY_TYPED may be > dispatched to a component different from the one the key was > pressed on. > > (Please, find the details in the Evaluation of the CR.) > > Thanks, > Anton. > > From Alexander.Potochkin at oracle.com Thu Jan 19 10:43:25 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 19 Jan 2012 22:43:25 +0400 Subject: Review request for 7130935: [macosx] Still, JSpinner 4656590 regression Message-ID: <4F18644D.3030403@oracle.com> Hello Please review the following fix: http://cr.openjdk.java.net/~alexp/7130935/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130935 The test case sets the font to JSpinner and then checks if the font from the DefaultEditor's textField is the same, attached In this fix I copied the missing block of code from the javax.swing.plaf.basic.BasicSpinnerUI class, lines 988-990 Thanks alexp -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: MyTest.java Url: http://mail.openjdk.java.net/pipermail/macosx-port-dev/attachments/20120119/d1809f77/MyTest.java From Alexander.Potochkin at oracle.com Thu Jan 19 10:46:32 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 19 Jan 2012 22:46:32 +0400 Subject: [jdk7u-osx] Request for approval for 7122246: [macosx] JCK swing test CaretTests fails in b205 Message-ID: <4F186508.9060108@oracle.com> This is a request to push the following fix to jdk7u-osx: http://cr.openjdk.java.net/~alexp/7122246/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122246 the fix was approved by swingler Thanks alexp From swingler at apple.com Thu Jan 19 10:55:28 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 19 Jan 2012 10:55:28 -0800 Subject: Review request for 7130935: [macosx] Still, JSpinner 4656590 regression In-Reply-To: <4F18644D.3030403@oracle.com> References: <4F18644D.3030403@oracle.com> Message-ID: On Jan 19, 2012, at 10:43 AM, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7130935/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130935 > > The test case sets the font to JSpinner and then checks > if the font from the DefaultEditor's textField is the same, attached > > In this fix I copied the missing block of code > from the javax.swing.plaf.basic.BasicSpinnerUI class, lines 988-990 > > Thanks > alexp > Looks good. Thanks, Mike Swingler Apple Inc. From kurchi.subhra.hazra at oracle.com Thu Jan 19 10:56:40 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 19 Jan 2012 10:56:40 -0800 Subject: Code Review Request: 7126993: JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] Message-ID: <4F186768.8070608@oracle.com> Hi, JCK tests api/java_util/jar/Jarfile and api/java_util/zip/ZipFile were both failing on Mac because the OPEN_DELETE flag sets the JVM_O_DELETE flag in native code, and the value of JVM_O_DELETE was changed from 0x10000 to0x10000000 for Mac OS. The JVM_O_DELETE flag is only used in src/share/native/java/util/zip/ZipFile.c and hence this change should be safe. Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126993 Webrev : http://cr.openjdk.java.net/~khazra/7126993/webrev.00/ Thanks, Kurchi From Alan.Bateman at oracle.com Thu Jan 19 11:18:53 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Jan 2012 19:18:53 +0000 Subject: Code Review Request: 7126993: JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] In-Reply-To: <4F186768.8070608@oracle.com> References: <4F186768.8070608@oracle.com> Message-ID: <4F186C9D.1070909@oracle.com> On 19/01/2012 18:56, Kurchi Hazra wrote: > > Hi, > > JCK tests api/java_util/jar/Jarfile and api/java_util/zip/ZipFile were > both failing > on Mac because the OPEN_DELETE flag sets the JVM_O_DELETE flag in > native code, and the > value of JVM_O_DELETE was changed from 0x10000 to0x10000000 for Mac OS. > The JVM_O_DELETE flag is only used in > src/share/native/java/util/zip/ZipFile.c > and hence this change should be safe. > > > Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126993 > > Webrev : http://cr.openjdk.java.net/~khazra/7126993/webrev.00/ At some point we need to change the zip and other code so that it's not using the JVM_ functions (not needed anymore). I checked os_bsd.cpp and O_DELETE is defined as 0x10000 so this is the value that JVM_O_DELETE needs to have in jvm_md.d. I don't know why it was changed to 0x10000000 but it must have had a corresponding change in HotSpot at one point. -Alan. From swingler at apple.com Thu Jan 19 11:23:41 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 19 Jan 2012 11:23:41 -0800 Subject: References to Apple JDK internal classes from other projects In-Reply-To: <4F184EE0.9090902@oracle.com> References: <4F184EE0.9090902@oracle.com> Message-ID: <4058A02C-3E87-48BD-B24F-C5C50FDED07F@apple.com> On Jan 19, 2012, at 9:12 AM, Artem Ananiev wrote: > Hi, Mike et al., > > I'm often contacted from other teams and projects about JDK7 on Mac. At the current moment, at least two requests are about Apple classes that are missed in Oracle JDK: > > Java3D: they reference apple.awt.CGraphicsDevice > SWT: they use apple.awt.CEmbeddedFrame to embed Swing content Java3D and SWT both are cases of embedding, which is by necessity a native operation to get correct when hosted in a cross-process context (like applets). In both of these cases, they should really use the CoreAnimation Layer based JAWT API which was introduced in Java SE 6, and attach or host the appropriate CALayer. SWT will have to do a little more work to marshal events into/out-of the AWT event model (depending on which way the embedding is going), but they actually have it pretty easy when it comes to hosting or creating the CALayer with their content (since they can make their NSView's layer backed). For the case of Java 3D, they should investigate how the JOGL and LWJGL projects have adopted CALayer-based JAWT already. The code is straightforward and works today in all modern browsers using Plugin2 on Java SE 6. > I would expect many other Mac OS X applications written in Java to rely on classes like these. Quick search for "import apple.awt" in Google shows at least 2 projects in top 10 results. They are about to suffer a rude awakening. Though, all bundled applications will have to undergo some form of repackaging to adopt Java 7, since they will embed the JRE in their bundle. Getting off of Apple-private API will just have to be one of those steps. > There are several options, but none of them looks perfect: > > 1. Force application developers to fork their code to run with JDK6 and JDK7+ In cases of embedding, they should use the CALayer-based JAWT API, since that works in both worlds. If they are using platform dependent classes to dig at some native data structure, they will have to re-write their code to use JNI and use the JavaNativeFoundation framework if they are doing extensive interfacing with Cocoa APIs. Again, with bundled applications, there should be no need to support Java 6, since they will already have a (clearly superior) Java 7 already inside them. > 2. Re-implement all the Apple classes in JDK7 (and place them to the same package?) It may be very hard, if possible at all, to preserve exactly the same behavior, though. In some cases, it's completely impossible because the component model in Java 7 is not NSView-backed, but CALayer/OpenGL backed. Some of the classes in apple.awt.* are just bridges onto NSView peers (or closely associated objects), which simply don't exist in Java 7. There may be limited cases where creating backwards compatible classes for a few things may be feasible, but I'd need to see specific examples to make a better recommendation. > 3. Add more APIs to com.apple.eawt both in JDK6 and JDK7 to use instead of direct references to Apple classes. What about classes that are not related to AWT? Ick. Maybe there is a reason to do this, but taken on a case-by-case basis, it might be more desirable to just populate the apple.awt.* package space, mark them all as deprecated, and encourage a Java 7-only solution as soon as possible (since they would have to write new code to adopt new eAWT API anyway). New eAWT API seems like the least desirable option because it means that everyone (Oracle, Apple, and devs) re-writes, and targets a non-optimal solution. > 4. Ignore such requests as all the applications relying on apple.*, or sun.*, or whatever else packages can be declared "unsupported". Let's take it on a case-by-case basis. :-) > Your ideas? > > Thanks, > > Artem Regards, Mike Swingler Apple Inc. From paul.hohensee at oracle.com Thu Jan 19 12:02:21 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 19 Jan 2012 15:02:21 -0500 Subject: Code Review Request: 7126993: JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] In-Reply-To: <4F186C9D.1070909@oracle.com> References: <4F186768.8070608@oracle.com> <4F186C9D.1070909@oracle.com> Message-ID: <4F1876CD.6010402@oracle.com> If this change needs to be make, we should make the same change in os_bsd.cpp. The original value of O_DELETE in os_bsd.cpp was 0x10000 and hasn't been changed since. Paul On 1/19/12 2:18 PM, Alan Bateman wrote: > On 19/01/2012 18:56, Kurchi Hazra wrote: >> >> Hi, >> >> JCK tests api/java_util/jar/Jarfile and api/java_util/zip/ZipFile >> were both failing >> on Mac because the OPEN_DELETE flag sets the JVM_O_DELETE flag in >> native code, and the >> value of JVM_O_DELETE was changed from 0x10000 to0x10000000 for Mac OS. >> The JVM_O_DELETE flag is only used in >> src/share/native/java/util/zip/ZipFile.c >> and hence this change should be safe. >> >> >> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126993 >> >> Webrev : http://cr.openjdk.java.net/~khazra/7126993/webrev.00/ > At some point we need to change the zip and other code so that it's > not using the JVM_ functions (not needed anymore). I checked > os_bsd.cpp and O_DELETE is defined as 0x10000 so this is the value > that JVM_O_DELETE needs to have in jvm_md.d. I don't know why it was > changed to 0x10000000 but it must have had a corresponding change in > HotSpot at one point. > > -Alan. From kurchi.subhra.hazra at oracle.com Thu Jan 19 12:17:46 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 19 Jan 2012 12:17:46 -0800 Subject: Code Review Request: 7126993: JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] In-Reply-To: <4F1876CD.6010402@oracle.com> References: <4F186768.8070608@oracle.com> <4F186C9D.1070909@oracle.com> <4F1876CD.6010402@oracle.com> Message-ID: <4F187A6A.6030703@oracle.com> I see that O_DELETE is 0x10000 in os_bsd.cpp in 7u4osx too. So basically, the only change required for the time being is the one in the webrev below. This maybe a stupid question, but if O_DELETE is already defined, why do we have to use a separate JVM_O_DELETE macro? Why can't we just use O_DELETE in ZipFile.c? If the reason is consistency, that is to have all flags used in open() defined at one place in jvm_md.h, then why can't we just use a dummy macro such as O_DEL and define it in jvm_md.h as O_DELETE? - Kurchi On 1/19/2012 12:02 PM, Paul Hohensee wrote: > If this change needs to be make, we should make the same > change in os_bsd.cpp. The original value of O_DELETE in > os_bsd.cpp was 0x10000 and hasn't been changed since. > > Paul > > On 1/19/12 2:18 PM, Alan Bateman wrote: >> On 19/01/2012 18:56, Kurchi Hazra wrote: >>> >>> Hi, >>> >>> JCK tests api/java_util/jar/Jarfile and api/java_util/zip/ZipFile >>> were both failing >>> on Mac because the OPEN_DELETE flag sets the JVM_O_DELETE flag in >>> native code, and the >>> value of JVM_O_DELETE was changed from 0x10000 to0x10000000 for Mac OS. >>> The JVM_O_DELETE flag is only used in >>> src/share/native/java/util/zip/ZipFile.c >>> and hence this change should be safe. >>> >>> >>> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126993 >>> >>> Webrev : http://cr.openjdk.java.net/~khazra/7126993/webrev.00/ >> At some point we need to change the zip and other code so that it's >> not using the JVM_ functions (not needed anymore). I checked >> os_bsd.cpp and O_DELETE is defined as 0x10000 so this is the value >> that JVM_O_DELETE needs to have in jvm_md.d. I don't know why it was >> changed to 0x10000000 but it must have had a corresponding change in >> HotSpot at one point. >> >> -Alan. -- -Kurchi From paul.hohensee at oracle.com Thu Jan 19 12:25:26 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 19 Jan 2012 15:25:26 -0500 Subject: Code Review Request: 7126993: JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] In-Reply-To: <4F187A6A.6030703@oracle.com> References: <4F186768.8070608@oracle.com> <4F186C9D.1070909@oracle.com> <4F1876CD.6010402@oracle.com> <4F187A6A.6030703@oracle.com> Message-ID: <4F187C36.3010204@oracle.com> I think the JVM_ names were intended to be used in platform-independent code. For "change required for the time being", are you referring to a change to os_bsd.cpp? Paul On 1/19/12 3:17 PM, Kurchi Hazra wrote: > > I see that O_DELETE is 0x10000 in os_bsd.cpp in 7u4osx too. So basically, > the only change required for the time being is the one in the webrev > below. > > This maybe a stupid question, but if O_DELETE is already defined, > why do we have to use a separate JVM_O_DELETE macro? Why can't we just > use > O_DELETE in ZipFile.c? > > If the reason is consistency, that is to have all flags used in open() > defined at one place in > jvm_md.h, then why can't we just use a dummy macro such as O_DEL and > define > it in jvm_md.h as O_DELETE? > > > - Kurchi > > > > On 1/19/2012 12:02 PM, Paul Hohensee wrote: >> If this change needs to be make, we should make the same >> change in os_bsd.cpp. The original value of O_DELETE in >> os_bsd.cpp was 0x10000 and hasn't been changed since. >> >> Paul >> >> On 1/19/12 2:18 PM, Alan Bateman wrote: >>> On 19/01/2012 18:56, Kurchi Hazra wrote: >>>> >>>> Hi, >>>> >>>> JCK tests api/java_util/jar/Jarfile and api/java_util/zip/ZipFile >>>> were both failing >>>> on Mac because the OPEN_DELETE flag sets the JVM_O_DELETE flag in >>>> native code, and the >>>> value of JVM_O_DELETE was changed from 0x10000 to0x10000000 for Mac >>>> OS. >>>> The JVM_O_DELETE flag is only used in >>>> src/share/native/java/util/zip/ZipFile.c >>>> and hence this change should be safe. >>>> >>>> >>>> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126993 >>>> >>>> Webrev : http://cr.openjdk.java.net/~khazra/7126993/webrev.00/ >>> At some point we need to change the zip and other code so that it's >>> not using the JVM_ functions (not needed anymore). I checked >>> os_bsd.cpp and O_DELETE is defined as 0x10000 so this is the value >>> that JVM_O_DELETE needs to have in jvm_md.d. I don't know why it was >>> changed to 0x10000000 but it must have had a corresponding change in >>> HotSpot at one point. >>> >>> -Alan. > From kurchi.subhra.hazra at oracle.com Thu Jan 19 12:29:33 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 19 Jan 2012 12:29:33 -0800 Subject: Code Review Request: 7126993: JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] In-Reply-To: <4F187C36.3010204@oracle.com> References: <4F186768.8070608@oracle.com> <4F186C9D.1070909@oracle.com> <4F1876CD.6010402@oracle.com> <4F187A6A.6030703@oracle.com> <4F187C36.3010204@oracle.com> Message-ID: <4F187D2D.6040100@oracle.com> On 1/19/2012 12:25 PM, Paul Hohensee wrote: > I think the JVM_ names were intended to be used in > platform-independent code. > > For "change required for the time being", are you referring to a change > to os_bsd.cpp? I meant jvm_md.h needs JVM_O_DELETE to be reset to 0x10000 as pointed out in the webrev. os_bsd.cpp already has O_DELETE defined as 0x10000 and does not need any change I guess. - Kurchi > > Paul > > On 1/19/12 3:17 PM, Kurchi Hazra wrote: >> >> I see that O_DELETE is 0x10000 in os_bsd.cpp in 7u4osx too. So >> basically, >> the only change required for the time being is the one in the webrev >> below. >> >> This maybe a stupid question, but if O_DELETE is already defined, >> why do we have to use a separate JVM_O_DELETE macro? Why can't we >> just use >> O_DELETE in ZipFile.c? >> >> If the reason is consistency, that is to have all flags used in >> open() defined at one place in >> jvm_md.h, then why can't we just use a dummy macro such as O_DEL and >> define >> it in jvm_md.h as O_DELETE? >> >> >> - Kurchi >> >> >> >> On 1/19/2012 12:02 PM, Paul Hohensee wrote: >>> If this change needs to be make, we should make the same >>> change in os_bsd.cpp. The original value of O_DELETE in >>> os_bsd.cpp was 0x10000 and hasn't been changed since. >>> >>> Paul >>> >>> On 1/19/12 2:18 PM, Alan Bateman wrote: >>>> On 19/01/2012 18:56, Kurchi Hazra wrote: >>>>> >>>>> Hi, >>>>> >>>>> JCK tests api/java_util/jar/Jarfile and api/java_util/zip/ZipFile >>>>> were both failing >>>>> on Mac because the OPEN_DELETE flag sets the JVM_O_DELETE flag in >>>>> native code, and the >>>>> value of JVM_O_DELETE was changed from 0x10000 to0x10000000 for >>>>> Mac OS. >>>>> The JVM_O_DELETE flag is only used in >>>>> src/share/native/java/util/zip/ZipFile.c >>>>> and hence this change should be safe. >>>>> >>>>> >>>>> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126993 >>>>> >>>>> Webrev : http://cr.openjdk.java.net/~khazra/7126993/webrev.00/ >>>> At some point we need to change the zip and other code so that it's >>>> not using the JVM_ functions (not needed anymore). I checked >>>> os_bsd.cpp and O_DELETE is defined as 0x10000 so this is the value >>>> that JVM_O_DELETE needs to have in jvm_md.d. I don't know why it >>>> was changed to 0x10000000 but it must have had a corresponding >>>> change in HotSpot at one point. >>>> >>>> -Alan. >> -- -Kurchi From paul.hohensee at oracle.com Thu Jan 19 12:38:14 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 19 Jan 2012 15:38:14 -0500 Subject: Code Review Request: 7126993: JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] In-Reply-To: <4F187D2D.6040100@oracle.com> References: <4F186768.8070608@oracle.com> <4F186C9D.1070909@oracle.com> <4F1876CD.6010402@oracle.com> <4F187A6A.6030703@oracle.com> <4F187C36.3010204@oracle.com> <4F187D2D.6040100@oracle.com> Message-ID: <4F187F36.5090807@oracle.com> Ok, got it. paul On 1/19/12 3:29 PM, Kurchi Hazra wrote: > > > On 1/19/2012 12:25 PM, Paul Hohensee wrote: >> I think the JVM_ names were intended to be used in >> platform-independent code. >> >> For "change required for the time being", are you referring to a change >> to os_bsd.cpp? > > I meant jvm_md.h needs JVM_O_DELETE to be reset to 0x10000 as pointed > out in the > webrev. os_bsd.cpp already has O_DELETE defined as 0x10000 and does > not need any change I > guess. > > - Kurchi > >> >> Paul >> >> On 1/19/12 3:17 PM, Kurchi Hazra wrote: >>> >>> I see that O_DELETE is 0x10000 in os_bsd.cpp in 7u4osx too. So >>> basically, >>> the only change required for the time being is the one in the webrev >>> below. >>> >>> This maybe a stupid question, but if O_DELETE is already defined, >>> why do we have to use a separate JVM_O_DELETE macro? Why can't we >>> just use >>> O_DELETE in ZipFile.c? >>> >>> If the reason is consistency, that is to have all flags used in >>> open() defined at one place in >>> jvm_md.h, then why can't we just use a dummy macro such as O_DEL and >>> define >>> it in jvm_md.h as O_DELETE? >>> >>> >>> - Kurchi >>> >>> >>> >>> On 1/19/2012 12:02 PM, Paul Hohensee wrote: >>>> If this change needs to be make, we should make the same >>>> change in os_bsd.cpp. The original value of O_DELETE in >>>> os_bsd.cpp was 0x10000 and hasn't been changed since. >>>> >>>> Paul >>>> >>>> On 1/19/12 2:18 PM, Alan Bateman wrote: >>>>> On 19/01/2012 18:56, Kurchi Hazra wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> JCK tests api/java_util/jar/Jarfile and api/java_util/zip/ZipFile >>>>>> were both failing >>>>>> on Mac because the OPEN_DELETE flag sets the JVM_O_DELETE flag in >>>>>> native code, and the >>>>>> value of JVM_O_DELETE was changed from 0x10000 to0x10000000 for >>>>>> Mac OS. >>>>>> The JVM_O_DELETE flag is only used in >>>>>> src/share/native/java/util/zip/ZipFile.c >>>>>> and hence this change should be safe. >>>>>> >>>>>> >>>>>> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126993 >>>>>> >>>>>> Webrev : http://cr.openjdk.java.net/~khazra/7126993/webrev.00/ >>>>> At some point we need to change the zip and other code so that >>>>> it's not using the JVM_ functions (not needed anymore). I checked >>>>> os_bsd.cpp and O_DELETE is defined as 0x10000 so this is the value >>>>> that JVM_O_DELETE needs to have in jvm_md.d. I don't know why it >>>>> was changed to 0x10000000 but it must have had a corresponding >>>>> change in HotSpot at one point. >>>>> >>>>> -Alan. >>> > From paul.hohensee at oracle.com Thu Jan 19 12:39:33 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 19 Jan 2012 15:39:33 -0500 Subject: Code Review Request: 7126993: JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] In-Reply-To: <4F187F36.5090807@oracle.com> References: <4F186768.8070608@oracle.com> <4F186C9D.1070909@oracle.com> <4F1876CD.6010402@oracle.com> <4F187A6A.6030703@oracle.com> <4F187C36.3010204@oracle.com> <4F187D2D.6040100@oracle.com> <4F187F36.5090807@oracle.com> Message-ID: <4F187F85.1000207@oracle.com> Actually, no, I don't have it. os_bsd.cpp is used in the macosx hotspot build. There's no separate osx code. So it should be changed in os_bsd.cpp too, right? Paul On 1/19/12 3:38 PM, Paul Hohensee wrote: > Ok, got it. > > paul > > On 1/19/12 3:29 PM, Kurchi Hazra wrote: >> >> >> On 1/19/2012 12:25 PM, Paul Hohensee wrote: >>> I think the JVM_ names were intended to be used in >>> platform-independent code. >>> >>> For "change required for the time being", are you referring to a change >>> to os_bsd.cpp? >> >> I meant jvm_md.h needs JVM_O_DELETE to be reset to 0x10000 as pointed >> out in the >> webrev. os_bsd.cpp already has O_DELETE defined as 0x10000 and does >> not need any change I >> guess. >> >> - Kurchi >> >>> >>> Paul >>> >>> On 1/19/12 3:17 PM, Kurchi Hazra wrote: >>>> >>>> I see that O_DELETE is 0x10000 in os_bsd.cpp in 7u4osx too. So >>>> basically, >>>> the only change required for the time being is the one in the >>>> webrev below. >>>> >>>> This maybe a stupid question, but if O_DELETE is already defined, >>>> why do we have to use a separate JVM_O_DELETE macro? Why can't we >>>> just use >>>> O_DELETE in ZipFile.c? >>>> >>>> If the reason is consistency, that is to have all flags used in >>>> open() defined at one place in >>>> jvm_md.h, then why can't we just use a dummy macro such as O_DEL >>>> and define >>>> it in jvm_md.h as O_DELETE? >>>> >>>> >>>> - Kurchi >>>> >>>> >>>> >>>> On 1/19/2012 12:02 PM, Paul Hohensee wrote: >>>>> If this change needs to be make, we should make the same >>>>> change in os_bsd.cpp. The original value of O_DELETE in >>>>> os_bsd.cpp was 0x10000 and hasn't been changed since. >>>>> >>>>> Paul >>>>> >>>>> On 1/19/12 2:18 PM, Alan Bateman wrote: >>>>>> On 19/01/2012 18:56, Kurchi Hazra wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> JCK tests api/java_util/jar/Jarfile and >>>>>>> api/java_util/zip/ZipFile were both failing >>>>>>> on Mac because the OPEN_DELETE flag sets the JVM_O_DELETE flag >>>>>>> in native code, and the >>>>>>> value of JVM_O_DELETE was changed from 0x10000 to0x10000000 for >>>>>>> Mac OS. >>>>>>> The JVM_O_DELETE flag is only used in >>>>>>> src/share/native/java/util/zip/ZipFile.c >>>>>>> and hence this change should be safe. >>>>>>> >>>>>>> >>>>>>> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126993 >>>>>>> >>>>>>> Webrev : http://cr.openjdk.java.net/~khazra/7126993/webrev.00/ >>>>>> At some point we need to change the zip and other code so that >>>>>> it's not using the JVM_ functions (not needed anymore). I checked >>>>>> os_bsd.cpp and O_DELETE is defined as 0x10000 so this is the >>>>>> value that JVM_O_DELETE needs to have in jvm_md.d. I don't know >>>>>> why it was changed to 0x10000000 but it must have had a >>>>>> corresponding change in HotSpot at one point. >>>>>> >>>>>> -Alan. >>>> >> From paul.hohensee at oracle.com Thu Jan 19 12:48:18 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 19 Jan 2012 15:48:18 -0500 Subject: Code Review Request: 7126993: JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] In-Reply-To: <4F187F85.1000207@oracle.com> References: <4F186768.8070608@oracle.com> <4F186C9D.1070909@oracle.com> <4F1876CD.6010402@oracle.com> <4F187A6A.6030703@oracle.com> <4F187C36.3010204@oracle.com> <4F187D2D.6040100@oracle.com> <4F187F36.5090807@oracle.com> <4F187F85.1000207@oracle.com> Message-ID: <4F188192.9060706@oracle.com> Never mind. I read the webrev backward. :( On 1/19/12 3:39 PM, Paul Hohensee wrote: > Actually, no, I don't have it. os_bsd.cpp is used in the macosx > hotspot build. > There's no separate osx code. So it should be changed in os_bsd.cpp > too, right? > > Paul > > On 1/19/12 3:38 PM, Paul Hohensee wrote: >> Ok, got it. >> >> paul >> >> On 1/19/12 3:29 PM, Kurchi Hazra wrote: >>> >>> >>> On 1/19/2012 12:25 PM, Paul Hohensee wrote: >>>> I think the JVM_ names were intended to be used in >>>> platform-independent code. >>>> >>>> For "change required for the time being", are you referring to a >>>> change >>>> to os_bsd.cpp? >>> >>> I meant jvm_md.h needs JVM_O_DELETE to be reset to 0x10000 as >>> pointed out in the >>> webrev. os_bsd.cpp already has O_DELETE defined as 0x10000 and does >>> not need any change I >>> guess. >>> >>> - Kurchi >>> >>>> >>>> Paul >>>> >>>> On 1/19/12 3:17 PM, Kurchi Hazra wrote: >>>>> >>>>> I see that O_DELETE is 0x10000 in os_bsd.cpp in 7u4osx too. So >>>>> basically, >>>>> the only change required for the time being is the one in the >>>>> webrev below. >>>>> >>>>> This maybe a stupid question, but if O_DELETE is already defined, >>>>> why do we have to use a separate JVM_O_DELETE macro? Why can't we >>>>> just use >>>>> O_DELETE in ZipFile.c? >>>>> >>>>> If the reason is consistency, that is to have all flags used in >>>>> open() defined at one place in >>>>> jvm_md.h, then why can't we just use a dummy macro such as O_DEL >>>>> and define >>>>> it in jvm_md.h as O_DELETE? >>>>> >>>>> >>>>> - Kurchi >>>>> >>>>> >>>>> >>>>> On 1/19/2012 12:02 PM, Paul Hohensee wrote: >>>>>> If this change needs to be make, we should make the same >>>>>> change in os_bsd.cpp. The original value of O_DELETE in >>>>>> os_bsd.cpp was 0x10000 and hasn't been changed since. >>>>>> >>>>>> Paul >>>>>> >>>>>> On 1/19/12 2:18 PM, Alan Bateman wrote: >>>>>>> On 19/01/2012 18:56, Kurchi Hazra wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> JCK tests api/java_util/jar/Jarfile and >>>>>>>> api/java_util/zip/ZipFile were both failing >>>>>>>> on Mac because the OPEN_DELETE flag sets the JVM_O_DELETE flag >>>>>>>> in native code, and the >>>>>>>> value of JVM_O_DELETE was changed from 0x10000 to0x10000000 for >>>>>>>> Mac OS. >>>>>>>> The JVM_O_DELETE flag is only used in >>>>>>>> src/share/native/java/util/zip/ZipFile.c >>>>>>>> and hence this change should be safe. >>>>>>>> >>>>>>>> >>>>>>>> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126993 >>>>>>>> >>>>>>>> Webrev : http://cr.openjdk.java.net/~khazra/7126993/webrev.00/ >>>>>>> At some point we need to change the zip and other code so that >>>>>>> it's not using the JVM_ functions (not needed anymore). I >>>>>>> checked os_bsd.cpp and O_DELETE is defined as 0x10000 so this is >>>>>>> the value that JVM_O_DELETE needs to have in jvm_md.d. I don't >>>>>>> know why it was changed to 0x10000000 but it must have had a >>>>>>> corresponding change in HotSpot at one point. >>>>>>> >>>>>>> -Alan. >>>>> >>> From swingler at apple.com Thu Jan 19 16:46:12 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 19 Jan 2012 16:46:12 -0800 Subject: Java on future Mac OS + eawt In-Reply-To: References: <20120118200409.1DB2935807625@lists.apple.com> <7172E381-07AE-4771-90F8-5DE74ED580F2@anu.edu.au> <8702CC55-8744-47B3-A162-9E32EE0CDB35@apple.com> <0B5579B4-04E1-464B-82A3-D21FD31F06C4@anu.edu.au> <4F189876.9040203@fastmail.fm> Message-ID: <967193DE-F046-4BD3-A696-E7FAC68CC3D7@apple.com> On Jan 19, 2012, at 2:59 PM, Scott Kovatch wrote: > On Jan 19, 2012, at 2:25 PM, Paul Taylor wrote: > >> On 19/01/2012 17:11, Scott Kovatch wrote: >>> >>> (Resending to all) >>> >>> On Jan 19, 2012, at 3:42 AM, Fabrizio Giudici wrote: >>> >>>> On Thu, 19 Jan 2012 12:31:08 +0100, Brian Davies wrote: >>>> >>>>> Mile >>>>> >>>>> 1) I'm confused. I already have it (Java for Mac OS X 10.7 Update 1) installed in a Lion system, and it's Java 1.6 not Java 1.7. My App (bundles) work fine with it, including drag and drop. Also, I already know my apps work under Java 1.7 on Windows, I was referring to the fact that the Oracle site says that drag and drop is not yet implemented in Java 1.7 on the Mac port which is in progress. >>>> >>>> I'm confused too. To reset this point, can please somebody recap which Java 7 distributions for Mac OS X are available and where they can be downloaded from? Thanks. >>> >>> Java 7 builds for Mac OS X are available now from http://jdk7.java.net/macportpreview/ >>> >>> The plan is for the Mac build to become just another supported OS platform, and you'll get it from http://www.java.com/en/download/manual.jsp like all other OS's >>> >> Scott >> >> Ive downloaded the preview from the site and followed the instruction, mounting the dmg and copying into Virtual Library >> >> I then tried running my application, but it still uses the Apple Java 1.6 >> So then changed my info.plist to >> JVMVersion >> 1.7 >> Now it complains 'No compatible version of Java 1.7 available', but when I click on 'Open Java Preferences' Java SE 7 Developer Preview is listed. >> I on a macbookpro running Mac OSX 10.7.2, and run the Apple 64bit Java VM no problem. > > Apple's launching infrastructure does not and will not work with Oracle's JDK 7. Apps in Java 7 will need to re-bundle the JRE included in the JDK with the launcher stub from the OpenJDK. > > Unfortunately we don't have documentation on how to do that yet, but the first step is checking out the source (see https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port) and finding the Xcode project at jdk/src/macosx//bundle/JavaAppLauncher/JavaAppLauncher.xcodeproj. Duplicate the project file, add your JARs and resources, and build. > > When you installed that JDK bundle you got a bundle that works on the command line and nothing else. Oracle will be releasing an end-user runtime (JRE) that will handle applets, Web Start and JARs. Not to completely crowd-source this, anyone has step-by-step instructions for how to build the new JavaAppLauncher and repackage your app, please put them here: . Also, this discussion is more appropriate on the macosx-port-dev at openjdk.java.net list, since it is an OpenJDK technology, and more Oracle people are on that who can help. Thanks, Mike Swingler Apple Inc. From kurchi.subhra.hazra at oracle.com Thu Jan 19 16:58:23 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 19 Jan 2012 16:58:23 -0800 Subject: [7u4-osx] Request for approval for 7126993: (macosx) JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] Message-ID: <4F18BC2F.3050704@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126993 Webrev:http://cr.openjdk.java.net/~khazra/7126993/webrev.00/ Reviewed by: alanb, phh This changeset will be pushed on my behalf by Michael McMahon (michaelm). Thanks, Kurchi From paul.hohensee at oracle.com Thu Jan 19 17:05:20 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 19 Jan 2012 20:05:20 -0500 Subject: [7u4-osx] Request for approval for 7126993: (macosx) JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] In-Reply-To: <4F18BC2F.3050704@oracle.com> References: <4F18BC2F.3050704@oracle.com> Message-ID: <4F18BDD0.5030005@oracle.com> Approved. Paul On 1/19/12 7:58 PM, Kurchi Hazra wrote: > > > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126993 > > Webrev:http://cr.openjdk.java.net/~khazra/7126993/webrev.00/ > > > Reviewed by: alanb, phh > > This changeset will be pushed on my behalf by Michael McMahon (michaelm). > > Thanks, > Kurchi > > From greg.x.brown at oracle.com Thu Jan 19 17:18:50 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Thu, 19 Jan 2012 20:18:50 -0500 Subject: Java on future Mac OS + eawt In-Reply-To: <967193DE-F046-4BD3-A696-E7FAC68CC3D7@apple.com> References: <20120118200409.1DB2935807625@lists.apple.com> <7172E381-07AE-4771-90F8-5DE74ED580F2@anu.edu.au> <8702CC55-8744-47B3-A162-9E32EE0CDB35@apple.com> <0B5579B4-04E1-464B-82A3-D21FD31F06C4@anu.edu.au> <4F189876.9040203@fastmail.fm> <967193DE-F046-4BD3-A696-E7FAC68CC3D7@apple.com> Message-ID: <5531995F-4880-4E56-B0AE-722B10B86656@oracle.com> > Not to completely crowd-source this, anyone has step-by-step instructions for how to build the new JavaAppLauncher and repackage your app, please put them here: . FYI, the XCode project doesn't build at the moment. I have a local fix but haven't gotten the approval to commit it yet. Also, I'm in the process of writing an Ant task to automate this packaging. I'll post documentation once it is a bit further along. G From artem.ananiev at oracle.com Fri Jan 20 01:15:01 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 20 Jan 2012 13:15:01 +0400 Subject: [7u-osx] Request for approval for CR 7130751: [macosx] EventTest0020 test fails in JCK-runtime-7 interactive In-Reply-To: References: Message-ID: <4F193095.5010602@oracle.com> Approved. On 1/19/2012 8:13 PM, Leonid Romanov wrote: > Hi, > This a request to push the following changes to jdk7u-osx. > > CR: http://monaco.us.oracle.com/detail.jsf?cr=7130751 > Webrev: http://cr.openjdk.java.net/~leonidr/7130751/webrev.00 > > The fix has been reviewed on macosx-port-dev mailing list by Dmitry Cherepanov. > > Thanks, > Leonid. > From artem.ananiev at oracle.com Fri Jan 20 01:16:05 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 20 Jan 2012 13:16:05 +0400 Subject: [jdk7u-osx] Request for approval for 7122246: [macosx] JCK swing test CaretTests fails in b205 In-Reply-To: <4F186508.9060108@oracle.com> References: <4F186508.9060108@oracle.com> Message-ID: <4F1930D5.8000305@oracle.com> Approved. On 1/19/2012 10:46 PM, Alexander Potochkin wrote: > This is a request to push the following fix to jdk7u-osx: > http://cr.openjdk.java.net/~alexp/7122246/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122246 > > the fix was approved by swingler > > Thanks > alexp From dmitry.cherepanov at oracle.com Fri Jan 20 02:34:56 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 20 Jan 2012 13:34:56 +0300 Subject: [7u-osx] Request for approval for 7128597: [macosx] Program freeze when Swing is used with -XstartOnFirstThread Message-ID: <4F194350.7080004@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7128597 Webrev: http://cr.openjdk.java.net/~dcherepanov/7128597/webrev.0 Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002126.html Thanks, Dmitry From artem.ananiev at oracle.com Fri Jan 20 01:52:16 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 20 Jan 2012 13:52:16 +0400 Subject: [7u-osx] Request for approval for 7128597: [macosx] Program freeze when Swing is used with -XstartOnFirstThread In-Reply-To: <4F194350.7080004@oracle.com> References: <4F194350.7080004@oracle.com> Message-ID: <4F193950.30508@oracle.com> Approved. On 1/20/2012 2:34 PM, Dmitry Cherepanov wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7128597 > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7128597/webrev.0 > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002126.html > > > Thanks, > Dmitry From anton.tarasov at oracle.com Fri Jan 20 03:04:56 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 20 Jan 2012 14:04:56 +0300 Subject: [7u-osx] Request for approval for 7125491 - [macosx] Regression: A component can get unexpected keyTyped event. Message-ID: <4F194A58.90603@oracle.com> Hello, A request to push the changes to jdk7u-osx. Reviewed on macosx-port-dev by Anthony Petrov & Artem Ananiev. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125491 Webrev: http://cr.openjdk.java.net/~ant/7125491/webrev.0/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002319.html Thanks, Anton. From dmitry.cherepanov at oracle.com Fri Jan 20 02:08:10 2012 From: dmitry.cherepanov at oracle.com (dmitry.cherepanov at oracle.com) Date: Fri, 20 Jan 2012 10:08:10 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7128597: [macosx] Program freeze when Swing is used with -XstartOnFirstThread Message-ID: <20120120100820.C25EE470BD@hg.openjdk.java.net> Changeset: 2a8bd80fe31d Author: dcherepanov Date: 2012-01-20 14:05 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/2a8bd80fe31d 7128597: [macosx] Program freeze when Swing is used with -XstartOnFirstThread Reviewed-by: art ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.h ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m From artem.ananiev at oracle.com Fri Jan 20 02:24:36 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 20 Jan 2012 14:24:36 +0400 Subject: [7u-osx] Request for approval for 7125491 - [macosx] Regression: A component can get unexpected keyTyped event. In-Reply-To: <4F194A58.90603@oracle.com> References: <4F194A58.90603@oracle.com> Message-ID: <4F1940E4.3060408@oracle.com> Approved. On 1/20/2012 3:04 PM, Anton V. Tarasov wrote: > Hello, > > A request to push the changes to jdk7u-osx. > Reviewed on macosx-port-dev by Anthony Petrov & Artem Ananiev. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125491 > Webrev: http://cr.openjdk.java.net/~ant/7125491/webrev.0/ > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002319.html > > > Thanks, > Anton. From sergey.bylokhov at oracle.com Fri Jan 20 05:21:39 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 20 Jan 2012 17:21:39 +0400 Subject: [7u4] Request for approval for 7124530 - What is background color of AWT component? (And foreground, for that matter) In-Reply-To: <3BBD9C26-CA01-4EDD-8279-F6C87AB25E61@apple.com> References: <4F0ED0EF.90208@oracle.com> <4F103F68.9040806@oracle.com> <9716158E-63E1-4554-B07C-2772A35F82E7@apple.com> <4F107D53.9060600@oracle.com> <3BBD9C26-CA01-4EDD-8279-F6C87AB25E61@apple.com> Message-ID: <4F196A63.9060209@oracle.com> 18.01.2012 0:29, Mike Swingler ?????: > On Jan 13, 2012, at 10:52 AM, Sergey Bylokhov wrote: > >> 13.01.2012 21:31, Mike Swingler ?????: >>> On Jan 13, 2012, at 6:27 AM, Sergey Bylokhov wrote: >>> >>>> 13.01.2012 6:30, Mike Swingler wrote: >>>> >>>>> On Jan 12, 2012, at 4:24 AM, Sergey Bylokhov wrote: >>>>> >>>>>> Hello, >>>>>> This is a request to push the following changes to jdk7u-osx. >>>>>> The fix has been reviewed on macosx-port-dev mailing list by Alexander Potochkin. >>>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 >>>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/7124530/webrev.00/ >>>>>> Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002143.html >>>>> I don't understand this part: >>>>> >>>>> --- old/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 19:02:19.913935900 +0400 >>>>> +++ new/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 19:02:19.557915600 +0400 >>>>> @@ -81,7 +81,8 @@ >>>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION] = [NSColor grayColor]; >>>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION_TEXT] = [NSColor grayColor]; >>>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION_BORDER] = [NSColor grayColor]; >>>>> - sColors[java_awt_SystemColor_WINDOW] = [NSColor grayColor]; >>>>> + const CGFloat color = (CGFloat)0xEE/(CGFloat)0xFF; >>>>> + sColors[java_awt_SystemColor_WINDOW] = [NSColor colorWithCalibratedRed:color green:color blue:color alpha:1.0f]; >>>>> sColors[java_awt_SystemColor_WINDOW_BORDER] = [NSColor windowFrameColor]; >>>>> sColors[java_awt_SystemColor_WINDOW_TEXT] = [NSColor windowFrameTextColor]; >>>>> sColors[java_awt_SystemColor_MENU] = [NSColor controlBackgroundColor]; >>>>> >>>>> Why aren't you just using [NSColor windowBackgroundColor]? >>>> Only selectedControlColor and selectedTextBackgroundColor are supported. >>>> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DrawColor/Tasks/SystemColors.html#//apple_ref/doc/uid/20000790 >>>> As I understand that`s why swing didn`t use this color. After the fix awt and swing use one color (before the fix this color was used by swing). >>>> If this color is wrong, now it`s possible to change it in one place. >>> I can assure you that the window background color reports the correct RGB value, even when the background color has changed between OS versions. You static constant will not. >>> >>> We use it today in Java SE 6. >> jdk6 on my system reports white color which is wrong. Can you please check it(testcase attached). > The test works fine in Java SE 6 with JFrames and other components. The bug where you are getting white from a pure AWT Frame is a side effect of something we call the "magic background color", which is not applicable to Java 7. On jdk 6 it works with swing components, because they use com.apple.laf.AquaNativeResources$CColorPaintUIResource with RGB[r=238,g=238,b=238] instead of SystemColor.WINDOW with RGB[r=255,g=255,b=255]. I assume that SystemColor.WINDOW is not used in jdk 6. > > Does +[NSColor windowBackgroundColor] not give you the correct RGB value? Yes. It return white color[r=255,g=255,b=255]. > > Regards, > Mike Swingler > Apple Inc. > -- Best regards, Sergey. From alexander.zuev at oracle.com Fri Jan 20 07:16:45 2012 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Fri, 20 Jan 2012 15:16:45 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7130751: [macosx] EventTest0020 test fails in JCK-runtime-7 interactive Message-ID: <20120120151655.88194470C4@hg.openjdk.java.net> Changeset: cade8d7be120 Author: leonidr Date: 2012-01-20 19:17 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/cade8d7be120 7130751: [macosx] EventTest0020 test fails in JCK-runtime-7 interactive Reviewed-by: dcherepanov ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java From Alexander.Potochkin at oracle.com Fri Jan 20 07:39:08 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Fri, 20 Jan 2012 19:39:08 +0400 Subject: [jdk7u-osx] Request for approval for 7130935: [macosx] Still, JSpinner 4656590 regression Message-ID: <4F198A9C.2000402@oracle.com> This is a request to push the following fix to jdk7u-osx: http://cr.openjdk.java.net/~alexp/7130935/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130935 the fix was approved by swingler Thanks alexp From kumar.x.srinivasan at oracle.COM Fri Jan 20 08:24:12 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 20 Jan 2012 08:24:12 -0800 Subject: [7u4-osx] Please review: 7124089: launcher refactoring v1.0 In-Reply-To: <4F14EC06.4040909@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> Message-ID: <4F19952C.7070408@oracle.COM> Hi All, Based on all the comments from Anthony, Joe and David, here is the modified version: Highlights: 1. re-factored code in solaris directory to be shared with macosx, reducing duplication across the *nixes. 2. adjusted the makefilesto allow the above 2. eliminated all conditionals from the shared java.c 3. added a new launcher regression test for the macosx specific -X options For those who have already reviewed the 0th version, here is an incremental webrev to make it easier reviewing the differences. http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/webrev.delta/index.html Here is the complete webrev: http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/index.html Thanks Kumar From anthony.petrov at oracle.com Fri Jan 20 08:32:56 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 20 Jan 2012 20:32:56 +0400 Subject: Review request for 7129420: [macosx] SplashScreen.getSplashScreen() returns null Message-ID: <4F199738.4020903@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7129420 at: http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.0/ We remove our custom mechanism to determine the splash screen dynamic library path and instead start using the GetJREPath() for this purpose. I've verified this fix with an SDK (not JRE!) image, and it works just fine. -- best regards, Anthony From anthony.petrov at oracle.com Fri Jan 20 08:36:19 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 20 Jan 2012 20:36:19 +0400 Subject: [7u4-osx] Please review: 7124089: launcher refactoring v1.0 In-Reply-To: <4F19952C.7070408@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F19952C.7070408@oracle.COM> Message-ID: <4F199803.3020702@oracle.com> Hi Kumar, The fix looks fine to me. -- best regards, Anthony On 1/20/2012 8:24 PM, Kumar Srinivasan wrote: > > Hi All, > > Based on all the comments from Anthony, Joe and David, > here is the modified version: > > Highlights: > 1. re-factored code in solaris directory to be shared with macosx, > reducing duplication across the *nixes. > > 2. adjusted the makefiles to allow the above > > 2. eliminated all conditionals from the shared java.c > > 3. added a new launcher regression test for the macosx specific -X options > > For those who have already reviewed the 0th version, here is an > incremental webrev to make it easier reviewing the differences. > http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/webrev.delta/index.html > > Here is the complete webrev: > http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/index.html > > Thanks > Kumar > > From alexander.zuev at oracle.com Fri Jan 20 09:31:35 2012 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Fri, 20 Jan 2012 17:31:35 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124306: [macosx] VoiceOver cursor not on currently focused object when app gets focus Message-ID: <20120120173146.4D093470CA@hg.openjdk.java.net> Changeset: 67f7e27a2945 Author: ptbrunet Date: 2012-01-20 21:32 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/67f7e27a2945 7124306: [macosx] VoiceOver cursor not on currently focused object when app gets focus Reviewed-by: skovatch ! src/macosx/native/sun/awt/CGraphicsDevice.m ! src/macosx/native/sun/awt/CMenuItem.m ! src/macosx/native/sun/awt/JavaAccessibilityUtilities.m From roger.yeung at oracle.com Fri Jan 20 10:32:41 2012 From: roger.yeung at oracle.com (Roger Yeung) Date: Fri, 20 Jan 2012 10:32:41 -0800 Subject: JDK 7 Mac Port Preview b226 Available In-Reply-To: <4F17007E.9010306@oracle.com> References: <4F17007E.9010306@oracle.com> Message-ID: <4F19B349.6030208@oracle.com> Hi, The JDK 7 Mac Port Preview b226 is now available: http://jdk7.java.net/macportpreview/ Regards, Roger Y. From staffan.larsen at oracle.com Fri Jan 20 11:17:35 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 20 Jan 2012 20:17:35 +0100 Subject: RFR (S): 7125793: MAC: test_gamma should always work In-Reply-To: <4F0CA809.7020001@oracle.com> References: <4EFECA5D.6010905@oracle.com> <4F034B51.3070609@oracle.com> <4F087516.40505@oracle.com> <4F0B7A34.5070406@oracle.com> <4F0CA809.7020001@oracle.com> Message-ID: Sorry if I am late to the game, but I was just wishing for this functionality - and there was the web rev! I've looked at this version of the patch: http://cr.openjdk.java.net/~jmelvin/7125793/webrev.03/ It looks good. Only two small comments: java_md.c:GetJVMPath - I don't think the code inside "#ifndef GAMMA" needs to be changed. The code is always compiled with GAMMA defined. The "#ifndef GAMMA" is just there to facilitate comparison with the original code in the JDK. os_bsd.cpp:2580 - (nit) incorrect indentation I have also verified that the "hotspot" launcher works after this change. /Staffan On 10 jan 2012, at 22:05, James Melvin wrote: > Hi Dan, > > Final webrev to reflect your comments... > > http://cr.openjdk.java.net/~jmelvin/7125793/webrev.02 > > Minor changes this round: > > make/bsd/makefiles/buildtree.make # Fail gracefully on Apple BOOTDIR > make/bsd/makefiles/launcher.make # Link with framework only on Mac > src/os/bsd/vm/os_bsd.cpp # Just spelling fix > > Lastly, I wanted to reply to John Coomes comments earlier about the > test_gamma script simplification. Although I also value economy of > expression, in this case I think the use of more advanced shell > constructs increases the time for fresh eyes to decipher. Given > performance and such is not an issue, I'd prefer to keep the simpler > version I'm proposing with this change on Mac OS X, to make it easier on > future maintenance. This should be a model for the other platforms when > we reconcile. I've attached the before and after copies should there be > further comments on the simplified short script. > > Thanks, > > Jim > > > On 1/9/12 6:37 PM, Daniel D. Daugherty wrote: >> On 1/7/12 9:38 AM, James Melvin wrote: >>> WEBREV: >>> http://cr.openjdk.java.net/~jmelvin/7125793/webrev.01 >> >> make/bsd/Makefile >> No comments. >> >> make/bsd/makefiles/buildtree.make >> No comments. >> >> make/bsd/makefiles/defs.make >> Thanks for fixing this one for BSD platforms. >> >> make/bsd/makefiles/launcher.make >> line 60: typo: 'inadvertenly' -> 'inadvertently' >> >> Sorry I missed this in my first review, but the addition >> of '-framework CoreFoundation' to LFLAGS_LAUNCHER is >> probably MacOS X specific. I think: >> >> ifeq ($(OS_VENDOR), Darwin) >> else >> endif >> >> will work in launcher.make also. >> >> make/bsd/makefiles/vm.make >> No comments. >> >> src/os/bsd/vm/os_bsd.cpp >> line 2544: typo: 'overriden' -> 'overridden' >> line 2588: typo: 'overriden' -> 'overridden' >> >> Looks like old code line 2576 depended on the 'hotspot' >> symlink to refer to either 'client' or 'server' or whatever >> JVM you wanted to run. I'm fairly certain that the 'hotspot' >> symlink was retired; I'm just not sure when. >> >> src/os/posix/launcher/java_md.c >> No comments. >> >> Dan >> >> > From kelly.ohair at oracle.com Fri Jan 20 11:26:10 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 20 Jan 2012 11:26:10 -0800 Subject: [7u4-osx] Please review: 7124089: launcher refactoring v1.0 In-Reply-To: <4F19952C.7070408@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F19952C.7070408@oracle.COM> Message-ID: <003F4B79-4D22-4C49-B408-666107C81E86@oracle.com> On the Makefiles.... Please refrain from using any wildcards (e.g. * ) in the make rules. Better to be explicit, or if necessary use something like FILES=$(wildcard $(SOMEDIR)/*) and a cp $(FILES) $(SOMEPLACE) so that we can at least see in the Makefile log what it really copied. Please indent the Makefile if/else/endif statements. Thank you for the trailing comments on the endif's. ;^) Please try to avoid escaped quotes on the compile lines, use this -DX='"abc"' rather than this -DX=\"abc\" escaped quotes are very problematic on Windows and I know this isn't Windows, but it tempts windows people to use it, it will not work in all situations. Where '"abc"' does. Please add a comment on what the -Os compiler option means, and also the -x objective-c, I could guess but would be better to document it in the makefile. -kto On Jan 20, 2012, at 8:24 AM, Kumar Srinivasan wrote: > > Hi All, > > Based on all the comments from Anthony, Joe and David, > here is the modified version: > > Highlights: > 1. re-factored code in solaris directory to be shared with macosx, > reducing duplication across the *nixes. > > 2. adjusted the makefilesto allow the above > > 2. eliminated all conditionals from the shared java.c > > 3. added a new launcher regression test for the macosx specific -X options > > For those who have already reviewed the 0th version, here is an > incremental webrev to make it easier reviewing the differences. > http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/webrev.delta/index.html > > Here is the complete webrev: > http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/index.html > > Thanks > Kumar > > From david.dehaven at oracle.com Fri Jan 20 13:05:47 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 20 Jan 2012 13:05:47 -0800 Subject: References to Apple JDK internal classes from other projects In-Reply-To: <4F184EE0.9090902@oracle.com> References: <4F184EE0.9090902@oracle.com> Message-ID: <247E3A55-9526-48D3-AD6E-BA3916CEF2E4@oracle.com> > 1. Force application developers to fork their code to run with JDK6 and JDK7+ > > 2. Re-implement all the Apple classes in JDK7 (and place them to the same package?) It may be very hard, if possible at all, to preserve exactly the same behavior, though. > > 3. Add more APIs to com.apple.eawt both in JDK6 and JDK7 to use instead of direct references to Apple classes. What about classes that are not related to AWT? > > 4. Ignore such requests as all the applications relying on apple.*, or sun.*, or whatever else packages can be declared "unsupported". 5. Migrate to JavaFX ;) -DrD- From david.dehaven at oracle.com Fri Jan 20 13:08:40 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 20 Jan 2012 13:08:40 -0800 Subject: Java on future Mac OS + eawt In-Reply-To: <5531995F-4880-4E56-B0AE-722B10B86656@oracle.com> References: <20120118200409.1DB2935807625@lists.apple.com> <7172E381-07AE-4771-90F8-5DE74ED580F2@anu.edu.au> <8702CC55-8744-47B3-A162-9E32EE0CDB35@apple.com> <0B5579B4-04E1-464B-82A3-D21FD31F06C4@anu.edu.au> <4F189876.9040203@fastmail.fm> <967193DE-F046-4BD3-A696-E7FAC68CC3D7@apple.com> <5531995F-4880-4E56-B0AE-722B10B86656@oracle.com> Message-ID: >> Not to completely crowd-source this, anyone has step-by-step instructions for how to build the new JavaAppLauncher and repackage your app, please put them here: . > > FYI, the XCode project doesn't build at the moment. I have a local fix but haven't gotten the approval to commit it yet. What sort of problems? I have it working on my systems, I used that project to test sandboxing for the impending Mac App Store sandbox requirement. There are a couple issues with the project related to sandboxing, but it worked otherwise. -DrD- From greg.x.brown at oracle.com Fri Jan 20 13:11:28 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 20 Jan 2012 16:11:28 -0500 Subject: Java on future Mac OS + eawt In-Reply-To: References: <20120118200409.1DB2935807625@lists.apple.com> <7172E381-07AE-4771-90F8-5DE74ED580F2@anu.edu.au> <8702CC55-8744-47B3-A162-9E32EE0CDB35@apple.com> <0B5579B4-04E1-464B-82A3-D21FD31F06C4@anu.edu.au> <4F189876.9040203@fastmail.fm> <967193DE-F046-4BD3-A696-E7FAC68CC3D7@apple.com> <5531995F-4880-4E56-B0AE-722B10B86656@oracle.com> Message-ID: <82664318-BAB9-4783-8398-81E75E329546@oracle.com> >>> Not to completely crowd-source this, anyone has step-by-step instructions for how to build the new JavaAppLauncher and repackage your app, please put them here: . >> >> FYI, the XCode project doesn't build at the moment. I have a local fix but haven't gotten the approval to commit it yet. > > What sort of problems? I have it working on my systems, I used that project to test sandboxing for the impending Mac App Store sandbox requirement. There are a couple issues with the project related to sandboxing, but it worked otherwise. Some of the paths were wrong - they were pointing to the wrong location for includes and linked libraries. From james.melvin at oracle.com Sat Jan 21 07:01:51 2012 From: james.melvin at oracle.com (James Melvin) Date: Sat, 21 Jan 2012 10:01:51 -0500 Subject: RFR (S): 7125793: MAC: test_gamma should always work In-Reply-To: References: <4EFECA5D.6010905@oracle.com> <4F034B51.3070609@oracle.com> <4F087516.40505@oracle.com> <4F0B7A34.5070406@oracle.com> <4F0CA809.7020001@oracle.com> Message-ID: <4F1AD35F.70005@oracle.com> Staffan, Thanks for the review. Coming back to this work after a few other initiatives. Comments inline... On 1/20/12 2:17 PM, Staffan Larsen wrote: > Sorry if I am late to the game, but I was just wishing for this > functionality - and there was the web rev! > > I've looked at this version of the patch: > http://cr.openjdk.java.net/~jmelvin/7125793/webrev.03/ > > It looks good. Only two small comments: > > java_md.c:GetJVMPath - I don't think the code inside "#ifndef GAMMA" > needs to be changed. The code is always compiled with GAMMA defined. The > "#ifndef GAMMA" is just there to facilitate comparison with the original > code in the JDK. Correct. The code in the jdk has also changed to something similar, but with ifdefs instead of code logic. I'm not sure of the history behind the gamma launcher and how much effort has been expended to keep the jdk and hotspot launchers in sync in these sections. There are additional changes proposed to the jdk launcher. They are in review at the moment. I'd like to keep the current code in place and revise later to reflect the jdk changes when the dust settles. > > os_bsd.cpp:2580 - (nit) incorrect indentation Hmmm... This must be a webrev/browser thing. I'm looking in xemacs and the webrev via Firefox on Mac and I don't see an indentation problem. I'll send you the source file in a private email to inspect. Let me know if you still see the problem. > > I have also verified that the "hotspot" launcher works after this change. Great! Note, the gamma launcher expects an OpenJDK JAVA_HOME layout. Therefore, it will not work with the Apple layout. This is detected in the test_gamma script and a more appropriate error message is displayed. Just change JAVA_HOME and you will see what I mean. Again, thanks for the review! Jim > > /Staffan > > > On 10 jan 2012, at 22:05, James Melvin wrote: > >> Hi Dan, >> >> Final webrev to reflect your comments... >> >> http://cr.openjdk.java.net/~jmelvin/7125793/webrev.02 >> >> Minor changes this round: >> >> make/bsd/makefiles/buildtree.make # Fail gracefully on Apple BOOTDIR >> make/bsd/makefiles/launcher.make # Link with framework only on Mac >> src/os/bsd/vm/os_bsd.cpp # Just spelling fix >> >> Lastly, I wanted to reply to John Coomes comments earlier about the >> test_gamma script simplification. Although I also value economy of >> expression, in this case I think the use of more advanced shell >> constructs increases the time for fresh eyes to decipher. Given >> performance and such is not an issue, I'd prefer to keep the simpler >> version I'm proposing with this change on Mac OS X, to make it easier on >> future maintenance. This should be a model for the other platforms when >> we reconcile. I've attached the before and after copies should there be >> further comments on the simplified short script. >> >> Thanks, >> >> Jim >> >> >> On 1/9/12 6:37 PM, Daniel D. Daugherty wrote: >>> On 1/7/12 9:38 AM, James Melvin wrote: >>>> WEBREV: >>>> http://cr.openjdk.java.net/~jmelvin/7125793/webrev.01 >>> >>> make/bsd/Makefile >>> No comments. >>> >>> make/bsd/makefiles/buildtree.make >>> No comments. >>> >>> make/bsd/makefiles/defs.make >>> Thanks for fixing this one for BSD platforms. >>> >>> make/bsd/makefiles/launcher.make >>> line 60: typo: 'inadvertenly' -> 'inadvertently' >>> >>> Sorry I missed this in my first review, but the addition >>> of '-framework CoreFoundation' to LFLAGS_LAUNCHER is >>> probably MacOS X specific. I think: >>> >>> ifeq ($(OS_VENDOR), Darwin) >>> else >>> endif >>> >>> will work in launcher.make also. >>> >>> make/bsd/makefiles/vm.make >>> No comments. >>> >>> src/os/bsd/vm/os_bsd.cpp >>> line 2544: typo: 'overriden' -> 'overridden' >>> line 2588: typo: 'overriden' -> 'overridden' >>> >>> Looks like old code line 2576 depended on the 'hotspot' >>> symlink to refer to either 'client' or 'server' or whatever >>> JVM you wanted to run. I'm fairly certain that the 'hotspot' >>> symlink was retired; I'm just not sure when. >>> >>> src/os/posix/launcher/java_md.c >>> No comments. >>> >>> Dan >>> >>> >> > From kumar.x.srinivasan at oracle.COM Sat Jan 21 10:05:20 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Sat, 21 Jan 2012 10:05:20 -0800 Subject: [7u4-osx] Please review: 7124089: launcher refactoring v2.0 In-Reply-To: <003F4B79-4D22-4C49-B408-666107C81E86@oracle.com> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F19952C.7070408@oracle.COM> <003F4B79-4D22-4C49-B408-666107C81E86@oracle.com> Message-ID: <4F1AFE60.2030506@oracle.COM> Hi Kelly et. al., I have beautified/fixed the Makefiles addressing Kellys' comments below: 1. Indented the Makefiles correctly. 2. Annotated with more trailing comments to the if/else/endif clauses 3. Removed the offending \ escapes 4. Removed the * from Release.gmk, it turns out the files being copied were not quite right (missing files), fixed it such that all the appropriate files are copied. 5. Added comments for the MacOSX specific cflags. The incremental webrev is here: http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/webrev.delta/index.html The full webrev is here: http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/index.html Thanks Kumar > On the Makefiles.... > > Please refrain from using any wildcards (e.g. * ) in the make rules. Better to be explicit, or if necessary > use something like FILES=$(wildcard $(SOMEDIR)/*) and a cp $(FILES) $(SOMEPLACE) > so that we can at least see in the Makefile log what it really copied. > > Please indent the Makefile if/else/endif statements. > > Thank you for the trailing comments on the endif's. ;^) > > Please try to avoid escaped quotes on the compile lines, use this -DX='"abc"' rather than this -DX=\"abc\" > escaped quotes are very problematic on Windows and I know this isn't Windows, but it tempts windows > people to use it, it will not work in all situations. Where '"abc"' does. > > Please add a comment on what the -Os compiler option means, and also the -x objective-c, I could guess > but would be better to document it in the makefile. > > -kto > > On Jan 20, 2012, at 8:24 AM, Kumar Srinivasan wrote: > >> Hi All, >> >> Based on all the comments from Anthony, Joe and David, >> here is the modified version: >> >> Highlights: >> 1. re-factored code in solaris directory to be shared with macosx, >> reducing duplication across the *nixes. >> >> 2. adjusted the makefilesto allow the above >> >> 2. eliminated all conditionals from the shared java.c >> >> 3. added a new launcher regression test for the macosx specific -X options >> >> For those who have already reviewed the 0th version, here is an >> incremental webrev to make it easier reviewing the differences. >> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/webrev.delta/index.html >> >> Here is the complete webrev: >> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/index.html >> >> Thanks >> Kumar >> >> From staffan.larsen at oracle.com Sun Jan 22 03:43:34 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sun, 22 Jan 2012 12:43:34 +0100 Subject: RFR (S): 7125793: MAC: test_gamma should always work In-Reply-To: <4F1AD35F.70005@oracle.com> References: <4EFECA5D.6010905@oracle.com> <4F034B51.3070609@oracle.com> <4F087516.40505@oracle.com> <4F0B7A34.5070406@oracle.com> <4F0CA809.7020001@oracle.com> <4F1AD35F.70005@oracle.com> Message-ID: <3955B287-2568-4937-855B-72A6CD003E07@oracle.com> Inline. On 21 jan 2012, at 16:01, James Melvin wrote: >> >> java_md.c:GetJVMPath - I don't think the code inside "#ifndef GAMMA" >> needs to be changed. The code is always compiled with GAMMA defined. The >> "#ifndef GAMMA" is just there to facilitate comparison with the original >> code in the JDK. > > Correct. The code in the jdk has also changed to something similar, but > with ifdefs instead of code logic. I'm not sure of the history behind > the gamma launcher and how much effort has been expended to keep the jdk > and hotspot launchers in sync in these sections. There are additional > changes proposed to the jdk launcher. They are in review at the moment. > I'd like to keep the current code in place and revise later to reflect > the jdk changes when the dust settles. > I think the last update was about a year ago, when I rebased the launcher code in hotspot to 6u22 code. At that point, I believe the only changes to the code was inside "#ifdef GAMMA". >> >> os_bsd.cpp:2580 - (nit) incorrect indentation > > Hmmm... This must be a webrev/browser thing. I'm looking in xemacs and > the webrev via Firefox on Mac and I don't see an indentation problem. > I'll send you the source file in a private email to inspect. Let me know > if you still see the problem. Could be a tabsize issue. I think the line was preceded by a tab instead of spaces. Thanks, /Staffan From james.melvin at oracle.com Sun Jan 22 17:43:13 2012 From: james.melvin at oracle.com (James Melvin) Date: Sun, 22 Jan 2012 20:43:13 -0500 Subject: RFR (S): 7125793: MAC: test_gamma should always work In-Reply-To: <3955B287-2568-4937-855B-72A6CD003E07@oracle.com> References: <4EFECA5D.6010905@oracle.com> <4F034B51.3070609@oracle.com> <4F087516.40505@oracle.com> <4F0B7A34.5070406@oracle.com> <4F0CA809.7020001@oracle.com> <4F1AD35F.70005@oracle.com> <3955B287-2568-4937-855B-72A6CD003E07@oracle.com> Message-ID: <4F1CBB31.7040103@oracle.com> Hi Staffan, Comments inline... On 1/22/12 6:43 AM, Staffan Larsen wrote: > Inline. > > On 21 jan 2012, at 16:01, James Melvin wrote: >>> >>> java_md.c:GetJVMPath - I don't think the code inside "#ifndef GAMMA" >>> needs to be changed. The code is always compiled with GAMMA defined. The >>> "#ifndef GAMMA" is just there to facilitate comparison with the original >>> code in the JDK. >> >> Correct. The code in the jdk has also changed to something similar, but >> with ifdefs instead of code logic. I'm not sure of the history behind >> the gamma launcher and how much effort has been expended to keep the jdk >> and hotspot launchers in sync in these sections. There are additional >> changes proposed to the jdk launcher. They are in review at the moment. >> I'd like to keep the current code in place and revise later to reflect >> the jdk changes when the dust settles. >> > > I think the last update was about a year ago, when I rebased the > launcher code in hotspot to 6u22 code. At that point, I believe the only > changes to the code was inside "#ifdef GAMMA". OK, I agree. I've reverted the code in the #ifndef GAMMA section. We can rebase after the JDK launcher changes. No problem. >>> os_bsd.cpp:2580 - (nit) incorrect indentation >> >> Hmmm... This must be a webrev/browser thing. I'm looking in xemacs and >> the webrev via Firefox on Mac and I don't see an indentation problem. >> I'll send you the source file in a private email to inspect. Let me know >> if you still see the problem. > > Could be a tabsize issue. I think the line was preceded by a tab instead > of spaces. Indeed, there was a tab at the beginning of the line. Hg jcheck would have discovered it after commit. Thanks! New webrev and JPRT available, including builds on Mac OS X... WEBREV: http://cr.openjdk.java.net/~jmelvin/7125793/webrev.04 JPRT: http://prt-web.us.oracle.com//archive/2012/01/2012-01-22-205611.jmelvin.7125793/ Thanks, Jim > Thanks, > /Staffan > From david.holmes at oracle.com Sun Jan 22 18:14:32 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Jan 2012 12:14:32 +1000 Subject: [7u4-osx] Please review: 7124089: launcher refactoring v2.0 In-Reply-To: <4F1AFE60.2030506@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F19952C.7070408@oracle.COM> <003F4B79-4D22-4C49-B408-666107C81E86@oracle.com> <4F1AFE60.2030506@oracle.COM> Message-ID: <4F1CC288.1070809@oracle.com> On 22/01/2012 4:05 AM, Kumar Srinivasan wrote: > Hi Kelly et. al., > > I have beautified/fixed the Makefiles addressing Kellys' comments below: > > 1. Indented the Makefiles correctly. By some definition of "correct". The existing indentation is all over the place with 2, 4 and 8 space indents. The changes seem to use 4 most often but the end result is still a mix of 2,4 and 8 AFAICS. :( David ----- > 2. Annotated with more trailing comments to the if/else/endif clauses > 3. Removed the offending \ escapes > 4. Removed the * from Release.gmk, it turns out the files being copied > were not quite right (missing files), fixed it such that all the > appropriate files > are copied. > 5. Added comments for the MacOSX specific cflags. > > The incremental webrev is here: > http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/webrev.delta/index.html > > The full webrev is here: > http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/index.html > > Thanks > Kumar > >> On the Makefiles.... >> >> Please refrain from using any wildcards (e.g. * ) in the make rules. >> Better to be explicit, or if necessary >> use something like FILES=$(wildcard $(SOMEDIR)/*) and a cp $(FILES) >> $(SOMEPLACE) >> so that we can at least see in the Makefile log what it really copied. >> >> Please indent the Makefile if/else/endif statements. >> >> Thank you for the trailing comments on the endif's. ;^) >> >> Please try to avoid escaped quotes on the compile lines, use this >> -DX='"abc"' rather than this -DX=\"abc\" >> escaped quotes are very problematic on Windows and I know this isn't >> Windows, but it tempts windows >> people to use it, it will not work in all situations. Where '"abc"' does. >> >> Please add a comment on what the -Os compiler option means, and also >> the -x objective-c, I could guess >> but would be better to document it in the makefile. >> >> -kto >> >> On Jan 20, 2012, at 8:24 AM, Kumar Srinivasan wrote: >> >>> Hi All, >>> >>> Based on all the comments from Anthony, Joe and David, >>> here is the modified version: >>> >>> Highlights: >>> 1. re-factored code in solaris directory to be shared with macosx, >>> reducing duplication across the *nixes. >>> >>> 2. adjusted the makefilesto allow the above >>> >>> 2. eliminated all conditionals from the shared java.c >>> >>> 3. added a new launcher regression test for the macosx specific -X >>> options >>> >>> For those who have already reviewed the 0th version, here is an >>> incremental webrev to make it easier reviewing the differences. >>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/webrev.delta/index.html >>> >>> >>> Here is the complete webrev: >>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/index.html >>> >>> Thanks >>> Kumar >>> >>> > From staffan.larsen at oracle.com Sun Jan 22 23:04:09 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 23 Jan 2012 08:04:09 +0100 Subject: RFR (S): 7125793: MAC: test_gamma should always work In-Reply-To: <4F1CBB31.7040103@oracle.com> References: <4EFECA5D.6010905@oracle.com> <4F034B51.3070609@oracle.com> <4F087516.40505@oracle.com> <4F0B7A34.5070406@oracle.com> <4F0CA809.7020001@oracle.com> <4F1AD35F.70005@oracle.com> <3955B287-2568-4937-855B-72A6CD003E07@oracle.com> <4F1CBB31.7040103@oracle.com> Message-ID: <914DDA21-DD6A-416D-A6A0-6C0B13DA8E7B@oracle.com> Looks great! On 23 jan 2012, at 02:43, James Melvin wrote: > Hi Staffan, > > Comments inline... > > On 1/22/12 6:43 AM, Staffan Larsen wrote: >> Inline. >> >> On 21 jan 2012, at 16:01, James Melvin wrote: >>>> >>>> java_md.c:GetJVMPath - I don't think the code inside "#ifndef GAMMA" >>>> needs to be changed. The code is always compiled with GAMMA defined. The >>>> "#ifndef GAMMA" is just there to facilitate comparison with the original >>>> code in the JDK. >>> >>> Correct. The code in the jdk has also changed to something similar, but >>> with ifdefs instead of code logic. I'm not sure of the history behind >>> the gamma launcher and how much effort has been expended to keep the jdk >>> and hotspot launchers in sync in these sections. There are additional >>> changes proposed to the jdk launcher. They are in review at the moment. >>> I'd like to keep the current code in place and revise later to reflect >>> the jdk changes when the dust settles. >>> >> >> I think the last update was about a year ago, when I rebased the >> launcher code in hotspot to 6u22 code. At that point, I believe the only >> changes to the code was inside "#ifdef GAMMA". > > OK, I agree. I've reverted the code in the #ifndef GAMMA section. We > can rebase after the JDK launcher changes. No problem. > > >>>> os_bsd.cpp:2580 - (nit) incorrect indentation >>> >>> Hmmm... This must be a webrev/browser thing. I'm looking in xemacs and >>> the webrev via Firefox on Mac and I don't see an indentation problem. >>> I'll send you the source file in a private email to inspect. Let me know >>> if you still see the problem. >> >> Could be a tabsize issue. I think the line was preceded by a tab instead >> of spaces. > > Indeed, there was a tab at the beginning of the line. Hg jcheck would > have discovered it after commit. Thanks! > > New webrev and JPRT available, including builds on Mac OS X... > > WEBREV: http://cr.openjdk.java.net/~jmelvin/7125793/webrev.04 > JPRT: http://prt-web.us.oracle.com//archive/2012/01/2012-01-22-205611.jmelvin.7125793/ > > Thanks, > > Jim > >> Thanks, >> /Staffan >> From alexey.menkov at oracle.com Mon Jan 23 00:53:18 2012 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 23 Jan 2012 12:53:18 +0400 Subject: Request for review 7124224: [macosx] Port's controls are improperly ordered Message-ID: <4F1D1FFE.1000503@oracle.com> Hi all, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124224 webrev: http://javaweb.us.oracle.com/jcg/fx-webrevs/7124224/2/ summary of the changes: - updated the case when AudioDevice has several AudioStreams; - implemented "virtual" master/mute/balance controls; - implemented configuration detection (test for control validity); - control hierarchy was updated to be consistent with other platforms; - fixed memory leaks. Also 2 .c files was removed (issue of macosx-port=>jdk7u-osx integration). regards Alex From michael.x.mcmahon at oracle.com Mon Jan 23 02:25:06 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 23 Jan 2012 10:25:06 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7126993: JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] Message-ID: <20120123102544.2C03B4712B@hg.openjdk.java.net> Changeset: e4d37d63e6dd Author: khazra Date: 2012-01-23 10:23 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/e4d37d63e6dd 7126993: JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx] Reviewed-by: phh, alanb ! src/solaris/javavm/export/jvm_md.h From artem.ananiev at oracle.com Mon Jan 23 03:15:05 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Jan 2012 15:15:05 +0400 Subject: [jdk7u-osx] Request for approval for 7130935: [macosx] Still, JSpinner 4656590 regression In-Reply-To: <4F198A9C.2000402@oracle.com> References: <4F198A9C.2000402@oracle.com> Message-ID: <4F1D4139.4010804@oracle.com> Approved. On 1/20/2012 7:39 PM, Alexander Potochkin wrote: > This is a request to push the following fix to jdk7u-osx: > http://cr.openjdk.java.net/~alexp/7130935/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130935 > > the fix was approved by swingler > > Thanks > alexp From leonid.romanov at oracle.com Mon Jan 23 05:36:37 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 23 Jan 2012 17:36:37 +0400 Subject: Review request for 7124364: [macosx] Robot screen capturing functionality doesn't work Message-ID: Hi, Please review a fix for http://monaco.us.oracle.com/detail.jsf?cr=7124364 The fix removes a bunch of code that was only useful when Robot used OpenGL for taking a screenshot. The removed code prevented Robot from correctly taking screenshot in case of multiple monitors configuration. webrev: http://cr.openjdk.java.net/~leonidr/7124364/webrev.00/ Thanks, Leonid. From alexander.potochkin at sun.com Mon Jan 23 05:33:30 2012 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Mon, 23 Jan 2012 13:33:30 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7130935: [macosx] Still, JSpinner 4656590 regression Message-ID: <20120123133352.BECAE4712E@hg.openjdk.java.net> Changeset: 4471ea791dc8 Author: alexp Date: 2012-01-23 17:56 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/4471ea791dc8 7130935: [macosx] Still, JSpinner 4656590 regression Reviewed-by: swingler ! src/macosx/classes/com/apple/laf/AquaSpinnerUI.java From alexander.potochkin at sun.com Mon Jan 23 05:40:44 2012 From: alexander.potochkin at sun.com (alexander.potochkin at sun.com) Date: Mon, 23 Jan 2012 13:40:44 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7122246: [macosx] JCK swing test CaretTests fails in b205 Message-ID: <20120123134055.045244712F@hg.openjdk.java.net> Changeset: 69df1cdfa87f Author: alexp Date: 2012-01-23 18:03 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/69df1cdfa87f 7122246: [macosx] JCK swing test CaretTests fails in b205 Reviewed-by: swingler ! src/macosx/classes/com/apple/laf/AquaCaret.java From anthony.petrov at oracle.com Mon Jan 23 06:12:25 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 23 Jan 2012 18:12:25 +0400 Subject: Review request for 7124364: [macosx] Robot screen capturing functionality doesn't work In-Reply-To: References: Message-ID: <4F1D6AC9.4050504@oracle.com> Looks good. -- best regards, Anthony On 01/23/12 17:36, Leonid Romanov wrote: > Hi, > Please review a fix for http://monaco.us.oracle.com/detail.jsf?cr=7124364 > > The fix removes a bunch of code that was only useful when Robot used OpenGL for taking a screenshot. The removed code prevented Robot from correctly taking screenshot in case of multiple monitors configuration. > > webrev: http://cr.openjdk.java.net/~leonidr/7124364/webrev.00/ > > Thanks, > Leonid. > > > > From alexander.zuev at oracle.com Mon Jan 23 07:13:25 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 23 Jan 2012 18:13:25 +0300 Subject: Approved: Re: Review request for 7124364: [macosx] Robot screen capturing functionality doesn't work In-Reply-To: References: Message-ID: <4F1D7915.7060901@oracle.com> Fix looks too... uncomplicated! Approved. On 1/23/12 16:36, Leonid Romanov wrote: > Hi, > Please review a fix for http://monaco.us.oracle.com/detail.jsf?cr=7124364 > > The fix removes a bunch of code that was only useful when Robot used OpenGL for taking a screenshot. The removed code prevented Robot from correctly taking screenshot in case of multiple monitors configuration. > > webrev: http://cr.openjdk.java.net/~leonidr/7124364/webrev.00/ > > Thanks, > Leonid. > > > > From leonid.romanov at oracle.com Mon Jan 23 06:53:32 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 23 Jan 2012 18:53:32 +0400 Subject: [7u4-osx] Request for approval for CR 7124364: [macosx] Robot screen capturing functionality doesn't work Message-ID: <85B4C26C-A399-454A-8080-0E9793A1CC2D@oracle.com> Hi, This a request to push the following changes to jdk7u-osx. CR: http://monaco.us.oracle.com/detail.jsf?cr=7124364 Webrev: http://cr.openjdk.java.net/~leonidr/7124364/webrev.00/ The fix removes a bunch of code that was only useful when Robot used OpenGL for taking a screenshot. The removed code prevented Robot from correctly taking screenshot in case of multiple monitors configuration. The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov and Alexander Zuev. Thanks, Leonid. From artem.ananiev at oracle.com Mon Jan 23 07:33:43 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Jan 2012 19:33:43 +0400 Subject: [7u4-osx] Request for approval for CR 7124364: [macosx] Robot screen capturing functionality doesn't work In-Reply-To: <85B4C26C-A399-454A-8080-0E9793A1CC2D@oracle.com> References: <85B4C26C-A399-454A-8080-0E9793A1CC2D@oracle.com> Message-ID: <4F1D7DD7.6090603@oracle.com> Approved. On 1/23/2012 6:53 PM, Leonid Romanov wrote: > Hi, > This a request to push the following changes to jdk7u-osx. > > CR: http://monaco.us.oracle.com/detail.jsf?cr=7124364 > Webrev: http://cr.openjdk.java.net/~leonidr/7124364/webrev.00/ > > The fix removes a bunch of code that was only useful when Robot used OpenGL for taking a screenshot. The removed code prevented Robot from correctly taking screenshot in case of multiple monitors configuration. > > The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov and Alexander Zuev. > > Thanks, > Leonid. > > From Alexander.Potochkin at oracle.com Mon Jan 23 08:12:33 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 23 Jan 2012 20:12:33 +0400 Subject: Review request for 7130360: [macosx] Packed JInternalFrame invisible on Aqua L&F Message-ID: <4F1D86F1.3040406@oracle.com> Hello Please review the following fix: http://cr.openjdk.java.net/~alexp/7130360/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130360 AquaInternalFrameUI.minimumLayoutSize() doesn't override any method and is never called from any other classes, so I removed it The LayoutManager in BasicInternalFrameUI is private, so I overrode getPreferredSize() method to make sure that it never returns the size less then the minimal size Thanks alexp From kelly.ohair at oracle.com Mon Jan 23 09:07:35 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 23 Jan 2012 09:07:35 -0800 Subject: [7u4-osx] Please review: 7124089: launcher refactoring v2.0 In-Reply-To: <4F1CC288.1070809@oracle.com> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F19952C.7070408@oracle.COM> <003F4B79-4D22-4C49-B408-666107C81E86@oracle.com> <4F1AFE60.2030506@oracle.COM> <4F1CC288.1070809@oracle.com> Message-ID: With Makefiles, I have tended to use 2 spaces for indentation because using 4 quickly puts you at 8, which might trigger a TAB character with some editor, which will cause strange errors in some cases. You can still get to 8 using 2, but less likely. Not sure this 2 space indentation rule for makefiles is written down anywhere. :^( -kto On Jan 22, 2012, at 6:14 PM, David Holmes wrote: > On 22/01/2012 4:05 AM, Kumar Srinivasan wrote: >> Hi Kelly et. al., >> >> I have beautified/fixed the Makefiles addressing Kellys' comments below: >> >> 1. Indented the Makefiles correctly. > > By some definition of "correct". The existing indentation is all over the place with 2, 4 and 8 space indents. The changes seem to use 4 most often but the end result is still a mix of 2,4 and 8 AFAICS. :( > > David > ----- > >> 2. Annotated with more trailing comments to the if/else/endif clauses >> 3. Removed the offending \ escapes >> 4. Removed the * from Release.gmk, it turns out the files being copied >> were not quite right (missing files), fixed it such that all the >> appropriate files >> are copied. >> 5. Added comments for the MacOSX specific cflags. >> >> The incremental webrev is here: >> http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/webrev.delta/index.html >> >> The full webrev is here: >> http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/index.html >> >> Thanks >> Kumar >> >>> On the Makefiles.... >>> >>> Please refrain from using any wildcards (e.g. * ) in the make rules. >>> Better to be explicit, or if necessary >>> use something like FILES=$(wildcard $(SOMEDIR)/*) and a cp $(FILES) >>> $(SOMEPLACE) >>> so that we can at least see in the Makefile log what it really copied. >>> >>> Please indent the Makefile if/else/endif statements. >>> >>> Thank you for the trailing comments on the endif's. ;^) >>> >>> Please try to avoid escaped quotes on the compile lines, use this >>> -DX='"abc"' rather than this -DX=\"abc\" >>> escaped quotes are very problematic on Windows and I know this isn't >>> Windows, but it tempts windows >>> people to use it, it will not work in all situations. Where '"abc"' does. >>> >>> Please add a comment on what the -Os compiler option means, and also >>> the -x objective-c, I could guess >>> but would be better to document it in the makefile. >>> >>> -kto >>> >>> On Jan 20, 2012, at 8:24 AM, Kumar Srinivasan wrote: >>> >>>> Hi All, >>>> >>>> Based on all the comments from Anthony, Joe and David, >>>> here is the modified version: >>>> >>>> Highlights: >>>> 1. re-factored code in solaris directory to be shared with macosx, >>>> reducing duplication across the *nixes. >>>> >>>> 2. adjusted the makefilesto allow the above >>>> >>>> 2. eliminated all conditionals from the shared java.c >>>> >>>> 3. added a new launcher regression test for the macosx specific -X >>>> options >>>> >>>> For those who have already reviewed the 0th version, here is an >>>> incremental webrev to make it easier reviewing the differences. >>>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/webrev.delta/index.html >>>> >>>> >>>> Here is the complete webrev: >>>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/index.html >>>> >>>> Thanks >>>> Kumar >>>> >>>> >> From michael.x.mcmahon at oracle.com Mon Jan 23 09:09:24 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 23 Jan 2012 17:09:24 +0000 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] Message-ID: <4F1D9444.7040807@oracle.com> Can I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/ The problem is that poll(2) doesn't seem to work in a specific edge case tested by JCK, namely, when a zero length UDP message is sent on a DatagramSocket. The problem is only detected on timed reads, ie. normal blocking reads work fine. The fix is to make the NET_Timeout() function use select() instead of poll(). Thanks, Michael. From michael.x.mcmahon at oracle.com Mon Jan 23 09:11:14 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 23 Jan 2012 17:11:14 +0000 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: <4F1D9444.7040807@oracle.com> References: <4F1D9444.7040807@oracle.com> Message-ID: <4F1D94B2.8040107@oracle.com> On 23/01/12 17:09, Michael McMahon wrote: > Can I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/ > > The problem is that poll(2) doesn't seem to work in a specific edge > case tested by JCK, > namely, when a zero length UDP message is sent on a DatagramSocket. > The problem is only > detected on timed reads, ie. normal blocking reads work fine. > > The fix is to make the NET_Timeout() function use select() instead of > poll(). > > Thanks, > Michael. > > > Forgot to mention, that the second file in the webrev is a file that needs to be removed from the repo, and which was added unintentionally in a previous merge. Thanks, Michael. From kelly.ohair at oracle.com Mon Jan 23 09:16:01 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 23 Jan 2012 09:16:01 -0800 Subject: [7u4-osx] Please review: 7124089: launcher refactoring v2.0 In-Reply-To: <4F1AFE60.2030506@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F19952C.7070408@oracle.COM> <003F4B79-4D22-4C49-B408-666107C81E86@oracle.com> <4F1AFE60.2030506@oracle.COM> Message-ID: <72C30940-6ECF-4C68-9892-87B198C78A41@oracle.com> I think you went above and beyond what I was thinking of, sorry if I mis-communicated. I didn't mean to ask for all else/endif's to get a trailing comment, I just add them when it helps clarify things when the nesting or length gets bad. I feel like I created more work for you than necessary, sorry. And you didn't need to re-indent anything you didn't actually change. I do think Release.gmk looks better. But it looks fine. I would have preferred indentation by 2, but not a big deal. Some kind of indentation is better than none. -kto On Jan 21, 2012, at 10:05 AM, Kumar Srinivasan wrote: > Hi Kelly et. al., > > I have beautified/fixed the Makefiles addressing Kellys' comments below: > > 1. Indented the Makefiles correctly. > 2. Annotated with more trailing comments to the if/else/endif clauses > 3. Removed the offending \ escapes > 4. Removed the * from Release.gmk, it turns out the files being copied > were not quite right (missing files), fixed it such that all the appropriate files > are copied. > 5. Added comments for the MacOSX specific cflags. > > The incremental webrev is here: > http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/webrev.delta/index.html > > The full webrev is here: > http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/index.html > > Thanks > Kumar > >> On the Makefiles.... >> >> Please refrain from using any wildcards (e.g. * ) in the make rules. Better to be explicit, or if necessary >> use something like FILES=$(wildcard $(SOMEDIR)/*) and a cp $(FILES) $(SOMEPLACE) >> so that we can at least see in the Makefile log what it really copied. >> >> Please indent the Makefile if/else/endif statements. >> >> Thank you for the trailing comments on the endif's. ;^) >> >> Please try to avoid escaped quotes on the compile lines, use this -DX='"abc"' rather than this -DX=\"abc\" >> escaped quotes are very problematic on Windows and I know this isn't Windows, but it tempts windows >> people to use it, it will not work in all situations. Where '"abc"' does. >> >> Please add a comment on what the -Os compiler option means, and also the -x objective-c, I could guess >> but would be better to document it in the makefile. >> >> -kto >> >> On Jan 20, 2012, at 8:24 AM, Kumar Srinivasan wrote: >> >>> Hi All, >>> >>> Based on all the comments from Anthony, Joe and David, >>> here is the modified version: >>> >>> Highlights: >>> 1. re-factored code in solaris directory to be shared with macosx, >>> reducing duplication across the *nixes. >>> >>> 2. adjusted the makefilesto allow the above >>> >>> 2. eliminated all conditionals from the shared java.c >>> >>> 3. added a new launcher regression test for the macosx specific -X options >>> >>> For those who have already reviewed the 0th version, here is an >>> incremental webrev to make it easier reviewing the differences. >>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/webrev.delta/index.html >>> >>> Here is the complete webrev: >>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/index.html >>> >>> Thanks >>> Kumar >>> >>> > From kumar.x.srinivasan at oracle.COM Mon Jan 23 09:33:08 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 23 Jan 2012 09:33:08 -0800 Subject: [7u4-osx] Please review: 7124089: launcher refactoring v2.0 In-Reply-To: <72C30940-6ECF-4C68-9892-87B198C78A41@oracle.com> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F19952C.7070408@oracle.COM> <003F4B79-4D22-4C49-B408-666107C81E86@oracle.com> <4F1AFE60.2030506@oracle.COM> <72C30940-6ECF-4C68-9892-87B198C78A41@oracle.com> Message-ID: <4F1D99D4.50401@oracle.COM> On 1/23/2012 9:16 AM, Kelly O'Hair wrote: > I think you went above and beyond what I was thinking of, sorry if I mis-communicated. > I didn't mean to ask for all else/endif's to get a trailing comment, I just add them when it helps > clarify things when the nesting or length gets bad. > I feel like I created more work for you than necessary, sorry. > > And you didn't need to re-indent anything you didn't actually change. No the indentation ticked me off as well, as I could not parse the conditionals. > > I do think Release.gmk looks better. > > But it looks fine. I would have preferred indentation by 2, but not a big deal. > Some kind of indentation is better than none. Right I was in the middle of firing away a response to the occupants of 221b Baker Street, and you answered some of my questions in your previous email. I will reset the indentation to 2, to be consistent, I have trouble with tabs, these days my editor of choice has been NB and it does not help any to edit makefiles, as I have set it to convert tabs to spaces for real code. Therefore, in order to insert tabs for makefiles, I switch back and forth between gvim. I think it is time someone came up under the build project to document coding conventions for makefiles, and *ahem* a jcheck for Makefiles perhaps ? One more webrev coming up, later today. Kumar > > -kto > > On Jan 21, 2012, at 10:05 AM, Kumar Srinivasan wrote: > >> Hi Kelly et. al., >> >> I have beautified/fixed the Makefiles addressing Kellys' comments below: >> >> 1. Indented the Makefiles correctly. >> 2. Annotated with more trailing comments to the if/else/endif clauses >> 3. Removed the offending \ escapes >> 4. Removed the * from Release.gmk, it turns out the files being copied >> were not quite right (missing files), fixed it such that all the appropriate files >> are copied. >> 5. Added comments for the MacOSX specific cflags. >> >> The incremental webrev is here: >> http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/webrev.delta/index.html >> >> The full webrev is here: >> http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/index.html >> >> Thanks >> Kumar >> >>> On the Makefiles.... >>> >>> Please refrain from using any wildcards (e.g. * ) in the make rules. Better to be explicit, or if necessary >>> use something like FILES=$(wildcard $(SOMEDIR)/*) and a cp $(FILES) $(SOMEPLACE) >>> so that we can at least see in the Makefile log what it really copied. >>> >>> Please indent the Makefile if/else/endif statements. >>> >>> Thank you for the trailing comments on the endif's. ;^) >>> >>> Please try to avoid escaped quotes on the compile lines, use this -DX='"abc"' rather than this -DX=\"abc\" >>> escaped quotes are very problematic on Windows and I know this isn't Windows, but it tempts windows >>> people to use it, it will not work in all situations. Where '"abc"' does. >>> >>> Please add a comment on what the -Os compiler option means, and also the -x objective-c, I could guess >>> but would be better to document it in the makefile. >>> >>> -kto >>> >>> On Jan 20, 2012, at 8:24 AM, Kumar Srinivasan wrote: >>> >>>> Hi All, >>>> >>>> Based on all the comments from Anthony, Joe and David, >>>> here is the modified version: >>>> >>>> Highlights: >>>> 1. re-factored code in solaris directory to be shared with macosx, >>>> reducing duplication across the *nixes. >>>> >>>> 2. adjusted the makefilesto allow the above >>>> >>>> 2. eliminated all conditionals from the shared java.c >>>> >>>> 3. added a new launcher regression test for the macosx specific -X options >>>> >>>> For those who have already reviewed the 0th version, here is an >>>> incremental webrev to make it easier reviewing the differences. >>>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/webrev.delta/index.html >>>> >>>> Here is the complete webrev: >>>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/index.html >>>> >>>> Thanks >>>> Kumar >>>> >>>> From Alexander.Potochkin at oracle.com Mon Jan 23 09:33:42 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 23 Jan 2012 21:33:42 +0400 Subject: Review request for 7124393: [macosx] JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click Message-ID: <4F1D99F6.9060709@oracle.com> Hello Please review the following fix: http://cr.openjdk.java.net/~alexp/7124393/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124393 The bug is in the test, F2 doesn't stop editing on MacOS, we should not use the keyboard to commit the data the test is also updated to access the Swing methods on the Event Dispatching Thread only Thanks alexp From alexander.zuev at oracle.com Mon Jan 23 11:06:13 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 23 Jan 2012 22:06:13 +0300 Subject: Review request for 7124316: [macosx] Passive and Peered IMF Client does not cope with input methods Message-ID: <4F1DAFA5.9060008@oracle.com> Hello, please review the following fix: http://cr.openjdk.java.net/~kizune/7124316/webrev.01/ the bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124316 The previous fix, while needed, solved problem only for a small set of locales. This fix should solve it for all the locales for heavyweight text components. Thanks, Alex From Alexander.Potochkin at oracle.com Mon Jan 23 10:04:41 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 23 Jan 2012 22:04:41 +0400 Subject: Review request for 7124387: [macosx] Application freezes on dispose window, created by JFileChooser Message-ID: <4F1DA139.1050902@oracle.com> Hello Please review the following fix: http://cr.openjdk.java.net/~alexp/7124387/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124387 on MacOS it takes more time for the test to warm, so the 10 seconds timeout is not enough. I removed the internal timeout check if (!MUX.await(10, TimeUnit.SECONDS)) { throw new RuntimeException("Timeout"); } and rely on the default jtreg's timeout. Thanks alexp From Alexander.Potochkin at oracle.com Mon Jan 23 10:14:28 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 23 Jan 2012 22:14:28 +0400 Subject: Review request for 7124316: [macosx] Passive and Peered IMF Client does not cope with input methods In-Reply-To: <4F1DAFA5.9060008@oracle.com> References: <4F1DAFA5.9060008@oracle.com> Message-ID: <4F1DA384.1090506@oracle.com> Hello Alexander Looks good! alexp > Hello, > > please review the following fix: > http://cr.openjdk.java.net/~kizune/7124316/webrev.01/ > > the bug description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124316 > The previous fix, while needed, solved problem only for a small set of > locales. > This fix should solve it for all the locales for heavyweight text > components. > > Thanks, > Alex From sergey.bylokhov at oracle.com Mon Jan 23 11:16:27 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Jan 2012 23:16:27 +0400 Subject: [7u4] Request for approval for 7124530 - What is background color of AWT component? (And foreground, for that matter) In-Reply-To: <4F196A63.9060209@oracle.com> References: <4F0ED0EF.90208@oracle.com> <4F103F68.9040806@oracle.com> <9716158E-63E1-4554-B07C-2772A35F82E7@apple.com> <4F107D53.9060600@oracle.com> <3BBD9C26-CA01-4EDD-8279-F6C87AB25E61@apple.com> <4F196A63.9060209@oracle.com> Message-ID: <4F1DB20B.7060208@oracle.com> Hello, Note: that the fix just replace one constant to another. And if there is a way to get this system background color in more appropriate way, we can do it later. If there is no other comments I request an approve for the fix again. 20.01.2012 17:21, Sergey Bylokhov wrote: > 18.01.2012 0:29, Mike Swingler wrote: >> On Jan 13, 2012, at 10:52 AM, Sergey Bylokhov wrote: >> >>> 13.01.2012 21:31, Mike Swingler ?????: >>>> On Jan 13, 2012, at 6:27 AM, Sergey Bylokhov wrote: >>>> >>>>> 13.01.2012 6:30, Mike Swingler wrote: >>>>> >>>>>> On Jan 12, 2012, at 4:24 AM, Sergey Bylokhov wrote: >>>>>> >>>>>>> Hello, >>>>>>> This is a request to push the following changes to jdk7u-osx. >>>>>>> The fix has been reviewed on macosx-port-dev mailing list by >>>>>>> Alexander Potochkin. >>>>>>> >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 >>>>>>> Webrev can be found at: >>>>>>> http://cr.openjdk.java.net/~serb/7124530/webrev.00/ >>>>>>> Technical review: >>>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002143.html >>>>>> I don't understand this part: >>>>>> >>>>>> --- old/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 >>>>>> 19:02:19.913935900 +0400 >>>>>> +++ new/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 >>>>>> 19:02:19.557915600 +0400 >>>>>> @@ -81,7 +81,8 @@ >>>>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION] = >>>>>> [NSColor grayColor]; >>>>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION_TEXT] = >>>>>> [NSColor grayColor]; >>>>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION_BORDER] = >>>>>> [NSColor grayColor]; >>>>>> - sColors[java_awt_SystemColor_WINDOW] = >>>>>> [NSColor grayColor]; >>>>>> + const CGFloat color = (CGFloat)0xEE/(CGFloat)0xFF; >>>>>> + sColors[java_awt_SystemColor_WINDOW] = [NSColor >>>>>> colorWithCalibratedRed:color green:color blue:color alpha:1.0f]; >>>>>> sColors[java_awt_SystemColor_WINDOW_BORDER] = >>>>>> [NSColor windowFrameColor]; >>>>>> sColors[java_awt_SystemColor_WINDOW_TEXT] = >>>>>> [NSColor windowFrameTextColor]; >>>>>> sColors[java_awt_SystemColor_MENU] = >>>>>> [NSColor controlBackgroundColor]; >>>>>> >>>>>> Why aren't you just using [NSColor windowBackgroundColor]? >>>>> Only selectedControlColor and selectedTextBackgroundColor are >>>>> supported. >>>>> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DrawColor/Tasks/SystemColors.html#//apple_ref/doc/uid/20000790 >>>>> >>>>> As I understand that`s why swing didn`t use this color. After the >>>>> fix awt and swing use one color (before the fix this color was >>>>> used by swing). >>>>> If this color is wrong, now it`s possible to change it in one place. >>>> I can assure you that the window background color reports the >>>> correct RGB value, even when the background color has changed >>>> between OS versions. You static constant will not. >>>> >>>> We use it today in Java SE 6. >>> jdk6 on my system reports white color which is wrong. Can you please >>> check it(testcase attached). >> The test works fine in Java SE 6 with JFrames and other components. >> The bug where you are getting white from a pure AWT Frame is a side >> effect of something we call the "magic background color", which is >> not applicable to Java 7. > On jdk 6 it works with swing components, because they use > com.apple.laf.AquaNativeResources$CColorPaintUIResource with > RGB[r=238,g=238,b=238] instead of SystemColor.WINDOW with > RGB[r=255,g=255,b=255]. I assume that SystemColor.WINDOW is not used > in jdk 6. >> >> Does +[NSColor windowBackgroundColor] not give you the correct RGB >> value? > Yes. It return white color[r=255,g=255,b=255]. >> >> Regards, >> Mike Swingler >> Apple Inc. >> > > -- Best regards, Sergey. From kumar.x.srinivasan at oracle.COM Mon Jan 23 12:42:50 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 23 Jan 2012 12:42:50 -0800 Subject: [7u4-osx] Please review: 7124089: launcher refactoring v2.0 In-Reply-To: <4F1AFE60.2030506@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F19952C.7070408@oracle.COM> <003F4B79-4D22-4C49-B408-666107C81E86@oracle.com> <4F1AFE60.2030506@oracle.COM> Message-ID: <4F1DC64A.4090401@oracle.COM> I fixed all the indenting in the build scripts to be 2 for consistency, removed tabs in conditionals (vi's set list revealed them), and some minor cleanups. Here is the incremental webrev: http://cr.openjdk.java.net/~ksrini/7124089/webrev.3/webrev.delta/index.html Full webrev: http://cr.openjdk.java.net/~ksrini/7124089/webrev.3/index.html I hope I am good to go now ? Thanks Kumar > Hi Kelly et. al., > > I have beautified/fixed the Makefiles addressing Kellys' comments below: > > 1. Indented the Makefiles correctly. > 2. Annotated with more trailing comments to the if/else/endif clauses > 3. Removed the offending \ escapes > 4. Removed the * from Release.gmk, it turns out the files being copied > were not quite right (missing files), fixed it such that all the > appropriate files > are copied. > 5. Added comments for the MacOSX specific cflags. > > The incremental webrev is here: > http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/webrev.delta/index.html > > > The full webrev is here: > http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/index.html > > Thanks > Kumar > >> On the Makefiles.... >> >> Please refrain from using any wildcards (e.g. * ) in the make rules. >> Better to be explicit, or if necessary >> use something like FILES=$(wildcard $(SOMEDIR)/*) and a cp $(FILES) >> $(SOMEPLACE) >> so that we can at least see in the Makefile log what it really copied. >> >> Please indent the Makefile if/else/endif statements. >> >> Thank you for the trailing comments on the endif's. ;^) >> >> Please try to avoid escaped quotes on the compile lines, use this >> -DX='"abc"' rather than this -DX=\"abc\" >> escaped quotes are very problematic on Windows and I know this isn't >> Windows, but it tempts windows >> people to use it, it will not work in all situations. Where '"abc"' >> does. >> >> Please add a comment on what the -Os compiler option means, and also >> the -x objective-c, I could guess >> but would be better to document it in the makefile. >> >> -kto >> >> On Jan 20, 2012, at 8:24 AM, Kumar Srinivasan wrote: >> >>> Hi All, >>> >>> Based on all the comments from Anthony, Joe and David, >>> here is the modified version: >>> >>> Highlights: >>> 1. re-factored code in solaris directory to be shared with macosx, >>> reducing duplication across the *nixes. >>> >>> 2. adjusted the makefilesto allow the above >>> >>> 2. eliminated all conditionals from the shared java.c >>> >>> 3. added a new launcher regression test for the macosx specific -X >>> options >>> >>> For those who have already reviewed the 0th version, here is an >>> incremental webrev to make it easier reviewing the differences. >>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/webrev.delta/index.html >>> >>> >>> Here is the complete webrev: >>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/index.html >>> >>> Thanks >>> Kumar >>> >>> > From Alan.Bateman at oracle.com Mon Jan 23 13:30:32 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Jan 2012 21:30:32 +0000 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: <4F1D9444.7040807@oracle.com> References: <4F1D9444.7040807@oracle.com> Message-ID: <4F1DD178.4000203@oracle.com> On 23/01/2012 17:09, Michael McMahon wrote: > Can I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/ > > The problem is that poll(2) doesn't seem to work in a specific edge > case tested by JCK, > namely, when a zero length UDP message is sent on a DatagramSocket. > The problem is only > detected on timed reads, ie. normal blocking reads work fine. > > The fix is to make the NET_Timeout() function use select() instead of > poll(). > > Thanks, > Michael. > The first argument to select is s+1, shouldn't is be 1? -alan From michael.x.mcmahon at oracle.com Mon Jan 23 14:32:40 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 23 Jan 2012 22:32:40 +0000 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: <4F1DD178.4000203@oracle.com> References: <4F1D9444.7040807@oracle.com> <4F1DD178.4000203@oracle.com> Message-ID: <4F1DE008.8060103@oracle.com> On 23/01/12 21:30, Alan Bateman wrote: > On 23/01/2012 17:09, Michael McMahon wrote: >> Can I get the following change reviewed please? >> >> http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/ >> >> The problem is that poll(2) doesn't seem to work in a specific edge >> case tested by JCK, >> namely, when a zero length UDP message is sent on a DatagramSocket. >> The problem is only >> detected on timed reads, ie. normal blocking reads work fine. >> >> The fix is to make the NET_Timeout() function use select() instead of >> poll(). >> >> Thanks, >> Michael. >> > The first argument to select is s+1, shouldn't is be 1? > > -alan No, I don't think so. fd_sets are bit masks and you have to specify the highest numbered bit in the mask (+1). - Michael. From Kelly.Ohair at Oracle.Com Mon Jan 23 15:32:19 2012 From: Kelly.Ohair at Oracle.Com (Kelly O'Hair) Date: Mon, 23 Jan 2012 15:32:19 -0800 Subject: [jdk7u-osx] Please review fix for 7130704 In-Reply-To: <4F1DE73F.9070508@oracle.com> References: <4F1DE73F.9070508@oracle.com> Message-ID: Looks good. But the test/jprt.config file should not be needed anymore, could just be deleted or emptied out. -kto On Jan 23, 2012, at 3:03 PM, Jim Holmlund wrote: > Here is the webrev > http://cr.openjdk.java.net/~jjh/7130704/ > > Most of the changes were copied from the macosx-port/macosx-port/langtools repo. The other changes are for the pleasure of jprt. > > Testing: > - langtools build and regression tests run by jprt on all platforms > > Thanks > - jjh > > > From astrange at apple.com Mon Jan 23 18:24:18 2012 From: astrange at apple.com (Alexander Strange) Date: Mon, 23 Jan 2012 21:24:18 -0500 Subject: Request for review 7124224: [macosx] Port's controls are improperly ordered In-Reply-To: <4F1D1FFE.1000503@oracle.com> References: <4F1D1FFE.1000503@oracle.com> Message-ID: On Jan 23, 2012, at 3:53 AM, Alex Menkov wrote: > Hi all, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124224 > webrev: http://javaweb.us.oracle.com/jcg/fx-webrevs/7124224/2/ > > summary of the changes: > - updated the case when AudioDevice has several AudioStreams; > - implemented "virtual" master/mute/balance controls; > - implemented configuration detection (test for control validity); > - control hierarchy was updated to be consistent with other platforms; > - fixed memory leaks. > > Also 2 .c files was removed (issue of macosx-port=>jdk7u-osx integration). Could you post this webrev somewhere publicly accessible? > > regards > Alex From michael.x.mcmahon at oracle.com Tue Jan 24 00:57:57 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 24 Jan 2012 08:57:57 +0000 Subject: hg: jdk7u/jdk7u-osx: 3 new changesets Message-ID: <20120124085757.7597047153@hg.openjdk.java.net> Changeset: 56d27771e217 Author: katleman Date: 2011-12-28 15:40 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/rev/56d27771e217 Added tag jdk7u4-b06 for changeset 1231e80827d0 ! .hgtags Changeset: 1c1d2ab8729b Author: katleman Date: 2012-01-19 09:34 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/rev/1c1d2ab8729b Added tag jdk7u4-b07 for changeset 56d27771e217 ! .hgtags Changeset: 27dc5251e681 Author: michaelm Date: 2012-01-24 08:56 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/rev/27dc5251e681 Merge ! .hgtags From michael.x.mcmahon at oracle.com Tue Jan 24 00:58:06 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 24 Jan 2012 08:58:06 +0000 Subject: hg: jdk7u/jdk7u-osx/corba: 4 new changesets Message-ID: <20120124085809.3CC9847154@hg.openjdk.java.net> Changeset: dbd1cd66b8f0 Author: katleman Date: 2011-12-28 15:40 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/dbd1cd66b8f0 Added tag jdk7u4-b06 for changeset 185304fa5422 ! .hgtags Changeset: 352a72e872ea Author: lana Date: 2012-01-13 11:11 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/352a72e872ea Merge Changeset: b86e44b7ad7b Author: katleman Date: 2012-01-19 09:34 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/b86e44b7ad7b Added tag jdk7u4-b07 for changeset 352a72e872ea ! .hgtags Changeset: 0e8770ade63c Author: michaelm Date: 2012-01-24 08:56 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/0e8770ade63c Merge ! .hgtags From michael.x.mcmahon at oracle.com Tue Jan 24 00:58:19 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 24 Jan 2012 08:58:19 +0000 Subject: hg: jdk7u/jdk7u-osx/hotspot: 2 new changesets Message-ID: <20120124085823.EA80247155@hg.openjdk.java.net> Changeset: 899ddc704d9f Author: katleman Date: 2012-01-19 09:35 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/899ddc704d9f Added tag jdk7u4-b07 for changeset 3804879a5ea0 ! .hgtags Changeset: 24ca10adedb5 Author: michaelm Date: 2012-01-24 08:56 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/24ca10adedb5 Merge ! .hgtags From michael.x.mcmahon at oracle.com Tue Jan 24 00:58:41 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 24 Jan 2012 08:58:41 +0000 Subject: hg: jdk7u/jdk7u-osx/jaxp: 4 new changesets Message-ID: <20120124085845.6586E47156@hg.openjdk.java.net> Changeset: 77600fe5b02c Author: katleman Date: 2011-12-28 15:41 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/77600fe5b02c Added tag jdk7u4-b06 for changeset 4ec17260df0f ! .hgtags Changeset: 4b20a76b4f0f Author: lana Date: 2012-01-13 11:11 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/4b20a76b4f0f Merge - build-defs.xml - build-drop-template.xml - jaxp.properties - patches/jaxp_src/README Changeset: 052450632c84 Author: katleman Date: 2012-01-19 09:35 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/052450632c84 Added tag jdk7u4-b07 for changeset 4b20a76b4f0f ! .hgtags Changeset: d3b2c77daf2c Author: michaelm Date: 2012-01-24 08:56 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/d3b2c77daf2c Merge ! .hgtags From michael.x.mcmahon at oracle.com Tue Jan 24 00:58:55 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 24 Jan 2012 08:58:55 +0000 Subject: hg: jdk7u/jdk7u-osx/jaxws: 3 new changesets Message-ID: <20120124085855.1AE2647157@hg.openjdk.java.net> Changeset: fc2b89be0b07 Author: katleman Date: 2011-12-28 15:41 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxws/rev/fc2b89be0b07 Added tag jdk7u4-b06 for changeset 961f897b134d ! .hgtags Changeset: e2bb49acbbc2 Author: katleman Date: 2012-01-19 09:35 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxws/rev/e2bb49acbbc2 Added tag jdk7u4-b07 for changeset fc2b89be0b07 ! .hgtags Changeset: 2f37da2e5657 Author: michaelm Date: 2012-01-24 08:56 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxws/rev/2f37da2e5657 Merge ! .hgtags From michael.x.mcmahon at oracle.com Tue Jan 24 01:00:01 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 24 Jan 2012 09:00:01 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 26 new changesets Message-ID: <20120124090423.ADBF347158@hg.openjdk.java.net> Changeset: d8462705e74c Author: chegar Date: 2012-01-16 18:05 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d8462705e74c 7129083: CookieManager does not store cookies if url is read before setting cookie manager Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java + test/sun/net/www/http/HttpClient/CookieHttpClientTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java Changeset: df5426ea5204 Author: chegar Date: 2012-01-17 19:51 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/df5426ea5204 6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol) Reviewed-by: alanb - test/java/io/File/BlockIsDirectory.java Changeset: 5470f5450566 Author: alanb Date: 2012-01-18 11:08 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5470f5450566 7130398: ProblemList.txt updates (1/2012) Reviewed-by: chegar ! test/ProblemList.txt Changeset: 730a7019e5bc Author: coffeys Date: 2012-01-18 11:12 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/730a7019e5bc 7058133: Javah should use the freshly built classes instead of those from the BOOTDIR jdk Reviewed-by: valeriep ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile Changeset: de5e9bf5b313 Author: valeriep Date: 2012-01-18 13:02 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/de5e9bf5b313 7088989: Improve the performance for T4 by utilizing the newly provided crypto APIs Summary: Added the OracleUcrypto provider for utilizing the Solaris ucrypto API. Reviewed-by: weijun ! make/com/oracle/Makefile + make/com/oracle/net/Makefile + make/com/oracle/nio/Makefile + make/com/oracle/security/ucrypto/FILES_c.gmk + make/com/oracle/security/ucrypto/Makefile + make/com/oracle/security/ucrypto/mapfile-vers + make/com/oracle/util/Makefile ! src/share/lib/security/java.security-solaris ! test/Makefile + test/com/oracle/security/ucrypto/TestAES.java + test/com/oracle/security/ucrypto/TestDigest.java + test/com/oracle/security/ucrypto/TestRSA.java + test/com/oracle/security/ucrypto/UcryptoTest.java ! test/java/security/Provider/DefaultPKCS11.java Changeset: 9ec80e94c5cd Author: valeriep Date: 2012-01-18 19:33 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/9ec80e94c5cd 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck. Summary: Changed patternCache from synchronizedMap to ConcurrentHashMap. Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java Changeset: b2488252ba0c Author: valeriep Date: 2012-01-18 19:35 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/b2488252ba0c 7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException Summary: Changed to always use full transformation as provider properties. Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! test/javax/crypto/Cipher/GetMaxAllowed.java Changeset: aa79e3ead22d Author: dbuck Date: 2012-01-19 12:00 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/aa79e3ead22d 7083621: Add fontconfig file for OEL6 and rename RH/O EL 5 file so that it is picked up for all 5.x updates Reviewed-by: bae, prr ! make/sun/awt/Makefile Changeset: e931d7fb0043 Author: fparain Date: 2012-01-19 01:02 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/e931d7fb0043 7104647: Adding a diagnostic command framework Reviewed-by: mchung, dholmes ! make/common/Release.gmk ! make/java/management/mapfile-vers ! make/launchers/Makefile ! make/sun/tools/Makefile + src/linux/doc/man/jcmd.1 + src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java + src/share/classes/com/sun/management/DiagnosticCommandInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java + src/share/classes/sun/tools/jcmd/Arguments.java + src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/HotSpotDiagnostic.c + src/solaris/doc/sun/man/man1/jcmd.1 + test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java ! test/sun/tools/common/CommonSetup.sh + test/sun/tools/jcmd/dcmd-script.txt + test/sun/tools/jcmd/help_help.out + test/sun/tools/jcmd/jcmd-Defaults.sh + test/sun/tools/jcmd/jcmd-f.sh + test/sun/tools/jcmd/jcmd-help-help.sh + test/sun/tools/jcmd/jcmd-help.sh + test/sun/tools/jcmd/jcmd-pid.sh + test/sun/tools/jcmd/jcmd_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output2.awk + test/sun/tools/jcmd/usage.out Changeset: 029394aa3e44 Author: katleman Date: 2011-12-28 15:41 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/029394aa3e44 Added tag jdk7u4-b06 for changeset 2c1b789d1803 ! .hgtags Changeset: d34bb20fc52e Author: lana Date: 2012-01-13 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d34bb20fc52e Merge Changeset: 73961d6fc494 Author: katleman Date: 2012-01-19 09:35 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/73961d6fc494 Added tag jdk7u4-b07 for changeset d34bb20fc52e ! .hgtags Changeset: 435a3314549f Author: cgruszka Date: 2011-09-16 11:13 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/435a3314549f Merge Changeset: a73a15b22a0b Author: cgruszka Date: 2011-09-23 10:25 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/a73a15b22a0b Merge Changeset: 1f54ad90c9c1 Author: cgruszka Date: 2011-10-17 22:15 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/1f54ad90c9c1 7099017: jdk7u2-dev does not build Summary: changes to skip demo/DEMOS_LICENSE and sample/SAMPLES_LICENSE when building OPENJDK Reviewed-by: ohair, billyh ! make/common/Release.gmk Changeset: 070b4b98885d Author: cgruszka Date: 2011-10-25 19:25 -0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/070b4b98885d Merge Changeset: 5ec14f014e10 Author: cgruszka Date: 2011-11-07 21:04 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5ec14f014e10 Merge - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - test/java/io/etc/FileDescriptorSharing.java Changeset: c6f2bd012ddf Author: cgruszka Date: 2011-11-17 15:48 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/c6f2bd012ddf Merge Changeset: ac81c77a109e Author: cgruszka Date: 2011-12-01 18:17 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/ac81c77a109e Merge Changeset: aa715726ab63 Author: cgruszka Date: 2011-12-12 15:53 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/aa715726ab63 Merge Changeset: 894df977ab68 Author: cgruszka Date: 2011-12-15 13:09 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/894df977ab68 Merge Changeset: e79e9c7316ab Author: cgruszka Date: 2011-12-22 14:53 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/e79e9c7316ab Merge Changeset: 98ad30ab22be Author: cgruszka Date: 2012-01-09 19:32 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/98ad30ab22be Merge Changeset: bcceb5734a34 Author: cgruszka Date: 2012-01-20 00:13 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/bcceb5734a34 Merge Changeset: 573f188ff65e Author: lana Date: 2012-01-20 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/573f188ff65e Merge Changeset: 831af87f8b99 Author: michaelm Date: 2012-01-24 08:56 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/831af87f8b99 Merge ! .hgtags ! make/com/oracle/net/Makefile ! make/common/Release.gmk ! make/sun/awt/Makefile ! make/sun/security/ec/Makefile ! make/sun/security/pkcs11/Makefile ! test/Makefile ! test/ProblemList.txt - test/java/io/File/BlockIsDirectory.java From michael.x.mcmahon at oracle.com Tue Jan 24 01:04:34 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 24 Jan 2012 09:04:34 +0000 Subject: hg: jdk7u/jdk7u-osx/langtools: 4 new changesets Message-ID: <20120124090443.DD8BD47159@hg.openjdk.java.net> Changeset: c747f413d531 Author: katleman Date: 2011-12-28 15:41 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/c747f413d531 Added tag jdk7u4-b06 for changeset 083eac71addf ! .hgtags Changeset: 10a63f9cdcb9 Author: lana Date: 2012-01-13 11:13 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/10a63f9cdcb9 Merge Changeset: 4be7205dae89 Author: katleman Date: 2012-01-19 09:35 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/4be7205dae89 Added tag jdk7u4-b07 for changeset 10a63f9cdcb9 ! .hgtags Changeset: 05bb743c223d Author: michaelm Date: 2012-01-24 08:56 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/05bb743c223d Merge ! .hgtags From alexey.menkov at oracle.com Tue Jan 24 01:11:07 2012 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 24 Jan 2012 13:11:07 +0400 Subject: Request for review 7124224: [macosx] Port's controls are improperly ordered In-Reply-To: References: <4F1D1FFE.1000503@oracle.com> Message-ID: <4F1E75AB.8080301@oracle.com> publicly accessible webrev: http://cr.openjdk.java.net/~amenkov/7124224/webrev.00/ regards Alex On 24.01.2012 06:24, Alexander Strange wrote: > > On Jan 23, 2012, at 3:53 AM, Alex Menkov wrote: > >> Hi all, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124224 >> webrev: http://javaweb.us.oracle.com/jcg/fx-webrevs/7124224/2/ >> >> summary of the changes: >> - updated the case when AudioDevice has several AudioStreams; >> - implemented "virtual" master/mute/balance controls; >> - implemented configuration detection (test for control validity); >> - control hierarchy was updated to be consistent with other platforms; >> - fixed memory leaks. >> >> Also 2 .c files was removed (issue of macosx-port=>jdk7u-osx integration). > > Could you post this webrev somewhere publicly accessible? > >> >> regards >> Alex > > From artem.ananiev at oracle.com Tue Jan 24 02:00:26 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 24 Jan 2012 14:00:26 +0400 Subject: Review request for 7124387: [macosx] Application freezes on dispose window, created by JFileChooser In-Reply-To: <4F1DA139.1050902@oracle.com> References: <4F1DA139.1050902@oracle.com> Message-ID: <4F1E813A.1020703@oracle.com> Looks fine. Thanks, Artem On 1/23/2012 10:04 PM, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7124387/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124387 > > on MacOS it takes more time for the test to warm, > so the 10 seconds timeout is not enough. > > I removed the internal timeout check > if (!MUX.await(10, TimeUnit.SECONDS)) { > throw new RuntimeException("Timeout"); > } > and rely on the default jtreg's timeout. > > Thanks > alexp From artem.ananiev at oracle.com Tue Jan 24 02:04:20 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 24 Jan 2012 14:04:20 +0400 Subject: Review request for 7124316: [macosx] Passive and Peered IMF Client does not cope with input methods In-Reply-To: <4F1DAFA5.9060008@oracle.com> References: <4F1DAFA5.9060008@oracle.com> Message-ID: <4F1E8224.1060208@oracle.com> Hi, Alex, did you consider using LWComponentPeer's sendEventToDelegate() method instead of AWTAccessor? Thanks, Artem On 1/23/2012 11:06 PM, Alexander Zuev wrote: > Hello, > > please review the following fix: > http://cr.openjdk.java.net/~kizune/7124316/webrev.01/ > > the bug description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124316 > The previous fix, while needed, solved problem only for a small set of > locales. > This fix should solve it for all the locales for heavyweight text > components. > > Thanks, > Alex From michael.x.mcmahon at oracle.com Tue Jan 24 02:16:54 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 24 Jan 2012 10:16:54 +0000 Subject: [jdk7u-osx] Request for approval for CR 7130948: Kerberos and JGSS JCK tests failing [macosx] Message-ID: <4F1E8516.7040405@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130948 Webrev: http://cr.openjdk.java.net/~michaelm/7130948/webrev.2/ Author: weijun Reviewed by: michaelm, bino, mullan Thanks, Michael. From michael.x.mcmahon at oracle.com Tue Jan 24 02:21:36 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 24 Jan 2012 10:21:36 +0000 Subject: [jdk7u-osx] Request for approval for CR 7126979: (props) JCK test java_lang/System/GetProperties.java failing [macosx] Message-ID: <4F1E8630.6040401@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126979 Webrev: http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/ Reviewed by: skovatch Thanks, Michael. From michael.x.mcmahon at oracle.com Tue Jan 24 02:41:43 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 24 Jan 2012 10:41:43 +0000 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: <4F1E8697.3020602@oracle.com> References: <4F1D9444.7040807@oracle.com> <4F1DD178.4000203@oracle.com> <4F1DE008.8060103@oracle.com> <4F1E8697.3020602@oracle.com> Message-ID: <4F1E8AE7.8010803@oracle.com> On 24/01/12 10:23, Chris Hegarty wrote: > I'm OK with this as it, but here are a few comments: > > The logic around the initial setting of the timeout seems a little > unnecessary (and the additional pointer), but not wrong. > Chris, The setting of the timeval could be combined ok, but I wanted to avoid calling gettimeofday() in the case where timeout == 0 > The comments should also be updated. > Yes, I'll do that. It still refers to poll() instead of select() now. I'll add a comment about the bug too. > Given this problem should the build be setting USE_SELECT? > I thought about that, and decided against it for two reasons. 1) it's only used by PlainSocketImpl in the networking code, and that usage doesn't seem to be affected by this problem. poll() is potentially a little more efficient than select() also 2) USE_SELECT is referenced in other places in other native code (in AWT) and I don't want to affect those usages. Granted that raises a question as to whether they are affected by this bug. But, I don't believe they are since, as far as I can see UDP sockets aren't used there. - Michael > -Chris. > > On 01/23/12 10:32 PM, Michael McMahon wrote: >> On 23/01/12 21:30, Alan Bateman wrote: >>> On 23/01/2012 17:09, Michael McMahon wrote: >>>> Can I get the following change reviewed please? >>>> >>>> http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/ >>>> >>>> The problem is that poll(2) doesn't seem to work in a specific edge >>>> case tested by JCK, >>>> namely, when a zero length UDP message is sent on a DatagramSocket. >>>> The problem is only >>>> detected on timed reads, ie. normal blocking reads work fine. >>>> >>>> The fix is to make the NET_Timeout() function use select() instead of >>>> poll(). >>>> >>>> Thanks, >>>> Michael. >>>> >>> The first argument to select is s+1, shouldn't is be 1? >>> >>> -alan >> No, I don't think so. fd_sets are bit masks and you have to specify the >> highest numbered bit in the >> mask (+1). >> >> - Michael. From Alan.Bateman at oracle.com Tue Jan 24 02:46:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Jan 2012 10:46:54 +0000 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: <4F1DE008.8060103@oracle.com> References: <4F1D9444.7040807@oracle.com> <4F1DD178.4000203@oracle.com> <4F1DE008.8060103@oracle.com> Message-ID: <4F1E8C1E.3040100@oracle.com> On 23/01/2012 22:32, Michael McMahon wrote: > No, I don't think so. fd_sets are bit masks and you have to specify > the highest numbered bit in the > mask (+1). Sorry, I wasn't thinking, it's nfds+1. In that case, I think the change is okay although having t, t1, and t1_p looks a bit messy. It might be cleaner to rename t to something like "tod" and move it to be a local in the places where gettimeofday is used. That you allow you to rename t1 and t1_p and t and tp which I think would be more readable. -Alan From michael.x.mcmahon at oracle.com Tue Jan 24 03:19:23 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 24 Jan 2012 11:19:23 +0000 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: <4F1E8C1E.3040100@oracle.com> References: <4F1D9444.7040807@oracle.com> <4F1DD178.4000203@oracle.com> <4F1DE008.8060103@oracle.com> <4F1E8C1E.3040100@oracle.com> Message-ID: <4F1E93BB.9090108@oracle.com> On 24/01/12 10:46, Alan Bateman wrote: > On 23/01/2012 22:32, Michael McMahon wrote: >> No, I don't think so. fd_sets are bit masks and you have to specify >> the highest numbered bit in the >> mask (+1). > Sorry, I wasn't thinking, it's nfds+1. > > In that case, I think the change is okay although having t, t1, and > t1_p looks a bit messy. It might be cleaner to rename t to something > like "tod" and move it to be a local in the places where gettimeofday > is used. That you allow you to rename t1 and t1_p and t and tp which I > think would be more readable. > > -Alan Ok, I've updated the webrev to do the above and to adjust the comments http://cr.openjdk.java.net/~michaelm/7131399/webrev.2/ Thanks Michael. From Alan.Bateman at oracle.com Tue Jan 24 03:22:28 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Jan 2012 11:22:28 +0000 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: <4F1E93BB.9090108@oracle.com> References: <4F1D9444.7040807@oracle.com> <4F1DD178.4000203@oracle.com> <4F1DE008.8060103@oracle.com> <4F1E8C1E.3040100@oracle.com> <4F1E93BB.9090108@oracle.com> Message-ID: <4F1E9474.1070304@oracle.com> On 24/01/2012 11:19, Michael McMahon wrote: > Ok, I've updated the webrev to do the above and to adjust the comments > > http://cr.openjdk.java.net/~michaelm/7131399/webrev.2/ > This looks much cleaner. I'd probably use tp = NULL myself but what you have is okay. -Alan From anthony.petrov at oracle.com Tue Jan 24 03:43:23 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 24 Jan 2012 15:43:23 +0400 Subject: [7u-osx] Request for approval for 7131038: [macosx] Document usage of -XstartOnFirstThread and -Xdock:* Message-ID: <4F1E995B.20906@oracle.com> Hello, This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131038 Webrev: http://cr.openjdk.java.net/~anthony/x-10-Xflags-7131038.0/ The changes to the specification are approved by CCC. -- best regards, Anthony From michael.x.mcmahon at oracle.com Tue Jan 24 03:47:35 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 24 Jan 2012 11:47:35 +0000 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: References: <4F1D9444.7040807@oracle.com> Message-ID: <4F1E9A57.8070004@oracle.com> On 24/01/12 11:27, Damjan Jovanovic wrote: > > > On Mon, Jan 23, 2012 at 7:09 PM, Michael McMahon > > > wrote: > > Can I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/ > > > The problem is that poll(2) doesn't seem to work in a specific > edge case tested by JCK, > namely, when a zero length UDP message is sent on a > DatagramSocket. The problem is only > detected on timed reads, ie. normal blocking reads work fine. > > The fix is to make the NET_Timeout() function use select() instead > of poll(). > > Thanks, > Michael. > > > > > > Hi > > I don't work at Oracle or anything, but IMHO this is a bad idea. > > The finite length bitset used by select() means that there is a limit > on the maximum integer that can fit in the bitset. With 1024 bits (a > common value), you only have to create >= 1021 file descriptors (and > of course stdin/stdout/stderr) to exceed this limit, and end up with a > file descriptor for which FD_SET breaks. This will be the case even if > that file descriptor is the only file descriptor you are trying to add > to the bitset. > > Please reconsider. > > Regards > Damjan Jovanovic > Damjan, We can only deal with a finite number of file descriptors already in this file, although the actual value can be set as high as required through setrlimit(). getFdEntry() checks that the fd number is within the particular limits and all I/O operations will return EBADF if they happen to be outside. This was the case even when poll() was used. - Michael From anthony.petrov at oracle.com Tue Jan 24 04:01:21 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 24 Jan 2012 16:01:21 +0400 Subject: Review request for 7130360: [macosx] Packed JInternalFrame invisible on Aqua L&F In-Reply-To: <4F1D86F1.3040406@oracle.com> References: <4F1D86F1.3040406@oracle.com> Message-ID: <4F1E9D91.8030006@oracle.com> Looks fine. -- best regards, Anthony On 1/23/2012 8:12 PM, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7130360/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130360 > > AquaInternalFrameUI.minimumLayoutSize() doesn't override any method > and is never called from any other classes, so I removed it > > The LayoutManager in BasicInternalFrameUI is private, > so I overrode getPreferredSize() method to make sure that it never > returns the size less then the minimal size > > Thanks > alexp > From Alan.Bateman at oracle.com Tue Jan 24 04:03:47 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Jan 2012 12:03:47 +0000 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: <4F1E9A57.8070004@oracle.com> References: <4F1D9444.7040807@oracle.com> <4F1E9A57.8070004@oracle.com> Message-ID: <4F1E9E23.8040008@oracle.com> On 24/01/2012 11:47, Michael McMahon wrote: > > Damjan, > > We can only deal with a finite number of file descriptors already in > this file, although the actual > value can be set as high as required through setrlimit(). getFdEntry() > checks that the fd number > is within the particular limits and all I/O operations will return > EBADF if they happen to be outside. > This was the case even when poll() was used. > > - Michael Another point is that this switching from poll to select is really just a temporary band aid in order to get this going. Either poll gets fixed or this code is changed to use kqueue. Without some initial band aid we have test failures and a compatibility issue. This goes for other areas of the code too and it will take a bit of time to clean up all areas. -Alan From anthony.petrov at oracle.com Tue Jan 24 04:08:31 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 24 Jan 2012 16:08:31 +0400 Subject: Review request for 7124393: [macosx] JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click In-Reply-To: <4F1D99F6.9060709@oracle.com> References: <4F1D99F6.9060709@oracle.com> Message-ID: <4F1E9F3F.4030705@oracle.com> Hi Alex, I'm OK with realSync() calls, but unsure about the stopCellEditing() call. Indeed, using a Swing method should produce correct results. However, I think that this regression test is supposed to emulate user's actions, not Swing calls, isn't it? If so, we should either find a cross-platform events that finish editing and use Robot to emulate them, or use the "os.name" property and synthesize different user actions on different platforms. Please correct me if my assumption is wrong. -- best regards, Anthony On 1/23/2012 9:33 PM, Alexander Potochkin wrote: > Hello > > Please review the following fix: > http://cr.openjdk.java.net/~alexp/7124393/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124393 > > The bug is in the test, F2 doesn't stop editing on MacOS, > we should not use the keyboard to commit the data > > the test is also updated > to access the Swing methods on the Event Dispatching Thread only > > Thanks > alexp From paul.hohensee at oracle.com Tue Jan 24 06:20:24 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 24 Jan 2012 09:20:24 -0500 Subject: [jdk7u-osx] Request for approval for CR 7130948: Kerberos and JGSS JCK tests failing [macosx] In-Reply-To: <4F1E8516.7040405@oracle.com> References: <4F1E8516.7040405@oracle.com> Message-ID: <4F1EBE28.8090709@oracle.com> Approved. Paul On 1/24/12 5:16 AM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130948 > > Webrev: http://cr.openjdk.java.net/~michaelm/7130948/webrev.2/ > > Author: weijun > > Reviewed by: michaelm, bino, mullan > > Thanks, > Michael. From paul.hohensee at oracle.com Tue Jan 24 06:21:35 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 24 Jan 2012 09:21:35 -0500 Subject: [jdk7u-osx] Request for approval for CR 7126979: (props) JCK test java_lang/System/GetProperties.java failing [macosx] In-Reply-To: <4F1E8630.6040401@oracle.com> References: <4F1E8630.6040401@oracle.com> Message-ID: <4F1EBE6F.2080401@oracle.com> Approved. Paul On 1/24/12 5:21 AM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126979 > > Webrev: http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/ > > Reviewed by: skovatch > > Thanks, > Michael. From anton.tarasov at oracle.com Tue Jan 24 07:23:14 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 24 Jan 2012 18:23:14 +0300 Subject: Review request for 7129825 - [macosx] Native activation is not changed when focusing other frame's owned window Message-ID: <4F1ECCE2.4030509@oracle.com> Hello, Please review a fix for 7129825. webrev: http://cr.openjdk.java.net/~ant/7129825/webrev.0/ The fix contains the following changes: 1. When a simple window requests focus its owner is properly activated. 2. The code that requests focus on a window from LWWindowPeer initial mouse handler is removed. It duplicates the logic implemented by LWWindowPeer.handleEvent(). Additionally, a window requests focus when its unfocusable component is clicked, or its empty spot is clicked. In this case KeyboardFocusManager sets focus on the window's default component. 3. The nativeIsApplicationActive() method is moved to LWToolkit. 4. Two native methods are changed to be called synchronously (performOnMainThreadWaiting:YES) as they are called from EDT. 5. Some minor changes. Tested with test/java/awt/Focus/* against regressions. Thanks, Anton. From paul.hohensee at oracle.com Tue Jan 24 06:23:54 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 24 Jan 2012 09:23:54 -0500 Subject: [7u-osx] Request for approval for 7131038: [macosx] Document usage of -XstartOnFirstThread and -Xdock:* In-Reply-To: <4F1E995B.20906@oracle.com> References: <4F1E995B.20906@oracle.com> Message-ID: <4F1EBEFA.304@oracle.com> Approved. Paul On 1/24/12 6:43 AM, Anthony Petrov wrote: > Hello, > > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131038 > > Webrev: http://cr.openjdk.java.net/~anthony/x-10-Xflags-7131038.0/ > > The changes to the specification are approved by CCC. > > -- > best regards, > Anthony From alexander.zuev at oracle.com Tue Jan 24 07:28:10 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 24 Jan 2012 18:28:10 +0300 Subject: Review request for 7124316: [macosx] Passive and Peered IMF Client does not cope with input methods In-Reply-To: <4F1E8224.1060208@oracle.com> References: <4F1DAFA5.9060008@oracle.com> <4F1E8224.1060208@oracle.com> Message-ID: <4F1ECE0A.9020301@oracle.com> Artem, i did, but this method itself will need to be updated then and all it actually does is doing a bunch of irrelevant checks and then creates a new event so i will have to add a machinery that will do it for InputMethodEvent and then finally just uses AWTAccessor. It's really an overkill - we might do it much simpler just by forwarding existing event to the right component. Thanks, Alex On 1/24/12 13:04, Artem Ananiev wrote: > Hi, Alex, > > did you consider using LWComponentPeer's sendEventToDelegate() method > instead of AWTAccessor? > > Thanks, > > Artem > > On 1/23/2012 11:06 PM, Alexander Zuev wrote: >> Hello, >> >> please review the following fix: >> http://cr.openjdk.java.net/~kizune/7124316/webrev.01/ >> >> the bug description is here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124316 >> The previous fix, while needed, solved problem only for a small set of >> locales. >> This fix should solve it for all the locales for heavyweight text >> components. >> >> Thanks, >> Alex From anthony.petrov at oracle.com Tue Jan 24 06:39:07 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 24 Jan 2012 18:39:07 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> <4F156177.9050007@oracle.com> <4F15C6ED.3000702@oracle.com> Message-ID: <4F1EC28B.9000904@oracle.com> Hi Mike, Thanks for proposing an alternative solution for this issue. I agree I find it more correct. Please take a look at the new fix at: http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.2/ Note that I decided to eliminate the changes from the CWrapper.NSWindow.addChildWindow() since the CWrapper is supposed to be a transparent proxy for Cocoa API w/o adding some logic to the wrapped methods. So instead I'm introducing CWrapper.NSWindow.setLevel() and using it where appropriate in the CPlatformWindow. -- best regards, Anthony On 1/18/2012 3:36 AM, Mike Swingler wrote: > On Jan 17, 2012, at 11:07 AM, Anthony Petrov wrote: > >> Hi Mike, >> >> On 1/17/2012 8:52 PM, Mike Swingler wrote: >>> On Jan 17, 2012, at 3:54 AM, Anthony Petrov wrote: >>>> On 1/16/2012 8:24 PM, Mike Swingler wrote: >>>>> I still don't understand why the list of hardcoded window levels needs to be included. Can't you just compare the window levels by their NSInteger numeric values? >>>> There are two reasons for not using the numeric values directly, or comparing them directly: >>>> >>>> 1. Cocoa specification doesn't define the numeric values for the NS*WindowLevel constants. They may (theoretically) change in the future. As long as they aren't specified, we don't want to rely on their current values. >>> Why do you have to know the values at all? Couldn't you just reset the child window level if it's different after the parent/child operation? After I re-read what you are trying to accomplish, even numeric comparison seems inappropriate. >> I've already answered this question to Leonid on Jan 12, but I'll copy my reply here for your convenience: >> >> If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >> >> Now, when we call -addChildWindow:, we really want to update the level >> of the child window so that both the parent and the child share the same >> window level. The if check ensures that we don't reset the level of the >> child window back to normal in this case. > > I think what you really want to do here is check if the parent and the child are Always-On-Top, and then reset the window level of the child only when the child is AOT and the parent is not. -[NSWindow addChildWindow:order:] forces the child to the same level as the parent already. > > I'd avoid trying to infer if there is any "higher" vs. "lower" relationship between the parent based on the window level as seen from AppKit using that table. > >>>> 2. There's a reference to the Quartz spec that defines the kCG*WindowLevel constants as a enum. The NS*WindowLevel macros are defined using these constants. However, if you take a look at the order of the constants in that enum [1] (and therefore their relative numerical order), you may notice that they don't exactly reflect the relative visual z-order between the levels as defined in the Cocoa spec [2]. E.g. kCGModalPanelWindowLevelKey is greater than kCGDockWindowLevelKey, while NSDockWindowLevel is defined being visually above the NSModalPanelWindowLevel. As such, a direct numeric comparison of window levels produces incorrect results. >>> Have you tried setting something at the "dock" level? That level may have been true for the NextStep dock, but not the Mac. And BTW: the NSDockWindowLevel is deprecated. Don't use it. >> Yes, this is a good tip. I've removed the NSDockWindowLevel from the array. An updated fix is available at: >> >> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.1/ > > Also, NSSubmenuWindowLevel and NSTornOffMenuWindowLevel are synonyms for each other, and end up being the same value. The documentation for NSWindow [2] says "The constant NSTornOffMenuWindowLevel is preferable to its synonym, NSSubmenuWindowLevel.", but again, I'd recommend just removing the table and higher/lower comparison. > >>>> The array of hardcoded window levels allows us to convert between window levels ordered arbitrarily and integer values ordered according to their visual z-order. This allows us to compare windows level with respect to their relative z-order as specified by Cocoa documentation. >>> These constants are for assignment based on intention, not simple comparison of stacking level. They have behavioral meaning beyond just simple visual level ordering. Windows above the normal window level will disappear in Expos?/Mission Control, and certain levels will float in all Spaces. Other levels exclude the window from Cmd-~ keyboard window cycling, or showing up in the Dock window menu. Please, please, please test the side effects of these changes before just popping windows into different levels. >> Could you please clarify what exact "different levels" you're talking about here? AWT currently uses only two window levels: NSNormalWindowLevel is used for regular windows, and NSFloatingWindowLevel for always-on-top windows (see AWTWindow.m). This code is already in the repository, and tests for always-on-top windows do work OK. > > The AWT will need to use more levels, and it's not clear how parent/child relationships need to affect these window levels. NSFloatingWindowLevel is used for palettes (like non-modal parented dialogs with small title bars), which do not participate in Expos?/Mission Control. NSModalPanelWindowLevel is what app-modal dialogs (like Open/Save) live at, which you might want "always on top" windows to be on top of too. Obviously popup menus should be at NSPopUpMenuWindowLevel. Another complication we encountered in Java SE 6 is full-screen exclusive windows, which still expect popups to be visible, so we had to push them above the NSScreenSaverWindowLevel as a gross hacky workaround. > > In your testing have you moved these windows between spaces? Can you separate them between spaces? Do the windows show as visible in Mission Control? When you right-click on the Dock icon, do they show in the window list? Should they? When you press Cmd-~, do they participate in the window cycle? These are the manual tests we do every time we futz with something like "window level" or "child windows" in Java SE 6, which can't easily be automated. > >> So back to the fix we're discussing, in reality the oldChildLevel in the CWrapper.addChildWindow() implementation can be either of these two levels, but not anything else. I guess we could simplify the fix and only include these two levels in the ORDERED_LEVELS{} array. I suppose Lubomir just wanted to provide a more generic and complete implementation that won't break if we ever start using any other levels in the future (or e.g. if OS temporarily puts our window on some other level). This is certainly unlikely, of course, however, I see absolutely no problems with an implementation of compareWindowLevels() that can work with all window levels officially supported by Cocoa, not just the two that we use currently. > > In the future, I agree, the existing child window level will have to be more than two values, but either it should be allowed to inherit from it's parent, or it should be reset to the original value. This is really a decision to be made based on the Java model state, and not an observed property in the AppKit model which is being changed behind your back and compared against a table. Right now the only decision hooks on if the AOT state of the parent and child, which is already present in the styleBits of the window. > > See the IS, SET, and MASK macro usage in AWTWindow.m for more info. You could make a simple accessor to report if ALWAYS_ON_TOP is set on both the parent and the child. > >>> The safest thing to do (if it works) is just to simply re-assign the window level after adding the child to the parent, but you will have to recursively descend into the child windows of the child, because setting the window level sets the level of all the children too (and changes their collection/spaces/cycle behavior). This may not be an issue if you never change a child window's parent. >> I've clarified above why simple reassignment won't work well. > > Got it. I think I've straightened out my thinking on this too, and paged back years of hacks and corner cases I would have preferred to have forgotten... > > Cheers, > Mike Swingler > Apple Inc. > >> -- >> best regards, >> Anthony >> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>>> Does this clarify the need for the array of window levels? Do you have any other concerns regarding the fix? >>>> >>>> [1] http://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/tdef/CGWindowLevelKey >>>> >>>> [2] http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Window_Levels >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> >>>>> Regards, >>>>> Mike Swingler >>>>> Apple Inc. >>>>> On Jan 14, 2012, at 7:40 PM, Mike Swingler wrote: >>>>>> In the course of preparing to contribute our current window stacking algorithm, I realized that there was a pair of internal SPI calls it was making. In the next revision we ship of the JavaRuntimeSupport.framework we can provide cover methods of these SPI, however that is of little benefit to the OpenJDK port in the immediate here-and-now. >>>>>> >>>>>> For now, using -addChildWindow: will be sufficient, however, we can provide an alternate implementation that uses a new pair of category methods on NSWindow if -respondsToSelector: shows that they are available: >>>>>> - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; >>>>>> - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; >>>>>> >>>>>> These functions will allow the window server to move each child window with respect to it's parent's level, but without being added to it's movement group. >>>>>> >>>>>> Once customers get an updated JavaNativeFoundation.framework by either Java update or OS update, the implementation will switch over dynamically at runtime. >>>>>> >>>>>> How does this sound for a plan? >>>>>> >>>>>> Regards, >>>>>> Mike Swingler >>>>>> Apple Inc. >>>>>> >>>>>> On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com wrote: >>>>>> >>>>>>> We fought this one in SWT and ended up going with the puppy route. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> On 12/01/2012 2:57 PM, Anthony Petrov wrote: >>>>>>>> Hi Mike, >>>>>>>> >>>>>>>> I recall we've discussed this issue with you back in 2010. Unfortunately, I wasn't able to implement anything like this that would work reliably back then (and I tried hard, really), that's why we ended up with -addChildWindow:. Note that JCK is very happy with this implementation, and so are we, I presume. As long as child windows receive their respective MOVE events, it seems that everything is all right. Besides, such behavior is very Mac-friendly, making Java apps behave like native apps. >>>>>>>> >>>>>>>> I realize that for some developers this behavior may be inconvenient. But then again, why not listen to MOVE events on the parent frame and compensate for its movement repositioning all its children? ( :) yeah, yeah, I know, sounds weird, but... as Steve says, you gotta do what you gotta do... I mean, there's a workaround at least!) >>>>>>>> >>>>>>>> So, if you or anyone else wish to contribute an alternative implementation for owned windows, that would be greatly appreciated. Otherwise I'm afraid we have to stick with using -addChildWindow: for now since we simply don't have a better solution. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>>>>>>>> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). >>>>>>>>> >>>>>>>>> In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Mike Swingler >>>>>>>>> Apple Inc. >>>>>>>>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>>>>>>>> >>>>>>>>>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>>>>>>>> >>>>>>>>>>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> best regards, >>>>>>>>>>> Anthony >>>>>>>>>>> >>>>>>>>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>>>>>>>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>>>>>>>>>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>>>>>>>>>>> >>>>>>>>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for taking a look at the fix. >>>>>>>>>>>>> >>>>>>>>>>>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>>>>>>>>> >>>>>>>>>>>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> best regards, >>>>>>>>>>>>> Anthony >>>>>>>>>>>>> >>>>>>>>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>>>>>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>> Anthony > From sergey.bylokhov at oracle.com Tue Jan 24 06:59:22 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Jan 2012 18:59:22 +0400 Subject: Request for review: 7124524 - OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer In-Reply-To: <4F15717D.5090105@oracle.com> References: <4F15717D.5090105@oracle.com> Message-ID: <4F1EC74A.6010506@oracle.com> Hi Everyone, Changes in CGLSurfaceData.java caused a few regressions. Looks like we cannot set peer&layer to null in invalidate(), because surface can still be in use. So i revert these changes. I assume that this is not mac specific issue and I will create separate CR for that. Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 New webrev can be found at: http://cr.openjdk.java.net/~serb/7124524/webrev.01/ 17.01.2012 17:02, Sergey Bylokhov wrote: > Hi Everyone, > This is a fix for 4 memory leaks. > 1. LWWindowPeer does not destroy backbuffer in disposeImpl(). > 2. LWToolkit stores unused links to Peer. > 3. Local references were not deleted in the AWTWindow.m, but according > JNFJObjectWrapper.jObjectWithEnv documentation "returns a new > local-ref, must be released with DeleteLocalRef". > 4. OGLContext in some cases can cache CGLSurfaceData in this case our > LWWindowPeer was not collected. > > Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124524/webrev.00/ > -- Best regards, Sergey. From kumar.x.srinivasan at oracle.COM Tue Jan 24 07:26:45 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 24 Jan 2012 07:26:45 -0800 Subject: [7u4-osx] Request approval for: 7124089: launcher refactoring Message-ID: <4F1ECDB5.5090009@oracle.COM> Hi, This is a request to push the following fix to jdk7u-osx. CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124089 Webrev: http://cr.openjdk.java.net/~ksrini/7124089/webrev.3/ Reviewed by: anthony, darcy, dholmes, ohair Thanks Kumar From anthony.petrov at oracle.com Tue Jan 24 07:36:37 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 24 Jan 2012 19:36:37 +0400 Subject: Request for review: 7124524 - OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer In-Reply-To: <4F1EC74A.6010506@oracle.com> References: <4F15717D.5090105@oracle.com> <4F1EC74A.6010506@oracle.com> Message-ID: <4F1ED005.50800@oracle.com> Looks good to me. -- best regards, Anthony On 1/24/2012 6:59 PM, Sergey Bylokhov wrote: > Hi Everyone, > Changes in CGLSurfaceData.java caused a few regressions. Looks like we > cannot set peer&layer to null in invalidate(), because surface can still > be in use. So i revert these changes. I assume that this is not mac > specific issue and I will create separate CR for that. > Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 > New webrev can be found at: > http://cr.openjdk.java.net/~serb/7124524/webrev.01/ > > 17.01.2012 17:02, Sergey Bylokhov wrote: >> Hi Everyone, >> This is a fix for 4 memory leaks. >> 1. LWWindowPeer does not destroy backbuffer in disposeImpl(). >> 2. LWToolkit stores unused links to Peer. >> 3. Local references were not deleted in the AWTWindow.m, but according >> JNFJObjectWrapper.jObjectWithEnv documentation "returns a new >> local-ref, must be released with DeleteLocalRef". >> 4. OGLContext in some cases can cache CGLSurfaceData in this case our >> LWWindowPeer was not collected. >> >> Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7124524/webrev.00/ >> > > From sergey.bylokhov at oracle.com Tue Jan 24 07:40:55 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Jan 2012 19:40:55 +0400 Subject: [7u4-osx] Request for approval for 7124524 - OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer Message-ID: <4F1ED107.7020800@oracle.com> Hello, This is a new request to push the following changes to jdk7u-osx. The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124524/webrev.01/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002241.html -- Best regards, Sergey. From paul.hohensee at oracle.com Tue Jan 24 08:07:20 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 24 Jan 2012 11:07:20 -0500 Subject: [7u4-osx] Request approval for: 7124089: launcher refactoring In-Reply-To: <4F1ECDB5.5090009@oracle.COM> References: <4F1ECDB5.5090009@oracle.COM> Message-ID: <4F1ED738.3020204@oracle.com> Approved. Paul On 1/24/12 10:26 AM, Kumar Srinivasan wrote: > Hi, > > This is a request to push the following fix to jdk7u-osx. > > CR: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124089 > > Webrev: http://cr.openjdk.java.net/~ksrini/7124089/webrev.3/ > > Reviewed by: anthony, darcy, dholmes, ohair > > > Thanks > Kumar > From michael.x.mcmahon at oracle.com Tue Jan 24 08:17:17 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 24 Jan 2012 16:17:17 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7130948: Kerberos and JGSS JCK tests failing [macosx] Message-ID: <20120124161730.4288B47168@hg.openjdk.java.net> Changeset: 67f1abd35c4e Author: weijun Date: 2012-01-24 16:15 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/67f1abd35c4e 7130948: Kerberos and JGSS JCK tests failing [macosx] Reviewed-by: michaelm, bino, mullan ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java From michael.x.mcmahon at oracle.com Tue Jan 24 08:19:52 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 24 Jan 2012 16:19:52 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7126979: (props) JCK test java_lang/System/GetProperties.java failing [macosx] Message-ID: <20120124162002.E8B8F47169@hg.openjdk.java.net> Changeset: 61c4a65004c1 Author: michaelm Date: 2012-01-24 16:18 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/61c4a65004c1 7126979: (props) JCK test java_lang/System/GetProperties.java failing [macosx] Reviewed-by: skovatch ! src/share/native/java/lang/System.c ! src/solaris/native/java/lang/java_props_macosx.c From dalibor.topic at oracle.com Tue Jan 24 08:16:27 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 24 Jan 2012 08:16:27 -0800 Subject: tag boucing again In-Reply-To: <6B253885-D687-4C31-A2EA-5D053874D689@oracle.com> References: <4F11C83D.1010602@oracle.com> <6B253885-D687-4C31-A2EA-5D053874D689@oracle.com> Message-ID: <4F1ED95B.1090008@oracle.com> On 1/17/12 2:00 PM, Kelly O'Hair wrote: > Which, in my opinion, is a tag that should not be made external in an openjdk repository. > It's very confusing to the openjdk community. It is very confusing in general that tags appear out of nowhere. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From michael.x.mcmahon at oracle.com Tue Jan 24 08:23:25 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 24 Jan 2012 16:23:25 +0000 Subject: [jdk7u-osx] Request for approval for CR 7131399: Poll system call appears to be broken on Mac OS [macosx] Message-ID: <4F1EDAFD.9010507@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131399 Webrev: http://cr.openjdk.java.net/~michaelm/7131399/webrev.2/ Reviewed by: alanb, chegar Thanks, Michael. From swingler at apple.com Tue Jan 24 08:44:59 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 24 Jan 2012 08:44:59 -0800 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F1EC28B.9000904@oracle.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> <4F156177.9050007@oracle.com> <4F15C6ED.3000702@oracle.com> <4F1EC28B.9000904@oracle.com> Message-ID: <75E38D54-190D-40C6-BEDD-8F69CB288AD6@apple.com> This comment does not seem accurate: // Used for NSWindow -setLevel: and -level (not yet implemented) Since you are making the window levels static final ints, you should use those constants in CWrapper.m, and add a MAX_WINDOW_LEVELS in Java: static NSInteger LEVELS[sun_lwawt_macosx_CWrapper_MAX_WINDOW_LEVELS]; LEVELS[sun_lwawt_macosx_CWrapper_NSNormalWindowLevel] = NSNormalWindowLevel; LEVELS[sun_lwawt_macosx_CWrapper_NSFloatingWindowLevel] = NSFloatingWindowLevel; With this level of verbosity and links back to the real logic in Java, the level check (which you can easily raise a JNFException of type kIllegalArgumentException, if that's what you really want to do), shouldn't even be necessary. Also, instead of creating a whole separate function to init the window levels array, just use dispatch_once() with a block: It's more efficient, fewer lines of code, and not racy from multiple threads. This is looking a lot better, Mike Swingler Apple Inc. On Jan 24, 2012, at 6:39 AM, Anthony Petrov wrote: > Hi Mike, > > Thanks for proposing an alternative solution for this issue. I agree I find it more correct. Please take a look at the new fix at: > > http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.2/ > > Note that I decided to eliminate the changes from the CWrapper.NSWindow.addChildWindow() since the CWrapper is supposed to be a transparent proxy for Cocoa API w/o adding some logic to the wrapped methods. So instead I'm introducing CWrapper.NSWindow.setLevel() and using it where appropriate in the CPlatformWindow. > > -- > best regards, > Anthony > > On 1/18/2012 3:36 AM, Mike Swingler wrote: >> On Jan 17, 2012, at 11:07 AM, Anthony Petrov wrote: >>> Hi Mike, >>> >>> On 1/17/2012 8:52 PM, Mike Swingler wrote: >>>> On Jan 17, 2012, at 3:54 AM, Anthony Petrov wrote: >>>>> On 1/16/2012 8:24 PM, Mike Swingler wrote: >>>>>> I still don't understand why the list of hardcoded window levels needs to be included. Can't you just compare the window levels by their NSInteger numeric values? >>>>> There are two reasons for not using the numeric values directly, or comparing them directly: >>>>> >>>>> 1. Cocoa specification doesn't define the numeric values for the NS*WindowLevel constants. They may (theoretically) change in the future. As long as they aren't specified, we don't want to rely on their current values. >>>> Why do you have to know the values at all? Couldn't you just reset the child window level if it's different after the parent/child operation? After I re-read what you are trying to accomplish, even numeric comparison seems inappropriate. >>> I've already answered this question to Leonid on Jan 12, but I'll copy my reply here for your convenience: >>> >>> If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>> >>> Now, when we call -addChildWindow:, we really want to update the level >>> of the child window so that both the parent and the child share the same >>> window level. The if check ensures that we don't reset the level of the >>> child window back to normal in this case. >> I think what you really want to do here is check if the parent and the child are Always-On-Top, and then reset the window level of the child only when the child is AOT and the parent is not. -[NSWindow addChildWindow:order:] forces the child to the same level as the parent already. >> I'd avoid trying to infer if there is any "higher" vs. "lower" relationship between the parent based on the window level as seen from AppKit using that table. >>>>> 2. There's a reference to the Quartz spec that defines the kCG*WindowLevel constants as a enum. The NS*WindowLevel macros are defined using these constants. However, if you take a look at the order of the constants in that enum [1] (and therefore their relative numerical order), you may notice that they don't exactly reflect the relative visual z-order between the levels as defined in the Cocoa spec [2]. E.g. kCGModalPanelWindowLevelKey is greater than kCGDockWindowLevelKey, while NSDockWindowLevel is defined being visually above the NSModalPanelWindowLevel. As such, a direct numeric comparison of window levels produces incorrect results. >>>> Have you tried setting something at the "dock" level? That level may have been true for the NextStep dock, but not the Mac. And BTW: the NSDockWindowLevel is deprecated. Don't use it. >>> Yes, this is a good tip. I've removed the NSDockWindowLevel from the array. An updated fix is available at: >>> >>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.1/ >> Also, NSSubmenuWindowLevel and NSTornOffMenuWindowLevel are synonyms for each other, and end up being the same value. The documentation for NSWindow [2] says "The constant NSTornOffMenuWindowLevel is preferable to its synonym, NSSubmenuWindowLevel.", but again, I'd recommend just removing the table and higher/lower comparison. >>>>> The array of hardcoded window levels allows us to convert between window levels ordered arbitrarily and integer values ordered according to their visual z-order. This allows us to compare windows level with respect to their relative z-order as specified by Cocoa documentation. >>>> These constants are for assignment based on intention, not simple comparison of stacking level. They have behavioral meaning beyond just simple visual level ordering. Windows above the normal window level will disappear in Expos?/Mission Control, and certain levels will float in all Spaces. Other levels exclude the window from Cmd-~ keyboard window cycling, or showing up in the Dock window menu. Please, please, please test the side effects of these changes before just popping windows into different levels. >>> Could you please clarify what exact "different levels" you're talking about here? AWT currently uses only two window levels: NSNormalWindowLevel is used for regular windows, and NSFloatingWindowLevel for always-on-top windows (see AWTWindow.m). This code is already in the repository, and tests for always-on-top windows do work OK. >> The AWT will need to use more levels, and it's not clear how parent/child relationships need to affect these window levels. NSFloatingWindowLevel is used for palettes (like non-modal parented dialogs with small title bars), which do not participate in Expos?/Mission Control. NSModalPanelWindowLevel is what app-modal dialogs (like Open/Save) live at, which you might want "always on top" windows to be on top of too. Obviously popup menus should be at NSPopUpMenuWindowLevel. Another complication we encountered in Java SE 6 is full-screen exclusive windows, which still expect popups to be visible, so we had to push them above the NSScreenSaverWindowLevel as a gross hacky workaround. >> In your testing have you moved these windows between spaces? Can you separate them between spaces? Do the windows show as visible in Mission Control? When you right-click on the Dock icon, do they show in the window list? Should they? When you press Cmd-~, do they participate in the window cycle? These are the manual tests we do every time we futz with something like "window level" or "child windows" in Java SE 6, which can't easily be automated. >>> So back to the fix we're discussing, in reality the oldChildLevel in the CWrapper.addChildWindow() implementation can be either of these two levels, but not anything else. I guess we could simplify the fix and only include these two levels in the ORDERED_LEVELS{} array. I suppose Lubomir just wanted to provide a more generic and complete implementation that won't break if we ever start using any other levels in the future (or e.g. if OS temporarily puts our window on some other level). This is certainly unlikely, of course, however, I see absolutely no problems with an implementation of compareWindowLevels() that can work with all window levels officially supported by Cocoa, not just the two that we use currently. >> In the future, I agree, the existing child window level will have to be more than two values, but either it should be allowed to inherit from it's parent, or it should be reset to the original value. This is really a decision to be made based on the Java model state, and not an observed property in the AppKit model which is being changed behind your back and compared against a table. Right now the only decision hooks on if the AOT state of the parent and child, which is already present in the styleBits of the window. >> See the IS, SET, and MASK macro usage in AWTWindow.m for more info. You could make a simple accessor to report if ALWAYS_ON_TOP is set on both the parent and the child. >>>> The safest thing to do (if it works) is just to simply re-assign the window level after adding the child to the parent, but you will have to recursively descend into the child windows of the child, because setting the window level sets the level of all the children too (and changes their collection/spaces/cycle behavior). This may not be an issue if you never change a child window's parent. >>> I've clarified above why simple reassignment won't work well. >> Got it. I think I've straightened out my thinking on this too, and paged back years of hacks and corner cases I would have preferred to have forgotten... >> Cheers, >> Mike Swingler >> Apple Inc. >>> -- >>> best regards, >>> Anthony >>> >>>> Regards, >>>> Mike Swingler >>>> Apple Inc. >>>>> Does this clarify the need for the array of window levels? Do you have any other concerns regarding the fix? >>>>> >>>>> [1] http://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/tdef/CGWindowLevelKey >>>>> >>>>> [2] http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Window_Levels >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> >>>>>> Regards, >>>>>> Mike Swingler >>>>>> Apple Inc. >>>>>> On Jan 14, 2012, at 7:40 PM, Mike Swingler wrote: >>>>>>> In the course of preparing to contribute our current window stacking algorithm, I realized that there was a pair of internal SPI calls it was making. In the next revision we ship of the JavaRuntimeSupport.framework we can provide cover methods of these SPI, however that is of little benefit to the OpenJDK port in the immediate here-and-now. >>>>>>> >>>>>>> For now, using -addChildWindow: will be sufficient, however, we can provide an alternate implementation that uses a new pair of category methods on NSWindow if -respondsToSelector: shows that they are available: >>>>>>> - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; >>>>>>> - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; >>>>>>> >>>>>>> These functions will allow the window server to move each child window with respect to it's parent's level, but without being added to it's movement group. >>>>>>> >>>>>>> Once customers get an updated JavaNativeFoundation.framework by either Java update or OS update, the implementation will switch over dynamically at runtime. >>>>>>> >>>>>>> How does this sound for a plan? >>>>>>> >>>>>>> Regards, >>>>>>> Mike Swingler >>>>>>> Apple Inc. >>>>>>> >>>>>>> On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com wrote: >>>>>>> >>>>>>>> We fought this one in SWT and ended up going with the puppy route. >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> On 12/01/2012 2:57 PM, Anthony Petrov wrote: >>>>>>>>> Hi Mike, >>>>>>>>> >>>>>>>>> I recall we've discussed this issue with you back in 2010. Unfortunately, I wasn't able to implement anything like this that would work reliably back then (and I tried hard, really), that's why we ended up with -addChildWindow:. Note that JCK is very happy with this implementation, and so are we, I presume. As long as child windows receive their respective MOVE events, it seems that everything is all right. Besides, such behavior is very Mac-friendly, making Java apps behave like native apps. >>>>>>>>> >>>>>>>>> I realize that for some developers this behavior may be inconvenient. But then again, why not listen to MOVE events on the parent frame and compensate for its movement repositioning all its children? ( :) yeah, yeah, I know, sounds weird, but... as Steve says, you gotta do what you gotta do... I mean, there's a workaround at least!) >>>>>>>>> >>>>>>>>> So, if you or anyone else wish to contribute an alternative implementation for owned windows, that would be greatly appreciated. Otherwise I'm afraid we have to stick with using -addChildWindow: for now since we simply don't have a better solution. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> best regards, >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>>>>>>>>> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). >>>>>>>>>> >>>>>>>>>> In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Mike Swingler >>>>>>>>>> Apple Inc. >>>>>>>>>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>>>>>>>>> >>>>>>>>>>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>>>>>>>>> >>>>>>>>>>>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> best regards, >>>>>>>>>>>> Anthony >>>>>>>>>>>> >>>>>>>>>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>>>>>>>>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>>>>>>>>>>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>>>>>>>>>>>> >>>>>>>>>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for taking a look at the fix. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>> Anthony >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>>>>>>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>>> Anthony From anthony.petrov at oracle.com Tue Jan 24 09:29:54 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 24 Jan 2012 21:29:54 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <75E38D54-190D-40C6-BEDD-8F69CB288AD6@apple.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> <4F156177.9050007@oracle.com> <4F15C6ED.3000702@oracle.com> <4F1EC28B.9000904@oracle.com> <75E38D54-190D-40C6-BEDD-8F69CB288AD6@apple.com> Message-ID: <4F1EEA92.6070806@oracle.com> Hi Mike, Thanks for your suggestions. I've just published an updated webrev at: http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.3/ Note that I've switched to using the dispatch_once() now since it seems to be thread safe, however, I still put this initialization code in a separate function in order to reuse it later when we implement CWrapper.NSWindow.level() (which isn't needed right now). -- best regards, Anthony On 1/24/2012 8:44 PM, Mike Swingler wrote: > This comment does not seem accurate: > > // Used for NSWindow -setLevel: and -level (not yet implemented) > > > Since you are making the window levels static final ints, you should use > those constants in CWrapper.m, and add a MAX_WINDOW_LEVELS in Java: > > static NSInteger LEVELS[sun_lwawt_macosx_CWrapper_MAX_WINDOW_LEVELS]; > > LEVELS[sun_lwawt_macosx_CWrapper_NSNormalWindowLevel] = NSNormalWindowLevel; > LEVELS[sun_lwawt_macosx_CWrapper_NSFloatingWindowLevel] = > NSFloatingWindowLevel; > > With this level of verbosity and links back to the real logic in Java, > the level check (which you can easily raise a JNFException of type > kIllegalArgumentException, if that's what you really want to do), > shouldn't even be necessary. > > Also, instead of creating a whole separate function to init the window > levels array, just use dispatch_once() with a block: > > It's more efficient, fewer lines of code, and not racy from multiple > threads. > > This is looking a lot better, > Mike Swingler > Apple Inc. > > On Jan 24, 2012, at 6:39 AM, Anthony Petrov wrote: > >> Hi Mike, >> >> Thanks for proposing an alternative solution for this issue. I agree I >> find it more correct. Please take a look at the new fix at: >> >> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.2/ >> >> Note that I decided to eliminate the changes from the >> CWrapper.NSWindow.addChildWindow() since the CWrapper is supposed to >> be a transparent proxy for Cocoa API w/o adding some logic to the >> wrapped methods. So instead I'm introducing >> CWrapper.NSWindow.setLevel() and using it where appropriate in the >> CPlatformWindow. >> >> -- >> best regards, >> Anthony >> >> On 1/18/2012 3:36 AM, Mike Swingler wrote: >>> On Jan 17, 2012, at 11:07 AM, Anthony Petrov wrote: >>>> Hi Mike, >>>> >>>> On 1/17/2012 8:52 PM, Mike Swingler wrote: >>>>> On Jan 17, 2012, at 3:54 AM, Anthony Petrov wrote: >>>>>> On 1/16/2012 8:24 PM, Mike Swingler wrote: >>>>>>> I still don't understand why the list of hardcoded window levels >>>>>>> needs to be included. Can't you just compare the window levels by >>>>>>> their NSInteger numeric values? >>>>>> There are two reasons for not using the numeric values directly, >>>>>> or comparing them directly: >>>>>> >>>>>> 1. Cocoa specification doesn't define the numeric values for the >>>>>> NS*WindowLevel constants. They may (theoretically) change in the >>>>>> future. As long as they aren't specified, we don't want to rely on >>>>>> their current values. >>>>> Why do you have to know the values at all? Couldn't you just reset >>>>> the child window level if it's different after the parent/child >>>>> operation? After I re-read what you are trying to accomplish, even >>>>> numeric comparison seems inappropriate. >>>> I've already answered this question to Leonid on Jan 12, but I'll >>>> copy my reply here for your convenience: >>>> >>>> If the parent window is an always-on-top window, its level is >>>> NSFloatingWindowLevel. Suppose a child window being added to it >>>> hasn't been assigned any level explicitly, so its default level is >>>> NSNormalWindowLevel. >>>> >>>> Now, when we call -addChildWindow:, we really want to update the level >>>> of the child window so that both the parent and the child share the same >>>> window level. The if check ensures that we don't reset the level of the >>>> child window back to normal in this case. >>> I think what you really want to do here is check if the parent and >>> the child are Always-On-Top, and then reset the window level of the >>> child only when the child is AOT and the parent is not. -[NSWindow >>> addChildWindow:order:] forces the child to the same level as the >>> parent already. >>> I'd avoid trying to infer if there is any "higher" vs. "lower" >>> relationship between the parent based on the window level as seen >>> from AppKit using that table. >>>>>> 2. There's a reference to the Quartz spec that defines the >>>>>> kCG*WindowLevel constants as a enum. The NS*WindowLevel macros are >>>>>> defined using these constants. However, if you take a look at the >>>>>> order of the constants in that enum [1] (and therefore their >>>>>> relative numerical order), you may notice that they don't exactly >>>>>> reflect the relative visual z-order between the levels as defined >>>>>> in the Cocoa spec [2]. E.g. kCGModalPanelWindowLevelKey is greater >>>>>> than kCGDockWindowLevelKey, while NSDockWindowLevel is defined >>>>>> being visually above the NSModalPanelWindowLevel. As such, a >>>>>> direct numeric comparison of window levels produces incorrect results. >>>>> Have you tried setting something at the "dock" level? That level >>>>> may have been true for the NextStep dock, but not the Mac. And BTW: >>>>> the NSDockWindowLevel is deprecated. Don't use it. >>>> Yes, this is a good tip. I've removed the NSDockWindowLevel from the >>>> array. An updated fix is available at: >>>> >>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.1/ >>> Also, NSSubmenuWindowLevel and NSTornOffMenuWindowLevel are synonyms >>> for each other, and end up being the same value. The documentation >>> for NSWindow [2] says "The constant NSTornOffMenuWindowLevel is >>> preferable to its synonym, NSSubmenuWindowLevel.", but again, I'd >>> recommend just removing the table and higher/lower comparison. >>>>>> The array of hardcoded window levels allows us to convert between >>>>>> window levels ordered arbitrarily and integer values ordered >>>>>> according to their visual z-order. This allows us to compare >>>>>> windows level with respect to their relative z-order as specified >>>>>> by Cocoa documentation. >>>>> These constants are for assignment based on intention, not simple >>>>> comparison of stacking level. They have behavioral meaning beyond >>>>> just simple visual level ordering. Windows above the normal window >>>>> level will disappear in Expos?/Mission Control, and certain levels >>>>> will float in all Spaces. Other levels exclude the window from >>>>> Cmd-~ keyboard window cycling, or showing up in the Dock window >>>>> menu. Please, please, please test the side effects of these changes >>>>> before just popping windows into different levels. >>>> Could you please clarify what exact "different levels" you're >>>> talking about here? AWT currently uses only two window levels: >>>> NSNormalWindowLevel is used for regular windows, and >>>> NSFloatingWindowLevel for always-on-top windows (see AWTWindow.m). >>>> This code is already in the repository, and tests for always-on-top >>>> windows do work OK. >>> The AWT will need to use more levels, and it's not clear how >>> parent/child relationships need to affect these window levels. >>> NSFloatingWindowLevel is used for palettes (like non-modal parented >>> dialogs with small title bars), which do not participate in >>> Expos?/Mission Control. NSModalPanelWindowLevel is what app-modal >>> dialogs (like Open/Save) live at, which you might want "always on >>> top" windows to be on top of too. Obviously popup menus should be at >>> NSPopUpMenuWindowLevel. Another complication we encountered in Java >>> SE 6 is full-screen exclusive windows, which still expect popups to >>> be visible, so we had to push them above the NSScreenSaverWindowLevel >>> as a gross hacky workaround. >>> In your testing have you moved these windows between spaces? Can you >>> separate them between spaces? Do the windows show as visible in >>> Mission Control? When you right-click on the Dock icon, do they show >>> in the window list? Should they? When you press Cmd-~, do they >>> participate in the window cycle? These are the manual tests we do >>> every time we futz with something like "window level" or "child >>> windows" in Java SE 6, which can't easily be automated. >>>> So back to the fix we're discussing, in reality the oldChildLevel in >>>> the CWrapper.addChildWindow() implementation can be either of these >>>> two levels, but not anything else. I guess we could simplify the fix >>>> and only include these two levels in the ORDERED_LEVELS{} array. I >>>> suppose Lubomir just wanted to provide a more generic and complete >>>> implementation that won't break if we ever start using any other >>>> levels in the future (or e.g. if OS temporarily puts our window on >>>> some other level). This is certainly unlikely, of course, however, I >>>> see absolutely no problems with an implementation of >>>> compareWindowLevels() that can work with all window levels >>>> officially supported by Cocoa, not just the two that we use currently. >>> In the future, I agree, the existing child window level will have to >>> be more than two values, but either it should be allowed to inherit >>> from it's parent, or it should be reset to the original value. This >>> is really a decision to be made based on the Java model state, and >>> not an observed property in the AppKit model which is being changed >>> behind your back and compared against a table. Right now the only >>> decision hooks on if the AOT state of the parent and child, which is >>> already present in the styleBits of the window. >>> See the IS, SET, and MASK macro usage in AWTWindow.m for more info. >>> You could make a simple accessor to report if ALWAYS_ON_TOP is set on >>> both the parent and the child. >>>>> The safest thing to do (if it works) is just to simply re-assign >>>>> the window level after adding the child to the parent, but you will >>>>> have to recursively descend into the child windows of the child, >>>>> because setting the window level sets the level of all the children >>>>> too (and changes their collection/spaces/cycle behavior). This may >>>>> not be an issue if you never change a child window's parent. >>>> I've clarified above why simple reassignment won't work well. >>> Got it. I think I've straightened out my thinking on this too, and >>> paged back years of hacks and corner cases I would have preferred to >>> have forgotten... >>> Cheers, >>> Mike Swingler >>> Apple Inc. >>>> -- >>>> best regards, >>>> Anthony >>>> >>>>> Regards, >>>>> Mike Swingler >>>>> Apple Inc. >>>>>> Does this clarify the need for the array of window levels? Do you >>>>>> have any other concerns regarding the fix? >>>>>> >>>>>> [1] >>>>>> http://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/tdef/CGWindowLevelKey >>>>>> >>>>>> [2] >>>>>> http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Window_Levels >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> >>>>>>> Regards, >>>>>>> Mike Swingler >>>>>>> Apple Inc. >>>>>>> On Jan 14, 2012, at 7:40 PM, Mike Swingler wrote: >>>>>>>> In the course of preparing to contribute our current window >>>>>>>> stacking algorithm, I realized that there was a pair of internal >>>>>>>> SPI calls it was making. In the next revision we ship of the >>>>>>>> JavaRuntimeSupport.framework we can provide cover methods of >>>>>>>> these SPI, however that is of little benefit to the OpenJDK port >>>>>>>> in the immediate here-and-now. >>>>>>>> >>>>>>>> For now, using -addChildWindow: will be sufficient, however, we >>>>>>>> can provide an alternate implementation that uses a new pair of >>>>>>>> category methods on NSWindow if -respondsToSelector: shows that >>>>>>>> they are available: >>>>>>>> - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; >>>>>>>> - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; >>>>>>>> >>>>>>>> These functions will allow the window server to move each child >>>>>>>> window with respect to it's parent's level, but without being >>>>>>>> added to it's movement group. >>>>>>>> >>>>>>>> Once customers get an updated JavaNativeFoundation.framework by >>>>>>>> either Java update or OS update, the implementation will switch >>>>>>>> over dynamically at runtime. >>>>>>>> >>>>>>>> How does this sound for a plan? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Mike Swingler >>>>>>>> Apple Inc. >>>>>>>> >>>>>>>> On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com >>>>>>>> wrote: >>>>>>>> >>>>>>>>> We fought this one in SWT and ended up going with the puppy route. >>>>>>>>> >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> On 12/01/2012 2:57 PM, Anthony Petrov wrote: >>>>>>>>>> Hi Mike, >>>>>>>>>> >>>>>>>>>> I recall we've discussed this issue with you back in 2010. >>>>>>>>>> Unfortunately, I wasn't able to implement anything like this >>>>>>>>>> that would work reliably back then (and I tried hard, really), >>>>>>>>>> that's why we ended up with -addChildWindow:. Note that JCK is >>>>>>>>>> very happy with this implementation, and so are we, I presume. >>>>>>>>>> As long as child windows receive their respective MOVE events, >>>>>>>>>> it seems that everything is all right. Besides, such behavior >>>>>>>>>> is very Mac-friendly, making Java apps behave like native apps. >>>>>>>>>> >>>>>>>>>> I realize that for some developers this behavior may be >>>>>>>>>> inconvenient. But then again, why not listen to MOVE events on >>>>>>>>>> the parent frame and compensate for its movement repositioning >>>>>>>>>> all its children? ( :) yeah, yeah, I know, sounds weird, >>>>>>>>>> but... as Steve says, you gotta do what you gotta do... I >>>>>>>>>> mean, there's a workaround at least!) >>>>>>>>>> >>>>>>>>>> So, if you or anyone else wish to contribute an alternative >>>>>>>>>> implementation for owned windows, that would be greatly >>>>>>>>>> appreciated. Otherwise I'm afraid we have to stick with using >>>>>>>>>> -addChildWindow: for now since we simply don't have a better >>>>>>>>>> solution. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> best regards, >>>>>>>>>> Anthony >>>>>>>>>> >>>>>>>>>> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>>>>>>>>>> Also, you should not use -addChildWindow:, because you also >>>>>>>>>>> get added to the movement group of the parent (moving the >>>>>>>>>>> parent moves all it's children). This is *highly* undesirable >>>>>>>>>>> behavior for Java's general use (and you can see it in >>>>>>>>>>> Eclipse when the find window follows around the IDE window >>>>>>>>>>> like a puppy). >>>>>>>>>>> >>>>>>>>>>> In the Java SE 6 AWT we manually restack every Java window in >>>>>>>>>>> native with -orderFront: every time a Java window changes >>>>>>>>>>> it's level to correctly handle it's children and the >>>>>>>>>>> relationships between them. This actually works out ok, since >>>>>>>>>>> all the changes happen at once, and when the next turn of the >>>>>>>>>>> event loop happens, the new stacking order only has one new >>>>>>>>>>> window moving to the background and one new window becoming >>>>>>>>>>> key/main. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Mike Swingler >>>>>>>>>>> Apple Inc. >>>>>>>>>>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>>>>>>>>>> >>>>>>>>>>>> Bah, I was wrong. The value of NS*WindowLevel is really >>>>>>>>>>>> funky, it was a wrong suggestion to rely on it. Sorry for >>>>>>>>>>>> wasting your time. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>>>>>>>>>> >>>>>>>>>>>>> The values of the NS*WindowLevel macros are not a part of >>>>>>>>>>>>> the contract for Cocoa API. Therefore, we shouldn't rely on >>>>>>>>>>>>> their current numerical values. The names, however, and >>>>>>>>>>>>> their relative z-order are clearly specified in the >>>>>>>>>>>>> documentation, and as such we may use them. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> best regards, >>>>>>>>>>>>> Anthony >>>>>>>>>>>>> >>>>>>>>>>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>>>>>>>>>> I see? It looks like the higher window level is, the >>>>>>>>>>>>>> higher is the value of corresponding NS*WindowLevel macro. >>>>>>>>>>>>>> Wouldn't it be better to implement compareWindowLevels() >>>>>>>>>>>>>> by simply subtracting one value from another? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for taking a look at the fix. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The if check is needed for the following case. If the >>>>>>>>>>>>>>> parent window is an always-on-top window, its level is >>>>>>>>>>>>>>> NSFloatingWindowLevel. Suppose a child window being added >>>>>>>>>>>>>>> to it hasn't been assigned any level explicitly, so its >>>>>>>>>>>>>>> default level is NSNormalWindowLevel. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Now, when we call -addChildWindow:, we really want to >>>>>>>>>>>>>>> update the level of the child window so that both the >>>>>>>>>>>>>>> parent and the child share the same window level. The if >>>>>>>>>>>>>>> check ensures that we don't reset the level of the child >>>>>>>>>>>>>>> window back to normal in this case. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>> Anthony >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>>>>>>>>>> Just wondering: what would happen if you simply set >>>>>>>>>>>>>>>> oldChildlevel without that "if" check? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please review a fix for >>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix >>>>>>>>>>>>>>>>> itself. I'm just going to integrate it into the repository. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A JWindow object is always a child window with either >>>>>>>>>>>>>>>>> an explicit parent, or a shared invisible owner frame. >>>>>>>>>>>>>>>>> Therefore, we always call NSWindow -addChildWindow: >>>>>>>>>>>>>>>>> when showing a JWindow object. The root cause of the >>>>>>>>>>>>>>>>> issue is that the -addChildWindow: resets the level of >>>>>>>>>>>>>>>>> the child window to match that of the parent window. >>>>>>>>>>>>>>>>> With this fix we restore the level back to its original >>>>>>>>>>>>>>>>> value after the -addChildWindow: call, and as such >>>>>>>>>>>>>>>>> preserve the always-on-top state of the child window. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've verified the fix with a test app attached to the >>>>>>>>>>>>>>>>> original issue at >>>>>>>>>>>>>>>>> http://java.net/jira/browse/MACOSX_PORT-158 , and it >>>>>>>>>>>>>>>>> works fine. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>>>> Anthony > From paul.hohensee at oracle.com Tue Jan 24 10:01:02 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 24 Jan 2012 13:01:02 -0500 Subject: [jdk7u-osx] Request for approval for CR 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: <4F1EDAFD.9010507@oracle.com> References: <4F1EDAFD.9010507@oracle.com> Message-ID: <4F1EF1DE.7090103@oracle.com> Approved. Paul On 1/24/12 11:23 AM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131399 > > Webrev: http://cr.openjdk.java.net/~michaelm/7131399/webrev.2/ > > Reviewed by: alanb, chegar > > Thanks, > Michael. From paul.hohensee at oracle.com Tue Jan 24 10:17:01 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 24 Jan 2012 13:17:01 -0500 Subject: [jdk7u-osx] Request for approval for 7130704: (macosx) Few of the jtreg tests need to be ported for mac builds In-Reply-To: <4F1EE66F.5070604@oracle.com> References: <4F1EE66F.5070604@oracle.com> Message-ID: <4F1EF59D.1080405@oracle.com> Approved. Paul On 1/24/12 12:12 PM, Jim Holmlund wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130704 > > Webrev: http://cr.openjdk.java.net/~jjh/7130704/ > Sent for review to : macosx-port-dev at openjdk.java.net > > Testing: langtools repo built and regression tests run by jprt on > all platforms > > Reviewed by: Kelly O'hair > > - jjh > From swingler at apple.com Tue Jan 24 11:11:41 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 24 Jan 2012 11:11:41 -0800 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F1EEA92.6070806@oracle.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> <4F156177.9050007@oracle.com> <4F15C6ED.3000702@oracle.com> <4F1EC28B.9000904@oracle.com> <75E38D54-190D-40C6-BEDD-8F69CB288AD6@apple.com> <4F1EEA92.6070806@oracle.com> Message-ID: <946E7122-51FB-419A-91F6-A6BAB3C8B759@apple.com> Looks good, but with one more minor nit: You should declare the NSWindow *window pointer outside of the block, so that when it is captured by the block for execution later, the block will automatically retain the pointer, and release it when the scope of the block finishes execution. This will also remove the necessity of the NSWIN macro, which only casts the jlong bit pattern, and is not recognizable to the block as an actual id pointer type that it needs to retain once the block gets copied off the stack. Regards, Mike Swingler Apple Inc. On Jan 24, 2012, at 9:29 AM, Anthony Petrov wrote: > Hi Mike, > > Thanks for your suggestions. I've just published an updated webrev at: > > http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.3/ > > Note that I've switched to using the dispatch_once() now since it seems to be thread safe, however, I still put this initialization code in a separate function in order to reuse it later when we implement CWrapper.NSWindow.level() (which isn't needed right now). > > -- > best regards, > Anthony > > On 1/24/2012 8:44 PM, Mike Swingler wrote: >> This comment does not seem accurate: >> // Used for NSWindow -setLevel: and -level (not yet implemented) >> Since you are making the window levels static final ints, you should use those constants in CWrapper.m, and add a MAX_WINDOW_LEVELS in Java: >> static NSInteger LEVELS[sun_lwawt_macosx_CWrapper_MAX_WINDOW_LEVELS]; >> LEVELS[sun_lwawt_macosx_CWrapper_NSNormalWindowLevel] = NSNormalWindowLevel; >> LEVELS[sun_lwawt_macosx_CWrapper_NSFloatingWindowLevel] = NSFloatingWindowLevel; >> With this level of verbosity and links back to the real logic in Java, the level check (which you can easily raise a JNFException of type kIllegalArgumentException, if that's what you really want to do), shouldn't even be necessary. >> Also, instead of creating a whole separate function to init the window levels array, just use dispatch_once() with a block: >> It's more efficient, fewer lines of code, and not racy from multiple threads. >> This is looking a lot better, >> Mike Swingler >> Apple Inc. >> On Jan 24, 2012, at 6:39 AM, Anthony Petrov wrote: >>> Hi Mike, >>> >>> Thanks for proposing an alternative solution for this issue. I agree I find it more correct. Please take a look at the new fix at: >>> >>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.2/ >>> >>> Note that I decided to eliminate the changes from the CWrapper.NSWindow.addChildWindow() since the CWrapper is supposed to be a transparent proxy for Cocoa API w/o adding some logic to the wrapped methods. So instead I'm introducing CWrapper.NSWindow.setLevel() and using it where appropriate in the CPlatformWindow. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/18/2012 3:36 AM, Mike Swingler wrote: >>>> On Jan 17, 2012, at 11:07 AM, Anthony Petrov wrote: >>>>> Hi Mike, >>>>> >>>>> On 1/17/2012 8:52 PM, Mike Swingler wrote: >>>>>> On Jan 17, 2012, at 3:54 AM, Anthony Petrov wrote: >>>>>>> On 1/16/2012 8:24 PM, Mike Swingler wrote: >>>>>>>> I still don't understand why the list of hardcoded window levels needs to be included. Can't you just compare the window levels by their NSInteger numeric values? >>>>>>> There are two reasons for not using the numeric values directly, or comparing them directly: >>>>>>> >>>>>>> 1. Cocoa specification doesn't define the numeric values for the NS*WindowLevel constants. They may (theoretically) change in the future. As long as they aren't specified, we don't want to rely on their current values. >>>>>> Why do you have to know the values at all? Couldn't you just reset the child window level if it's different after the parent/child operation? After I re-read what you are trying to accomplish, even numeric comparison seems inappropriate. >>>>> I've already answered this question to Leonid on Jan 12, but I'll copy my reply here for your convenience: >>>>> >>>>> If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>> >>>>> Now, when we call -addChildWindow:, we really want to update the level >>>>> of the child window so that both the parent and the child share the same >>>>> window level. The if check ensures that we don't reset the level of the >>>>> child window back to normal in this case. >>>> I think what you really want to do here is check if the parent and the child are Always-On-Top, and then reset the window level of the child only when the child is AOT and the parent is not. -[NSWindow addChildWindow:order:] forces the child to the same level as the parent already. >>>> I'd avoid trying to infer if there is any "higher" vs. "lower" relationship between the parent based on the window level as seen from AppKit using that table. >>>>>>> 2. There's a reference to the Quartz spec that defines the kCG*WindowLevel constants as a enum. The NS*WindowLevel macros are defined using these constants. However, if you take a look at the order of the constants in that enum [1] (and therefore their relative numerical order), you may notice that they don't exactly reflect the relative visual z-order between the levels as defined in the Cocoa spec [2]. E.g. kCGModalPanelWindowLevelKey is greater than kCGDockWindowLevelKey, while NSDockWindowLevel is defined being visually above the NSModalPanelWindowLevel. As such, a direct numeric comparison of window levels produces incorrect results. >>>>>> Have you tried setting something at the "dock" level? That level may have been true for the NextStep dock, but not the Mac. And BTW: the NSDockWindowLevel is deprecated. Don't use it. >>>>> Yes, this is a good tip. I've removed the NSDockWindowLevel from the array. An updated fix is available at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.1/ >>>> Also, NSSubmenuWindowLevel and NSTornOffMenuWindowLevel are synonyms for each other, and end up being the same value. The documentation for NSWindow [2] says "The constant NSTornOffMenuWindowLevel is preferable to its synonym, NSSubmenuWindowLevel.", but again, I'd recommend just removing the table and higher/lower comparison. >>>>>>> The array of hardcoded window levels allows us to convert between window levels ordered arbitrarily and integer values ordered according to their visual z-order. This allows us to compare windows level with respect to their relative z-order as specified by Cocoa documentation. >>>>>> These constants are for assignment based on intention, not simple comparison of stacking level. They have behavioral meaning beyond just simple visual level ordering. Windows above the normal window level will disappear in Expos?/Mission Control, and certain levels will float in all Spaces. Other levels exclude the window from Cmd-~ keyboard window cycling, or showing up in the Dock window menu. Please, please, please test the side effects of these changes before just popping windows into different levels. >>>>> Could you please clarify what exact "different levels" you're talking about here? AWT currently uses only two window levels: NSNormalWindowLevel is used for regular windows, and NSFloatingWindowLevel for always-on-top windows (see AWTWindow.m). This code is already in the repository, and tests for always-on-top windows do work OK. >>>> The AWT will need to use more levels, and it's not clear how parent/child relationships need to affect these window levels. NSFloatingWindowLevel is used for palettes (like non-modal parented dialogs with small title bars), which do not participate in Expos?/Mission Control. NSModalPanelWindowLevel is what app-modal dialogs (like Open/Save) live at, which you might want "always on top" windows to be on top of too. Obviously popup menus should be at NSPopUpMenuWindowLevel. Another complication we encountered in Java SE 6 is full-screen exclusive windows, which still expect popups to be visible, so we had to push them above the NSScreenSaverWindowLevel as a gross hacky workaround. >>>> In your testing have you moved these windows between spaces? Can you separate them between spaces? Do the windows show as visible in Mission Control? When you right-click on the Dock icon, do they show in the window list? Should they? When you press Cmd-~, do they participate in the window cycle? These are the manual tests we do every time we futz with something like "window level" or "child windows" in Java SE 6, which can't easily be automated. >>>>> So back to the fix we're discussing, in reality the oldChildLevel in the CWrapper.addChildWindow() implementation can be either of these two levels, but not anything else. I guess we could simplify the fix and only include these two levels in the ORDERED_LEVELS{} array. I suppose Lubomir just wanted to provide a more generic and complete implementation that won't break if we ever start using any other levels in the future (or e.g. if OS temporarily puts our window on some other level). This is certainly unlikely, of course, however, I see absolutely no problems with an implementation of compareWindowLevels() that can work with all window levels officially supported by Cocoa, not just the two that we use currently. >>>> In the future, I agree, the existing child window level will have to be more than two values, but either it should be allowed to inherit from it's parent, or it should be reset to the original value. This is really a decision to be made based on the Java model state, and not an observed property in the AppKit model which is being changed behind your back and compared against a table. Right now the only decision hooks on if the AOT state of the parent and child, which is already present in the styleBits of the window. >>>> See the IS, SET, and MASK macro usage in AWTWindow.m for more info. You could make a simple accessor to report if ALWAYS_ON_TOP is set on both the parent and the child. >>>>>> The safest thing to do (if it works) is just to simply re-assign the window level after adding the child to the parent, but you will have to recursively descend into the child windows of the child, because setting the window level sets the level of all the children too (and changes their collection/spaces/cycle behavior). This may not be an issue if you never change a child window's parent. >>>>> I've clarified above why simple reassignment won't work well. >>>> Got it. I think I've straightened out my thinking on this too, and paged back years of hacks and corner cases I would have preferred to have forgotten... >>>> Cheers, >>>> Mike Swingler >>>> Apple Inc. >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>>> Regards, >>>>>> Mike Swingler >>>>>> Apple Inc. >>>>>>> Does this clarify the need for the array of window levels? Do you have any other concerns regarding the fix? >>>>>>> >>>>>>> [1] http://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/tdef/CGWindowLevelKey >>>>>>> >>>>>>> [2] http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Window_Levels >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> >>>>>>>> Regards, >>>>>>>> Mike Swingler >>>>>>>> Apple Inc. >>>>>>>> On Jan 14, 2012, at 7:40 PM, Mike Swingler wrote: >>>>>>>>> In the course of preparing to contribute our current window stacking algorithm, I realized that there was a pair of internal SPI calls it was making. In the next revision we ship of the JavaRuntimeSupport.framework we can provide cover methods of these SPI, however that is of little benefit to the OpenJDK port in the immediate here-and-now. >>>>>>>>> >>>>>>>>> For now, using -addChildWindow: will be sufficient, however, we can provide an alternate implementation that uses a new pair of category methods on NSWindow if -respondsToSelector: shows that they are available: >>>>>>>>> - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; >>>>>>>>> - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; >>>>>>>>> >>>>>>>>> These functions will allow the window server to move each child window with respect to it's parent's level, but without being added to it's movement group. >>>>>>>>> >>>>>>>>> Once customers get an updated JavaNativeFoundation.framework by either Java update or OS update, the implementation will switch over dynamically at runtime. >>>>>>>>> >>>>>>>>> How does this sound for a plan? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Mike Swingler >>>>>>>>> Apple Inc. >>>>>>>>> >>>>>>>>> On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com wrote: >>>>>>>>> >>>>>>>>>> We fought this one in SWT and ended up going with the puppy route. >>>>>>>>>> >>>>>>>>>> Steve >>>>>>>>>> >>>>>>>>>> On 12/01/2012 2:57 PM, Anthony Petrov wrote: >>>>>>>>>>> Hi Mike, >>>>>>>>>>> >>>>>>>>>>> I recall we've discussed this issue with you back in 2010. Unfortunately, I wasn't able to implement anything like this that would work reliably back then (and I tried hard, really), that's why we ended up with -addChildWindow:. Note that JCK is very happy with this implementation, and so are we, I presume. As long as child windows receive their respective MOVE events, it seems that everything is all right. Besides, such behavior is very Mac-friendly, making Java apps behave like native apps. >>>>>>>>>>> >>>>>>>>>>> I realize that for some developers this behavior may be inconvenient. But then again, why not listen to MOVE events on the parent frame and compensate for its movement repositioning all its children? ( :) yeah, yeah, I know, sounds weird, but... as Steve says, you gotta do what you gotta do... I mean, there's a workaround at least!) >>>>>>>>>>> >>>>>>>>>>> So, if you or anyone else wish to contribute an alternative implementation for owned windows, that would be greatly appreciated. Otherwise I'm afraid we have to stick with using -addChildWindow: for now since we simply don't have a better solution. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> best regards, >>>>>>>>>>> Anthony >>>>>>>>>>> >>>>>>>>>>> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>>>>>>>>>>> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). >>>>>>>>>>>> >>>>>>>>>>>> In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Mike Swingler >>>>>>>>>>>> Apple Inc. >>>>>>>>>>>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>> Anthony >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>>>>>>>>>>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>>>>>>>>>>>>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for taking a look at the fix. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>>> Anthony >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>>>>>>>>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>>>>> Anthony From chris.hegarty at oracle.com Tue Jan 3 09:27:45 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 03 Jan 2012 17:27:45 -0000 Subject: Code review: 71257522 [macosx] 7u4 b200 crash i.e. in Tonga In-Reply-To: <4F0335D2.7040304@oracle.com> References: <4F0335D2.7040304@oracle.com> Message-ID: <4F033B62.9070109@oracle.com> Looks fine to me. -Chris. On 03/01/2012 17:07, Michael McMahon wrote: > Could I get the following webrev reviewed please? > > http://cr.openjdk.java.net/~michaelm/7125722/webrev.1/ > > JNI field ids were being used before being initialized. > > Thanks, > Michael. > > From joe.darcy at oracle.com Thu Jan 5 18:30:19 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 06 Jan 2012 02:30:19 -0000 Subject: [7u4-osx] Request for approval for 7123392 (launcher) fix MacOSX launcher failures In-Reply-To: <4F05D49B.8030201@oracle.COM> References: <4F05D49B.8030201@oracle.COM> Message-ID: <4F065CB6.7050909@oracle.com> Hi Kumar, Looks fine. In test/tools/launcher/Test7029048.java, I suggest rephrasing 289 System.out.println("Note: not applicable on Windows and MacOSX"); as "Note: applicable on neither Windows nor MacOSX". -Joe On 1/5/2012 8:49 AM, Kumar Srinivasan wrote: > Hi, > > Please approve, > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123392 > Webrev: http://cr.openjdk.java.net/~ksrini/7123392/ > > Fixes for the launcher tests which fail with MacOSX and OpenJDK, a > precursor to > the re-factoring launcher work in progress. > > Thanks > Kumar > From John.Coomes at oracle.com Wed Jan 11 12:01:04 2012 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 11 Jan 2012 12:01:04 -0800 Subject: RFR (S): 7125793: MAC: test_gamma should always work In-Reply-To: <4F0CA809.7020001@oracle.com> References: <4EFECA5D.6010905@oracle.com> <4F034B51.3070609@oracle.com> <4F087516.40505@oracle.com> <4F0B7A34.5070406@oracle.com> <4F0CA809.7020001@oracle.com> Message-ID: <20237.60032.473316.761490@oracle.com> James Melvin (james.melvin at oracle.com) wrote: > Hi Dan, > > Final webrev to reflect your comments... > > http://cr.openjdk.java.net/~jmelvin/7125793/webrev.02 > > Minor changes this round: > > make/bsd/makefiles/buildtree.make # Fail gracefully on Apple BOOTDIR > make/bsd/makefiles/launcher.make # Link with framework only on Mac > src/os/bsd/vm/os_bsd.cpp # Just spelling fix > > Lastly, I wanted to reply to John Coomes comments earlier about the > test_gamma script simplification. Although I also value economy of > expression, in this case I think the use of more advanced shell > constructs increases the time for fresh eyes to decipher. Given > performance and such is not an issue, I'd prefer to keep the simpler > version I'm proposing with this change on Mac OS X, to make it easier on > future maintenance. This should be a model for the other platforms when > we reconcile. I've attached the before and after copies should there be > further comments on the simplified short script. As mentioned before, I have problems with you're proposed change beyond just brevity. First, it makes reconciling changes with the other platforms more difficult, so do all (if you get agreement) or do none. Second, any semantic changes are lost in the reformatting noise. Do the reformatting separately from the semantic change. And the expanded version is waaaay to bloated. I'm open to some code expansion, but the whitespace decorators around comment blocks for each trivial statement is too much. It reminds me of beginning cobol. -John > On 1/9/12 6:37 PM, Daniel D. Daugherty wrote: > > On 1/7/12 9:38 AM, James Melvin wrote: > >> WEBREV: > >> http://cr.openjdk.java.net/~jmelvin/7125793/webrev.01 > > > > make/bsd/Makefile > > No comments. > > > > make/bsd/makefiles/buildtree.make > > No comments. > > > > make/bsd/makefiles/defs.make > > Thanks for fixing this one for BSD platforms. > > > > make/bsd/makefiles/launcher.make > > line 60: typo: 'inadvertenly' -> 'inadvertently' > > > > Sorry I missed this in my first review, but the addition > > of '-framework CoreFoundation' to LFLAGS_LAUNCHER is > > probably MacOS X specific. I think: > > > > ifeq ($(OS_VENDOR), Darwin) > > else > > endif > > > > will work in launcher.make also. > > > > make/bsd/makefiles/vm.make > > No comments. > > > > src/os/bsd/vm/os_bsd.cpp > > line 2544: typo: 'overriden' -> 'overridden' > > line 2588: typo: 'overriden' -> 'overridden' > > > > Looks like old code line 2576 depended on the 'hotspot' > > symlink to refer to either 'client' or 'server' or whatever > > JVM you wanted to run. I'm fairly certain that the 'hotspot' > > symlink was retired; I'm just not sure when. > > > > src/os/posix/launcher/java_md.c > > No comments. > > > > Dan > > > > > > ---------------------------------------------------------------------- > #!/bin/sh > # Generated by /Users/jmelvin/dev/testing/make/bsd/makefiles/buildtree.make > . ./env.sh > if [ "" != "" ]; then { echo Cross compiling for ARCH , skipping gamma run.; exit 0; }; fi > if [ -z $JAVA_HOME ]; then { echo JAVA_HOME must be set to run this test.; exit 0; }; fi > if ! ${JAVA_HOME}/bin/java -d32 -fullversion 2>&1 > /dev/null > then > echo JAVA_HOME must point to 32bit JDK.; exit 0; > fi > rm -f Queens.class > ${JAVA_HOME}/bin/javac -d . /Users/jmelvin/dev/testing/make/test/Queens.java > [ -f gamma_g ] && { gamma=gamma_g; } > ./${gamma:-gamma} -Xbatch -showversion Queens < /dev/null > exit 0 > > ---------------------------------------------------------------------- > #!/bin/sh > > # Generated by /Users/jmelvin/dev/7125793/make/bsd/makefiles/buildtree.make > > # > # Include environment settings for gamma run > # > > . ./env.sh > > > # > # Do not run gamma test for cross compiles > # > > if [ -n "" ]; then > echo Cross compiling for ARCH , skipping gamma run. > exit 0 > fi > > > # > # Make sure JAVA_HOME is set as it is required for gamma > # > > if [ -z "${JAVA_HOME}" ]; then > echo JAVA_HOME must be set to run this test. > exit 0 > fi > > > # > # Report JAVA_HOME version to be used for the test > # > > FULL_VERSION="`${JAVA_HOME}/bin/java -d64 -fullversion`" > if [ $? -ne 0 ]; then > echo JAVA_HOME must point to a 64-bit OpenJDK. > exit 0 > fi > echo "${FULL_VERSION}" | awk '{printf("%s",$0);}' > > > # > # Use gamma_g if it exists > # > > GAMMA_PROG=gamma > if [ -f gamma_g ]; then > GAMMA_PROG=gamma_g > fi > > > # > # Ensure architecture for gamma and JAVA_HOME is the same. > # NOTE: gamma assumes the OpenJDK directory layout. > # > > GAMMA_ARCH="`file ${GAMMA_PROG} | awk '{print $NF}'`" > JVM_LIB="${JAVA_HOME}/jre/lib/libjava.dylib" > if [ ! -f ${JVM_LIB} ]; then > JVM_LIB="${JAVA_HOME}/jre/lib/amd64/libjava.dylib" > fi > if [ ! -f ${JVM_LIB} ] || [ -z "`file ${JVM_LIB} | grep ${GAMMA_ARCH}`" ]; then > echo JAVA_HOME must point to a 64-bit OpenJDK. > exit 0 > fi > > > # > # Compile Queens program for test > # > > rm -f Queens.class > ${JAVA_HOME}/bin/javac -d . /Users/jmelvin/dev/7125793/make/test/Queens.java > > > # > # Set library path solely for gamma launcher test run > # > > LD_LIBRARY_PATH=.:${JAVA_HOME}/jre/lib/amd64/native_threads:${JAVA_HOME}/jre/lib/amd64: > DYLD_LIBRARY_PATH=.:${JAVA_HOME}/jre/lib/native_threads:${JAVA_HOME}/jre/lib:${JAVA_HOME}/jre/lib/amd64/native_threads:${JAVA_HOME}/jre/lib/amd64: > export DYLD_LIBRARY_PATH > > > # > # Use the gamma launcher and JAVA_HOME to run the test > # > > ./${GAMMA_PROG} -Xbatch -showversion Queens < /dev/null From anton.tarasov at sun.com Thu Jan 12 01:34:15 2012 From: anton.tarasov at sun.com (anton.tarasov at sun.com) Date: Thu, 12 Jan 2012 09:34:15 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124283: [macosx] Can't move focus out of a table with the keyboard. Message-ID: <20120112093434.B6F3F47935@hg.openjdk.java.net> Changeset: ac2948107df1 Author: ant Date: 2012-01-12 13:32 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/ac2948107df1 7124283: [macosx] Can't move focus out of a table with the keyboard. Reviewed-by: anthony, art ! src/macosx/native/sun/awt/AWTView.m From denis.fokin at sun.com Fri Jan 13 05:36:25 2012 From: denis.fokin at sun.com (denis.fokin at sun.com) Date: Fri, 13 Jan 2012 13:36:25 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124515: [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items) Message-ID: <20120113133643.0E6944795F@hg.openjdk.java.net> Changeset: 61f551d646ea Author: alexsch Date: 2012-01-13 17:30 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/61f551d646ea 7124515: [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items) Reviewed-by: art ! src/macosx/classes/sun/lwawt/LWListPeer.java + test/java/awt/List/EmptyListEventTest/EmptyListEventTest.java From joe.darcy at oracle.com Tue Jan 17 16:03:20 2012 From: joe.darcy at oracle.com (Joseph Darcy) Date: Tue, 17 Jan 2012 16:03:20 -0800 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F15A353.7080802@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F1575F4.3060104@oracle.com> <4F15A353.7080802@oracle.COM> Message-ID: <4F160C48.2070606@oracle.com> Hello, On 1/17/2012 8:35 AM, Kumar Srinivasan wrote: > Hi Anthony, > >> >> src/share/bin/java.c >>> 987 } else if (IsMacOSX() && JLI_StrCmp(arg, >>> "-XstartOnFirstThread") == 0) { >>> 988 ProcessSpecialArg(arg); >>> 989 } else if (IsMacOSX() && JLI_StrCCmp(arg, "-Xdock:") == >>> 0) { >>> 990 ProcessSpecialArg(arg); > If we don't have those runtime checks then Windows, > Linux and Solaris will accept those flags without a fuss, so what > should the behavior be ? > > Was a specification (ccc) filed for these flags ? Will this be > documented in the help > section ? though X flags are unsupported, in the past we have > documented them, both > in the man pages as well as "java -X", if these will be left > undocumented should we take > the vm approach and mark it -XX ? Yes, we should have ccc requests to cover any new flags and any platform-specific flags. If a flag is generally sensible, I'd prefer to see the flag supported across platforms. Cheers, -Joe From joe.darcy at oracle.com Tue Jan 17 16:05:17 2012 From: joe.darcy at oracle.com (Joseph Darcy) Date: Tue, 17 Jan 2012 16:05:17 -0800 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F15A353.7080802@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F1575F4.3060104@oracle.com> <4F15A353.7080802@oracle.COM> Message-ID: <4F160CBD.7090905@oracle.com> Kumar, What is the general plan on getting this functionality into JDK 8 as well as 7uX? Like Anthony, I'm a bit concerned about the code duplications, although generally the changes look good. -Joe On 1/17/2012 8:35 AM, Kumar Srinivasan wrote: > Hi Anthony, > >> >> src/share/bin/java.c >>> 987 } else if (IsMacOSX() && JLI_StrCmp(arg, >>> "-XstartOnFirstThread") == 0) { >>> 988 ProcessSpecialArg(arg); >>> 989 } else if (IsMacOSX() && JLI_StrCCmp(arg, "-Xdock:") == >>> 0) { >>> 990 ProcessSpecialArg(arg); > If we don't have those runtime checks then Windows, > Linux and Solaris will accept those flags without a fuss, so what > should the behavior be ? > > Was a specification (ccc) filed for these flags ? Will this be > documented in the help > section ? though X flags are unsupported, in the past we have > documented them, both > in the man pages as well as "java -X", if these will be left > undocumented should we take > the vm approach and mark it -XX ? >> >>> 1595 if (IsMacOSX()) { > > I can make this platform specific. > > >> >> Generally, the fix looks good. Lots of #ifdef MACOSX looked very >> confusing before. However, I feel uncomfortable with having so much >> code duplicated between src/solaris/bin/java_md.c and >> src/macosx/bin/java_md.c. This seems to increase launcher code >> maintenance cost. Is there any possibility to fold the code up in a >> common source file that is shared between solaris/linux and macosx, >> and only define really specific parts of the code in separate files? >> The simplest way to accomplish this would be to leave exactly one >> #ifdef MACOSX in the shared file and #include a platform specific >> part there. Or we could tweak the make files to compile an additional >> file. > Yes it is a lot more readable, and yes it increases duplication , but we > already have some duplication between windows and unix. Since > this is platform specific code, and 7uX will go into maintenance mode, > the exposure will be limited. > > However, for jdk8 we need a hierarchical structure, as I heard some > noise about > restructuring the platform code, at that time it will be a good idea > to coalesce > these things, and remove the LD_LIBRARY_PATH cloaking in > solaris/java_md.c > which is not relevant to MacOSX. > >> >> Also, the major part of the JVMInit() function is identical on all >> three platforms - solaris/linux, macosx, and windows. It makes sense >> to define a function containing that code in the java.c and call it >> by platform-specific JVMInit() implementations where needed. > Yes this can be done, I will look into it. > > Kumar > >> >> -- >> best regards, >> Anthony >> >> On 1/17/2012 7:33 AM, Kumar Srinivasan wrote: >>> oops missed setting the subject line to 7ux-osx. >>> >>> Kumar >>> >>>> Hi, >>>> >>>> Please review the launcher refactoring work, the webrev is here: >>>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.0/ >>>> >>>> Notes: >>>> 1. Moves the majority of the launcher code into platform specific >>>> directories/files, >>>> removed redundant conditionals. >>>> >>>> 2. The solaris/linux code co-exists together as before. >>>> >>>> 3. On MacOSX, "java -client" will launch the server VM, for >>>> compatibility reasons, >>>> and dual mode is left in the macosx's java_md.c, this will >>>> enable experiments >>>> with universal libraries, quite easily. Also the mac >>>> ergonomics will always return >>>> server. >>>> >>>> Testing: >>>> Tested splash screen on all platforms and launcher regression >>>> tests. >>>> >>>> Thanks >>>> Kumar >>>> >>>> >>>> >>> > From anton.tarasov at sun.com Wed Jan 18 06:12:04 2012 From: anton.tarasov at sun.com (anton.tarasov at sun.com) Date: Wed, 18 Jan 2012 14:12:04 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124430: [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet Message-ID: <20120118141216.30FF6479B7@hg.openjdk.java.net> Changeset: 02a0c46f9a52 Author: ant Date: 2012-01-18 18:09 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/02a0c46f9a52 7124430: [macosx] LWCToolkit.grab() and LWCToolkit.ungrab() events are not implemented yet Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Window/Grab/GrabTest.java From joe.darcy at oracle.com Wed Jan 18 16:55:22 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 18 Jan 2012 16:55:22 -0800 Subject: [7ux-osx] Please review: 7124089: launcher refactoring In-Reply-To: <4F16DEEC.6090107@oracle.com> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F1575F4.3060104@oracle.com> <4F15A353.7080802@oracle.COM> <4F160C48.2070606@oracle.com> <4F16134A.2050207@oracle.COM> <4F16DEEC.6090107@oracle.com> Message-ID: <4F1769FA.2070309@oracle.com> On 01/18/2012 07:02 AM, Anthony Petrov wrote: > On 1/18/2012 4:33 AM, Kumar Srinivasan wrote: >>>> Was a specification (ccc) filed for these flags ? Will this be >>>> documented in the help >>>> section ? though X flags are unsupported, in the past we have >>>> documented them, both >>>> in the man pages as well as "java -X", if these will be left >>>> undocumented should we take >>>> the vm approach and mark it -XX ? >>> >>> Yes, we should have ccc requests to cover any new flags and any >>> platform-specific flags. >>> >>> If a flag is generally sensible, I'd prefer to see the flag >>> supported across platforms. >> >> Yes I agree, a ccc needs to be filed asap, and IMO the awt team should >> be filing this, as they are aware of all the nuances of these flags. > > I've filed 7131038 to address this. > > Joe, do you think it absolutely needs an official -help output and a > CCC approval in 7u4 time-frame, or could it wait till e.g. 7u6? If flags are officially supported in 7u4, then the ccc request should be done by 7u4; I don't expect much contention about this request so it should be approved quickly. -Joe From anton.tarasov at sun.com Fri Jan 20 02:42:04 2012 From: anton.tarasov at sun.com (anton.tarasov at sun.com) Date: Fri, 20 Jan 2012 10:42:04 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7125491: [macosx] Regression: A component can get unexpected keyTyped event. Message-ID: <20120120104242.EF2F1470BE@hg.openjdk.java.net> Changeset: 4156455c1481 Author: ant Date: 2012-01-20 14:41 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/4156455c1481 7125491: [macosx] Regression: A component can get unexpected keyTyped event. Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java From joe.darcy at oracle.com Mon Jan 23 10:13:41 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 23 Jan 2012 10:13:41 -0800 Subject: [7u4-osx] Please review: 7124089: launcher refactoring v2.0 In-Reply-To: <4F1AFE60.2030506@oracle.COM> References: <4F14EB72.5010203@oracle.COM> <4F14EC06.4040909@oracle.COM> <4F19952C.7070408@oracle.COM> <003F4B79-4D22-4C49-B408-666107C81E86@oracle.com> <4F1AFE60.2030506@oracle.COM> Message-ID: <4F1DA355.6060903@oracle.com> Launcher changes looks good, -Joe On 01/21/2012 10:05 AM, Kumar Srinivasan wrote: > Hi Kelly et. al., > > I have beautified/fixed the Makefiles addressing Kellys' comments below: > > 1. Indented the Makefiles correctly. > 2. Annotated with more trailing comments to the if/else/endif clauses > 3. Removed the offending \ escapes > 4. Removed the * from Release.gmk, it turns out the files being copied > were not quite right (missing files), fixed it such that all the > appropriate files > are copied. > 5. Added comments for the MacOSX specific cflags. > > The incremental webrev is here: > http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/webrev.delta/index.html > > > The full webrev is here: > http://cr.openjdk.java.net/~ksrini/7124089/webrev.2/index.html > > Thanks > Kumar > >> On the Makefiles.... >> >> Please refrain from using any wildcards (e.g. * ) in the make rules. >> Better to be explicit, or if necessary >> use something like FILES=$(wildcard $(SOMEDIR)/*) and a cp $(FILES) >> $(SOMEPLACE) >> so that we can at least see in the Makefile log what it really copied. >> >> Please indent the Makefile if/else/endif statements. >> >> Thank you for the trailing comments on the endif's. ;^) >> >> Please try to avoid escaped quotes on the compile lines, use this >> -DX='"abc"' rather than this -DX=\"abc\" >> escaped quotes are very problematic on Windows and I know this isn't >> Windows, but it tempts windows >> people to use it, it will not work in all situations. Where '"abc"' >> does. >> >> Please add a comment on what the -Os compiler option means, and also >> the -x objective-c, I could guess >> but would be better to document it in the makefile. >> >> -kto >> >> On Jan 20, 2012, at 8:24 AM, Kumar Srinivasan wrote: >> >>> Hi All, >>> >>> Based on all the comments from Anthony, Joe and David, >>> here is the modified version: >>> >>> Highlights: >>> 1. re-factored code in solaris directory to be shared with macosx, >>> reducing duplication across the *nixes. >>> >>> 2. adjusted the makefilesto allow the above >>> >>> 2. eliminated all conditionals from the shared java.c >>> >>> 3. added a new launcher regression test for the macosx specific -X >>> options >>> >>> For those who have already reviewed the 0th version, here is an >>> incremental webrev to make it easier reviewing the differences. >>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/webrev.delta/index.html >>> >>> >>> Here is the complete webrev: >>> http://cr.openjdk.java.net/~ksrini/7124089/webrev.1/index.html >>> >>> Thanks >>> Kumar >>> >>> > From james.holmlund at oracle.com Mon Jan 23 15:03:27 2012 From: james.holmlund at oracle.com (Jim Holmlund) Date: Mon, 23 Jan 2012 15:03:27 -0800 Subject: [jdk7u-osx] Please review fix for 7130704 Message-ID: <4F1DE73F.9070508@oracle.com> Here is the webrev http://cr.openjdk.java.net/~jjh/7130704/ Most of the changes were copied from the macosx-port/macosx-port/langtools repo. The other changes are for the pleasure of jprt. Testing: - langtools build and regression tests run by jprt on all platforms Thanks - jjh From james.holmlund at oracle.com Mon Jan 23 15:50:50 2012 From: james.holmlund at oracle.com (Jim Holmlund) Date: Mon, 23 Jan 2012 15:50:50 -0800 Subject: [jdk7u-osx] Please review fix for 7130704 In-Reply-To: References: <4F1DE73F.9070508@oracle.com> Message-ID: <4F1DF25A.10507@oracle.com> On 1/23/2012 3:32 PM, Kelly O'Hair wrote: > Looks good. But the test/jprt.config file should not be needed anymore, could just be deleted > or emptied out. > Thanks Kelly. I deleted test/jprt.config and am rerunning the jprt job just to be safe. - jjh > -kto > > On Jan 23, 2012, at 3:03 PM, Jim Holmlund wrote: > >> Here is the webrev >> http://cr.openjdk.java.net/~jjh/7130704/ >> >> Most of the changes were copied from the macosx-port/macosx-port/langtools repo. The other changes are for the pleasure of jprt. >> >> Testing: >> - langtools build and regression tests run by jprt on all platforms >> >> Thanks >> - jjh >> >> >> From chris.hegarty at oracle.com Tue Jan 24 02:23:19 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 24 Jan 2012 10:23:19 +0000 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: <4F1DE008.8060103@oracle.com> References: <4F1D9444.7040807@oracle.com> <4F1DD178.4000203@oracle.com> <4F1DE008.8060103@oracle.com> Message-ID: <4F1E8697.3020602@oracle.com> I'm OK with this as it, but here are a few comments: The logic around the initial setting of the timeout seems a little unnecessary (and the additional pointer), but not wrong. The comments should also be updated. Given this problem should the build be setting USE_SELECT? -Chris. On 01/23/12 10:32 PM, Michael McMahon wrote: > On 23/01/12 21:30, Alan Bateman wrote: >> On 23/01/2012 17:09, Michael McMahon wrote: >>> Can I get the following change reviewed please? >>> >>> http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/ >>> >>> The problem is that poll(2) doesn't seem to work in a specific edge >>> case tested by JCK, >>> namely, when a zero length UDP message is sent on a DatagramSocket. >>> The problem is only >>> detected on timed reads, ie. normal blocking reads work fine. >>> >>> The fix is to make the NET_Timeout() function use select() instead of >>> poll(). >>> >>> Thanks, >>> Michael. >>> >> The first argument to select is s+1, shouldn't is be 1? >> >> -alan > No, I don't think so. fd_sets are bit masks and you have to specify the > highest numbered bit in the > mask (+1). > > - Michael. From chris.hegarty at oracle.com Tue Jan 24 02:39:33 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 24 Jan 2012 10:39:33 +0000 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: <4F1E8AE7.8010803@oracle.com> References: <4F1D9444.7040807@oracle.com> <4F1DD178.4000203@oracle.com> <4F1DE008.8060103@oracle.com> <4F1E8697.3020602@oracle.com> <4F1E8AE7.8010803@oracle.com> Message-ID: <4F1E8A65.3000509@oracle.com> Thanks the explanations. As I said, I'm fine with the change as is. -Chris. On 01/24/12 10:41 AM, Michael McMahon wrote: > On 24/01/12 10:23, Chris Hegarty wrote: >> I'm OK with this as it, but here are a few comments: >> >> The logic around the initial setting of the timeout seems a little >> unnecessary (and the additional pointer), but not wrong. >> > Chris, > > The setting of the timeval could be combined ok, but I wanted to avoid > calling gettimeofday() > in the case where timeout == 0 >> The comments should also be updated. >> > Yes, I'll do that. It still refers to poll() instead of select() now. > I'll add a comment about > the bug too. >> Given this problem should the build be setting USE_SELECT? >> > I thought about that, and decided against it for two reasons. > > 1) it's only used by PlainSocketImpl in the networking code, and that > usage doesn't seem > to be affected by this problem. poll() is potentially a little more > efficient than select() also > > 2) USE_SELECT is referenced in other places in other native code (in AWT) > and I don't want to affect those usages. Granted that raises a question > as to whether they > are affected by this bug. But, I don't believe they are since, as far as > I can see UDP sockets > aren't used there. > > - Michael > > >> -Chris. >> >> On 01/23/12 10:32 PM, Michael McMahon wrote: >>> On 23/01/12 21:30, Alan Bateman wrote: >>>> On 23/01/2012 17:09, Michael McMahon wrote: >>>>> Can I get the following change reviewed please? >>>>> >>>>> http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/ >>>>> >>>>> The problem is that poll(2) doesn't seem to work in a specific edge >>>>> case tested by JCK, >>>>> namely, when a zero length UDP message is sent on a DatagramSocket. >>>>> The problem is only >>>>> detected on timed reads, ie. normal blocking reads work fine. >>>>> >>>>> The fix is to make the NET_Timeout() function use select() instead of >>>>> poll(). >>>>> >>>>> Thanks, >>>>> Michael. >>>>> >>>> The first argument to select is s+1, shouldn't is be 1? >>>> >>>> -alan >>> No, I don't think so. fd_sets are bit masks and you have to specify the >>> highest numbered bit in the >>> mask (+1). >>> >>> - Michael. > From damjan.jov at gmail.com Tue Jan 24 03:27:22 2012 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Tue, 24 Jan 2012 13:27:22 +0200 Subject: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx] In-Reply-To: <4F1D9444.7040807@oracle.com> References: <4F1D9444.7040807@oracle.com> Message-ID: On Mon, Jan 23, 2012 at 7:09 PM, Michael McMahon < michael.x.mcmahon at oracle.com> wrote: > Can I get the following change reviewed please? > > http://cr.openjdk.java.net/~**michaelm/7131399/webrev.1/ > > The problem is that poll(2) doesn't seem to work in a specific edge case > tested by JCK, > namely, when a zero length UDP message is sent on a DatagramSocket. The > problem is only > detected on timed reads, ie. normal blocking reads work fine. > > The fix is to make the NET_Timeout() function use select() instead of > poll(). > > Thanks, > Michael. > > > > Hi I don't work at Oracle or anything, but IMHO this is a bad idea. The finite length bitset used by select() means that there is a limit on the maximum integer that can fit in the bitset. With 1024 bits (a common value), you only have to create >= 1021 file descriptors (and of course stdin/stdout/stderr) to exceed this limit, and end up with a file descriptor for which FD_SET breaks. This will be the case even if that file descriptor is the only file descriptor you are trying to add to the bitset. Please reconsider. Regards Damjan Jovanovic From james.holmlund at oracle.com Tue Jan 24 09:12:15 2012 From: james.holmlund at oracle.com (Jim Holmlund) Date: Tue, 24 Jan 2012 09:12:15 -0800 Subject: [jdk7u-osx] Request for approval for 7130704: (macosx) Few of the jtreg tests need to be ported for mac builds Message-ID: <4F1EE66F.5070604@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130704 Webrev: http://cr.openjdk.java.net/~jjh/7130704/ Sent for review to : macosx-port-dev at openjdk.java.net Testing: langtools repo built and regression tests run by jprt on all platforms Reviewed by: Kelly O'hair - jjh From jim.holmlund at sun.com Tue Jan 24 10:25:08 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Tue, 24 Jan 2012 18:25:08 +0000 Subject: hg: jdk7u/jdk7u-osx/langtools: 7130704: Few of the jtreg tests need to be ported for mac builds Message-ID: <20120124182510.B1A7C47170@hg.openjdk.java.net> Changeset: d8e7e2ccbd41 Author: jjh Date: 2012-01-24 10:24 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/d8e7e2ccbd41 7130704: Few of the jtreg tests need to be ported for mac builds Reviewed-by: ohair ! make/jprt.properties ! test/Makefile - test/jprt.config ! test/tools/javac/4846262/Test.sh ! test/tools/javac/6302184/T6302184.sh ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/MissingInclude.sh ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh ! test/tools/javac/T5090006/compiler.sh ! test/tools/javac/apt.sh ! test/tools/javac/constDebug/ConstDebug.sh ! test/tools/javac/fatalErrors/NoJavaLang.sh ! test/tools/javac/innerClassFile/Driver.sh ! test/tools/javac/javazip/Test.sh ! test/tools/javac/links/links.sh ! test/tools/javac/newlines/Newlines.sh ! test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/unicode/SupplementaryJavaID6.sh ! test/tools/javah/6257087/foo.sh ! test/tools/javah/ConstMacroTest.sh ! test/tools/javah/MissingParamClassTest.sh ! test/tools/javah/ReadOldClass.sh ! test/tools/javap/pathsep.sh From paul.hohensee at oracle.com Tue Jan 24 15:50:51 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 24 Jan 2012 18:50:51 -0500 Subject: jdk7u-osx, VM mode In-Reply-To: <6592F495-7FBC-4151-BF43-4EAB4D76132A@mac.com> References: <4EDE7418.30800@oracle.com> <6592F495-7FBC-4151-BF43-4EAB4D76132A@mac.com> Message-ID: <4F1F43DB.7040402@oracle.com> No. Oracle supports both 32 and 64-bit on linux, solaris and windows, as well as 32-bit on ppc and arm. Paul On 12/6/11 8:21 PM, Andrew Thompson wrote: > Is hotspot now 64bit only on all platforms? > > On Dec 6, 2011, at 3:23 PM, Henri Gomez wrote: > >>>> Did the OpenJDK 7 for osx from jdk7u-osx will stay 32/64 (universal) >>>> like the current OpenJDK 7 from macosx-port ? >>> See Michael's reply here: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-December/001683.html >> I saw his reply and replied on it. >> >> To me OSX should have a 32/64 bits VM >> >> - It's how OpenJDK 7 from macosx-port works today >> - Apple 1.6 VMs where 32/64 bits VM >> - Other OS have 32 and 64 bits VM From kumar.x.srinivasan at oracle.com Tue Jan 24 16:50:39 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 25 Jan 2012 00:50:39 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124089: (launcher) refactor the launcher code for macosx Message-ID: <20120125005049.88C154717C@hg.openjdk.java.net> Changeset: 6b4f3fb8e218 Author: ksrini Date: 2012-01-24 10:42 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/6b4f3fb8e218 7124089: (launcher) refactor the launcher code for macosx Reviewed-by: anthony, darcy, dholmes, ohair ! make/common/Program.gmk ! make/common/Release.gmk ! make/java/jli/Makefile + src/macosx/bin/java_md_macosx.c + src/macosx/bin/java_md_macosx.h + src/macosx/bin/jexec.c + src/macosx/bin/universal/jvm.cfg + src/macosx/lib/Info-cmdline.plist + src/macosx/lib/Info-privileged.plist ! src/share/bin/java.c ! src/share/bin/java.h ! src/solaris/bin/ergo.c ! src/solaris/bin/ergo.h ! src/solaris/bin/ergo_i586.c - src/solaris/bin/java_md.c ! src/solaris/bin/java_md.h + src/solaris/bin/java_md_common.c + src/solaris/bin/java_md_solinux.c + src/solaris/bin/java_md_solinux.h - src/solaris/bin/universal/jvm.cfg - src/solaris/lib/Info-cmdline.plist - src/solaris/lib/Info-privileged.plist ! src/windows/bin/java_md.c ! test/tools/launcher/Test7029048.java + test/tools/launcher/TestSpecialArgs.java From astrange at apple.com Tue Jan 24 21:46:41 2012 From: astrange at apple.com (Alexander Strange) Date: Wed, 25 Jan 2012 00:46:41 -0500 Subject: Request for review 7124224: [macosx] Port's controls are improperly ordered In-Reply-To: <4F1E75AB.8080301@oracle.com> References: <4F1D1FFE.1000503@oracle.com> <4F1E75AB.8080301@oracle.com> Message-ID: <6DA9416D-781D-4EED-B65E-4480A2B1B718@apple.com> Looks ok to me. On Jan 24, 2012, at 4:11 AM, Alex Menkov wrote: > publicly accessible webrev: > http://cr.openjdk.java.net/~amenkov/7124224/webrev.00/ > > regards > Alex > > On 24.01.2012 06:24, Alexander Strange wrote: >> >> On Jan 23, 2012, at 3:53 AM, Alex Menkov wrote: >> >>> Hi all, >>> >>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124224 >>> webrev: http://javaweb.us.oracle.com/jcg/fx-webrevs/7124224/2/ >>> >>> summary of the changes: >>> - updated the case when AudioDevice has several AudioStreams; >>> - implemented "virtual" master/mute/balance controls; >>> - implemented configuration detection (test for control validity); >>> - control hierarchy was updated to be consistent with other platforms; >>> - fixed memory leaks. >>> >>> Also 2 .c files was removed (issue of macosx-port=>jdk7u-osx integration). >> >> Could you post this webrev somewhere publicly accessible? >> >>> >>> regards >>> Alex >> >> From michael.x.mcmahon at oracle.com Wed Jan 25 01:50:49 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 25 Jan 2012 09:50:49 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 2 new changesets Message-ID: <20120125095119.69D884718C@hg.openjdk.java.net> Changeset: 0bb5eee1fa7f Author: michaelm Date: 2012-01-25 09:47 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/0bb5eee1fa7f 7131399: Poll system call appears to be broken on Mac OS [macosx] Reviewed-by: alanb, chegar - src/solaris/native/java/net/PlainDatagramSocketImpl.c.orig ! src/solaris/native/java/net/bsd_close.c Changeset: 9d6057281172 Author: michaelm Date: 2012-01-25 09:49 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/9d6057281172 Merge - src/solaris/bin/java_md.c - src/solaris/bin/universal/jvm.cfg - src/solaris/lib/Info-cmdline.plist - src/solaris/lib/Info-privileged.plist From anthony.petrov at oracle.com Wed Jan 25 03:09:45 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 25 Jan 2012 15:09:45 +0400 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <946E7122-51FB-419A-91F6-A6BAB3C8B759@apple.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> <4F156177.9050007@oracle.com> <4F15C6ED.3000702@oracle.com> <4F1EC28B.9000904@oracle.com> <75E38D54-190D-40C6-BEDD-8F69CB288AD6@apple.com> <4F1EEA92.6070806@oracle.com> <946E7122-51FB-419A-91F6-A6BAB3C8B759@apple.com> Message-ID: <4F1FE2F9.6040608@oracle.com> Good point. Here's the latest version: http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.4/ -- best regards, Anthony On 1/24/2012 11:11 PM, Mike Swingler wrote: > Looks good, but with one more minor nit: > > You should declare the NSWindow *window pointer outside of the block, so that when it is captured by the block for execution later, the block will automatically retain the pointer, and release it when the scope of the block finishes execution. > > This will also remove the necessity of the NSWIN macro, which only casts the jlong bit pattern, and is not recognizable to the block as an actual id pointer type that it needs to retain once the block gets copied off the stack. > > Regards, > Mike Swingler > Apple Inc. > > On Jan 24, 2012, at 9:29 AM, Anthony Petrov wrote: > >> Hi Mike, >> >> Thanks for your suggestions. I've just published an updated webrev at: >> >> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.3/ >> >> Note that I've switched to using the dispatch_once() now since it seems to be thread safe, however, I still put this initialization code in a separate function in order to reuse it later when we implement CWrapper.NSWindow.level() (which isn't needed right now). >> >> -- >> best regards, >> Anthony >> >> On 1/24/2012 8:44 PM, Mike Swingler wrote: >>> This comment does not seem accurate: >>> // Used for NSWindow -setLevel: and -level (not yet implemented) >>> Since you are making the window levels static final ints, you should use those constants in CWrapper.m, and add a MAX_WINDOW_LEVELS in Java: >>> static NSInteger LEVELS[sun_lwawt_macosx_CWrapper_MAX_WINDOW_LEVELS]; >>> LEVELS[sun_lwawt_macosx_CWrapper_NSNormalWindowLevel] = NSNormalWindowLevel; >>> LEVELS[sun_lwawt_macosx_CWrapper_NSFloatingWindowLevel] = NSFloatingWindowLevel; >>> With this level of verbosity and links back to the real logic in Java, the level check (which you can easily raise a JNFException of type kIllegalArgumentException, if that's what you really want to do), shouldn't even be necessary. >>> Also, instead of creating a whole separate function to init the window levels array, just use dispatch_once() with a block: >>> It's more efficient, fewer lines of code, and not racy from multiple threads. >>> This is looking a lot better, >>> Mike Swingler >>> Apple Inc. >>> On Jan 24, 2012, at 6:39 AM, Anthony Petrov wrote: >>>> Hi Mike, >>>> >>>> Thanks for proposing an alternative solution for this issue. I agree I find it more correct. Please take a look at the new fix at: >>>> >>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.2/ >>>> >>>> Note that I decided to eliminate the changes from the CWrapper.NSWindow.addChildWindow() since the CWrapper is supposed to be a transparent proxy for Cocoa API w/o adding some logic to the wrapped methods. So instead I'm introducing CWrapper.NSWindow.setLevel() and using it where appropriate in the CPlatformWindow. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 1/18/2012 3:36 AM, Mike Swingler wrote: >>>>> On Jan 17, 2012, at 11:07 AM, Anthony Petrov wrote: >>>>>> Hi Mike, >>>>>> >>>>>> On 1/17/2012 8:52 PM, Mike Swingler wrote: >>>>>>> On Jan 17, 2012, at 3:54 AM, Anthony Petrov wrote: >>>>>>>> On 1/16/2012 8:24 PM, Mike Swingler wrote: >>>>>>>>> I still don't understand why the list of hardcoded window levels needs to be included. Can't you just compare the window levels by their NSInteger numeric values? >>>>>>>> There are two reasons for not using the numeric values directly, or comparing them directly: >>>>>>>> >>>>>>>> 1. Cocoa specification doesn't define the numeric values for the NS*WindowLevel constants. They may (theoretically) change in the future. As long as they aren't specified, we don't want to rely on their current values. >>>>>>> Why do you have to know the values at all? Couldn't you just reset the child window level if it's different after the parent/child operation? After I re-read what you are trying to accomplish, even numeric comparison seems inappropriate. >>>>>> I've already answered this question to Leonid on Jan 12, but I'll copy my reply here for your convenience: >>>>>> >>>>>> If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>> >>>>>> Now, when we call -addChildWindow:, we really want to update the level >>>>>> of the child window so that both the parent and the child share the same >>>>>> window level. The if check ensures that we don't reset the level of the >>>>>> child window back to normal in this case. >>>>> I think what you really want to do here is check if the parent and the child are Always-On-Top, and then reset the window level of the child only when the child is AOT and the parent is not. -[NSWindow addChildWindow:order:] forces the child to the same level as the parent already. >>>>> I'd avoid trying to infer if there is any "higher" vs. "lower" relationship between the parent based on the window level as seen from AppKit using that table. >>>>>>>> 2. There's a reference to the Quartz spec that defines the kCG*WindowLevel constants as a enum. The NS*WindowLevel macros are defined using these constants. However, if you take a look at the order of the constants in that enum [1] (and therefore their relative numerical order), you may notice that they don't exactly reflect the relative visual z-order between the levels as defined in the Cocoa spec [2]. E.g. kCGModalPanelWindowLevelKey is greater than kCGDockWindowLevelKey, while NSDockWindowLevel is defined being visually above the NSModalPanelWindowLevel. As such, a direct numeric comparison of window levels produces incorrect results. >>>>>>> Have you tried setting something at the "dock" level? That level may have been true for the NextStep dock, but not the Mac. And BTW: the NSDockWindowLevel is deprecated. Don't use it. >>>>>> Yes, this is a good tip. I've removed the NSDockWindowLevel from the array. An updated fix is available at: >>>>>> >>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.1/ >>>>> Also, NSSubmenuWindowLevel and NSTornOffMenuWindowLevel are synonyms for each other, and end up being the same value. The documentation for NSWindow [2] says "The constant NSTornOffMenuWindowLevel is preferable to its synonym, NSSubmenuWindowLevel.", but again, I'd recommend just removing the table and higher/lower comparison. >>>>>>>> The array of hardcoded window levels allows us to convert between window levels ordered arbitrarily and integer values ordered according to their visual z-order. This allows us to compare windows level with respect to their relative z-order as specified by Cocoa documentation. >>>>>>> These constants are for assignment based on intention, not simple comparison of stacking level. They have behavioral meaning beyond just simple visual level ordering. Windows above the normal window level will disappear in Expos?/Mission Control, and certain levels will float in all Spaces. Other levels exclude the window from Cmd-~ keyboard window cycling, or showing up in the Dock window menu. Please, please, please test the side effects of these changes before just popping windows into different levels. >>>>>> Could you please clarify what exact "different levels" you're talking about here? AWT currently uses only two window levels: NSNormalWindowLevel is used for regular windows, and NSFloatingWindowLevel for always-on-top windows (see AWTWindow.m). This code is already in the repository, and tests for always-on-top windows do work OK. >>>>> The AWT will need to use more levels, and it's not clear how parent/child relationships need to affect these window levels. NSFloatingWindowLevel is used for palettes (like non-modal parented dialogs with small title bars), which do not participate in Expos?/Mission Control. NSModalPanelWindowLevel is what app-modal dialogs (like Open/Save) live at, which you might want "always on top" windows to be on top of too. Obviously popup menus should be at NSPopUpMenuWindowLevel. Another complication we encountered in Java SE 6 is full-screen exclusive windows, which still expect popups to be visible, so we had to push them above the NSScreenSaverWindowLevel as a gross hacky workaround. >>>>> In your testing have you moved these windows between spaces? Can you separate them between spaces? Do the windows show as visible in Mission Control? When you right-click on the Dock icon, do they show in the window list? Should they? When you press Cmd-~, do they participate in the window cycle? These are the manual tests we do every time we futz with something like "window level" or "child windows" in Java SE 6, which can't easily be automated. >>>>>> So back to the fix we're discussing, in reality the oldChildLevel in the CWrapper.addChildWindow() implementation can be either of these two levels, but not anything else. I guess we could simplify the fix and only include these two levels in the ORDERED_LEVELS{} array. I suppose Lubomir just wanted to provide a more generic and complete implementation that won't break if we ever start using any other levels in the future (or e.g. if OS temporarily puts our window on some other level). This is certainly unlikely, of course, however, I see absolutely no problems with an implementation of compareWindowLevels() that can work with all window levels officially supported by Cocoa, not just the two that we use currently. >>>>> In the future, I agree, the existing child window level will have to be more than two values, but either it should be allowed to inherit from it's parent, or it should be reset to the original value. This is really a decision to be made based on the Java model state, and not an observed property in the AppKit model which is being changed behind your back and compared against a table. Right now the only decision hooks on if the AOT state of the parent and child, which is already present in the styleBits of the window. >>>>> See the IS, SET, and MASK macro usage in AWTWindow.m for more info. You could make a simple accessor to report if ALWAYS_ON_TOP is set on both the parent and the child. >>>>>>> The safest thing to do (if it works) is just to simply re-assign the window level after adding the child to the parent, but you will have to recursively descend into the child windows of the child, because setting the window level sets the level of all the children too (and changes their collection/spaces/cycle behavior). This may not be an issue if you never change a child window's parent. >>>>>> I've clarified above why simple reassignment won't work well. >>>>> Got it. I think I've straightened out my thinking on this too, and paged back years of hacks and corner cases I would have preferred to have forgotten... >>>>> Cheers, >>>>> Mike Swingler >>>>> Apple Inc. >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>>> Regards, >>>>>>> Mike Swingler >>>>>>> Apple Inc. >>>>>>>> Does this clarify the need for the array of window levels? Do you have any other concerns regarding the fix? >>>>>>>> >>>>>>>> [1] http://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/tdef/CGWindowLevelKey >>>>>>>> >>>>>>>> [2] http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Window_Levels >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Mike Swingler >>>>>>>>> Apple Inc. >>>>>>>>> On Jan 14, 2012, at 7:40 PM, Mike Swingler wrote: >>>>>>>>>> In the course of preparing to contribute our current window stacking algorithm, I realized that there was a pair of internal SPI calls it was making. In the next revision we ship of the JavaRuntimeSupport.framework we can provide cover methods of these SPI, however that is of little benefit to the OpenJDK port in the immediate here-and-now. >>>>>>>>>> >>>>>>>>>> For now, using -addChildWindow: will be sufficient, however, we can provide an alternate implementation that uses a new pair of category methods on NSWindow if -respondsToSelector: shows that they are available: >>>>>>>>>> - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; >>>>>>>>>> - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; >>>>>>>>>> >>>>>>>>>> These functions will allow the window server to move each child window with respect to it's parent's level, but without being added to it's movement group. >>>>>>>>>> >>>>>>>>>> Once customers get an updated JavaNativeFoundation.framework by either Java update or OS update, the implementation will switch over dynamically at runtime. >>>>>>>>>> >>>>>>>>>> How does this sound for a plan? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Mike Swingler >>>>>>>>>> Apple Inc. >>>>>>>>>> >>>>>>>>>> On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com wrote: >>>>>>>>>> >>>>>>>>>>> We fought this one in SWT and ended up going with the puppy route. >>>>>>>>>>> >>>>>>>>>>> Steve >>>>>>>>>>> >>>>>>>>>>> On 12/01/2012 2:57 PM, Anthony Petrov wrote: >>>>>>>>>>>> Hi Mike, >>>>>>>>>>>> >>>>>>>>>>>> I recall we've discussed this issue with you back in 2010. Unfortunately, I wasn't able to implement anything like this that would work reliably back then (and I tried hard, really), that's why we ended up with -addChildWindow:. Note that JCK is very happy with this implementation, and so are we, I presume. As long as child windows receive their respective MOVE events, it seems that everything is all right. Besides, such behavior is very Mac-friendly, making Java apps behave like native apps. >>>>>>>>>>>> >>>>>>>>>>>> I realize that for some developers this behavior may be inconvenient. But then again, why not listen to MOVE events on the parent frame and compensate for its movement repositioning all its children? ( :) yeah, yeah, I know, sounds weird, but... as Steve says, you gotta do what you gotta do... I mean, there's a workaround at least!) >>>>>>>>>>>> >>>>>>>>>>>> So, if you or anyone else wish to contribute an alternative implementation for owned windows, that would be greatly appreciated. Otherwise I'm afraid we have to stick with using -addChildWindow: for now since we simply don't have a better solution. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> best regards, >>>>>>>>>>>> Anthony >>>>>>>>>>>> >>>>>>>>>>>> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>>>>>>>>>>>> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). >>>>>>>>>>>>> >>>>>>>>>>>>> In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Mike Swingler >>>>>>>>>>>>> Apple Inc. >>>>>>>>>>>>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>> Anthony >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>>>>>>>>>>>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>>>>>>>>>>>>>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks for taking a look at the fix. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>>>> Anthony >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>>>>>>>>>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>>>>>> Anthony > From anthony.petrov at oracle.com Wed Jan 25 03:16:35 2012 From: anthony.petrov at oracle.com (anthony.petrov at oracle.com) Date: Wed, 25 Jan 2012 11:16:35 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7131038: [macosx] Document usage of -XstartOnFirstThread and -Xdock:* Message-ID: <20120125111646.33FD14718D@hg.openjdk.java.net> Changeset: bb6ca744cb04 Author: anthony Date: 2012-01-25 15:15 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/bb6ca744cb04 7131038: [macosx] Document usage of -XstartOnFirstThread and -Xdock:* Summary: Update java -help output Reviewed-by: ksrini ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties From anthony.petrov at oracle.com Wed Jan 25 03:38:08 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 25 Jan 2012 15:38:08 +0400 Subject: Review request for 7129420: [macosx] SplashScreen.getSplashScreen() returns null In-Reply-To: <4F19A90A.4040502@oracle.COM> References: <4F199738.4020903@oracle.com> <4F19A90A.4040502@oracle.COM> Message-ID: <4F1FE9A0.3070303@oracle.com> Hi Kumar, Thanks for refactoring the Java launcher code! I've just re-based my fix to the new structure of the Mac OS X launcher sources, here it is: http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.1/ I've applied all the suggestions listed below. Thanks for the review! Regarding your question about checking for dlopen() status - yes, we're OK if the splash screen library is unable to load. E.g. Embedded folks often remove some unnecessary parts from a JRE image to reduce its size. If they remove the splash screen dynamic library we'll just silently ignore the error and continue w/o showing the splash screen - not that it's much needed for embedded applications anyway. The path lengths, however, are true error conditions, that's why I JLI_ReportErrorMessage() them with my fix. -- best regards, Anthony On 1/20/2012 9:48 PM, Kumar Srinivasan wrote: > Hi Anthony, > > Do you want to wait until I push the launcher changes which > are under review ? > > In the launcher code we tend to use the JLI prefixed posix > calls, ex: JLI_Snprintf. vs snprintf > > The error messages are defined in emessages.h, this is so > that we can L10N these messages in the future, if such a > requirement arises. I think you can use JRE_ERROR11 > > Personally I would create two more buffers to avoid errors > and make it safer, these are a cause of some grief when > security audits are performed for buffer overruns. > > char tail[PATH_MAX] > char tmp[PATH_MAX] > > JLI_Snprintf(tail, PATH_MAX, "/lib/%s", SPLASHSCREEN_SO); > > if (JLI_Snprintf(tmp, PATH_MAX, "%s%s", path, tail)) { > JLI_ReportErrorMessage....... > } > > also I noticed that there is no check for dlopen, so is it ok for the > splashscreen to fail silently if dlopen fails ? > > Thanks > Kumar > > >> Hello, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7129420 >> at: >> >> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.0/ >> >> We remove our custom mechanism to determine the splash screen dynamic >> library path and instead start using the GetJREPath() for this >> purpose. I've verified this fix with an SDK (not JRE!) image, and it >> works just fine. >> >> -- >> best regards, >> Anthony > From sergey.bylokhov at oracle.com Wed Jan 25 04:18:06 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 25 Jan 2012 16:18:06 +0400 Subject: Request for review: 7130587 - [macosx] Scrolling and painting issues with late invocation of setText Message-ID: <4F1FF2FE.6030507@oracle.com> Hi Everyone, We should invalidate text component, when its state changed and then we should validate its container. Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7130587 Webrev can be found at:http://cr.openjdk.java.net/~serb/7130587/webrev.00/ -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Jan 25 04:44:53 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 25 Jan 2012 16:44:53 +0400 Subject: Request for review: 7130587 - [macosx] Scrolling and painting issues with late invocation of setText In-Reply-To: <4F1FF2FE.6030507@oracle.com> References: <4F1FF2FE.6030507@oracle.com> Message-ID: <4F1FF945.10806@oracle.com> Hi Sergey, I'd like to clarify the logic behind invalidating/validating parts of component hierarchies. src/macosx/classes/sun/lwawt/LWTextComponentPeer.java > 177 protected final void revalidate() { > 178 synchronized (getDelegateLock()) { > 179 getTextComponent().invalidate(); > 180 getDelegate().validate(); > 181 } > 182 } Here we're actually dealing with two different, unrelated component hierarchies: 1. The real, user's hierarchy: the text component belongs to it. We're calling invalidate() for this real, AWT component which results in invalidating the component and its ancestors. Do I understand correctly that user's code is responsible for validating their components back after each setText()/insert()/etc calls? Is this how a HW AWT hierarchy behaves (e.g. on Win and X11)? 2. Our internal, not visible to the user hierarchy: the delegate Swing component belongs to this hierarchy. We're only calling validate() for it assuming that it's been invalidated somewhere else already. Is this correct? Before we did invalidate it explicitly with a call to getDelegate().invalidate() in sendTextEvent(). Would it make sense to add a call to getDelegate().invalidate() before calling its validate() in LWTextComponentPeer.revalidate() to make sure the validate() isn't a no-op? -- best regards, Anthony On 1/25/2012 4:18 PM, Sergey Bylokhov wrote: > Hi Everyone, > We should invalidate text component, when its state changed and then we > should validate its container. > > Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7130587 > Webrev can be found at:http://cr.openjdk.java.net/~serb/7130587/webrev.00/ > From sergey.bylokhov at oracle.com Wed Jan 25 04:55:47 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 25 Jan 2012 16:55:47 +0400 Subject: Request for review: 7130587 - [macosx] Scrolling and painting issues with late invocation of setText In-Reply-To: <4F1FF945.10806@oracle.com> References: <4F1FF2FE.6030507@oracle.com> <4F1FF945.10806@oracle.com> Message-ID: <4F1FFBD3.3010501@oracle.com> 25.01.2012 16:44, Anthony Petrov wrote: > Hi Sergey, > > I'd like to clarify the logic behind invalidating/validating parts of > component hierarchies. > > src/macosx/classes/sun/lwawt/LWTextComponentPeer.java >> 177 protected final void revalidate() { >> 178 synchronized (getDelegateLock()) { >> 179 getTextComponent().invalidate(); >> 180 getDelegate().validate(); >> 181 } >> 182 } > > Here we're actually dealing with two different, unrelated component > hierarchies: > > 1. The real, user's hierarchy: the text component belongs to it. We're > calling invalidate() for this real, AWT component which results in > invalidating the component and its ancestors. Do I understand > correctly that user's code is responsible for validating their > components back after each setText()/insert()/etc calls? Is this how a > HW AWT hierarchy behaves (e.g. on Win and X11)? No, we invalidate internal delegate(JScrollPane) starting from its child TextComponent(JTextArea). > > 2. Our internal, not visible to the user hierarchy: the delegate Swing > component belongs to this hierarchy. We're only calling validate() for > it assuming that it's been invalidated somewhere else already. Is this > correct? > Before we did invalidate it explicitly with a call to > getDelegate().invalidate() in sendTextEvent(). For textfield nothing changed because getTextComponent() returns delegate. For textarea we start invalidating from the child(JTextArea) of our delegate(JScrollPane) > Would it make sense to add a call to getDelegate().invalidate() before > calling its validate() in LWTextComponentPeer.revalidate() to make > sure the validate() isn't a no-op? > > -- > best regards, > Anthony > > On 1/25/2012 4:18 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> We should invalidate text component, when its state changed and then >> we should validate its container. >> >> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7130587 >> Webrev can be found >> at:http://cr.openjdk.java.net/~serb/7130587/webrev.00/ >> -- Best regards, Sergey. From anton.tarasov at oracle.com Wed Jan 25 05:58:59 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 25 Jan 2012 16:58:59 +0300 Subject: Review request for 7131196 - [macosx] Cmd-Q does not quit a graphical Java app Message-ID: <4F200AA3.40105@oracle.com> Hello, Please review a fix for 7131196. webrev: http://cr.openjdk.java.net/~ant/7131196/webrev.0/ -[NSView performKeyEquivalent:] serves to listen to key events with modifiers. Currently it returns NO (FALSE). This prevents NSApp from processing the event by default. For instance, CMD+Q doesn't close the app. The fix is to return NO from the method. So, it will allow default processing for all the events with modifiers (along with dispatching them to Java). Thanks, Anton. From anthony.petrov at oracle.com Wed Jan 25 04:59:38 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 25 Jan 2012 16:59:38 +0400 Subject: Request for review: 7130587 - [macosx] Scrolling and painting issues with late invocation of setText In-Reply-To: <4F1FFBD3.3010501@oracle.com> References: <4F1FF2FE.6030507@oracle.com> <4F1FF945.10806@oracle.com> <4F1FFBD3.3010501@oracle.com> Message-ID: <4F1FFCBA.6050209@oracle.com> Ah, I missed that part that getTextComponent() actually returns our internal Swing text component, not the target. Thanks for clarifying that. I'm fine with the fix then. -- best regards, Anthony On 1/25/2012 4:55 PM, Sergey Bylokhov wrote: > 25.01.2012 16:44, Anthony Petrov wrote: >> Hi Sergey, >> >> I'd like to clarify the logic behind invalidating/validating parts of >> component hierarchies. >> >> src/macosx/classes/sun/lwawt/LWTextComponentPeer.java >>> 177 protected final void revalidate() { >>> 178 synchronized (getDelegateLock()) { >>> 179 getTextComponent().invalidate(); >>> 180 getDelegate().validate(); >>> 181 } >>> 182 } >> >> Here we're actually dealing with two different, unrelated component >> hierarchies: >> >> 1. The real, user's hierarchy: the text component belongs to it. We're >> calling invalidate() for this real, AWT component which results in >> invalidating the component and its ancestors. Do I understand >> correctly that user's code is responsible for validating their >> components back after each setText()/insert()/etc calls? Is this how a >> HW AWT hierarchy behaves (e.g. on Win and X11)? > No, we invalidate internal delegate(JScrollPane) starting from its child > TextComponent(JTextArea). >> >> 2. Our internal, not visible to the user hierarchy: the delegate Swing >> component belongs to this hierarchy. We're only calling validate() for >> it assuming that it's been invalidated somewhere else already. Is this >> correct? >> Before we did invalidate it explicitly with a call to >> getDelegate().invalidate() in sendTextEvent(). > For textfield nothing changed because getTextComponent() returns > delegate. For textarea we start invalidating from the child(JTextArea) > of our delegate(JScrollPane) >> Would it make sense to add a call to getDelegate().invalidate() before >> calling its validate() in LWTextComponentPeer.revalidate() to make >> sure the validate() isn't a no-op? >> >> -- >> best regards, >> Anthony >> >> On 1/25/2012 4:18 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> We should invalidate text component, when its state changed and then >>> we should validate its container. >>> >>> Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7130587 >>> Webrev can be found >>> at:http://cr.openjdk.java.net/~serb/7130587/webrev.00/ >>> > > From anthony.petrov at oracle.com Wed Jan 25 05:02:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 25 Jan 2012 17:02:22 +0400 Subject: Review request for 7131196 - [macosx] Cmd-Q does not quit a graphical Java app In-Reply-To: <4F200AA3.40105@oracle.com> References: <4F200AA3.40105@oracle.com> Message-ID: <4F1FFD5E.9010009@oracle.com> Hi Anton, On 1/25/2012 5:58 PM, Anton V. Tarasov wrote: > Please review a fix for 7131196. > > webrev: http://cr.openjdk.java.net/~ant/7131196/webrev.0/ > > -[NSView performKeyEquivalent:] serves to listen to key events with > modifiers. Currently it returns NO (FALSE). This prevents NSApp from You meant TRUE (YES) here, right? :) > processing the event by default. For instance, CMD+Q doesn't close > the app. > > The fix is to return NO from the method. So, it will allow default > processing for all the events with modifiers (along with dispatching > them to Java). The fix looks good to me. -- best regards, Anthony From sergey.bylokhov at oracle.com Wed Jan 25 05:17:23 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 25 Jan 2012 17:17:23 +0400 Subject: Request for review: 7131752 [macosx] Multiselect List doesn't display scrollbar after consecutive additions Message-ID: <4F2000E3.6030103@oracle.com> Hi Everyone, We should invalidate list component, when its state changed and then we should validate its container. Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7131752 Webrev can be found at: http://cr.openjdk.java.net/~serb/7131752/webrev.00/ -- Best regards, Sergey. From anton.tarasov at oracle.com Wed Jan 25 05:18:43 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 25 Jan 2012 17:18:43 +0400 Subject: Review request for 7131196 - [macosx] Cmd-Q does not quit a graphical Java app In-Reply-To: <4F1FFD5E.9010009@oracle.com> References: <4F200AA3.40105@oracle.com> <4F1FFD5E.9010009@oracle.com> Message-ID: <4F200133.5010008@oracle.com> On 25.01.2012 17:02, Anthony Petrov wrote: > Hi Anton, > > On 1/25/2012 5:58 PM, Anton V. Tarasov wrote: >> Please review a fix for 7131196. >> >> webrev: http://cr.openjdk.java.net/~ant/7131196/webrev.0/ >> >> -[NSView performKeyEquivalent:] serves to listen to key events with >> modifiers. Currently it returns NO (FALSE). This prevents NSApp from > > You meant TRUE (YES) here, right? :) Ah, right! Thanks for the correction =) Anton. > >> processing the event by default. For instance, CMD+Q doesn't close >> the app. >> >> The fix is to return NO from the method. So, it will allow default >> processing for all the events with modifiers (along with dispatching >> them to Java). > > The fix looks good to me. > > -- > best regards, > Anthony From anthony.petrov at oracle.com Wed Jan 25 05:23:39 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 25 Jan 2012 17:23:39 +0400 Subject: Request for review: 7131752 [macosx] Multiselect List doesn't display scrollbar after consecutive additions In-Reply-To: <4F2000E3.6030103@oracle.com> References: <4F2000E3.6030103@oracle.com> Message-ID: <4F20025B.8070203@oracle.com> Looks fine. -- best regards, Anthony On 1/25/2012 5:17 PM, Sergey Bylokhov wrote: > Hi Everyone, > We should invalidate list component, when its state changed and then we > should validate its container. > > Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7131752 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7131752/webrev.00/ > From alexander.zuev at oracle.com Wed Jan 25 05:28:34 2012 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Wed, 25 Jan 2012 13:28:34 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124364: [macosx] Robot screen capturing functionality doesn't work Message-ID: <20120125132844.E49E147190@hg.openjdk.java.net> Changeset: 1551cb104ed3 Author: leonidr Date: 2012-01-25 17:29 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/1551cb104ed3 7124364: [macosx] Robot screen capturing functionality doesn't work Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/macosx/CRobot.java From sergey.bylokhov at oracle.com Wed Jan 25 05:34:25 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 25 Jan 2012 17:34:25 +0400 Subject: [7u4-osx] Request for approval for 7130587 - [macosx] Scrolling and painting issues with late invocation of setText Message-ID: <4F2004E1.4080308@oracle.com> Hello, This is a new request to push the following changes to jdk7u-osx. The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7130587 Webrev can be found at: http://cr.openjdk.java.net/~serb/7130587/webrev.00/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002457.html -- Best regards, Sergey. From sergey.bylokhov at oracle.com Wed Jan 25 05:39:31 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 25 Jan 2012 17:39:31 +0400 Subject: [7u4-osx] Request for approval for 7131752 - [macosx] Multiselect List doesn't display scrollbar after consecutive additions Message-ID: <4F200613.9020406@oracle.com> Hello, This is a request to push the following changes to jdk7u-osx. The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov. Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7131752 Webrev can be found at: http://cr.openjdk.java.net/~serb/7131752/webrev.00/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002463.html -- Best regards, Sergey. From kumar.x.srinivasan at oracle.COM Wed Jan 25 05:51:53 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Wed, 25 Jan 2012 05:51:53 -0800 Subject: Review request for 7129420: [macosx] SplashScreen.getSplashScreen() returns null In-Reply-To: <4F1FE9A0.3070303@oracle.com> References: <4F199738.4020903@oracle.com> <4F19A90A.4040502@oracle.COM> <4F1FE9A0.3070303@oracle.com> Message-ID: <4F2008F9.4050106@oracle.COM> Hi Anthony, Generally looks good, however few more comments. Shouldn't we check for negative returns from snprintf ? The snprintf(3) contract indicates on openbsd that it will return <0 values for errors, in which case, we could be feeding an unitialized splashPath to dlopen, perhaps we should initialize it as well ? Also appreciate including your comments below in the platform source(s) if applicable, explaining why we don't check the return value for dlopen, will be good. This is in case someone decides to to be meticulous and adds a check. Thanks Kumar [PS: cc'ing Joe and David Holmes on launcher fixes, they are usually interested in launcher changes] > Hi Kumar, > > Thanks for refactoring the Java launcher code! I've just re-based my > fix to the new structure of the Mac OS X launcher sources, here it is: > > http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.1/ > > I've applied all the suggestions listed below. Thanks for the review! > > Regarding your question about checking for dlopen() status - yes, > we're OK if the splash screen library is unable to load. E.g. Embedded > folks often remove some unnecessary parts from a JRE image to reduce > its size. If they remove the splash screen dynamic library we'll just > silently ignore the error and continue w/o showing the splash screen - > not that it's much needed for embedded applications anyway. > > The path lengths, however, are true error conditions, that's why I > JLI_ReportErrorMessage() them with my fix. > > -- > best regards, > Anthony > > On 1/20/2012 9:48 PM, Kumar Srinivasan wrote: >> Hi Anthony, >> >> Do you want to wait until I push the launcher changes which >> are under review ? >> >> In the launcher code we tend to use the JLI prefixed posix >> calls, ex: JLI_Snprintf. vs snprintf >> >> The error messages are defined in emessages.h, this is so >> that we can L10N these messages in the future, if such a >> requirement arises. I think you can use JRE_ERROR11 >> >> Personally I would create two more buffers to avoid errors >> and make it safer, these are a cause of some grief when >> security audits are performed for buffer overruns. >> >> char tail[PATH_MAX] >> char tmp[PATH_MAX] >> >> JLI_Snprintf(tail, PATH_MAX, "/lib/%s", SPLASHSCREEN_SO); >> >> if (JLI_Snprintf(tmp, PATH_MAX, "%s%s", path, tail)) { >> JLI_ReportErrorMessage....... >> } >> >> also I noticed that there is no check for dlopen, so is it ok for the >> splashscreen to fail silently if dlopen fails ? >> >> Thanks >> Kumar >> >> >>> Hello, >>> >>> Please review a fix for >>> http://bugs.sun.com/view_bug.do?bug_id=7129420 at: >>> >>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.0/ >>> >>> We remove our custom mechanism to determine the splash screen >>> dynamic library path and instead start using the GetJREPath() for >>> this purpose. I've verified this fix with an SDK (not JRE!) image, >>> and it works just fine. >>> >>> -- >>> best regards, >>> Anthony >> From anthony.petrov at oracle.com Wed Jan 25 06:42:11 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 25 Jan 2012 18:42:11 +0400 Subject: Review request for 7129420: [macosx] SplashScreen.getSplashScreen() returns null In-Reply-To: <4F2008F9.4050106@oracle.COM> References: <4F199738.4020903@oracle.com> <4F19A90A.4040502@oracle.COM> <4F1FE9A0.3070303@oracle.com> <4F2008F9.4050106@oracle.COM> Message-ID: <4F2014C3.90806@oracle.com> Hi Kumar, You're right, this additional check and a comment make sense. I've updated the webrev at: http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.2/ Please review. -- best regards, Anthony On 1/25/2012 5:51 PM, Kumar Srinivasan wrote: > Hi Anthony, > > Generally looks good, however few more comments. > > Shouldn't we check for negative returns from snprintf ? > > The snprintf(3) contract indicates on openbsd that it will return <0 values > for errors, in which case, we could be feeding an unitialized > splashPath to dlopen, perhaps we should initialize it as well ? > > Also appreciate including your comments below in the platform > source(s) if applicable, explaining why we don't check the return > value for dlopen, will be good. This is in case someone decides > to to be meticulous and adds a check. > > Thanks > > Kumar > [PS: cc'ing Joe and David Holmes on launcher fixes, they are > usually interested in launcher changes] > >> Hi Kumar, >> >> Thanks for refactoring the Java launcher code! I've just re-based my >> fix to the new structure of the Mac OS X launcher sources, here it is: >> >> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.1/ >> >> I've applied all the suggestions listed below. Thanks for the review! >> >> Regarding your question about checking for dlopen() status - yes, >> we're OK if the splash screen library is unable to load. E.g. Embedded >> folks often remove some unnecessary parts from a JRE image to reduce >> its size. If they remove the splash screen dynamic library we'll just >> silently ignore the error and continue w/o showing the splash screen - >> not that it's much needed for embedded applications anyway. >> >> The path lengths, however, are true error conditions, that's why I >> JLI_ReportErrorMessage() them with my fix. >> >> -- >> best regards, >> Anthony >> >> On 1/20/2012 9:48 PM, Kumar Srinivasan wrote: >>> Hi Anthony, >>> >>> Do you want to wait until I push the launcher changes which >>> are under review ? >>> >>> In the launcher code we tend to use the JLI prefixed posix >>> calls, ex: JLI_Snprintf. vs snprintf >>> >>> The error messages are defined in emessages.h, this is so >>> that we can L10N these messages in the future, if such a >>> requirement arises. I think you can use JRE_ERROR11 >>> >>> Personally I would create two more buffers to avoid errors >>> and make it safer, these are a cause of some grief when >>> security audits are performed for buffer overruns. >>> >>> char tail[PATH_MAX] >>> char tmp[PATH_MAX] >>> >>> JLI_Snprintf(tail, PATH_MAX, "/lib/%s", SPLASHSCREEN_SO); >>> >>> if (JLI_Snprintf(tmp, PATH_MAX, "%s%s", path, tail)) { >>> JLI_ReportErrorMessage....... >>> } >>> >>> also I noticed that there is no check for dlopen, so is it ok for the >>> splashscreen to fail silently if dlopen fails ? >>> >>> Thanks >>> Kumar >>> >>> >>>> Hello, >>>> >>>> Please review a fix for >>>> http://bugs.sun.com/view_bug.do?bug_id=7129420 at: >>>> >>>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.0/ >>>> >>>> We remove our custom mechanism to determine the splash screen >>>> dynamic library path and instead start using the GetJREPath() for >>>> this purpose. I've verified this fix with an SDK (not JRE!) image, >>>> and it works just fine. >>>> >>>> -- >>>> best regards, >>>> Anthony >>> > From kumar.x.srinivasan at oracle.COM Wed Jan 25 06:52:18 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Wed, 25 Jan 2012 06:52:18 -0800 Subject: Review request for 7129420: [macosx] SplashScreen.getSplashScreen() returns null In-Reply-To: <4F2014C3.90806@oracle.com> References: <4F199738.4020903@oracle.com> <4F19A90A.4040502@oracle.COM> <4F1FE9A0.3070303@oracle.com> <4F2008F9.4050106@oracle.COM> <4F2014C3.90806@oracle.com> Message-ID: <4F201722.2020804@oracle.COM> Hi Anthony, Approved. Also I take it now the splash screen should work from sdk and jre images directory, it did not work before. Is someone going to fix those SplashScreen regression tests ? Just curious. Thanks Kumar > Hi Kumar, > > You're right, this additional check and a comment make sense. I've > updated the webrev at: > > http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.2/ > > Please review. > > -- > best regards, > Anthony > > On 1/25/2012 5:51 PM, Kumar Srinivasan wrote: >> Hi Anthony, >> >> Generally looks good, however few more comments. >> >> Shouldn't we check for negative returns from snprintf ? >> >> The snprintf(3) contract indicates on openbsd that it will return <0 >> values >> for errors, in which case, we could be feeding an unitialized >> splashPath to dlopen, perhaps we should initialize it as well ? >> >> Also appreciate including your comments below in the platform >> source(s) if applicable, explaining why we don't check the return >> value for dlopen, will be good. This is in case someone decides >> to to be meticulous and adds a check. >> >> Thanks >> >> Kumar >> [PS: cc'ing Joe and David Holmes on launcher fixes, they are >> usually interested in launcher changes] >> >>> Hi Kumar, >>> >>> Thanks for refactoring the Java launcher code! I've just re-based my >>> fix to the new structure of the Mac OS X launcher sources, here it is: >>> >>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.1/ >>> >>> I've applied all the suggestions listed below. Thanks for the review! >>> >>> Regarding your question about checking for dlopen() status - yes, >>> we're OK if the splash screen library is unable to load. E.g. >>> Embedded folks often remove some unnecessary parts from a JRE image >>> to reduce its size. If they remove the splash screen dynamic library >>> we'll just silently ignore the error and continue w/o showing the >>> splash screen - not that it's much needed for embedded applications >>> anyway. >>> >>> The path lengths, however, are true error conditions, that's why I >>> JLI_ReportErrorMessage() them with my fix. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/20/2012 9:48 PM, Kumar Srinivasan wrote: >>>> Hi Anthony, >>>> >>>> Do you want to wait until I push the launcher changes which >>>> are under review ? >>>> >>>> In the launcher code we tend to use the JLI prefixed posix >>>> calls, ex: JLI_Snprintf. vs snprintf >>>> >>>> The error messages are defined in emessages.h, this is so >>>> that we can L10N these messages in the future, if such a >>>> requirement arises. I think you can use JRE_ERROR11 >>>> >>>> Personally I would create two more buffers to avoid errors >>>> and make it safer, these are a cause of some grief when >>>> security audits are performed for buffer overruns. >>>> >>>> char tail[PATH_MAX] >>>> char tmp[PATH_MAX] >>>> >>>> JLI_Snprintf(tail, PATH_MAX, "/lib/%s", SPLASHSCREEN_SO); >>>> >>>> if (JLI_Snprintf(tmp, PATH_MAX, "%s%s", path, tail)) { >>>> JLI_ReportErrorMessage....... >>>> } >>>> >>>> also I noticed that there is no check for dlopen, so is it ok for the >>>> splashscreen to fail silently if dlopen fails ? >>>> >>>> Thanks >>>> Kumar >>>> >>>> >>>>> Hello, >>>>> >>>>> Please review a fix for >>>>> http://bugs.sun.com/view_bug.do?bug_id=7129420 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.0/ >>>>> >>>>> We remove our custom mechanism to determine the splash screen >>>>> dynamic library path and instead start using the GetJREPath() for >>>>> this purpose. I've verified this fix with an SDK (not JRE!) image, >>>>> and it works just fine. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>> >> From anthony.petrov at oracle.com Wed Jan 25 06:56:13 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 25 Jan 2012 18:56:13 +0400 Subject: Review request for 7129420: [macosx] SplashScreen.getSplashScreen() returns null In-Reply-To: <4F201722.2020804@oracle.COM> References: <4F199738.4020903@oracle.com> <4F19A90A.4040502@oracle.COM> <4F1FE9A0.3070303@oracle.com> <4F2008F9.4050106@oracle.COM> <4F2014C3.90806@oracle.com> <4F201722.2020804@oracle.COM> Message-ID: <4F20180D.7080301@oracle.com> On 1/25/2012 6:52 PM, Kumar Srinivasan wrote: > Approved. Thanks! > Also I take it now the splash screen should work from sdk and jre > images directory, it did not work before. > > Is someone going to fix those SplashScreen regression tests ? > Just curious. The tests should now run fine regardless of what image is used to run them. -- best regards, Anthony > > Thanks > Kumar > >> Hi Kumar, >> >> You're right, this additional check and a comment make sense. I've >> updated the webrev at: >> >> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.2/ >> >> Please review. >> >> -- >> best regards, >> Anthony >> >> On 1/25/2012 5:51 PM, Kumar Srinivasan wrote: >>> Hi Anthony, >>> >>> Generally looks good, however few more comments. >>> >>> Shouldn't we check for negative returns from snprintf ? >>> >>> The snprintf(3) contract indicates on openbsd that it will return <0 >>> values >>> for errors, in which case, we could be feeding an unitialized >>> splashPath to dlopen, perhaps we should initialize it as well ? >>> >>> Also appreciate including your comments below in the platform >>> source(s) if applicable, explaining why we don't check the return >>> value for dlopen, will be good. This is in case someone decides >>> to to be meticulous and adds a check. >>> >>> Thanks >>> >>> Kumar >>> [PS: cc'ing Joe and David Holmes on launcher fixes, they are >>> usually interested in launcher changes] >>> >>>> Hi Kumar, >>>> >>>> Thanks for refactoring the Java launcher code! I've just re-based my >>>> fix to the new structure of the Mac OS X launcher sources, here it is: >>>> >>>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.1/ >>>> >>>> I've applied all the suggestions listed below. Thanks for the review! >>>> >>>> Regarding your question about checking for dlopen() status - yes, >>>> we're OK if the splash screen library is unable to load. E.g. >>>> Embedded folks often remove some unnecessary parts from a JRE image >>>> to reduce its size. If they remove the splash screen dynamic library >>>> we'll just silently ignore the error and continue w/o showing the >>>> splash screen - not that it's much needed for embedded applications >>>> anyway. >>>> >>>> The path lengths, however, are true error conditions, that's why I >>>> JLI_ReportErrorMessage() them with my fix. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 1/20/2012 9:48 PM, Kumar Srinivasan wrote: >>>>> Hi Anthony, >>>>> >>>>> Do you want to wait until I push the launcher changes which >>>>> are under review ? >>>>> >>>>> In the launcher code we tend to use the JLI prefixed posix >>>>> calls, ex: JLI_Snprintf. vs snprintf >>>>> >>>>> The error messages are defined in emessages.h, this is so >>>>> that we can L10N these messages in the future, if such a >>>>> requirement arises. I think you can use JRE_ERROR11 >>>>> >>>>> Personally I would create two more buffers to avoid errors >>>>> and make it safer, these are a cause of some grief when >>>>> security audits are performed for buffer overruns. >>>>> >>>>> char tail[PATH_MAX] >>>>> char tmp[PATH_MAX] >>>>> >>>>> JLI_Snprintf(tail, PATH_MAX, "/lib/%s", SPLASHSCREEN_SO); >>>>> >>>>> if (JLI_Snprintf(tmp, PATH_MAX, "%s%s", path, tail)) { >>>>> JLI_ReportErrorMessage....... >>>>> } >>>>> >>>>> also I noticed that there is no check for dlopen, so is it ok for the >>>>> splashscreen to fail silently if dlopen fails ? >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>> >>>>>> Hello, >>>>>> >>>>>> Please review a fix for >>>>>> http://bugs.sun.com/view_bug.do?bug_id=7129420 at: >>>>>> >>>>>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.0/ >>>>>> >>>>>> We remove our custom mechanism to determine the splash screen >>>>>> dynamic library path and instead start using the GetJREPath() for >>>>>> this purpose. I've verified this fix with an SDK (not JRE!) image, >>>>>> and it works just fine. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>> >>> > From artem.ananiev at oracle.com Wed Jan 25 07:00:26 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 25 Jan 2012 19:00:26 +0400 Subject: [7u4] Request for approval for 7124530 - What is background color of AWT component? (And foreground, for that matter) In-Reply-To: <4F1DB20B.7060208@oracle.com> References: <4F0ED0EF.90208@oracle.com> <4F103F68.9040806@oracle.com> <9716158E-63E1-4554-B07C-2772A35F82E7@apple.com> <4F107D53.9060600@oracle.com> <3BBD9C26-CA01-4EDD-8279-F6C87AB25E61@apple.com> <4F196A63.9060209@oracle.com> <4F1DB20B.7060208@oracle.com> Message-ID: <4F20190A.5080404@oracle.com> On 1/23/2012 11:16 PM, Sergey Bylokhov wrote: > Hello, > Note: that the fix just replace one constant to another. And if there is > a way to get this system background color in more appropriate way, we > can do it later. This is an important notice: the fix doesn't do any harm. Although it may not be perfect, it should be addressed separately. I'm fine with it. Thanks, Artem > If there is no other comments I request an approve for the fix again. > > 20.01.2012 17:21, Sergey Bylokhov wrote: >> 18.01.2012 0:29, Mike Swingler wrote: >>> On Jan 13, 2012, at 10:52 AM, Sergey Bylokhov wrote: >>> >>>> 13.01.2012 21:31, Mike Swingler ?????: >>>>> On Jan 13, 2012, at 6:27 AM, Sergey Bylokhov wrote: >>>>> >>>>>> 13.01.2012 6:30, Mike Swingler wrote: >>>>>> >>>>>>> On Jan 12, 2012, at 4:24 AM, Sergey Bylokhov wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> This is a request to push the following changes to jdk7u-osx. >>>>>>>> The fix has been reviewed on macosx-port-dev mailing list by >>>>>>>> Alexander Potochkin. >>>>>>>> >>>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124530 >>>>>>>> Webrev can be found at: >>>>>>>> http://cr.openjdk.java.net/~serb/7124530/webrev.00/ >>>>>>>> Technical review: >>>>>>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002143.html >>>>>>>> >>>>>>> I don't understand this part: >>>>>>> >>>>>>> --- old/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 >>>>>>> 19:02:19.913935900 +0400 >>>>>>> +++ new/src/macosx/native/sun/awt/CSystemColors.m 2011-12-28 >>>>>>> 19:02:19.557915600 +0400 >>>>>>> @@ -81,7 +81,8 @@ >>>>>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION] = [NSColor >>>>>>> grayColor]; >>>>>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION_TEXT] = [NSColor >>>>>>> grayColor]; >>>>>>> sColors[java_awt_SystemColor_INACTIVE_CAPTION_BORDER] = [NSColor >>>>>>> grayColor]; >>>>>>> - sColors[java_awt_SystemColor_WINDOW] = [NSColor grayColor]; >>>>>>> + const CGFloat color = (CGFloat)0xEE/(CGFloat)0xFF; >>>>>>> + sColors[java_awt_SystemColor_WINDOW] = [NSColor >>>>>>> colorWithCalibratedRed:color green:color blue:color alpha:1.0f]; >>>>>>> sColors[java_awt_SystemColor_WINDOW_BORDER] = [NSColor >>>>>>> windowFrameColor]; >>>>>>> sColors[java_awt_SystemColor_WINDOW_TEXT] = [NSColor >>>>>>> windowFrameTextColor]; >>>>>>> sColors[java_awt_SystemColor_MENU] = [NSColor >>>>>>> controlBackgroundColor]; >>>>>>> >>>>>>> Why aren't you just using [NSColor windowBackgroundColor]? >>>>>> Only selectedControlColor and selectedTextBackgroundColor are >>>>>> supported. >>>>>> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DrawColor/Tasks/SystemColors.html#//apple_ref/doc/uid/20000790 >>>>>> >>>>>> As I understand that`s why swing didn`t use this color. After the >>>>>> fix awt and swing use one color (before the fix this color was >>>>>> used by swing). >>>>>> If this color is wrong, now it`s possible to change it in one place. >>>>> I can assure you that the window background color reports the >>>>> correct RGB value, even when the background color has changed >>>>> between OS versions. You static constant will not. >>>>> >>>>> We use it today in Java SE 6. >>>> jdk6 on my system reports white color which is wrong. Can you please >>>> check it(testcase attached). >>> The test works fine in Java SE 6 with JFrames and other components. >>> The bug where you are getting white from a pure AWT Frame is a side >>> effect of something we call the "magic background color", which is >>> not applicable to Java 7. >> On jdk 6 it works with swing components, because they use >> com.apple.laf.AquaNativeResources$CColorPaintUIResource with >> RGB[r=238,g=238,b=238] instead of SystemColor.WINDOW with >> RGB[r=255,g=255,b=255]. I assume that SystemColor.WINDOW is not used >> in jdk 6. >>> >>> Does +[NSColor windowBackgroundColor] not give you the correct RGB >>> value? >> Yes. It return white color[r=255,g=255,b=255]. >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> >> >> > > From artem.ananiev at oracle.com Wed Jan 25 07:02:29 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 25 Jan 2012 19:02:29 +0400 Subject: [7u-osx] Request for approval for 7131038: [macosx] Document usage of -XstartOnFirstThread and -Xdock:* In-Reply-To: <4F1E995B.20906@oracle.com> References: <4F1E995B.20906@oracle.com> Message-ID: <4F201985.6000000@oracle.com> Approved. On 1/24/2012 3:43 PM, Anthony Petrov wrote: > Hello, > > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131038 > > Webrev: http://cr.openjdk.java.net/~anthony/x-10-Xflags-7131038.0/ > > The changes to the specification are approved by CCC. > > -- > best regards, > Anthony From artem.ananiev at oracle.com Wed Jan 25 07:08:19 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 25 Jan 2012 19:08:19 +0400 Subject: Review request for 7129825 - [macosx] Native activation is not changed when focusing other frame's owned window In-Reply-To: <4F1ECCE2.4030509@oracle.com> References: <4F1ECCE2.4030509@oracle.com> Message-ID: <4F201AE3.409@oracle.com> I don't see anything obviously wrong with the fix, though I'm not a focus expert. Thanks, Artem On 1/24/2012 7:23 PM, Anton V. Tarasov wrote: > Hello, > > Please review a fix for 7129825. > > webrev: http://cr.openjdk.java.net/~ant/7129825/webrev.0/ > > The fix contains the following changes: > > 1. When a simple window requests focus its owner is properly activated. > > 2. The code that requests focus on a window from LWWindowPeer > initial mouse handler is removed. It duplicates the logic implemented > by LWWindowPeer.handleEvent(). Additionally, a window requests focus > when its unfocusable component is clicked, or its empty spot is clicked. > In this case KeyboardFocusManager sets focus on the window's default > component. > > 3. The nativeIsApplicationActive() method is moved to LWToolkit. > > 4. Two native methods are changed to be called synchronously > (performOnMainThreadWaiting:YES) as they are called from EDT. > > 5. Some minor changes. > > Tested with test/java/awt/Focus/* against regressions. > > Thanks, > Anton. > > From artem.ananiev at oracle.com Wed Jan 25 07:12:21 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 25 Jan 2012 19:12:21 +0400 Subject: Review request for 7124316: [macosx] Passive and Peered IMF Client does not cope with input methods In-Reply-To: <4F1ECE0A.9020301@oracle.com> References: <4F1DAFA5.9060008@oracle.com> <4F1E8224.1060208@oracle.com> <4F1ECE0A.9020301@oracle.com> Message-ID: <4F201BD5.1040305@oracle.com> On 1/24/2012 7:28 PM, Alexander Zuev wrote: > Artem, > > i did, but this method itself will need to be updated then and all it > actually does is > doing a bunch of irrelevant checks and then creates a new event so i > will have to add a > machinery that will do it for InputMethodEvent and then finally just > uses AWTAccessor. > It's really an overkill - we might do it much simpler just by forwarding > existing event to > the right component. OK, I got it. The only thing that bothers me is that Swing text delegates may not process input method events targeted to other components correctly, but as long as you've proved them to work, I'm fine with the fix. Thanks, Artem > Thanks, > Alex > > On 1/24/12 13:04, Artem Ananiev wrote: >> Hi, Alex, >> >> did you consider using LWComponentPeer's sendEventToDelegate() method >> instead of AWTAccessor? >> >> Thanks, >> >> Artem >> >> On 1/23/2012 11:06 PM, Alexander Zuev wrote: >>> Hello, >>> >>> please review the following fix: >>> http://cr.openjdk.java.net/~kizune/7124316/webrev.01/ >>> >>> the bug description is here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124316 >>> The previous fix, while needed, solved problem only for a small set of >>> locales. >>> This fix should solve it for all the locales for heavyweight text >>> components. >>> >>> Thanks, >>> Alex > From artem.ananiev at oracle.com Wed Jan 25 07:13:28 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 25 Jan 2012 19:13:28 +0400 Subject: [7u4-osx] Request for approval for 7124524 - OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer In-Reply-To: <4F1ED107.7020800@oracle.com> References: <4F1ED107.7020800@oracle.com> Message-ID: <4F201C18.9030208@oracle.com> Approved. On 1/24/2012 7:40 PM, Sergey Bylokhov wrote: > Hello, > This is a new request to push the following changes to jdk7u-osx. > The fix has been reviewed on macosx-port-dev mailing list by Anthony > Petrov. > > Bug: http://monaco.us.oracle.com/detail.jsf?cr=7124524 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124524/webrev.01/ > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002241.html > > From artem.ananiev at oracle.com Wed Jan 25 07:22:26 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 25 Jan 2012 19:22:26 +0400 Subject: [7u4-osx] Request for approval for 7130587 - [macosx] Scrolling and painting issues with late invocation of setText In-Reply-To: <4F2004E1.4080308@oracle.com> References: <4F2004E1.4080308@oracle.com> Message-ID: <4F201E32.3020003@oracle.com> Approved. On 1/25/2012 5:34 PM, Sergey Bylokhov wrote: > Hello, > This is a new request to push the following changes to jdk7u-osx. > The fix has been reviewed on macosx-port-dev mailing list by Anthony > Petrov. > > Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7130587 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7130587/webrev.00/ > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002457.html > > From artem.ananiev at oracle.com Wed Jan 25 07:22:48 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 25 Jan 2012 19:22:48 +0400 Subject: [7u4-osx] Request for approval for 7131752 - [macosx] Multiselect List doesn't display scrollbar after consecutive additions In-Reply-To: <4F200613.9020406@oracle.com> References: <4F200613.9020406@oracle.com> Message-ID: <4F201E48.9080506@oracle.com> Approved. On 1/25/2012 5:39 PM, Sergey Bylokhov wrote: > Hello, > This is a request to push the following changes to jdk7u-osx. > The fix has been reviewed on macosx-port-dev mailing list by Anthony > Petrov. > > Bug: http://monaco.sfbay.sun.com/detail.jsf?cr=7131752 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7131752/webrev.00/ > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002463.html > > From alexander.zuev at oracle.com Wed Jan 25 08:59:53 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 25 Jan 2012 19:59:53 +0300 Subject: [jdk7u-osx] Request for approval for 7124316: [macosx] Passive and Peered IMF Client does not cope with input methods Message-ID: <4F203509.5080605@oracle.com> Hello, this is request to approve push for the fix for 7124316: [macosx] Passive and Peered IMF Client does not cope with input methods The fix has been reviewed on macosx-port-dev mailing list by Alexander Potochkin and Artem Ananiev. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124316 Webrev for the fix can be found here: http://cr.openjdk.java.net/~kizune/7124316/webrev.01/ Thanks, Alex From sergey.bylokhov at oracle.com Wed Jan 25 08:05:54 2012 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Wed, 25 Jan 2012 16:05:54 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124562: [macosx] RobotTest0001 & RobotTest0002 are not functional in JCK-runtime-7 interactive Message-ID: <20120125160605.8CA2147193@hg.openjdk.java.net> Changeset: 28fb85f284a4 Author: serb Date: 2012-01-25 20:00 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/28fb85f284a4 7124562: [macosx] RobotTest0001 & RobotTest0002 are not functional in JCK-runtime-7 interactive Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/LWLabelPeer.java From swingler at apple.com Wed Jan 25 08:20:45 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 25 Jan 2012 08:20:45 -0800 Subject: Review request for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F1FE2F9.6040608@oracle.com> References: <4F0DA940.7040203@oracle.com> <4F0EDAEB.7090404@oracle.com> <1E9614B5-8F83-4394-8952-4E1AFB6CC5D2@oracle.com> <4F0EE5B4.4090607@oracle.com> <1D91DEA7-164A-4B9C-A511-D296220306EE@apple.com> <4F0F3B2B.7040101@oracle.com> <4F0F5B1F.5070601@oracle.com> <612A99B0-7049-4C43-B2C0-CB22FAE0C89B@apple.com> <4F156177.9050007@oracle.com> <4F15C6ED.3000702@oracle.com> <4F1EC28B.9000904@oracle.com> <75E38D54-190D-40C6-BEDD-8F69CB288AD6@apple.com> <4F1EEA92.6070806@oracle.com> <946E7122-51FB-419A-91F6-A6BAB3C8B759@apple.com> <4F1FE2F9.6040608@oracle.com> Message-ID: <9DD7AF9D-D008-45A1-BC4E-4FC5DC4FCDD1@apple.com> Perfect. :-) Mike Swingler Apple Inc. On Jan 25, 2012, at 3:09 AM, Anthony Petrov wrote: > Good point. Here's the latest version: > > http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.4/ > > -- > best regards, > Anthony > > On 1/24/2012 11:11 PM, Mike Swingler wrote: >> Looks good, but with one more minor nit: >> You should declare the NSWindow *window pointer outside of the block, so that when it is captured by the block for execution later, the block will automatically retain the pointer, and release it when the scope of the block finishes execution. >> This will also remove the necessity of the NSWIN macro, which only casts the jlong bit pattern, and is not recognizable to the block as an actual id pointer type that it needs to retain once the block gets copied off the stack. >> Regards, >> Mike Swingler >> Apple Inc. >> On Jan 24, 2012, at 9:29 AM, Anthony Petrov wrote: >>> Hi Mike, >>> >>> Thanks for your suggestions. I've just published an updated webrev at: >>> >>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.3/ >>> >>> Note that I've switched to using the dispatch_once() now since it seems to be thread safe, however, I still put this initialization code in a separate function in order to reuse it later when we implement CWrapper.NSWindow.level() (which isn't needed right now). >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/24/2012 8:44 PM, Mike Swingler wrote: >>>> This comment does not seem accurate: >>>> // Used for NSWindow -setLevel: and -level (not yet implemented) >>>> Since you are making the window levels static final ints, you should use those constants in CWrapper.m, and add a MAX_WINDOW_LEVELS in Java: >>>> static NSInteger LEVELS[sun_lwawt_macosx_CWrapper_MAX_WINDOW_LEVELS]; >>>> LEVELS[sun_lwawt_macosx_CWrapper_NSNormalWindowLevel] = NSNormalWindowLevel; >>>> LEVELS[sun_lwawt_macosx_CWrapper_NSFloatingWindowLevel] = NSFloatingWindowLevel; >>>> With this level of verbosity and links back to the real logic in Java, the level check (which you can easily raise a JNFException of type kIllegalArgumentException, if that's what you really want to do), shouldn't even be necessary. >>>> Also, instead of creating a whole separate function to init the window levels array, just use dispatch_once() with a block: >>>> It's more efficient, fewer lines of code, and not racy from multiple threads. >>>> This is looking a lot better, >>>> Mike Swingler >>>> Apple Inc. >>>> On Jan 24, 2012, at 6:39 AM, Anthony Petrov wrote: >>>>> Hi Mike, >>>>> >>>>> Thanks for proposing an alternative solution for this issue. I agree I find it more correct. Please take a look at the new fix at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.2/ >>>>> >>>>> Note that I decided to eliminate the changes from the CWrapper.NSWindow.addChildWindow() since the CWrapper is supposed to be a transparent proxy for Cocoa API w/o adding some logic to the wrapped methods. So instead I'm introducing CWrapper.NSWindow.setLevel() and using it where appropriate in the CPlatformWindow. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 1/18/2012 3:36 AM, Mike Swingler wrote: >>>>>> On Jan 17, 2012, at 11:07 AM, Anthony Petrov wrote: >>>>>>> Hi Mike, >>>>>>> >>>>>>> On 1/17/2012 8:52 PM, Mike Swingler wrote: >>>>>>>> On Jan 17, 2012, at 3:54 AM, Anthony Petrov wrote: >>>>>>>>> On 1/16/2012 8:24 PM, Mike Swingler wrote: >>>>>>>>>> I still don't understand why the list of hardcoded window levels needs to be included. Can't you just compare the window levels by their NSInteger numeric values? >>>>>>>>> There are two reasons for not using the numeric values directly, or comparing them directly: >>>>>>>>> >>>>>>>>> 1. Cocoa specification doesn't define the numeric values for the NS*WindowLevel constants. They may (theoretically) change in the future. As long as they aren't specified, we don't want to rely on their current values. >>>>>>>> Why do you have to know the values at all? Couldn't you just reset the child window level if it's different after the parent/child operation? After I re-read what you are trying to accomplish, even numeric comparison seems inappropriate. >>>>>>> I've already answered this question to Leonid on Jan 12, but I'll copy my reply here for your convenience: >>>>>>> >>>>>>> If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>>> >>>>>>> Now, when we call -addChildWindow:, we really want to update the level >>>>>>> of the child window so that both the parent and the child share the same >>>>>>> window level. The if check ensures that we don't reset the level of the >>>>>>> child window back to normal in this case. >>>>>> I think what you really want to do here is check if the parent and the child are Always-On-Top, and then reset the window level of the child only when the child is AOT and the parent is not. -[NSWindow addChildWindow:order:] forces the child to the same level as the parent already. >>>>>> I'd avoid trying to infer if there is any "higher" vs. "lower" relationship between the parent based on the window level as seen from AppKit using that table. >>>>>>>>> 2. There's a reference to the Quartz spec that defines the kCG*WindowLevel constants as a enum. The NS*WindowLevel macros are defined using these constants. However, if you take a look at the order of the constants in that enum [1] (and therefore their relative numerical order), you may notice that they don't exactly reflect the relative visual z-order between the levels as defined in the Cocoa spec [2]. E.g. kCGModalPanelWindowLevelKey is greater than kCGDockWindowLevelKey, while NSDockWindowLevel is defined being visually above the NSModalPanelWindowLevel. As such, a direct numeric comparison of window levels produces incorrect results. >>>>>>>> Have you tried setting something at the "dock" level? That level may have been true for the NextStep dock, but not the Mac. And BTW: the NSDockWindowLevel is deprecated. Don't use it. >>>>>>> Yes, this is a good tip. I've removed the NSDockWindowLevel from the array. An updated fix is available at: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.1/ >>>>>> Also, NSSubmenuWindowLevel and NSTornOffMenuWindowLevel are synonyms for each other, and end up being the same value. The documentation for NSWindow [2] says "The constant NSTornOffMenuWindowLevel is preferable to its synonym, NSSubmenuWindowLevel.", but again, I'd recommend just removing the table and higher/lower comparison. >>>>>>>>> The array of hardcoded window levels allows us to convert between window levels ordered arbitrarily and integer values ordered according to their visual z-order. This allows us to compare windows level with respect to their relative z-order as specified by Cocoa documentation. >>>>>>>> These constants are for assignment based on intention, not simple comparison of stacking level. They have behavioral meaning beyond just simple visual level ordering. Windows above the normal window level will disappear in Expos?/Mission Control, and certain levels will float in all Spaces. Other levels exclude the window from Cmd-~ keyboard window cycling, or showing up in the Dock window menu. Please, please, please test the side effects of these changes before just popping windows into different levels. >>>>>>> Could you please clarify what exact "different levels" you're talking about here? AWT currently uses only two window levels: NSNormalWindowLevel is used for regular windows, and NSFloatingWindowLevel for always-on-top windows (see AWTWindow.m). This code is already in the repository, and tests for always-on-top windows do work OK. >>>>>> The AWT will need to use more levels, and it's not clear how parent/child relationships need to affect these window levels. NSFloatingWindowLevel is used for palettes (like non-modal parented dialogs with small title bars), which do not participate in Expos?/Mission Control. NSModalPanelWindowLevel is what app-modal dialogs (like Open/Save) live at, which you might want "always on top" windows to be on top of too. Obviously popup menus should be at NSPopUpMenuWindowLevel. Another complication we encountered in Java SE 6 is full-screen exclusive windows, which still expect popups to be visible, so we had to push them above the NSScreenSaverWindowLevel as a gross hacky workaround. >>>>>> In your testing have you moved these windows between spaces? Can you separate them between spaces? Do the windows show as visible in Mission Control? When you right-click on the Dock icon, do they show in the window list? Should they? When you press Cmd-~, do they participate in the window cycle? These are the manual tests we do every time we futz with something like "window level" or "child windows" in Java SE 6, which can't easily be automated. >>>>>>> So back to the fix we're discussing, in reality the oldChildLevel in the CWrapper.addChildWindow() implementation can be either of these two levels, but not anything else. I guess we could simplify the fix and only include these two levels in the ORDERED_LEVELS{} array. I suppose Lubomir just wanted to provide a more generic and complete implementation that won't break if we ever start using any other levels in the future (or e.g. if OS temporarily puts our window on some other level). This is certainly unlikely, of course, however, I see absolutely no problems with an implementation of compareWindowLevels() that can work with all window levels officially supported by Cocoa, not just the two that we use currently. >>>>>> In the future, I agree, the existing child window level will have to be more than two values, but either it should be allowed to inherit from it's parent, or it should be reset to the original value. This is really a decision to be made based on the Java model state, and not an observed property in the AppKit model which is being changed behind your back and compared against a table. Right now the only decision hooks on if the AOT state of the parent and child, which is already present in the styleBits of the window. >>>>>> See the IS, SET, and MASK macro usage in AWTWindow.m for more info. You could make a simple accessor to report if ALWAYS_ON_TOP is set on both the parent and the child. >>>>>>>> The safest thing to do (if it works) is just to simply re-assign the window level after adding the child to the parent, but you will have to recursively descend into the child windows of the child, because setting the window level sets the level of all the children too (and changes their collection/spaces/cycle behavior). This may not be an issue if you never change a child window's parent. >>>>>>> I've clarified above why simple reassignment won't work well. >>>>>> Got it. I think I've straightened out my thinking on this too, and paged back years of hacks and corner cases I would have preferred to have forgotten... >>>>>> Cheers, >>>>>> Mike Swingler >>>>>> Apple Inc. >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>>> Regards, >>>>>>>> Mike Swingler >>>>>>>> Apple Inc. >>>>>>>>> Does this clarify the need for the array of window levels? Do you have any other concerns regarding the fix? >>>>>>>>> >>>>>>>>> [1] http://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/Reference/reference.html#//apple_ref/c/tdef/CGWindowLevelKey >>>>>>>>> >>>>>>>>> [2] http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Window_Levels >>>>>>>>> >>>>>>>>> -- >>>>>>>>> best regards, >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Mike Swingler >>>>>>>>>> Apple Inc. >>>>>>>>>> On Jan 14, 2012, at 7:40 PM, Mike Swingler wrote: >>>>>>>>>>> In the course of preparing to contribute our current window stacking algorithm, I realized that there was a pair of internal SPI calls it was making. In the next revision we ship of the JavaRuntimeSupport.framework we can provide cover methods of these SPI, however that is of little benefit to the OpenJDK port in the immediate here-and-now. >>>>>>>>>>> >>>>>>>>>>> For now, using -addChildWindow: will be sufficient, however, we can provide an alternate implementation that uses a new pair of category methods on NSWindow if -respondsToSelector: shows that they are available: >>>>>>>>>>> - (void)javaAddToOrderingGroup:(NSWindow *)ownedWindow; >>>>>>>>>>> - (void)javaRemoveFromOrderingGroup:(NSWindow *)ownedWindow; >>>>>>>>>>> >>>>>>>>>>> These functions will allow the window server to move each child window with respect to it's parent's level, but without being added to it's movement group. >>>>>>>>>>> >>>>>>>>>>> Once customers get an updated JavaNativeFoundation.framework by either Java update or OS update, the implementation will switch over dynamically at runtime. >>>>>>>>>>> >>>>>>>>>>> How does this sound for a plan? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Mike Swingler >>>>>>>>>>> Apple Inc. >>>>>>>>>>> >>>>>>>>>>> On Jan 12, 2012, at 2:13 PM, steve.x.northover at oracle.com wrote: >>>>>>>>>>> >>>>>>>>>>>> We fought this one in SWT and ended up going with the puppy route. >>>>>>>>>>>> >>>>>>>>>>>> Steve >>>>>>>>>>>> >>>>>>>>>>>> On 12/01/2012 2:57 PM, Anthony Petrov wrote: >>>>>>>>>>>>> Hi Mike, >>>>>>>>>>>>> >>>>>>>>>>>>> I recall we've discussed this issue with you back in 2010. Unfortunately, I wasn't able to implement anything like this that would work reliably back then (and I tried hard, really), that's why we ended up with -addChildWindow:. Note that JCK is very happy with this implementation, and so are we, I presume. As long as child windows receive their respective MOVE events, it seems that everything is all right. Besides, such behavior is very Mac-friendly, making Java apps behave like native apps. >>>>>>>>>>>>> >>>>>>>>>>>>> I realize that for some developers this behavior may be inconvenient. But then again, why not listen to MOVE events on the parent frame and compensate for its movement repositioning all its children? ( :) yeah, yeah, I know, sounds weird, but... as Steve says, you gotta do what you gotta do... I mean, there's a workaround at least!) >>>>>>>>>>>>> >>>>>>>>>>>>> So, if you or anyone else wish to contribute an alternative implementation for owned windows, that would be greatly appreciated. Otherwise I'm afraid we have to stick with using -addChildWindow: for now since we simply don't have a better solution. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> best regards, >>>>>>>>>>>>> Anthony >>>>>>>>>>>>> >>>>>>>>>>>>> On 1/12/2012 11:17 PM, Mike Swingler wrote: >>>>>>>>>>>>>> Also, you should not use -addChildWindow:, because you also get added to the movement group of the parent (moving the parent moves all it's children). This is *highly* undesirable behavior for Java's general use (and you can see it in Eclipse when the find window follows around the IDE window like a puppy). >>>>>>>>>>>>>> >>>>>>>>>>>>>> In the Java SE 6 AWT we manually restack every Java window in native with -orderFront: every time a Java window changes it's level to correctly handle it's children and the relationships between them. This actually works out ok, since all the changes happen at once, and when the next turn of the event loop happens, the new stacking order only has one new window moving to the background and one new window becoming key/main. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> Mike Swingler >>>>>>>>>>>>>> Apple Inc. >>>>>>>>>>>>>> On Jan 12, 2012, at 6:34 AM, Leonid Romanov wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bah, I was wrong. The value of NS*WindowLevel is really funky, it was a wrong suggestion to rely on it. Sorry for wasting your time. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 12.01.2012, at 17:52, Anthony Petrov wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The values of the NS*WindowLevel macros are not a part of the contract for Cocoa API. Therefore, we shouldn't rely on their current numerical values. The names, however, and their relative z-order are clearly specified in the documentation, and as such we may use them. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>>> Anthony >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 01/12/12 17:44, Leonid Romanov wrote: >>>>>>>>>>>>>>>>> I see? It looks like the higher window level is, the higher is the value of corresponding NS*WindowLevel macro. >>>>>>>>>>>>>>>>> Wouldn't it be better to implement compareWindowLevels() by simply subtracting one value from another? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 12.01.2012, at 17:06, Anthony Petrov wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks for taking a look at the fix. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The if check is needed for the following case. If the parent window is an always-on-top window, its level is NSFloatingWindowLevel. Suppose a child window being added to it hasn't been assigned any level explicitly, so its default level is NSNormalWindowLevel. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Now, when we call -addChildWindow:, we really want to update the level of the child window so that both the parent and the child share the same window level. The if check ensures that we don't reset the level of the child window back to normal in this case. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>>>>> Anthony >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 01/11/12 21:48, Leonid Romanov wrote: >>>>>>>>>>>>>>>>>>> Just wondering: what would happen if you simply set oldChildlevel without that "if" check? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 11.01.2012, at 19:22, Anthony Petrov wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124554 at: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.0/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Lubomir Nerad (CC'ed) should be credited for the fix itself. I'm just going to integrate it into the repository. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> A JWindow object is always a child window with either an explicit parent, or a shared invisible owner frame. Therefore, we always call NSWindow -addChildWindow: when showing a JWindow object. The root cause of the issue is that the -addChildWindow: resets the level of the child window to match that of the parent window. With this fix we restore the level back to its original value after the -addChildWindow: call, and as such preserve the always-on-top state of the child window. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I've verified the fix with a test app attached to the original issue at http://java.net/jira/browse/MACOSX_PORT-158 , and it works fine. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> best regards, >>>>>>>>>>>>>>>>>>>> Anthony From sergey.bylokhov at oracle.com Wed Jan 25 08:29:30 2012 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Wed, 25 Jan 2012 16:29:30 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124994: [macosx] GUI app is stuck in i18n testing (caused by reference cast) Message-ID: <20120125162942.1CE8947194@hg.openjdk.java.net> Changeset: 4a8cbf11c3b4 Author: serb Date: 2012-01-25 20:28 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/4a8cbf11c3b4 7124994: [macosx] GUI app is stuck in i18n testing (caused by reference cast) Reviewed-by: alexp ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java From artem.ananiev at oracle.com Wed Jan 25 08:55:59 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 25 Jan 2012 20:55:59 +0400 Subject: [jdk7u-osx] Request for approval for 7124316: [macosx] Passive and Peered IMF Client does not cope with input methods In-Reply-To: <4F203509.5080605@oracle.com> References: <4F203509.5080605@oracle.com> Message-ID: <4F20341F.20107@oracle.com> Approved. On 1/25/2012 8:59 PM, Alexander Zuev wrote: > Hello, > > this is request to approve push for the fix for > 7124316: [macosx] Passive and Peered IMF Client does not cope with input > methods > > The fix has been reviewed on macosx-port-dev mailing list by Alexander > Potochkin and Artem Ananiev. > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124316 > Webrev for the fix can be found here: > http://cr.openjdk.java.net/~kizune/7124316/webrev.01/ > > Thanks, > Alex From alexander.zuev at oracle.com Wed Jan 25 09:31:02 2012 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Wed, 25 Jan 2012 17:31:02 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124316: [macosx] Passive and Peered IMF Client does not cope with input methods Message-ID: <20120125173113.47E6147198@hg.openjdk.java.net> Changeset: ea8458a4ada3 Author: kizune Date: 2012-01-25 21:32 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/ea8458a4ada3 7124316: [macosx] Passive and Peered IMF Client does not cope with input methods Reviewed-by: art, alexp ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java From alex.menkov at sun.com Thu Jan 26 00:45:14 2012 From: alex.menkov at sun.com (alex.menkov at sun.com) Date: Thu, 26 Jan 2012 08:45:14 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124224: [macosx] Port's controls are improperly ordered Message-ID: <20120126084525.04252471C4@hg.openjdk.java.net> Changeset: fe56f3a406ce Author: amenkov Date: 2012-01-26 12:41 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/fe56f3a406ce 7124224: [macosx] Port's controls are improperly ordered Reviewed-by: astrange - src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Ports.c ! src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Ports.cpp - src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Utils.c From michael.x.mcmahon at oracle.com Thu Jan 26 00:55:21 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 26 Jan 2012 08:55:21 +0000 Subject: hg: jdk7u/jdk7u-osx/hotspot: 18 new changesets Message-ID: <20120126085556.C17F7471C5@hg.openjdk.java.net> Changeset: 9f7d76c6b0a8 Author: katleman Date: 2012-01-23 10:02 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/9f7d76c6b0a8 Added tag jdk7u4-b08 for changeset 899ddc704d9f ! .hgtags Changeset: 338d438ee229 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/338d438ee229 Added tag jdk8-b22 for changeset 24727fb37561 ! .hgtags Changeset: 4e80db53c323 Author: amurillo Date: 2012-01-14 00:52 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/4e80db53c323 7129512: new hotspot build - hs23-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 94ec88ca68e2 Author: phh Date: 2012-01-11 17:34 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/94ec88ca68e2 7115199: Add event tracing hooks and Java Flight Recorder infrastructure Summary: Added a nop tracing infrastructure, JFR makefile changes and other infrastructure used only by JFR. Reviewed-by: acorn, sspitsyn Contributed-by: markus.gronlund at oracle.com ! make/Makefile ! make/bsd/makefiles/vm.make ! make/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jni.cpp + src/share/vm/prims/jniExport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp + src/share/vm/trace/traceEventTypes.hpp + src/share/vm/trace/traceMacros.hpp + src/share/vm/trace/tracing.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4f3ce9284781 Author: phh Date: 2012-01-11 17:58 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/4f3ce9284781 Merge ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp Changeset: f1cd52d6ce02 Author: kamg Date: 2012-01-17 10:16 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/f1cd52d6ce02 Merge Changeset: d7e3846464d0 Author: zgu Date: 2012-01-17 13:08 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/d7e3846464d0 7071311: Decoder enhancement Summary: Made decoder thread-safe Reviewed-by: coleenp, kamg - src/os/bsd/vm/decoder_bsd.cpp + src/os/bsd/vm/decoder_machO.cpp + src/os/bsd/vm/decoder_machO.hpp ! src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/decoder_windows.cpp + src/os/windows/vm/decoder_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp + src/share/vm/utilities/decoder_elf.cpp + src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 6520f9861937 Author: kamg Date: 2012-01-17 21:25 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/6520f9861937 Merge Changeset: db18ca98d237 Author: zgu Date: 2012-01-18 11:45 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/db18ca98d237 7131050: fix for "7071311 Decoder enhancement" does not build on MacOS X Summary: Decoder API changes did not reflect in os_bsd Reviewed-by: kamg, dcubed ! src/os/bsd/vm/os_bsd.cpp Changeset: eaa9557116a2 Author: bdelsart Date: 2012-01-18 16:18 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/eaa9557116a2 7120448: Fix FP values for compiled frames in frame::describe Summary: fix for debug method frame::describe Reviewed-by: never, kvn ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp Changeset: 15d394228cfa Author: jrose Date: 2012-01-19 13:00 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/15d394228cfa 7111138: delete the obsolete flag -XX:+UseRicochetFrames Reviewed-by: dholmes, bdelsart, kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 898522ae3c32 Author: iveresov Date: 2012-01-19 10:56 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/898522ae3c32 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) Summary: Fix exception handler stub size, enable guarantees to check for the correct deopt and exception stub sizes in the future Reviewed-by: kvn, never, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 469e0a46f2fe Author: jrose Date: 2012-01-19 17:20 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/469e0a46f2fe Merge Changeset: 50d9b7a0072c Author: jrose Date: 2012-01-19 18:35 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/50d9b7a0072c Merge Changeset: dcc292399a39 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/dcc292399a39 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: e850d8e7ea54 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/e850d8e7ea54 Added tag hs23-b11 for changeset dcc292399a39 ! .hgtags Changeset: c5695e7d2e4f Author: amurillo Date: 2012-01-24 14:50 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/c5695e7d2e4f Merge ! .hgtags ! make/hotspot_version - src/os/bsd/vm/decoder_bsd.cpp ! src/os/windows/vm/os_windows.cpp Changeset: e3e4285d7a2f Author: michaelm Date: 2012-01-26 08:53 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/e3e4285d7a2f Merge ! .hgtags - src/os/bsd/vm/decoder_bsd.cpp From michael.x.mcmahon at oracle.com Thu Jan 26 00:56:21 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 26 Jan 2012 08:56:21 +0000 Subject: hg: jdk7u/jdk7u-osx/langtools: 7 new changesets Message-ID: <20120126085635.A44F5471C6@hg.openjdk.java.net> Changeset: 4b1503723257 Author: dmeetry Date: 2012-01-24 17:09 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/4b1503723257 7127924: langtools regression tests sometimes fail en-masse on windows Reviewed-by: jjh ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: 5842b848a41a Author: dmeetry Date: 2012-01-25 08:17 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/5842b848a41a 7123100: javac fails with java.lang.StackOverflowError Summary: Inference of under-constrained type-variables creates erroneous recursive wildcard types Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/cast/7123100/T7123100a.java + test/tools/javac/cast/7123100/T7123100a.out + test/tools/javac/cast/7123100/T7123100b.java + test/tools/javac/cast/7123100/T7123100b.out + test/tools/javac/cast/7123100/T7123100c.java + test/tools/javac/cast/7123100/T7123100c.out + test/tools/javac/cast/7123100/T7123100d.java + test/tools/javac/cast/7123100/T7123100d.out Changeset: cfdc1b1c4c86 Author: bpatel Date: 2012-01-25 10:47 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/cfdc1b1c4c86 7132631: The help-doc.html generates an invalid link to constant-values.html Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties + test/com/sun/javadoc/testHelpFile/TestHelpFile.java Changeset: bf0e932fe9b4 Author: bpatel Date: 2012-01-25 16:31 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/bf0e932fe9b4 7068595: html files in class-use dir do not get loaded correctly when Frames link is clicked Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! test/com/sun/javadoc/testUseOption/TestUseOption.java Changeset: 83d5084beaa1 Author: jjh Date: 2012-01-25 17:26 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/83d5084beaa1 7129225: javac fails to run annotation processors when star import of package of gensrc Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/7129225/Anno.java + test/tools/javac/7129225/AnnoProcessor.java + test/tools/javac/7129225/NegTest.ref + test/tools/javac/7129225/TestImportStar.java + test/tools/javac/7129225/TestImportStar.ref Changeset: 7ca6d8cb4cc7 Author: jjh Date: 2012-01-25 17:33 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/7ca6d8cb4cc7 7126832: com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager cannot be cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javah/T7126832/T7126832.java + test/tools/javah/T7126832/java.java Changeset: 1bee7edbb4b4 Author: michaelm Date: 2012-01-26 08:53 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/1bee7edbb4b4 Merge From michael.x.mcmahon at oracle.com Thu Jan 26 00:59:34 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 26 Jan 2012 08:59:34 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 9 new changesets Message-ID: <20120126090107.8E995471C7@hg.openjdk.java.net> Changeset: bbb32414449f Author: rbackman Date: 2012-01-17 16:20 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/bbb32414449f 7132386: makefile support for tracing/Java Flight Recorder framework phase I Reviewed-by: dholmes, ohair, rottenha Contributed-by: Markus Gronlund , Erik Gahlin , Nils Loodin , Rickard Backman , Staffan Larsen ! make/com/oracle/Makefile + make/com/oracle/jfr/Makefile ! make/common/Defs.gmk ! make/common/Release.gmk Changeset: 6d17a729259d Author: mullan Date: 2012-01-24 11:27 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/6d17a729259d 7131084: XMLDSig XPathFilter2Transform regression involving intersect filter Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! test/javax/xml/crypto/dsig/KeySelectors.java ! test/javax/xml/crypto/dsig/ValidationTests.java ! test/javax/xml/crypto/dsig/X509KeySelector.java + test/javax/xml/crypto/dsig/data/xmldsig-xfilter2.xml Changeset: 1e376c214a68 Author: mullan Date: 2012-01-24 11:30 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/1e376c214a68 Merge Changeset: f45ddb8b71aa Author: jrose Date: 2011-06-14 22:47 -0700 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/f45ddb8b71aa 7054590: (JSR-292) MethodHandleProxies.asInterfaceInstance() accepts private/protected nested interfaces Summary: fix non-compliant logic in MethodHandleProxies, fix invalid private classes in MethodHandlesTest Reviewed-by: twisti, never ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 98f844077547 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/98f844077547 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init Summary: Use correct access token for unreflecting MHs where setAccessible(true) Reviewed-by: never, twisti ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 6fb7e795664e Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/6fb7e795664e 7030453: JSR 292 ClassValue.get method is too slow Summary: Implement ClassValue cooperatively with Class like ThreadLocal with Thread. Reviewed-by: twisti, mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassValue.java ! test/java/lang/invoke/ClassValueTest.java Changeset: e22dda65a42c Author: ksrini Date: 2012-01-11 08:14 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/e22dda65a42c 7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2 Reviewed-by: sherman, mchung, darcy ! src/share/bin/java.c + test/tools/launcher/I18NJarTest.java ! test/tools/launcher/TestHelper.java Changeset: 988c39c7b9ac Author: michaelm Date: 2012-01-26 08:53 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/988c39c7b9ac Merge ! make/common/Defs.gmk ! make/common/Release.gmk ! src/share/bin/java.c ! test/tools/launcher/TestHelper.java Changeset: ff2d1f46256a Author: michaelm Date: 2012-01-26 08:58 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/ff2d1f46256a Merge - src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Ports.c - src/macosx/native/com/sun/media/sound/PLATFORM_API_MacOSX_Utils.c From sergey.bylokhov at oracle.com Thu Jan 26 04:17:39 2012 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Thu, 26 Jan 2012 12:17:39 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124530: What is background color of AWT component? (And foreground, for that matter) Message-ID: <20120126121750.407B3471C9@hg.openjdk.java.net> Changeset: aa30a9aebd68 Author: serb Date: 2012-01-26 16:13 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/aa30a9aebd68 7124530: What is background color of AWT component? (And foreground, for that matter) Reviewed-by: alexp ! src/macosx/classes/com/apple/laf/AquaImageFactory.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWContainerPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWPanelPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/CSystemColors.m From anthony.petrov at oracle.com Thu Jan 26 04:51:04 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 26 Jan 2012 16:51:04 +0400 Subject: [7u-osx] Request for approval for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property Message-ID: <4F214C38.8090101@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124554 Webrev: http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.4/ Technical review and approval: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002482.html -- best regards, Anthony From leonid.romanov at oracle.com Thu Jan 26 05:23:31 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 26 Jan 2012 17:23:31 +0400 Subject: Review request for MACOSX_PORT-568: KeyEvent difference between Apple 1.6 and openjdk 1.7 Message-ID: Hi, Please review a better fix for http://java.net/jira/browse/MACOSX_PORT-568 The idea behind the fix is that instead of doing character translation in Java (which doesn't work for layouts other than English), we rely on OS X to do it for us. Also note that this fix is a prerequisite for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124286 webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-568/webrev.00/ Thanks, Leonid. From artem.ananiev at oracle.com Thu Jan 26 06:01:12 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 26 Jan 2012 18:01:12 +0400 Subject: [7u-osx] Request for approval for 7124554: [macosx] JWindow does ignore setAlwaysOnTop property In-Reply-To: <4F214C38.8090101@oracle.com> References: <4F214C38.8090101@oracle.com> Message-ID: <4F215CA8.5060406@oracle.com> Approved. On 1/26/2012 4:51 PM, Anthony Petrov wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124554 > > Webrev: http://cr.openjdk.java.net/~anthony/x-6-alwaysOnTop.4/ > > Technical review and approval: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002482.html > > > -- > best regards, > Anthony > > From anthony.petrov at oracle.com Thu Jan 26 06:06:52 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 26 Jan 2012 18:06:52 +0400 Subject: Review request for 7129420: [macosx] SplashScreen.getSplashScreen() returns null In-Reply-To: <4F20180D.7080301@oracle.com> References: <4F199738.4020903@oracle.com> <4F19A90A.4040502@oracle.COM> <4F1FE9A0.3070303@oracle.com> <4F2008F9.4050106@oracle.COM> <4F2014C3.90806@oracle.com> <4F201722.2020804@oracle.COM> <4F20180D.7080301@oracle.com> Message-ID: <4F215DFC.2010908@oracle.com> Would at least one more person review the fix please? Thanks in advance! The link to the webrev for your convenience: http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.2/ Please see the quote below for more details if needed. -- best regards, Anthony On 01/25/12 18:56, Anthony Petrov wrote: > On 1/25/2012 6:52 PM, Kumar Srinivasan wrote: >> Approved. > > Thanks! > > >> Also I take it now the splash screen should work from sdk and jre >> images directory, it did not work before. >> >> Is someone going to fix those SplashScreen regression tests ? >> Just curious. > > The tests should now run fine regardless of what image is used to run them. > > -- > best regards, > Anthony > >> >> Thanks >> Kumar >> >>> Hi Kumar, >>> >>> You're right, this additional check and a comment make sense. I've >>> updated the webrev at: >>> >>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.2/ >>> >>> Please review. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/25/2012 5:51 PM, Kumar Srinivasan wrote: >>>> Hi Anthony, >>>> >>>> Generally looks good, however few more comments. >>>> >>>> Shouldn't we check for negative returns from snprintf ? >>>> >>>> The snprintf(3) contract indicates on openbsd that it will return <0 >>>> values >>>> for errors, in which case, we could be feeding an unitialized >>>> splashPath to dlopen, perhaps we should initialize it as well ? >>>> >>>> Also appreciate including your comments below in the platform >>>> source(s) if applicable, explaining why we don't check the return >>>> value for dlopen, will be good. This is in case someone decides >>>> to to be meticulous and adds a check. >>>> >>>> Thanks >>>> >>>> Kumar >>>> [PS: cc'ing Joe and David Holmes on launcher fixes, they are >>>> usually interested in launcher changes] >>>> >>>>> Hi Kumar, >>>>> >>>>> Thanks for refactoring the Java launcher code! I've just re-based >>>>> my fix to the new structure of the Mac OS X launcher sources, here >>>>> it is: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.1/ >>>>> >>>>> I've applied all the suggestions listed below. Thanks for the review! >>>>> >>>>> Regarding your question about checking for dlopen() status - yes, >>>>> we're OK if the splash screen library is unable to load. E.g. >>>>> Embedded folks often remove some unnecessary parts from a JRE image >>>>> to reduce its size. If they remove the splash screen dynamic >>>>> library we'll just silently ignore the error and continue w/o >>>>> showing the splash screen - not that it's much needed for embedded >>>>> applications anyway. >>>>> >>>>> The path lengths, however, are true error conditions, that's why I >>>>> JLI_ReportErrorMessage() them with my fix. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 1/20/2012 9:48 PM, Kumar Srinivasan wrote: >>>>>> Hi Anthony, >>>>>> >>>>>> Do you want to wait until I push the launcher changes which >>>>>> are under review ? >>>>>> >>>>>> In the launcher code we tend to use the JLI prefixed posix >>>>>> calls, ex: JLI_Snprintf. vs snprintf >>>>>> >>>>>> The error messages are defined in emessages.h, this is so >>>>>> that we can L10N these messages in the future, if such a >>>>>> requirement arises. I think you can use JRE_ERROR11 >>>>>> >>>>>> Personally I would create two more buffers to avoid errors >>>>>> and make it safer, these are a cause of some grief when >>>>>> security audits are performed for buffer overruns. >>>>>> >>>>>> char tail[PATH_MAX] >>>>>> char tmp[PATH_MAX] >>>>>> >>>>>> JLI_Snprintf(tail, PATH_MAX, "/lib/%s", SPLASHSCREEN_SO); >>>>>> >>>>>> if (JLI_Snprintf(tmp, PATH_MAX, "%s%s", path, tail)) { >>>>>> JLI_ReportErrorMessage....... >>>>>> } >>>>>> >>>>>> also I noticed that there is no check for dlopen, so is it ok for the >>>>>> splashscreen to fail silently if dlopen fails ? >>>>>> >>>>>> Thanks >>>>>> Kumar >>>>>> >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Please review a fix for >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7129420 at: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.0/ >>>>>>> >>>>>>> We remove our custom mechanism to determine the splash screen >>>>>>> dynamic library path and instead start using the GetJREPath() for >>>>>>> this purpose. I've verified this fix with an SDK (not JRE!) >>>>>>> image, and it works just fine. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>> >>>> >> From anthony.petrov at oracle.com Thu Jan 26 06:21:37 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 26 Jan 2012 18:21:37 +0400 Subject: Review request for MACOSX_PORT-568: KeyEvent difference between Apple 1.6 and openjdk 1.7 In-Reply-To: References: Message-ID: <4F216171.3040707@oracle.com> Approved. -- best regards, Anthony On 01/26/12 17:23, Leonid Romanov wrote: > Hi, > Please review a better fix for http://java.net/jira/browse/MACOSX_PORT-568 > > The idea behind the fix is that instead of doing character translation in Java (which doesn't work for layouts other than English), we rely on OS X to do it for us. Also note that this fix is a prerequisite for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124286 > > webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-568/webrev.00/ > > Thanks, > Leonid. > > > From david.katleman at oracle.com Thu Jan 26 06:32:04 2012 From: david.katleman at oracle.com (David Katleman (Oracle)) Date: Thu, 26 Jan 2012 06:32:04 -0800 Subject: 7u-osx not buildable, failing at jfr-orig.jar generation (macosx fails earlier in hotspot) Message-ID: <4F2163E4.9010702@oracle.com> I'll be filing a bug later this morning, this is a heads up, in case someone knows about these already So far both linux, solaris-i586 and windows-amd64 have failed, I would expect the others to follow Needless to say, build/promotion of 7u4 b227 based on 7u-osx will be delayed today. > com/oracle/jrockit/jfr com/oracle/jrockit/jfr/client > com/oracle/jrockit/jfr/management oracle/jrockit/jfr > oracle/jrockit/jfr/events oracle/jrockit/jfr/openmbean > oracle/jrockit/jfr/parser oracle/jrockit/jfr/settings > oracle/jrockit/jfr/tools oracle/jrockit/jfr/util > oracle/jrockit/jfr/util/log oracle/jrockit/jfr/util/os > oracle/jrockit/jfr/util/text -J-XX:-PrintVMOptions > -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m > -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m > java.util.zip.ZipException: duplicate entry: > com/oracle/jrockit/jfr/client/ > at > java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:175) > at java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:92) > at sun.tools.jar.Main.addFile(Main.java:683) > at sun.tools.jar.Main.create(Main.java:437) > at sun.tools.jar.Main.run(Main.java:160) > at sun.tools.jar.Main.main(Main.java:1022) > gnumake[3]: *** > [/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA/build/linux-amd64/../linux-amd64-fastdebug/tmp/jfr-orig.jar] > Error 1 > gnumake[3]: Leaving directory > `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA/jdk/make' > gnumake[2]: *** [jdk-build] Error 2 > gnumake[2]: Leaving directory > `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA' > gnumake[1]: *** [generic_debug_build] Error 2 > gnumake[1]: Leaving directory > `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA' > gnumake: *** [build_fastdebug_image] Error 2 > + gmkexitcode=2 > + '[' 2 -ne 0 ']' > + errorExit 'gnumake failed, return code 2' > + echo 'ERROR: gnumake failed, return code 2' > ERROR: gnumake failed, return code 2 http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-linux-amd64-product/94/console http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-linux-i586-product/88/console http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-solaris-i586-product/92/console http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-windows-amd64-product/111/console macosx-amd64 is failing much earlier, in hotspot > In file included from > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp:11, > from > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:9: > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:127: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:130: > error: 'fio_fd' does not name a type > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:150: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:152: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:152: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:185: > error: 'fio_fd' does not name a type > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:188: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:194: > error: 'filesize' does not name a type > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:196: > error: 'filesize' does not name a type > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:202: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:204: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:206: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:209: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:211: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:211: > error: 'filesize' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:213: > error: expected ';' before '(' token > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:215: > error: 'filesize' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:234: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:234: > error: 'filesize' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:236: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:236: > error: 'filesize' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:238: > error: 'filesize' does not name a type > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp: > In static member function 'static bool FileIO::is_bad_fd(int)': > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:127: > error: 'BAD_FD' was not declared in this scope > In file included from > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:9: > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp: > At global scope: > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp:19: > error: 'filesize' does not name a type > In file included from > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/trace/traceEventTypes.hpp:12, > from > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:10: > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/trace/traceComplexEvent.hpp:35: > error: 'filesize' does not name a type > In file included from > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:18: > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:56: > error: 'filesize' does not name a type > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:57: > error: 'fio_fd' does not name a type > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:62: > error: 'fio_fd' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:179: > error: 'filesize' does not name a type > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:189: > error: 'filesize' has not been declared > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp: > In constructor 'streamwriter::streamwriter()': > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: > error: class 'streamwriter' does not have any field named 'stream_pos' > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: > error: class 'streamwriter' does not have any field named 'out' > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: > error: 'BAD_FD' was not declared in this scope > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp: > In member function 'void streamwriter::reset(int)': > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:64: > error: 'stream_pos' was not declared in this scope > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:65: > error: 'out' was not declared in this scope > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp: > In static member function 'static void > JFREventWriter::write_event(TraceEventId, const void*, countertime, > countertime)': > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:227: > error: cast from '_opaque_pthread_t*' to 'u4' loses precision > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp: > At global scope: > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:274: > error: 'filesize' does not name a type > Compiling > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims/evmCompat.cpp > rm -f evmCompat.o > llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -DFASTDEBUG > -I. > -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/prims > -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims > -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm > -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm > -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/precompiled > -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/cpu/x86/vm > -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/cpu/x86/vm > -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os_cpu/bsd_x86/vm > -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os/bsd/vm > -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/os/posix/vm > -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os/posix/vm > -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.0-b11\"" > -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" > -DHOTSPOT_BUILD_USER="\"java_re\"" -DHOTSPOT_LIB_ARCH=\"amd64\" > -DJRE_RELEASE_VERSION="\"1.7.0_04-ea-fastdebug-b227\"" > -DHOTSPOT_VM_DISTRO="\"Java HotSpot(TM)\"" -DTARGET_OS_FAMILY_bsd > -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 > -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 > -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m64 > -pipe -Os -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 > -fno-omit-frame-pointer -DINCLUDE_TRACE -Werror -Wpointer-arith > -Wconversion -Wsign-compare -DDTRACE_ENABLED -D_XOPEN_SOURCE > -D_DARWIN_C_SOURCE -c -MMD -MP -MF > ../generated/dependencies/evmCompat.o.d -o evmCompat.o > /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims/evmCompat.cpp > > gnumake[7]: *** [eventwriter.o] Error 1 > gnumake[7]: *** Waiting for unfinished jobs.... > gnumake[6]: *** [the_vm] Error 2 > gnumake[5]: *** [fastdebug] Error 2 > gnumake[4]: *** [generic_build2] Error 2 > gnumake[3]: *** [fastdebug] Error 2 > gnumake[2]: *** [hotspot-build] Error 2 > gnumake[1]: *** [generic_debug_build] Error 2 > gnumake: *** [build_fastdebug_image] Error 2 > + gmkexitcode=2 > + '[' 2 -ne 0 ']' > + errorExit 'gnumake failed, return code 2' > + echo 'ERROR: gnumake failed, return code 2' > ERROR: gnumake failed, return code 2 http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-macosx-amd64-product/15/console From rickard.backman at oracle.com Thu Jan 26 06:43:17 2012 From: rickard.backman at oracle.com (=?ISO-8859-1?Q?Rickard_B=E4ckman?=) Date: Thu, 26 Jan 2012 15:43:17 +0100 Subject: 7u-osx not buildable, failing at jfr-orig.jar generation (macosx fails earlier in hotspot) In-Reply-To: <4F2163E4.9010702@oracle.com> References: <4F2163E4.9010702@oracle.com> Message-ID: <4F216685.6020701@oracle.com> This has been resolved in jdk7u-dev earlier today. See http://monaco.us.oracle.com/detail.jsf?cr=7133124 /R On 01/26/2012 03:32 PM, David Katleman (Oracle) wrote: > I'll be filing a bug later this morning, this is a heads up, in case > someone knows about these already From david.katleman at oracle.com Thu Jan 26 06:53:57 2012 From: david.katleman at oracle.com (David Katleman (Oracle)) Date: Thu, 26 Jan 2012 06:53:57 -0800 Subject: 7u-osx not buildable, failing at jfr-orig.jar generation (macosx fails earlier in hotspot) In-Reply-To: <4F2163E4.9010702@oracle.com> References: <4F2163E4.9010702@oracle.com> Message-ID: <4F216905.9070101@oracle.com> The jfr-orig.jar is a known issue 7133124 JDK7u4 builds failed for all platforms at Step 2 of build process for 1/24/2012 http://monaco.us.oracle.com/detail.jsf?cr=7133124 Once the fix is in 7u, it needs to be sync'd down to 7u-osx (I've noted that in the CR) I don't have an existing CR for the macosx hotspot failure. Dave David Katleman (Oracle) wrote: > I'll be filing a bug later this morning, this is a heads up, in case > someone knows about these already > > So far both linux, solaris-i586 and windows-amd64 have failed, I would > expect the others to follow > > Needless to say, build/promotion of 7u4 b227 based on 7u-osx will be > delayed today. > >> com/oracle/jrockit/jfr com/oracle/jrockit/jfr/client >> com/oracle/jrockit/jfr/management oracle/jrockit/jfr >> oracle/jrockit/jfr/events oracle/jrockit/jfr/openmbean >> oracle/jrockit/jfr/parser oracle/jrockit/jfr/settings >> oracle/jrockit/jfr/tools oracle/jrockit/jfr/util >> oracle/jrockit/jfr/util/log oracle/jrockit/jfr/util/os >> oracle/jrockit/jfr/util/text -J-XX:-PrintVMOptions >> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m >> -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m >> java.util.zip.ZipException: duplicate entry: >> com/oracle/jrockit/jfr/client/ >> at >> java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:175) >> at >> java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:92) >> at sun.tools.jar.Main.addFile(Main.java:683) >> at sun.tools.jar.Main.create(Main.java:437) >> at sun.tools.jar.Main.run(Main.java:160) >> at sun.tools.jar.Main.main(Main.java:1022) >> gnumake[3]: *** >> [/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA/build/linux-amd64/../linux-amd64-fastdebug/tmp/jfr-orig.jar] >> Error 1 >> gnumake[3]: Leaving directory >> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA/jdk/make' >> gnumake[2]: *** [jdk-build] Error 2 >> gnumake[2]: Leaving directory >> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA' >> gnumake[1]: *** [generic_debug_build] Error 2 >> gnumake[1]: Leaving directory >> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA' >> gnumake: *** [build_fastdebug_image] Error 2 >> + gmkexitcode=2 >> + '[' 2 -ne 0 ']' >> + errorExit 'gnumake failed, return code 2' >> + echo 'ERROR: gnumake failed, return code 2' >> ERROR: gnumake failed, return code 2 > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-linux-amd64-product/94/console > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-linux-i586-product/88/console > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-solaris-i586-product/92/console > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-windows-amd64-product/111/console > > > > macosx-amd64 is failing much earlier, in hotspot >> In file included from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp:11, >> >> from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:9: >> >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:127: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:130: >> error: 'fio_fd' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:150: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:152: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:152: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:185: >> error: 'fio_fd' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:188: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:194: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:196: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:202: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:204: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:206: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:209: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:211: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:211: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:213: >> error: expected ';' before '(' token >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:215: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:234: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:234: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:236: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:236: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:238: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp: >> In static member function 'static bool FileIO::is_bad_fd(int)': >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:127: >> error: 'BAD_FD' was not declared in this scope >> In file included from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:9: >> >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp: >> At global scope: >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp:19: >> error: 'filesize' does not name a type >> In file included from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/trace/traceEventTypes.hpp:12, >> >> from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:10: >> >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/trace/traceComplexEvent.hpp:35: >> error: 'filesize' does not name a type >> In file included from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:18: >> >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:56: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:57: >> error: 'fio_fd' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:62: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:179: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:189: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp: >> In constructor 'streamwriter::streamwriter()': >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >> error: class 'streamwriter' does not have any field named 'stream_pos' >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >> error: class 'streamwriter' does not have any field named 'out' >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >> error: 'BAD_FD' was not declared in this scope >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp: >> In member function 'void streamwriter::reset(int)': >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:64: >> error: 'stream_pos' was not declared in this scope >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:65: >> error: 'out' was not declared in this scope >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp: >> In static member function 'static void >> JFREventWriter::write_event(TraceEventId, const void*, countertime, >> countertime)': >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:227: >> error: cast from '_opaque_pthread_t*' to 'u4' loses precision >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp: >> At global scope: >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:274: >> error: 'filesize' does not name a type >> Compiling >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims/evmCompat.cpp >> >> rm -f evmCompat.o >> llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -DFASTDEBUG >> -I. >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/prims >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/precompiled >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/cpu/x86/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/cpu/x86/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os_cpu/bsd_x86/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os/bsd/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/os/posix/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os/posix/vm >> -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.0-b11\"" >> -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" >> -DHOTSPOT_BUILD_USER="\"java_re\"" -DHOTSPOT_LIB_ARCH=\"amd64\" >> -DJRE_RELEASE_VERSION="\"1.7.0_04-ea-fastdebug-b227\"" >> -DHOTSPOT_VM_DISTRO="\"Java HotSpot(TM)\"" -DTARGET_OS_FAMILY_bsd >> -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 >> -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 >> -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m64 >> -pipe -Os -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 >> -fno-omit-frame-pointer -DINCLUDE_TRACE -Werror -Wpointer-arith >> -Wconversion -Wsign-compare -DDTRACE_ENABLED -D_XOPEN_SOURCE >> -D_DARWIN_C_SOURCE -c -MMD -MP -MF >> ../generated/dependencies/evmCompat.o.d -o evmCompat.o >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims/evmCompat.cpp >> >> gnumake[7]: *** [eventwriter.o] Error 1 >> gnumake[7]: *** Waiting for unfinished jobs.... >> gnumake[6]: *** [the_vm] Error 2 >> gnumake[5]: *** [fastdebug] Error 2 >> gnumake[4]: *** [generic_build2] Error 2 >> gnumake[3]: *** [fastdebug] Error 2 >> gnumake[2]: *** [hotspot-build] Error 2 >> gnumake[1]: *** [generic_debug_build] Error 2 >> gnumake: *** [build_fastdebug_image] Error 2 >> + gmkexitcode=2 >> + '[' 2 -ne 0 ']' >> + errorExit 'gnumake failed, return code 2' >> + echo 'ERROR: gnumake failed, return code 2' >> ERROR: gnumake failed, return code 2 > > > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-macosx-amd64-product/15/console > > From michael.x.mcmahon at oracle.com Thu Jan 26 07:08:34 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 26 Jan 2012 15:08:34 +0000 Subject: 7u-osx not buildable, failing at jfr-orig.jar generation (macosx fails earlier in hotspot) In-Reply-To: <4F216905.9070101@oracle.com> References: <4F2163E4.9010702@oracle.com> <4F216905.9070101@oracle.com> Message-ID: <4F216C72.1040109@oracle.com> On 26/01/12 14:53, David Katleman (Oracle) wrote: > The jfr-orig.jar is a known issue > > 7133124 JDK7u4 builds failed for all platforms at Step 2 of build > process for 1/24/2012 > http://monaco.us.oracle.com/detail.jsf?cr=7133124 > > Once the fix is in 7u, it needs to be sync'd down to 7u-osx (I've > noted that in the CR) > > I don't have an existing CR for the macosx hotspot failure. > This has been fixed already in hotspot-rt. I'm just checking it works in my repo and will push it to jdk7u-osx as soon as that is confirmed. - Michael. > Dave > > > David Katleman (Oracle) wrote: >> I'll be filing a bug later this morning, this is a heads up, in case >> someone knows about these already >> >> So far both linux, solaris-i586 and windows-amd64 have failed, I >> would expect the others to follow >> >> Needless to say, build/promotion of 7u4 b227 based on 7u-osx will be >> delayed today. >> >>> com/oracle/jrockit/jfr com/oracle/jrockit/jfr/client >>> com/oracle/jrockit/jfr/management oracle/jrockit/jfr >>> oracle/jrockit/jfr/events oracle/jrockit/jfr/openmbean >>> oracle/jrockit/jfr/parser oracle/jrockit/jfr/settings >>> oracle/jrockit/jfr/tools oracle/jrockit/jfr/util >>> oracle/jrockit/jfr/util/log oracle/jrockit/jfr/util/os >>> oracle/jrockit/jfr/util/text -J-XX:-PrintVMOptions >>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m >>> -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m >>> java.util.zip.ZipException: duplicate entry: >>> com/oracle/jrockit/jfr/client/ >>> at >>> java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:175) >>> at >>> java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:92) >>> at sun.tools.jar.Main.addFile(Main.java:683) >>> at sun.tools.jar.Main.create(Main.java:437) >>> at sun.tools.jar.Main.run(Main.java:160) >>> at sun.tools.jar.Main.main(Main.java:1022) >>> gnumake[3]: *** >>> [/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA/build/linux-amd64/../linux-amd64-fastdebug/tmp/jfr-orig.jar] >>> Error 1 >>> gnumake[3]: Leaving directory >>> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA/jdk/make' >>> >>> gnumake[2]: *** [jdk-build] Error 2 >>> gnumake[2]: Leaving directory >>> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA' >>> gnumake[1]: *** [generic_debug_build] Error 2 >>> gnumake[1]: Leaving directory >>> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA' >>> gnumake: *** [build_fastdebug_image] Error 2 >>> + gmkexitcode=2 >>> + '[' 2 -ne 0 ']' >>> + errorExit 'gnumake failed, return code 2' >>> + echo 'ERROR: gnumake failed, return code 2' >>> ERROR: gnumake failed, return code 2 >> >> http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-linux-amd64-product/94/console >> >> http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-linux-i586-product/88/console >> >> http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-solaris-i586-product/92/console >> >> http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-windows-amd64-product/111/console >> >> >> >> macosx-amd64 is failing much earlier, in hotspot >>> In file included from >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp:11, >>> >>> from >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:9: >>> >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:127: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:130: >>> error: 'fio_fd' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:150: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:152: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:152: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:185: >>> error: 'fio_fd' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:188: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:194: >>> error: 'filesize' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:196: >>> error: 'filesize' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:202: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:204: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:206: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:209: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:211: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:211: >>> error: 'filesize' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:213: >>> error: expected ';' before '(' token >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:215: >>> error: 'filesize' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:234: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:234: >>> error: 'filesize' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:236: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:236: >>> error: 'filesize' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:238: >>> error: 'filesize' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp: >>> In static member function 'static bool FileIO::is_bad_fd(int)': >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:127: >>> error: 'BAD_FD' was not declared in this scope >>> In file included from >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:9: >>> >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp: >>> At global scope: >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp:19: >>> error: 'filesize' does not name a type >>> In file included from >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/trace/traceEventTypes.hpp:12, >>> >>> from >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:10: >>> >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/trace/traceComplexEvent.hpp:35: >>> error: 'filesize' does not name a type >>> In file included from >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:18: >>> >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:56: >>> error: 'filesize' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:57: >>> error: 'fio_fd' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:62: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:179: >>> error: 'filesize' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:189: >>> error: 'filesize' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp: >>> In constructor 'streamwriter::streamwriter()': >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >>> error: class 'streamwriter' does not have any field named 'stream_pos' >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >>> error: class 'streamwriter' does not have any field named 'out' >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >>> error: 'BAD_FD' was not declared in this scope >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp: >>> In member function 'void streamwriter::reset(int)': >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:64: >>> error: 'stream_pos' was not declared in this scope >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:65: >>> error: 'out' was not declared in this scope >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp: >>> In static member function 'static void >>> JFREventWriter::write_event(TraceEventId, const void*, countertime, >>> countertime)': >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:227: >>> error: cast from '_opaque_pthread_t*' to 'u4' loses precision >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp: >>> At global scope: >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:274: >>> error: 'filesize' does not name a type >>> Compiling >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims/evmCompat.cpp >>> >>> rm -f evmCompat.o >>> llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -DFASTDEBUG >>> -I. >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/prims >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/precompiled >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/cpu/x86/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/cpu/x86/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os_cpu/bsd_x86/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os/bsd/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/os/posix/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os/posix/vm >>> -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.0-b11\"" >>> -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" >>> -DHOTSPOT_BUILD_USER="\"java_re\"" -DHOTSPOT_LIB_ARCH=\"amd64\" >>> -DJRE_RELEASE_VERSION="\"1.7.0_04-ea-fastdebug-b227\"" >>> -DHOTSPOT_VM_DISTRO="\"Java HotSpot(TM)\"" -DTARGET_OS_FAMILY_bsd >>> -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 >>> -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 >>> -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti >>> -fno-exceptions -pthread -fcheck-new -m64 -pipe -Os >>> -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 >>> -fno-omit-frame-pointer -DINCLUDE_TRACE -Werror -Wpointer-arith >>> -Wconversion -Wsign-compare -DDTRACE_ENABLED -D_XOPEN_SOURCE >>> -D_DARWIN_C_SOURCE -c -MMD -MP -MF >>> ../generated/dependencies/evmCompat.o.d -o evmCompat.o >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims/evmCompat.cpp >>> >>> gnumake[7]: *** [eventwriter.o] Error 1 >>> gnumake[7]: *** Waiting for unfinished jobs.... >>> gnumake[6]: *** [the_vm] Error 2 >>> gnumake[5]: *** [fastdebug] Error 2 >>> gnumake[4]: *** [generic_build2] Error 2 >>> gnumake[3]: *** [fastdebug] Error 2 >>> gnumake[2]: *** [hotspot-build] Error 2 >>> gnumake[1]: *** [generic_debug_build] Error 2 >>> gnumake: *** [build_fastdebug_image] Error 2 >>> + gmkexitcode=2 >>> + '[' 2 -ne 0 ']' >>> + errorExit 'gnumake failed, return code 2' >>> + echo 'ERROR: gnumake failed, return code 2' >>> ERROR: gnumake failed, return code 2 >> >> >> >> http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-macosx-amd64-product/15/console >> >> > From anthony.petrov at oracle.com Thu Jan 26 07:41:48 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 26 Jan 2012 19:41:48 +0400 Subject: Review request for 7132809: [macosx] MAXIMIZED_BOTH set before setVisible(true) hides Frame Message-ID: <4F21743C.8020709@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7132809 at: http://cr.openjdk.java.net/~anthony/x-11-MaximizedBoth-7132809.0/ We shouldn't apply the extended state when a window is hidden. With this fix the CPlatformWindow.setVisible() re-applies the state when the window gets shown. -- best regards, Anthony From artem.ananiev at oracle.com Thu Jan 26 07:50:44 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 26 Jan 2012 19:50:44 +0400 Subject: Review request for 7129420: [macosx] SplashScreen.getSplashScreen() returns null In-Reply-To: <4F2014C3.90806@oracle.com> References: <4F199738.4020903@oracle.com> <4F19A90A.4040502@oracle.COM> <4F1FE9A0.3070303@oracle.com> <4F2008F9.4050106@oracle.COM> <4F2014C3.90806@oracle.com> Message-ID: <4F217654.7050008@oracle.com> On 1/25/2012 6:42 PM, Anthony Petrov wrote: > Hi Kumar, > > You're right, this additional check and a comment make sense. I've > updated the webrev at: > > http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.2/ > > Please review. Looks fine for me as well. Thanks, Artem > -- > best regards, > Anthony > > On 1/25/2012 5:51 PM, Kumar Srinivasan wrote: >> Hi Anthony, >> >> Generally looks good, however few more comments. >> >> Shouldn't we check for negative returns from snprintf ? >> >> The snprintf(3) contract indicates on openbsd that it will return <0 >> values >> for errors, in which case, we could be feeding an unitialized >> splashPath to dlopen, perhaps we should initialize it as well ? >> >> Also appreciate including your comments below in the platform >> source(s) if applicable, explaining why we don't check the return >> value for dlopen, will be good. This is in case someone decides >> to to be meticulous and adds a check. >> >> Thanks >> >> Kumar >> [PS: cc'ing Joe and David Holmes on launcher fixes, they are >> usually interested in launcher changes] >> >>> Hi Kumar, >>> >>> Thanks for refactoring the Java launcher code! I've just re-based my >>> fix to the new structure of the Mac OS X launcher sources, here it is: >>> >>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.1/ >>> >>> I've applied all the suggestions listed below. Thanks for the review! >>> >>> Regarding your question about checking for dlopen() status - yes, >>> we're OK if the splash screen library is unable to load. E.g. >>> Embedded folks often remove some unnecessary parts from a JRE image >>> to reduce its size. If they remove the splash screen dynamic library >>> we'll just silently ignore the error and continue w/o showing the >>> splash screen - not that it's much needed for embedded applications >>> anyway. >>> >>> The path lengths, however, are true error conditions, that's why I >>> JLI_ReportErrorMessage() them with my fix. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/20/2012 9:48 PM, Kumar Srinivasan wrote: >>>> Hi Anthony, >>>> >>>> Do you want to wait until I push the launcher changes which >>>> are under review ? >>>> >>>> In the launcher code we tend to use the JLI prefixed posix >>>> calls, ex: JLI_Snprintf. vs snprintf >>>> >>>> The error messages are defined in emessages.h, this is so >>>> that we can L10N these messages in the future, if such a >>>> requirement arises. I think you can use JRE_ERROR11 >>>> >>>> Personally I would create two more buffers to avoid errors >>>> and make it safer, these are a cause of some grief when >>>> security audits are performed for buffer overruns. >>>> >>>> char tail[PATH_MAX] >>>> char tmp[PATH_MAX] >>>> >>>> JLI_Snprintf(tail, PATH_MAX, "/lib/%s", SPLASHSCREEN_SO); >>>> >>>> if (JLI_Snprintf(tmp, PATH_MAX, "%s%s", path, tail)) { >>>> JLI_ReportErrorMessage....... >>>> } >>>> >>>> also I noticed that there is no check for dlopen, so is it ok for the >>>> splashscreen to fail silently if dlopen fails ? >>>> >>>> Thanks >>>> Kumar >>>> >>>> >>>>> Hello, >>>>> >>>>> Please review a fix for >>>>> http://bugs.sun.com/view_bug.do?bug_id=7129420 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.0/ >>>>> >>>>> We remove our custom mechanism to determine the splash screen >>>>> dynamic library path and instead start using the GetJREPath() for >>>>> this purpose. I've verified this fix with an SDK (not JRE!) image, >>>>> and it works just fine. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>> >> From anthony.petrov at oracle.com Thu Jan 26 07:51:55 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 26 Jan 2012 19:51:55 +0400 Subject: [7u-osx] Request for approval for 7129420: [macosx] SplashScreen.getSplashScreen() returns null Message-ID: <4F21769B.1080605@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129420 http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.2/ Technical review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002456.html -- best regards, Anthony From artem.ananiev at oracle.com Thu Jan 26 08:04:12 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 26 Jan 2012 20:04:12 +0400 Subject: [7u-osx] Request for approval for 7129420: [macosx] SplashScreen.getSplashScreen() returns null In-Reply-To: <4F21769B.1080605@oracle.com> References: <4F21769B.1080605@oracle.com> Message-ID: <4F21797C.6090204@oracle.com> Approved. On 1/26/2012 7:51 PM, Anthony Petrov wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129420 > > http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.2/ > > Technical review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002456.html > > > -- > best regards, > Anthony > From michael.x.mcmahon at oracle.com Thu Jan 26 08:15:08 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 26 Jan 2012 16:15:08 +0000 Subject: hg: jdk7u/jdk7u-osx/hotspot: 15 new changesets Message-ID: <20120126161537.841D7471D3@hg.openjdk.java.net> Changeset: af739d5ab23c Author: bpittore Date: 2012-01-21 23:02 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/af739d5ab23c 6972759: Step over not working after thrown exception and Pop Summary: reset jvmtithreadstate exception state after frame pop and forceearlyreturn processed Reviewed-by: minqi, dholmes, dlong Contributed-by: bill.pittore at oracle.com ! src/share/vm/prims/jvmtiThreadState.cpp ! src/share/vm/prims/jvmtiThreadState.hpp Changeset: 583b428aa858 Author: coleenp Date: 2012-01-23 17:45 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/583b428aa858 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: d6660fedbab5 Author: phh Date: 2012-01-24 14:07 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/d6660fedbab5 7126732: MAC: Require Mac OS X builds/tests for JPRT integrate jobs for HotSpot Summary: Modify jprt.properties to run OSX builds and tests. Reviewed-by: dcubed, kamg, ohair, dholmes Contributed-by: james.melvin at oracle.com ! make/jprt.properties Changeset: bf864f701a4a Author: dsamersoff Date: 2012-01-25 02:29 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/bf864f701a4a 7066129: GarbageCollectorMXBean#getLastGcInfo leaks native memory Summary: Make GCStatInfo a resource object Reviewed-by: phh, coleenp ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp Changeset: df88f58f3b61 Author: dsamersoff Date: 2012-01-24 20:15 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/df88f58f3b61 Merge Changeset: e8a4934564b2 Author: phh Date: 2012-01-24 19:33 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/e8a4934564b2 7125793: MAC: test_gamma should always work Summary: Fix gamma launcher on Mac OS X and reconcile test_gamma script on Unix platforms Reviewed-by: dcubed, ohair, jcoomes, dholmes, ksrini Contributed-by: james.melvin at oracle.com ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/buildtree.make ! make/solaris/makefiles/buildtree.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/posix/launcher/java_md.c Changeset: 78dadb7b16ab Author: phh Date: 2012-01-25 01:16 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/78dadb7b16ab Merge Changeset: 5f3fcd591768 Author: amurillo Date: 2012-01-20 17:07 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/5f3fcd591768 7131979: new hotspot build - hs23-b12 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d708a8cdd022 Author: kamg Date: 2012-01-25 10:08 -0500 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/d708a8cdd022 Merge Changeset: 520830f632e7 Author: fparain Date: 2012-01-25 10:32 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/520830f632e7 7131346: Parsing of boolean arguments to diagnostic commands is broken Reviewed-by: dholmes, dcubed ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 24ec1a6d6ef3 Author: fparain Date: 2012-01-25 16:33 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/24ec1a6d6ef3 Merge Changeset: a42c07c38c47 Author: dsamersoff Date: 2012-01-25 21:10 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/a42c07c38c47 7132515: Add dcmd to manage UnlockingCommercialFeature flag Summary: Added dcmd to unlock or check status of UnlockingCommercialFeature flag Reviewed-by: fparain, rottenha ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp + src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp Changeset: 6d00795f99a1 Author: dsamersoff Date: 2012-01-25 15:03 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/6d00795f99a1 Merge Changeset: 6db63e782d3d Author: dsamersoff Date: 2012-01-25 18:58 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/6db63e782d3d Merge Changeset: 150e8a9b085e Author: michaelm Date: 2012-01-26 15:37 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/150e8a9b085e Merge ! make/hotspot_version From michael.x.mcmahon at oracle.com Thu Jan 26 08:15:53 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 26 Jan 2012 16:15:53 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 2 new changesets Message-ID: <20120126161615.06E5A471D4@hg.openjdk.java.net> Changeset: 0c2dd6584b7c Author: rbackman Date: 2012-01-26 09:51 +0100 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/0c2dd6584b7c 7133124: Remove redundant packages from JAR command line Reviewed-by: acorn, alanb, dholmes, rottenha ! make/common/Release.gmk Changeset: 3e0b39f1caa6 Author: michaelm Date: 2012-01-26 15:44 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/3e0b39f1caa6 Merge ! make/common/Release.gmk From david.katleman at oracle.com Thu Jan 26 08:52:01 2012 From: david.katleman at oracle.com (David Katleman) Date: Thu, 26 Jan 2012 08:52:01 -0800 Subject: 7u-osx not buildable, failing at jfr-orig.jar generation (macosx fails earlier in hotspot) Message-ID: <4F2184B1.8030509@oracle.com> The jfr-orig.jar is a known issue 7133124 JDK7u4 builds failed for all platforms at Step 2 of build process for 1/24/2012 http://monaco.us.oracle.com/detail.jsf?cr=7133124 Once the fix is in 7u, it needs to be sync'd down to 7u-osx (I've noted that in the CR) I don't have an existing CR for the macosx hotspot failure. Dave David Katleman (Oracle) wrote: > I'll be filing a bug later this morning, this is a heads up, in case > someone knows about these already > > So far both linux, solaris-i586 and windows-amd64 have failed, I would > expect the others to follow > > Needless to say, build/promotion of 7u4 b227 based on 7u-osx will be > delayed today. > >> com/oracle/jrockit/jfr com/oracle/jrockit/jfr/client >> com/oracle/jrockit/jfr/management oracle/jrockit/jfr >> oracle/jrockit/jfr/events oracle/jrockit/jfr/openmbean >> oracle/jrockit/jfr/parser oracle/jrockit/jfr/settings >> oracle/jrockit/jfr/tools oracle/jrockit/jfr/util >> oracle/jrockit/jfr/util/log oracle/jrockit/jfr/util/os >> oracle/jrockit/jfr/util/text -J-XX:-PrintVMOptions >> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m >> -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m >> java.util.zip.ZipException: duplicate entry: >> com/oracle/jrockit/jfr/client/ >> at >> java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:175) >> at >> java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:92) >> at sun.tools.jar.Main.addFile(Main.java:683) >> at sun.tools.jar.Main.create(Main.java:437) >> at sun.tools.jar.Main.run(Main.java:160) >> at sun.tools.jar.Main.main(Main.java:1022) >> gnumake[3]: *** >> [/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA/build/linux-amd64/../linux-amd64-fastdebug/tmp/jfr-orig.jar] >> Error 1 >> gnumake[3]: Leaving directory >> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA/jdk/make' >> gnumake[2]: *** [jdk-build] Error 2 >> gnumake[2]: Leaving directory >> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA' >> gnumake[1]: *** [generic_debug_build] Error 2 >> gnumake[1]: Leaving directory >> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA' >> gnumake: *** [build_fastdebug_image] Error 2 >> + gmkexitcode=2 >> + '[' 2 -ne 0 ']' >> + errorExit 'gnumake failed, return code 2' >> + echo 'ERROR: gnumake failed, return code 2' >> ERROR: gnumake failed, return code 2 > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-linux-amd64-product/94/console > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-linux-i586-product/88/console > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-solaris-i586-product/92/console > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-windows-amd64-product/111/console > > > > macosx-amd64 is failing much earlier, in hotspot >> In file included from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp:11, >> >> from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:9: >> >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:127: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:130: >> error: 'fio_fd' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:150: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:152: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:152: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:185: >> error: 'fio_fd' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:188: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:194: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:196: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:202: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:204: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:206: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:209: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:211: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:211: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:213: >> error: expected ';' before '(' token >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:215: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:234: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:234: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:236: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:236: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:238: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp: >> In static member function 'static bool FileIO::is_bad_fd(int)': >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:127: >> error: 'BAD_FD' was not declared in this scope >> In file included from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:9: >> >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp: >> At global scope: >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp:19: >> error: 'filesize' does not name a type >> In file included from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/trace/traceEventTypes.hpp:12, >> >> from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:10: >> >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/trace/traceComplexEvent.hpp:35: >> error: 'filesize' does not name a type >> In file included from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:18: >> >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:56: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:57: >> error: 'fio_fd' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:62: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:179: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:189: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp: >> In constructor 'streamwriter::streamwriter()': >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >> error: class 'streamwriter' does not have any field named 'stream_pos' >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >> error: class 'streamwriter' does not have any field named 'out' >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >> error: 'BAD_FD' was not declared in this scope >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp: >> In member function 'void streamwriter::reset(int)': >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:64: >> error: 'stream_pos' was not declared in this scope >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:65: >> error: 'out' was not declared in this scope >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp: >> In static member function 'static void >> JFREventWriter::write_event(TraceEventId, const void*, countertime, >> countertime)': >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:227: >> error: cast from '_opaque_pthread_t*' to 'u4' loses precision >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp: >> At global scope: >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:274: >> error: 'filesize' does not name a type >> Compiling >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims/evmCompat.cpp >> >> rm -f evmCompat.o >> llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -DFASTDEBUG >> -I. >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/prims >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/precompiled >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/cpu/x86/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/cpu/x86/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os_cpu/bsd_x86/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os/bsd/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/os/posix/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os/posix/vm >> -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.0-b11\"" >> -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" >> -DHOTSPOT_BUILD_USER="\"java_re\"" -DHOTSPOT_LIB_ARCH=\"amd64\" >> -DJRE_RELEASE_VERSION="\"1.7.0_04-ea-fastdebug-b227\"" >> -DHOTSPOT_VM_DISTRO="\"Java HotSpot(TM)\"" -DTARGET_OS_FAMILY_bsd >> -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 >> -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 >> -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m64 >> -pipe -Os -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 >> -fno-omit-frame-pointer -DINCLUDE_TRACE -Werror -Wpointer-arith >> -Wconversion -Wsign-compare -DDTRACE_ENABLED -D_XOPEN_SOURCE >> -D_DARWIN_C_SOURCE -c -MMD -MP -MF >> ../generated/dependencies/evmCompat.o.d -o evmCompat.o >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims/evmCompat.cpp >> >> gnumake[7]: *** [eventwriter.o] Error 1 >> gnumake[7]: *** Waiting for unfinished jobs.... >> gnumake[6]: *** [the_vm] Error 2 >> gnumake[5]: *** [fastdebug] Error 2 >> gnumake[4]: *** [generic_build2] Error 2 >> gnumake[3]: *** [fastdebug] Error 2 >> gnumake[2]: *** [hotspot-build] Error 2 >> gnumake[1]: *** [generic_debug_build] Error 2 >> gnumake: *** [build_fastdebug_image] Error 2 >> + gmkexitcode=2 >> + '[' 2 -ne 0 ']' >> + errorExit 'gnumake failed, return code 2' >> + echo 'ERROR: gnumake failed, return code 2' >> ERROR: gnumake failed, return code 2 > > > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-macosx-amd64-product/15/console > > From Alexander.Potochkin at oracle.com Thu Jan 26 09:02:35 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 26 Jan 2012 21:02:35 +0400 Subject: Review request for 7124393: [macosx] JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click In-Reply-To: <4F1E9F3F.4030705@oracle.com> References: <4F1D99F6.9060709@oracle.com> <4F1E9F3F.4030705@oracle.com> Message-ID: <4F21872B.5000409@oracle.com> Hello Anthony > Hi Alex, > > I'm OK with realSync() calls, but unsure about the stopCellEditing() > call. Indeed, using a Swing method should produce correct results. > However, I think that this regression test is supposed to emulate > user's actions, not Swing calls, isn't it? If so, we should either > find a cross-platform events that finish editing and use Robot to > emulate them, or use the "os.name" property and synthesize different > user actions on different platforms. > > Please correct me if my assumption is wrong. Your assumption is correct it is indeed better to always emulate the user's action. However in this case it is not as simple because Aqua LaF doesn't provide a key shortcut which stops the cell editing see BasicLookAndFeel line 1545, F2 is bound to "startEditing" action (it calls stopEditing() method) there is no such an action bound to any key in AquaKeyBinding.getTableInputMap() So calling stopCellEditing inside the test is a good tradeoff because it is simple, makes the test compatible with every LaF and doesn't interfere with what the *bug6711682 *actually tests Thanks alexp > > -- > best regards, > Anthony > > On 1/23/2012 9:33 PM, Alexander Potochkin wrote: >> Hello >> >> Please review the following fix: >> http://cr.openjdk.java.net/~alexp/7124393/webrev.00/ >> >> the bug's description is here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124393 >> >> The bug is in the test, F2 doesn't stop editing on MacOS, >> we should not use the keyboard to commit the data >> >> the test is also updated >> to access the Swing methods on the Event Dispatching Thread only >> >> Thanks >> alexp From Alexander.Potochkin at oracle.com Thu Jan 26 09:23:43 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Thu, 26 Jan 2012 21:23:43 +0400 Subject: Review request for MACOSX_PORT-568: KeyEvent difference between Apple 1.6 and openjdk 1.7 In-Reply-To: References: Message-ID: <4F218C1F.9060403@oracle.com> Hello Leonid > Hi, > Please review a better fix for http://java.net/jira/browse/MACOSX_PORT-568 > > The idea behind the fix is that instead of doing character translation in Java (which doesn't work for layouts other than English), we rely on OS X to do it for us. Also note that this fix is a prerequisite for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124286 > > webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-568/webrev.00/ The fix looks fine and I like how laconic it is! Could you reopen the http://java.net/jira/browse/MACOSX_PORT-568 add a comment about non English locales and mark it as resolved again when you commit the fix? Thanks alexp > > Thanks, > Leonid. > > > From sergey.bylokhov at oracle.com Thu Jan 26 09:29:59 2012 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Thu, 26 Jan 2012 17:29:59 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124524: OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer Message-ID: <20120126173011.75A7B471D8@hg.openjdk.java.net> Changeset: 36f7b80cdb5a Author: serb Date: 2012-01-26 21:28 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/36f7b80cdb5a 7124524: OutOfMemory exception after (or even before) some 2500 creations of LWWindowPeer Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/native/sun/awt/AWTWindow.m From sergey.bylokhov at oracle.com Thu Jan 26 09:45:58 2012 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Thu, 26 Jan 2012 17:45:58 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7130587: [macosx] Scrolling and painting issues with late invocation of setText Message-ID: <20120126174608.D1B3C471D9@hg.openjdk.java.net> Changeset: 3fe2884e7f05 Author: serb Date: 2012-01-26 21:44 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/3fe2884e7f05 7130587: [macosx] Scrolling and painting issues with late invocation of setText Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java From sergey.bylokhov at oracle.com Thu Jan 26 09:48:44 2012 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Thu, 26 Jan 2012 17:48:44 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7131752: [macosx] Multiselect List doesn't display scrollbar after consecutive additions Message-ID: <20120126174855.905FA471DA@hg.openjdk.java.net> Changeset: 2e4258236920 Author: serb Date: 2012-01-26 21:47 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/2e4258236920 7131752: [macosx] Multiselect List doesn't display scrollbar after consecutive additions Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/LWListPeer.java From swingler at apple.com Thu Jan 26 10:09:35 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 26 Jan 2012 10:09:35 -0800 Subject: Review request for 7129420: [macosx] SplashScreen.getSplashScreen() returns null In-Reply-To: <4F215DFC.2010908@oracle.com> References: <4F199738.4020903@oracle.com> <4F19A90A.4040502@oracle.COM> <4F1FE9A0.3070303@oracle.com> <4F2008F9.4050106@oracle.COM> <4F2014C3.90806@oracle.com> <4F201722.2020804@oracle.COM> <4F20180D.7080301@oracle.com> <4F215DFC.2010908@oracle.com> Message-ID: <68CA8E50-9250-48C8-8BA2-15F796CB320C@apple.com> Looks lovely. Regards, Mike Swingler Apple Inc. On Jan 26, 2012, at 6:06 AM, Anthony Petrov wrote: > Would at least one more person review the fix please? Thanks in advance! > > The link to the webrev for your convenience: > http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.2/ > > Please see the quote below for more details if needed. > > -- > best regards, > Anthony > > On 01/25/12 18:56, Anthony Petrov wrote: >> On 1/25/2012 6:52 PM, Kumar Srinivasan wrote: >>> Approved. >> >> Thanks! >> >> >>> Also I take it now the splash screen should work from sdk and jre >>> images directory, it did not work before. >>> >>> Is someone going to fix those SplashScreen regression tests ? >>> Just curious. >> >> The tests should now run fine regardless of what image is used to run them. >> >> -- >> best regards, >> Anthony >> >>> >>> Thanks >>> Kumar >>> >>>> Hi Kumar, >>>> >>>> You're right, this additional check and a comment make sense. I've >>>> updated the webrev at: >>>> >>>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.2/ >>>> >>>> Please review. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 1/25/2012 5:51 PM, Kumar Srinivasan wrote: >>>>> Hi Anthony, >>>>> >>>>> Generally looks good, however few more comments. >>>>> >>>>> Shouldn't we check for negative returns from snprintf ? >>>>> >>>>> The snprintf(3) contract indicates on openbsd that it will return <0 >>>>> values >>>>> for errors, in which case, we could be feeding an unitialized >>>>> splashPath to dlopen, perhaps we should initialize it as well ? >>>>> >>>>> Also appreciate including your comments below in the platform >>>>> source(s) if applicable, explaining why we don't check the return >>>>> value for dlopen, will be good. This is in case someone decides >>>>> to to be meticulous and adds a check. >>>>> >>>>> Thanks >>>>> >>>>> Kumar >>>>> [PS: cc'ing Joe and David Holmes on launcher fixes, they are >>>>> usually interested in launcher changes] >>>>> >>>>>> Hi Kumar, >>>>>> >>>>>> Thanks for refactoring the Java launcher code! I've just re-based >>>>>> my fix to the new structure of the Mac OS X launcher sources, here >>>>>> it is: >>>>>> >>>>>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.1/ >>>>>> >>>>>> I've applied all the suggestions listed below. Thanks for the review! >>>>>> >>>>>> Regarding your question about checking for dlopen() status - yes, >>>>>> we're OK if the splash screen library is unable to load. E.g. >>>>>> Embedded folks often remove some unnecessary parts from a JRE image >>>>>> to reduce its size. If they remove the splash screen dynamic >>>>>> library we'll just silently ignore the error and continue w/o >>>>>> showing the splash screen - not that it's much needed for embedded >>>>>> applications anyway. >>>>>> >>>>>> The path lengths, however, are true error conditions, that's why I >>>>>> JLI_ReportErrorMessage() them with my fix. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 1/20/2012 9:48 PM, Kumar Srinivasan wrote: >>>>>>> Hi Anthony, >>>>>>> >>>>>>> Do you want to wait until I push the launcher changes which >>>>>>> are under review ? >>>>>>> >>>>>>> In the launcher code we tend to use the JLI prefixed posix >>>>>>> calls, ex: JLI_Snprintf. vs snprintf >>>>>>> >>>>>>> The error messages are defined in emessages.h, this is so >>>>>>> that we can L10N these messages in the future, if such a >>>>>>> requirement arises. I think you can use JRE_ERROR11 >>>>>>> >>>>>>> Personally I would create two more buffers to avoid errors >>>>>>> and make it safer, these are a cause of some grief when >>>>>>> security audits are performed for buffer overruns. >>>>>>> >>>>>>> char tail[PATH_MAX] >>>>>>> char tmp[PATH_MAX] >>>>>>> >>>>>>> JLI_Snprintf(tail, PATH_MAX, "/lib/%s", SPLASHSCREEN_SO); >>>>>>> >>>>>>> if (JLI_Snprintf(tmp, PATH_MAX, "%s%s", path, tail)) { >>>>>>> JLI_ReportErrorMessage....... >>>>>>> } >>>>>>> >>>>>>> also I noticed that there is no check for dlopen, so is it ok for the >>>>>>> splashscreen to fail silently if dlopen fails ? >>>>>>> >>>>>>> Thanks >>>>>>> Kumar >>>>>>> >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review a fix for >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7129420 at: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.0/ >>>>>>>> >>>>>>>> We remove our custom mechanism to determine the splash screen >>>>>>>> dynamic library path and instead start using the GetJREPath() for >>>>>>>> this purpose. I've verified this fix with an SDK (not JRE!) >>>>>>>> image, and it works just fine. >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>> >>>>> >>> From david.katleman at sun.com Thu Jan 26 18:26:49 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 27 Jan 2012 02:26:49 +0000 Subject: hg: jdk7u/jdk7u-osx: Added tag jdk7u4-b227 for changeset 27dc5251e681 Message-ID: <20120127022649.2B68E471EC@hg.openjdk.java.net> Changeset: 74f31fdf52d6 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/rev/74f31fdf52d6 Added tag jdk7u4-b227 for changeset 27dc5251e681 ! .hgtags From david.katleman at sun.com Thu Jan 26 18:27:04 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 27 Jan 2012 02:27:04 +0000 Subject: hg: jdk7u/jdk7u-osx/corba: Added tag jdk7u4-b227 for changeset 0e8770ade63c Message-ID: <20120127022705.811C7471ED@hg.openjdk.java.net> Changeset: ddc6a8c79faa Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/corba/rev/ddc6a8c79faa Added tag jdk7u4-b227 for changeset 0e8770ade63c ! .hgtags From david.katleman at sun.com Thu Jan 26 18:28:38 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 27 Jan 2012 02:28:38 +0000 Subject: hg: jdk7u/jdk7u-osx/hotspot: Added tag jdk7u4-b227 for changeset 150e8a9b085e Message-ID: <20120127022840.D6AFD471EE@hg.openjdk.java.net> Changeset: 615c22773d4c Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/hotspot/rev/615c22773d4c Added tag jdk7u4-b227 for changeset 150e8a9b085e ! .hgtags From david.katleman at sun.com Thu Jan 26 18:29:56 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 27 Jan 2012 02:29:56 +0000 Subject: hg: jdk7u/jdk7u-osx/jaxp: Added tag jdk7u4-b227 for changeset d3b2c77daf2c Message-ID: <20120127022958.80A32471EF@hg.openjdk.java.net> Changeset: 3d9734845366 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxp/rev/3d9734845366 Added tag jdk7u4-b227 for changeset d3b2c77daf2c ! .hgtags From david.katleman at sun.com Thu Jan 26 18:30:04 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 27 Jan 2012 02:30:04 +0000 Subject: hg: jdk7u/jdk7u-osx/jaxws: Added tag jdk7u4-b227 for changeset 2f37da2e5657 Message-ID: <20120127023004.C7881471F2@hg.openjdk.java.net> Changeset: 163c1e712d5e Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jaxws/rev/163c1e712d5e Added tag jdk7u4-b227 for changeset 2f37da2e5657 ! .hgtags From david.katleman at sun.com Thu Jan 26 18:30:16 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 27 Jan 2012 02:30:16 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: Added tag jdk7u4-b227 for changeset 2e4258236920 Message-ID: <20120127023027.24B8C471F3@hg.openjdk.java.net> Changeset: c0036a561b5a Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/c0036a561b5a Added tag jdk7u4-b227 for changeset 2e4258236920 ! .hgtags From david.katleman at sun.com Thu Jan 26 18:31:39 2012 From: david.katleman at sun.com (david.katleman at sun.com) Date: Fri, 27 Jan 2012 02:31:39 +0000 Subject: hg: jdk7u/jdk7u-osx/langtools: Added tag jdk7u4-b227 for changeset 1bee7edbb4b4 Message-ID: <20120127023141.65C97471F4@hg.openjdk.java.net> Changeset: 3fa78bea37a3 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/langtools/rev/3fa78bea37a3 Added tag jdk7u4-b227 for changeset 1bee7edbb4b4 ! .hgtags From david.holmes at oracle.com Thu Jan 26 21:18:17 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Jan 2012 15:18:17 +1000 Subject: Review request for 7129420: [macosx] SplashScreen.getSplashScreen() returns null In-Reply-To: <4F2008F9.4050106@oracle.COM> References: <4F199738.4020903@oracle.com> <4F19A90A.4040502@oracle.COM> <4F1FE9A0.3070303@oracle.com> <4F2008F9.4050106@oracle.COM> Message-ID: <4F223399.4050404@oracle.com> Thanks Kumar but I have nothing to comment on re splashscreen changes. David On 25/01/2012 11:51 PM, Kumar Srinivasan wrote: > Hi Anthony, > > Generally looks good, however few more comments. > > Shouldn't we check for negative returns from snprintf ? > > The snprintf(3) contract indicates on openbsd that it will return <0 values > for errors, in which case, we could be feeding an unitialized > splashPath to dlopen, perhaps we should initialize it as well ? > > Also appreciate including your comments below in the platform > source(s) if applicable, explaining why we don't check the return > value for dlopen, will be good. This is in case someone decides > to to be meticulous and adds a check. > > Thanks > > Kumar > [PS: cc'ing Joe and David Holmes on launcher fixes, they are > usually interested in launcher changes] > >> Hi Kumar, >> >> Thanks for refactoring the Java launcher code! I've just re-based my >> fix to the new structure of the Mac OS X launcher sources, here it is: >> >> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.1/ >> >> I've applied all the suggestions listed below. Thanks for the review! >> >> Regarding your question about checking for dlopen() status - yes, >> we're OK if the splash screen library is unable to load. E.g. Embedded >> folks often remove some unnecessary parts from a JRE image to reduce >> its size. If they remove the splash screen dynamic library we'll just >> silently ignore the error and continue w/o showing the splash screen - >> not that it's much needed for embedded applications anyway. >> >> The path lengths, however, are true error conditions, that's why I >> JLI_ReportErrorMessage() them with my fix. >> >> -- >> best regards, >> Anthony >> >> On 1/20/2012 9:48 PM, Kumar Srinivasan wrote: >>> Hi Anthony, >>> >>> Do you want to wait until I push the launcher changes which >>> are under review ? >>> >>> In the launcher code we tend to use the JLI prefixed posix >>> calls, ex: JLI_Snprintf. vs snprintf >>> >>> The error messages are defined in emessages.h, this is so >>> that we can L10N these messages in the future, if such a >>> requirement arises. I think you can use JRE_ERROR11 >>> >>> Personally I would create two more buffers to avoid errors >>> and make it safer, these are a cause of some grief when >>> security audits are performed for buffer overruns. >>> >>> char tail[PATH_MAX] >>> char tmp[PATH_MAX] >>> >>> JLI_Snprintf(tail, PATH_MAX, "/lib/%s", SPLASHSCREEN_SO); >>> >>> if (JLI_Snprintf(tmp, PATH_MAX, "%s%s", path, tail)) { >>> JLI_ReportErrorMessage....... >>> } >>> >>> also I noticed that there is no check for dlopen, so is it ok for the >>> splashscreen to fail silently if dlopen fails ? >>> >>> Thanks >>> Kumar >>> >>> >>>> Hello, >>>> >>>> Please review a fix for >>>> http://bugs.sun.com/view_bug.do?bug_id=7129420 at: >>>> >>>> http://cr.openjdk.java.net/~anthony/x-8-getSplashScreenNull.0/ >>>> >>>> We remove our custom mechanism to determine the splash screen >>>> dynamic library path and instead start using the GetJREPath() for >>>> this purpose. I've verified this fix with an SDK (not JRE!) image, >>>> and it works just fine. >>>> >>>> -- >>>> best regards, >>>> Anthony >>> > From anton.tarasov at oracle.com Thu Jan 26 23:29:01 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 27 Jan 2012 11:29:01 +0400 Subject: [7u-osx] Request for approval for 7129825 - [macosx] Native activation is not changed when focusing other frame's owned window Message-ID: <4F22523D.8040708@oracle.com> Hello, A request to push the changes to jdk7u-osx. Reviewed on macosx-port-dev by Artem Ananiev. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129825 Webrev: http://cr.openjdk.java.net/~ant/7129825/webrev.0/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002475.html Thanks, Anton. From anton.tarasov at oracle.com Thu Jan 26 23:31:40 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 27 Jan 2012 11:31:40 +0400 Subject: [7u-osx] Request for approval for 7131196 - [macosx] Cmd-Q does not quit a graphical Java app Message-ID: <4F2252DC.7050900@oracle.com> Hello, A request to push the changes to jdk7u-osx. Reviewed on macosx-port-dev by Artem Ananiev. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131196 Webrev: http://cr.openjdk.java.net/~ant/7131196/webrev.0/ Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002464.html Thanks, Anton. From artem.ananiev at oracle.com Fri Jan 27 01:57:22 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 27 Jan 2012 13:57:22 +0400 Subject: [7u-osx] Request for approval for 7131196 - [macosx] Cmd-Q does not quit a graphical Java app In-Reply-To: <4F2252DC.7050900@oracle.com> References: <4F2252DC.7050900@oracle.com> Message-ID: <4F227502.6010502@oracle.com> Approved. On 1/27/2012 11:31 AM, Anton V. Tarasov wrote: > Hello, > > A request to push the changes to jdk7u-osx. > Reviewed on macosx-port-dev by Artem Ananiev. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131196 > Webrev: http://cr.openjdk.java.net/~ant/7131196/webrev.0/ > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002464.html > > > Thanks, > Anton. From leonid.romanov at oracle.com Fri Jan 27 03:07:45 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 27 Jan 2012 15:07:45 +0400 Subject: [7u-osx] Request for approval for MACOSX_PORT-568: KeyEvent difference between Apple 1.6 and openjdk 1.7 Message-ID: <39DB006C-B021-43ED-B4E7-48E01CAADB73@oracle.com> Hi, This a request to push the following changes to jdk7u-osx. CR: http://java.net/jira/browse/MACOSX_PORT-568 Webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-568/webrev.00/ The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov and Alexander Potochkin. Thanks, Leonid. From anthony.petrov at oracle.com Fri Jan 27 03:38:30 2012 From: anthony.petrov at oracle.com (anthony.petrov at oracle.com) Date: Fri, 27 Jan 2012 11:38:30 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7129420: [macosx] SplashScreen.getSplashScreen() returns null Message-ID: <20120127113854.A024247223@hg.openjdk.java.net> Changeset: 03d38a9723ff Author: anthony Date: 2012-01-27 15:37 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/03d38a9723ff 7129420: [macosx] SplashScreen.getSplashScreen() returns null Summary: Use GetJREPath() to infer the location of the splash screen library Reviewed-by: art, ksrini, swingler ! src/macosx/bin/java_md_macosx.c ! src/share/bin/emessages.h From artem.ananiev at oracle.com Fri Jan 27 03:42:20 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 27 Jan 2012 15:42:20 +0400 Subject: [7u-osx] Request for approval for MACOSX_PORT-568: KeyEvent difference between Apple 1.6 and openjdk 1.7 In-Reply-To: <39DB006C-B021-43ED-B4E7-48E01CAADB73@oracle.com> References: <39DB006C-B021-43ED-B4E7-48E01CAADB73@oracle.com> Message-ID: <4F228D9C.9070004@oracle.com> Approved. On 1/27/2012 3:07 PM, Leonid Romanov wrote: > Hi, > This a request to push the following changes to jdk7u-osx. > > CR: http://java.net/jira/browse/MACOSX_PORT-568 > Webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-568/webrev.00/ > > The fix has been reviewed on macosx-port-dev mailing list by Anthony Petrov and Alexander Potochkin. > > Thanks, > Leonid. > From michael.x.mcmahon at oracle.com Fri Jan 27 03:41:08 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 27 Jan 2012 11:41:08 +0000 Subject: RFR: 7134690: remove legacy jnilib support from ClassLoader and System [macosx] Message-ID: <4F228D54.8040801@oracle.com> Can I get the following change reviewed please? The change is to remove some mac specific code from: src/share/classes/java/lang/System.java and src/share/classes/java/lang/ClassLoader.java which added support for non-standard native library suffixes on Mac OS (ie. .jnilib as well as the standard .dylib). We would like to remove this code, so there will be no changes to those sources when the Mac changes get pushed to jdk7u-dev I have submitted a hotspot CR to track providing the same functionality in Mac specific code in hotspot. Though we can probably live without it in the short-term. http://cr.openjdk.java.net/~michaelm/7134690/webrev.1/ Thanks Michael From anthony.petrov at oracle.com Fri Jan 27 04:02:54 2012 From: anthony.petrov at oracle.com (anthony.petrov at oracle.com) Date: Fri, 27 Jan 2012 12:02:54 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124554: [macosx] JWindow does ignore setAlwaysOnTop property Message-ID: <20120127120305.1851147224@hg.openjdk.java.net> Changeset: c28e318653c6 Author: anthony Date: 2012-01-27 16:02 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/c28e318653c6 7124554: [macosx] JWindow does ignore setAlwaysOnTop property Summary: Re-apply the Floating level to AlwaysOnTop child windows after -addCHildWindow: calls Reviewed-by: leonidr, swingler ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/native/sun/awt/CWrapper.m From Alan.Bateman at oracle.com Fri Jan 27 04:12:08 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Jan 2012 12:12:08 +0000 Subject: RFR: 7134690: remove legacy jnilib support from ClassLoader and System [macosx] In-Reply-To: <4F228D54.8040801@oracle.com> References: <4F228D54.8040801@oracle.com> Message-ID: <4F229498.7030701@oracle.com> On 27/01/2012 11:41, Michael McMahon wrote: > Can I get the following change reviewed please? The change is to remove > some mac specific code from: > > src/share/classes/java/lang/System.java and > src/share/classes/java/lang/ClassLoader.java > > which added support for non-standard native library suffixes on Mac OS > (ie. .jnilib as well as the standard .dylib). > > We would like to remove this code, so there will be no changes to > those sources > when the Mac changes get pushed to jdk7u-dev > > I have submitted a hotspot CR to track providing the same functionality > in Mac specific code in hotspot. Though we can probably live without > it in the short-term. > > http://cr.openjdk.java.net/~michaelm/7134690/webrev.1/ This looks fine to me as this wasn't the right place to support this. I don't know how common .jnilib was to know if the VM changes will be required in the short term. -Alan From anthony.petrov at oracle.com Fri Jan 27 04:26:32 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 27 Jan 2012 16:26:32 +0400 Subject: Review request for 7124393: [macosx] JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click In-Reply-To: <4F21872B.5000409@oracle.com> References: <4F1D99F6.9060709@oracle.com> <4F1E9F3F.4030705@oracle.com> <4F21872B.5000409@oracle.com> Message-ID: <4F2297F8.1070605@oracle.com> Hi Alex and Mike, On 1/26/2012 9:02 PM, Alexander Potochkin wrote: >> I'm OK with realSync() calls, but unsure about the stopCellEditing() >> call. Indeed, using a Swing method should produce correct results. >> However, I think that this regression test is supposed to emulate >> user's actions, not Swing calls, isn't it? If so, we should either >> find a cross-platform events that finish editing and use Robot to >> emulate them, or use the "os.name" property and synthesize different >> user actions on different platforms. >> >> Please correct me if my assumption is wrong. > > Your assumption is correct > it is indeed better to always emulate the user's action. > > However in this case it is not as simple because Aqua LaF doesn't > provide a key shortcut which stops the cell editing > see BasicLookAndFeel line 1545, F2 is bound to "startEditing" action (it > calls stopEditing() method) > there is no such an action bound to any key in > AquaKeyBinding.getTableInputMap() > > So calling stopCellEditing inside the test is a good tradeoff > because it is simple, makes the test compatible with every LaF > and doesn't interfere with what the *bug6711682 *actually tests 6711682 describes an issue related to actions produced by user only: > A DESCRIPTION OF THE PROBLEM : > The cell editor is a JCheckBox and the table stays in edit mode after clicking the JCheckBox. > If you are in editing mode and click on an other row of the same column to select/unselect the JCheckBox, only each second time the value changed. If we follow this procedure manually on the Mac with the original test case for 6711682, will we reproduce the problem described in that CR? If the answer to this is yes, then we have to find a way to fix 6711682 for the Mac as well, and this (I suppose) should provide us with a way to emulate the stopEditing() action by means of using Robot. Could you please verify this? Also, a question to Mike: can we update Aqua L&F to add a binding for the start/stopEditing() action? -- best regards, Anthony > > Thanks > alexp > >> >> -- >> best regards, >> Anthony >> >> On 1/23/2012 9:33 PM, Alexander Potochkin wrote: >>> Hello >>> >>> Please review the following fix: >>> http://cr.openjdk.java.net/~alexp/7124393/webrev.00/ >>> >>> the bug's description is here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124393 >>> >>> The bug is in the test, F2 doesn't stop editing on MacOS, >>> we should not use the keyboard to commit the data >>> >>> the test is also updated >>> to access the Swing methods on the Event Dispatching Thread only >>> >>> Thanks >>> alexp > From Alexander.Potochkin at oracle.com Fri Jan 27 05:08:55 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Fri, 27 Jan 2012 17:08:55 +0400 Subject: Review request for 7124393: [macosx] JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click In-Reply-To: <4F2297F8.1070605@oracle.com> References: <4F1D99F6.9060709@oracle.com> <4F1E9F3F.4030705@oracle.com> <4F21872B.5000409@oracle.com> <4F2297F8.1070605@oracle.com> Message-ID: <4F22A1E7.2030100@oracle.com> Hello Anthony > > 6711682 describes an issue related to actions produced by user only: > >> A DESCRIPTION OF THE PROBLEM : >> The cell editor is a JCheckBox and the table stays in edit mode after >> clicking the JCheckBox. >> If you are in editing mode and click on an other row of the same >> column to select/unselect the JCheckBox, only each second time the >> value changed. it is about mouse clicking, not about pressing any keys. It is me, as the author of the test case for 6711682, decided to explicitly stop editing but for the *last cell only* > > If we follow this procedure manually on the Mac with the original test > case for 6711682, will we reproduce the problem described in that CR? > If the answer to this is yes, then we have to find a way to fix > 6711682 for the Mac as well, and this (I suppose) should provide us > with a way to emulate the stopEditing() action by means of using Robot. > > Could you please verify this? The original test for 6711682 (which is provided in the description) is not reproducible on Mac or any platform because it is fixed, and the fix in the code, shared by all LaFs verified > > Also, a question to Mike: can we update Aqua L&F to add a binding for > the start/stopEditing() action? If Aqua LaF guidelines doesn't require this action we shouldn't add it without a reasonable request from the customers Thanks alexp > > -- > best regards, > Anthony > > >> >> Thanks >> alexp >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 1/23/2012 9:33 PM, Alexander Potochkin wrote: >>>> Hello >>>> >>>> Please review the following fix: >>>> http://cr.openjdk.java.net/~alexp/7124393/webrev.00/ >>>> >>>> the bug's description is here: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124393 >>>> >>>> The bug is in the test, F2 doesn't stop editing on MacOS, >>>> we should not use the keyboard to commit the data >>>> >>>> the test is also updated >>>> to access the Swing methods on the Event Dispatching Thread only >>>> >>>> Thanks >>>> alexp >> From Alan.Bateman at oracle.com Fri Jan 27 05:35:23 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Jan 2012 13:35:23 +0000 Subject: 7131697 :(se) Need AsynchronousChannelProvider implementation Message-ID: <4F22A81B.4060000@oracle.com> The Mac port doesn't currently have an implementation of the asynchronous I/O API and so all tests for this area, including JCK tests, are failing. I've whipped up an initial implementation based on kqueue and put the webrev here: http://cr.openjdk.java.net/~alanb/7131697/webrev/ It's very simple and works very similarly to the the epoll based implementation that we have on Linux. It passes all tests on both 10.6.8 and 10.7. In summary, each channel group has a kernel queue and channels associated with the group register for events on that queue. The channel group's thread pool services the events. The events are retrieved in batch by a leader thread that makes them available to any other threads. There is clearly some performance work that needs to be done around this but it's not critical in the short term. Note that that sun.nio.ch.KQueue is its own class so that we can re-use in a re-work of Apple's kqueue based Selector implementation. That Selector needs a bit of work in order to pass all tests and so is not currently used by default. Another thing to mention is that I updated the mapfile although that doesn't appear to be used in the current build. -Alan. From anthony.petrov at oracle.com Fri Jan 27 05:36:21 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 27 Jan 2012 17:36:21 +0400 Subject: Review request for 7124393: [macosx] JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click In-Reply-To: <4F22A1E7.2030100@oracle.com> References: <4F1D99F6.9060709@oracle.com> <4F1E9F3F.4030705@oracle.com> <4F21872B.5000409@oracle.com> <4F2297F8.1070605@oracle.com> <4F22A1E7.2030100@oracle.com> Message-ID: <4F22A855.70802@oracle.com> Thanks for the confirmation, Alex. I'm OK with the fix then. -- best regards, Anthony On 1/27/2012 5:08 PM, Alexander Potochkin wrote: > Hello Anthony >> >> 6711682 describes an issue related to actions produced by user only: >> >>> A DESCRIPTION OF THE PROBLEM : >>> The cell editor is a JCheckBox and the table stays in edit mode after >>> clicking the JCheckBox. >>> If you are in editing mode and click on an other row of the same >>> column to select/unselect the JCheckBox, only each second time the >>> value changed. > > it is about mouse clicking, not about pressing any keys. > It is me, as the author of the test case for 6711682, decided to > explicitly stop editing but for the *last cell only* >> >> If we follow this procedure manually on the Mac with the original test >> case for 6711682, will we reproduce the problem described in that CR? >> If the answer to this is yes, then we have to find a way to fix >> 6711682 for the Mac as well, and this (I suppose) should provide us >> with a way to emulate the stopEditing() action by means of using Robot. >> >> Could you please verify this? > > The original test for 6711682 (which is provided in the description) is > not reproducible on Mac or any platform because it is fixed, > and the fix in the code, shared by all LaFs > > verified > >> >> Also, a question to Mike: can we update Aqua L&F to add a binding for >> the start/stopEditing() action? > > If Aqua LaF guidelines doesn't require this action we shouldn't add it > without a reasonable request from the customers > > Thanks > alexp > >> >> -- >> best regards, >> Anthony >> >> >>> >>> Thanks >>> alexp >>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 1/23/2012 9:33 PM, Alexander Potochkin wrote: >>>>> Hello >>>>> >>>>> Please review the following fix: >>>>> http://cr.openjdk.java.net/~alexp/7124393/webrev.00/ >>>>> >>>>> the bug's description is here: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124393 >>>>> >>>>> The bug is in the test, F2 doesn't stop editing on MacOS, >>>>> we should not use the keyboard to commit the data >>>>> >>>>> the test is also updated >>>>> to access the Swing methods on the Event Dispatching Thread only >>>>> >>>>> Thanks >>>>> alexp >>> > From greg.x.brown at oracle.com Fri Jan 27 05:46:49 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 27 Jan 2012 08:46:49 -0500 Subject: Fwd: [7u4] Review request for CR 7134730 References: Message-ID: <30307560-D34E-4959-9777-9247F11BE612@oracle.com> Sent original review request to 7u4 list by accident. Please see below. Begin forwarded message: > From: Greg Brown > Subject: [7u4] Review request for CR 7134730 > Date: January 27, 2012 8:44:47 AM EST > To: JDK 7u > > This change resolves some path issues in the XCode project that builds the JavaAppLauncher executable and updates the XCode project for XCode 4.2. It also fixes some issues with classpath and command-line argument handling. > > > From Alan.Bateman at oracle.com Fri Jan 27 05:52:18 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Jan 2012 13:52:18 +0000 Subject: 7133476: (fs) Files.readAttributes throws NPE Message-ID: <4F22AC12.9030308@oracle.com> Currently Files.readAttributes throws NPE rather than UOE on Mac OS X when invoked to read DOS attributes. This looks like an issue introduced upstream in the BSD porting project. To fix this requires removing BsdFileSystemProvider.readAttributes (the super class implementation does the right thing already). While I was there I also removed commented out code that should not be here. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7133476/webrev/ Thanks, Alan. From Alexander.Potochkin at oracle.com Fri Jan 27 06:08:25 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Fri, 27 Jan 2012 18:08:25 +0400 Subject: Review request for 7124393: [macosx] JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click In-Reply-To: <4F22A855.70802@oracle.com> References: <4F1D99F6.9060709@oracle.com> <4F1E9F3F.4030705@oracle.com> <4F21872B.5000409@oracle.com> <4F2297F8.1070605@oracle.com> <4F22A1E7.2030100@oracle.com> <4F22A855.70802@oracle.com> Message-ID: <4F22AFD9.3040102@oracle.com> Hello Anthony > Thanks for the confirmation, Alex. I'm OK with the fix then. Thanks! alexp > > -- > best regards, > Anthony > > On 1/27/2012 5:08 PM, Alexander Potochkin wrote: >> Hello Anthony >>> >>> 6711682 describes an issue related to actions produced by user only: >>> >>>> A DESCRIPTION OF THE PROBLEM : >>>> The cell editor is a JCheckBox and the table stays in edit mode >>>> after clicking the JCheckBox. >>>> If you are in editing mode and click on an other row of the same >>>> column to select/unselect the JCheckBox, only each second time the >>>> value changed. >> >> it is about mouse clicking, not about pressing any keys. >> It is me, as the author of the test case for 6711682, decided to >> explicitly stop editing but for the *last cell only* >>> >>> If we follow this procedure manually on the Mac with the original >>> test case for 6711682, will we reproduce the problem described in >>> that CR? If the answer to this is yes, then we have to find a way to >>> fix 6711682 for the Mac as well, and this (I suppose) should provide >>> us with a way to emulate the stopEditing() action by means of using >>> Robot. >>> >>> Could you please verify this? >> >> The original test for 6711682 (which is provided in the description) >> is not reproducible on Mac or any platform because it is fixed, >> and the fix in the code, shared by all LaFs >> >> verified >> >>> >>> Also, a question to Mike: can we update Aqua L&F to add a binding >>> for the start/stopEditing() action? >> >> If Aqua LaF guidelines doesn't require this action we shouldn't add >> it without a reasonable request from the customers >> >> Thanks >> alexp >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>>> >>>> Thanks >>>> alexp >>>> >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 1/23/2012 9:33 PM, Alexander Potochkin wrote: >>>>>> Hello >>>>>> >>>>>> Please review the following fix: >>>>>> http://cr.openjdk.java.net/~alexp/7124393/webrev.00/ >>>>>> >>>>>> the bug's description is here: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124393 >>>>>> >>>>>> The bug is in the test, F2 doesn't stop editing on MacOS, >>>>>> we should not use the keyboard to commit the data >>>>>> >>>>>> the test is also updated >>>>>> to access the Swing methods on the Event Dispatching Thread only >>>>>> >>>>>> Thanks >>>>>> alexp >>>> >> From dmitry.cherepanov at oracle.com Fri Jan 27 07:17:04 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Fri, 27 Jan 2012 18:17:04 +0300 Subject: Review request for 7131793: [macosx] some cleanup in OGL pipeline code Message-ID: <4F22BFF0.406@oracle.com> Hello, Here's some changes to remove some stale code from the OGL pipeline. This code has been introduced as a part of the initial implementation for CALayer-based rendering and disabled by the changes for MACOSX_PORT-766. http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.1/ Thanks, Dmitry From michael.x.mcmahon at oracle.com Fri Jan 27 06:47:02 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 27 Jan 2012 14:47:02 +0000 Subject: 7131697 :(se) Need AsynchronousChannelProvider implementation In-Reply-To: <4F22A81B.4060000@oracle.com> References: <4F22A81B.4060000@oracle.com> Message-ID: <4F22B8E6.50707@oracle.com> Very impressive. And so little native code as well . One question. Since you use the ONESHOT mode, does that not mean only one read (or write) operation can be outstanding on a channel at the same time? One minor nit. The test in DefaultAsynchronousChannelProvider.java should probably be startsWith("Mac OS"); Thanks, Michael. On 27/01/12 13:35, Alan Bateman wrote: > > The Mac port doesn't currently have an implementation of the > asynchronous I/O API and so all tests for this area, including JCK > tests, are failing. I've whipped up an initial implementation based on > kqueue and put the webrev here: > > http://cr.openjdk.java.net/~alanb/7131697/webrev/ > > It's very simple and works very similarly to the the epoll based > implementation that we have on Linux. It passes all tests on both > 10.6.8 and 10.7. In summary, each channel group has a kernel queue and > channels associated with the group register for events on that queue. > The channel group's thread pool services the events. The events are > retrieved in batch by a leader thread that makes them available to any > other threads. There is clearly some performance work that needs to be > done around this but it's not critical in the short term. > > Note that that sun.nio.ch.KQueue is its own class so that we can > re-use in a re-work of Apple's kqueue based Selector implementation. > That Selector needs a bit of work in order to pass all tests and so is > not currently used by default. Another thing to mention is that I > updated the mapfile although that doesn't appear to be used in the > current build. > > -Alan. > From Alan.Bateman at oracle.com Fri Jan 27 07:14:13 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Jan 2012 15:14:13 +0000 Subject: 7131697 :(se) Need AsynchronousChannelProvider implementation In-Reply-To: <4F22B8E6.50707@oracle.com> References: <4F22A81B.4060000@oracle.com> <4F22B8E6.50707@oracle.com> Message-ID: <4F22BF45.8080705@oracle.com> On 27/01/2012 14:47, Michael McMahon wrote: > Very impressive. And so little native code as well . > > One question. Since you use the ONESHOT mode, does that not mean > only one read (or write) operation can be outstanding on a channel at > the same time? That's right, all covered in the javadoc and *PendingExceptions defined for these cases. > > One minor nit. The test in DefaultAsynchronousChannelProvider.java > should probably be startsWith("Mac OS"); Thanks, I've fixed that and regenerated the webrev. Since you are happy I will seek approval on jdk7u-dev to get this into jdk7u/jdk7u-osx. -Alan From michael.x.mcmahon at oracle.com Fri Jan 27 07:20:28 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 27 Jan 2012 15:20:28 +0000 Subject: 7131697 :(se) Need AsynchronousChannelProvider implementation In-Reply-To: <4F22BF45.8080705@oracle.com> References: <4F22A81B.4060000@oracle.com> <4F22B8E6.50707@oracle.com> <4F22BF45.8080705@oracle.com> Message-ID: <4F22C0BC.6060402@oracle.com> On 27/01/12 15:14, Alan Bateman wrote: > On 27/01/2012 14:47, Michael McMahon wrote: >> Very impressive. And so little native code as well . >> >> One question. Since you use the ONESHOT mode, does that not mean >> only one read (or write) operation can be outstanding on a channel at >> the same time? > That's right, all covered in the javadoc and *PendingExceptions > defined for these cases. ah right. Thanks! >> >> One minor nit. The test in DefaultAsynchronousChannelProvider.java >> should probably be startsWith("Mac OS"); > Thanks, I've fixed that and regenerated the webrev. > > Since you are happy I will seek approval on jdk7u-dev to get this into > jdk7u/jdk7u-osx. > That's fine. - Michael. > -Alan From michael.x.mcmahon at oracle.com Fri Jan 27 07:28:26 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 27 Jan 2012 15:28:26 +0000 Subject: [jdk7u-osx] Request for approval for CR 7134690: remove legacy jnilib support from ClassLoader and System [macosx] Message-ID: <4F22C29A.20901@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7134690 Webrev: http://cr.openjdk.java.net/~michaelm/7134690/webrev.1/ Reviewed by: alanb Thanks, Michael. From paul.hohensee at oracle.com Fri Jan 27 07:30:57 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 27 Jan 2012 10:30:57 -0500 Subject: [jdk7u-osx] Request for approval for CR 7134690: remove legacy jnilib support from ClassLoader and System [macosx] In-Reply-To: <4F22C29A.20901@oracle.com> References: <4F22C29A.20901@oracle.com> Message-ID: <4F22C331.4020401@oracle.com> Approved. Paul On 1/27/12 10:28 AM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7134690 > > Webrev: http://cr.openjdk.java.net/~michaelm/7134690/webrev.1/ > > Reviewed by: alanb > > Thanks, > Michael. From Alan.Bateman at oracle.com Fri Jan 27 07:34:13 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Jan 2012 15:34:13 +0000 Subject: [7u-osx] Request for approval for 7131697 :(se) Need AsynchronousChannelProvider implementation Message-ID: <4F22C3F5.6080707@oracle.com> This is a request to push to the jdk7u/jdk7u-osx forest. CR: http://bugs.sun.com/view_bug.do?bug_id=7131697 Webrev: http://cr.openjdk.java.net/~alanb/7131697/webrev/ Reviewed by: michaelm Thanks, Alan. From scott.kovatch at oracle.com Fri Jan 27 07:56:36 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 27 Jan 2012 07:56:36 -0800 Subject: RFR: 7134690: remove legacy jnilib support from ClassLoader and System [macosx] In-Reply-To: <4F229498.7030701@oracle.com> References: <4F228D54.8040801@oracle.com> <4F229498.7030701@oracle.com> Message-ID: On Jan 27, 2012, at 4:12 AM, Alan Bateman wrote: > On 27/01/2012 11:41, Michael McMahon wrote: >> Can I get the following change reviewed please? The change is to remove >> some mac specific code from: >> >> src/share/classes/java/lang/System.java and >> src/share/classes/java/lang/ClassLoader.java >> >> which added support for non-standard native library suffixes on Mac OS >> (ie. .jnilib as well as the standard .dylib). >> >> We would like to remove this code, so there will be no changes to those sources >> when the Mac changes get pushed to jdk7u-dev >> >> I have submitted a hotspot CR to track providing the same functionality >> in Mac specific code in hotspot. Though we can probably live without it in the short-term. >> >> http://cr.openjdk.java.net/~michaelm/7134690/webrev.1/ > This looks fine to me as this wasn't the right place to support this. I don't know how common .jnilib was to know if the VM changes will be required in the short term. For 7u4 this is probably going to be okay, but we definitely need this functionality for 7u6 when the plugin is released. There are some popular web sites (Minecraft, for example) that use JOGL, which uses a .jnilib extension. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From paul.hohensee at oracle.com Fri Jan 27 07:57:01 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 27 Jan 2012 10:57:01 -0500 Subject: [7u-osx] Request for approval for 7131697 :(se) Need AsynchronousChannelProvider implementation In-Reply-To: <4F22C3F5.6080707@oracle.com> References: <4F22C3F5.6080707@oracle.com> Message-ID: <4F22C94D.7050508@oracle.com> Approved. Paul On 1/27/12 10:34 AM, Alan Bateman wrote: > > This is a request to push to the jdk7u/jdk7u-osx forest. > > CR: http://bugs.sun.com/view_bug.do?bug_id=7131697 > > Webrev: http://cr.openjdk.java.net/~alanb/7131697/webrev/ > > Reviewed by: michaelm > > Thanks, > Alan. From swingler at apple.com Fri Jan 27 08:39:14 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 27 Jan 2012 08:39:14 -0800 Subject: Review request for 7131793: [macosx] some cleanup in OGL pipeline code In-Reply-To: <4F22BFF0.406@oracle.com> References: <4F22BFF0.406@oracle.com> Message-ID: <15184530-A44F-45DB-B1A8-FC890521D635@apple.com> On Jan 27, 2012, at 7:17 AM, Dmitry Cherepanov wrote: > Hello, > > Here's some changes to remove some stale code from the OGL pipeline. This code has been introduced as a part of the initial implementation for CALayer-based rendering and disabled by the changes for MACOSX_PORT-766. > > http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.1/ One tiny detail: I'd recommend using -jObjectWithEnv: instead of -jObject here (because it's a little faster to not re-fetch the env): + JNFCallVoidMethod(env, [self.javaLayer jObject], jm_drawInCGLContext); I'm very glad to see this code getting shorter, and using a retain/release wrapper around the JNI global refs. Looks great, Mike Swingler Apple Inc. From swingler at apple.com Fri Jan 27 08:49:21 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 27 Jan 2012 08:49:21 -0800 Subject: Review request for 7124393: [macosx] JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click In-Reply-To: <4F22A1E7.2030100@oracle.com> References: <4F1D99F6.9060709@oracle.com> <4F1E9F3F.4030705@oracle.com> <4F21872B.5000409@oracle.com> <4F2297F8.1070605@oracle.com> <4F22A1E7.2030100@oracle.com> Message-ID: <45629B54-84DD-4069-B5F7-96C680D0FB29@apple.com> On Jan 27, 2012, at 5:08 AM, Alexander Potochkin wrote: >> Also, a question to Mike: can we update Aqua L&F to add a binding for the start/stopEditing() action? > > If Aqua LaF guidelines doesn't require this action we shouldn't add it without a reasonable request from the customers I think this is generally the right approach. Cheers, Mike Swingler Apple Inc. From swingler at apple.com Fri Jan 27 09:19:59 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 27 Jan 2012 09:19:59 -0800 Subject: [7u4] Review request for CR 7134730 In-Reply-To: <30307560-D34E-4959-9777-9247F11BE612@oracle.com> References: <30307560-D34E-4959-9777-9247F11BE612@oracle.com> Message-ID: I've taken a look at this diff and have a few suggestions: diff -r 2e4258236920 src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m --- a/src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m Thu Jan 26 21:47:53 2012 +0400 +++ b/src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m Fri Jan 27 08:43:08 2012 -0500 @@ -77,7 +77,7 @@ NSString *GetJavaRoot(NSDictionary *jvmInfoDict) { NSObject *javaRoot = [jvmInfoDict objectForKey:@"$JAVAROOT"]; - if (![javaRoot isKindOfClass:[NSString class]]) return @"$APP_PACKAGE/Contents/Java"; + if (![javaRoot isKindOfClass:[NSString class]]) return @"$APP_PACKAGE/Contents/Resources/Java"; return (NSString *)javaRoot; } I'd actually recommend putting the Java resources (.jars and .jnilibs) into Contents/Java now, and not Contents/Resources/Java, because of issues with code-signing (Resources is designed to be a location for localized content or images, which may be changeable without breaking the bundle's code signature). I know this is different from traditional app bundles, but since developers will have to re-bundle anyway, this is actually the most compatible thing for them to do moving forward. Also, I'd simply suggest initializing: + NSMutableArray *arguments = [NSMutableArray array]; and not worry about pre-initializing the capacity, or re-assigning the variable later on. It just makes the code a lot cleaner (with no measurable performance cost, since this straight-line code is only executed once). You can also simply do: + [jvmOptions addObjectsFromArray:arguments] instead of: + // Add arguments + [arguments enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) { + [jvmOptions addObject:obj]; + }]; + If you are manually adding the arguments list to the jvmOptions array, then you don't need to re-stuff the arguments back into the jvmInfo dictionary, so you can completely remove the lines: [jvmInfo setObject:arguments forKey:kArgumentsKey]; I'm also a little confused by: + expanded = [expanded stringByReplacingOccurrencesOfString:@" " withString:@"\\ "]; Does this mean that HotSpot needs spaces (and possibly other shell-interpreted characters) pre-escaped with backslashes for it? I really don't think this is actually the case, because our previous code did nothing like this. Please remember that the output of this tool is injected directly to HotSpot via API, and is not used to invoke a shell or a shell tool to like "java" or "javac". Regards, Mike Swingler Apple Inc. On Jan 27, 2012, at 5:46 AM, Greg Brown wrote: > Sent original review request to 7u4 list by accident. Please see below. > > Begin forwarded message: > >> From: Greg Brown >> Subject: [7u4] Review request for CR 7134730 >> Date: January 27, 2012 8:44:47 AM EST >> To: JDK 7u >> >> This change resolves some path issues in the XCode project that builds the JavaAppLauncher executable and updates the XCode project for XCode 4.2. It also fixes some issues with classpath and command-line argument handling. From greg.x.brown at oracle.com Fri Jan 27 09:48:47 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 27 Jan 2012 12:48:47 -0500 Subject: [7u4] Review request for CR 7134730 In-Reply-To: References: <30307560-D34E-4959-9777-9247F11BE612@oracle.com> Message-ID: <8B3E78BA-AE06-4A1C-ACAE-BDBCB7DA42BC@oracle.com> > I'd actually recommend putting the Java resources (.jars and .jnilibs) into Contents/Java now, and not Contents/Resources/Java, because of issues with code-signing (Resources is designed to be a location for localized content or images, which may be changeable without breaking the bundle's code signature). Will do. > Also, I'd simply suggest initializing: > + NSMutableArray *arguments = [NSMutableArray array]; > and not worry about pre-initializing the capacity, or re-assigning the variable later on. It just makes the code a lot cleaner (with no measurable performance cost, since this straight-line code is only executed once). OK. > I'm also a little confused by: > + expanded = [expanded stringByReplacingOccurrencesOfString:@" " withString:@"\\ "]; > > Does this mean that HotSpot needs spaces (and possibly other shell-interpreted characters) pre-escaped with backslashes for it? I really don't think this is actually the case, because our previous code did nothing like this. Please remember that the output of this tool is injected directly to HotSpot via API, and is not used to invoke a shell or a shell tool to like "java" or "javac". That's a good point. I had added this code because I wasn't able to launch a bundle whose name contained a space - however, it didn't actually fix the problem and should probably be removed. I'll take it out. Thanks for the review! Greg From igor.nekrestyanov at oracle.com Fri Jan 27 09:51:15 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Fri, 27 Jan 2012 09:51:15 -0800 Subject: RFR: 7134690: remove legacy jnilib support from ClassLoader and System [macosx] In-Reply-To: References: <4F228D54.8040801@oracle.com> <4F229498.7030701@oracle.com> Message-ID: <4F22E413.40808@oracle.com> On 1/27/12 7:56 AM, Scott Kovatch wrote: > On Jan 27, 2012, at 4:12 AM, Alan Bateman wrote: > >> On 27/01/2012 11:41, Michael McMahon wrote: >>> Can I get the following change reviewed please? The change is to remove >>> some mac specific code from: >>> >>> src/share/classes/java/lang/System.java and >>> src/share/classes/java/lang/ClassLoader.java >>> >>> which added support for non-standard native library suffixes on Mac OS >>> (ie. .jnilib as well as the standard .dylib). >>> >>> We would like to remove this code, so there will be no changes to those sources >>> when the Mac changes get pushed to jdk7u-dev >>> >>> I have submitted a hotspot CR to track providing the same functionality >>> in Mac specific code in hotspot. Though we can probably live without it in the short-term. >>> >>> http://cr.openjdk.java.net/~michaelm/7134690/webrev.1/ >> This looks fine to me as this wasn't the right place to support this. I don't know how common .jnilib was to know if the VM changes will be required in the short term. > For 7u4 this is probably going to be okay, but we definitely need this functionality for 7u6 when the plugin is released. There are some popular web sites (Minecraft, for example) that use JOGL, which uses a .jnilib extension. IMHO, this is enough to justify support for .jnilib in 7u4. Otherwise beta plugin bundle will not work for most popular sites ... -igor > > -- Scott K. > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > > From alexander.zuev at oracle.com Fri Jan 27 09:58:16 2012 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Fri, 27 Jan 2012 17:58:16 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7134826: [macosx] KeyEvent difference between Apple 1.6 and openjdk Message-ID: <20120127175826.BC82647235@hg.openjdk.java.net> Changeset: 5780795f381e Author: leonidr Date: 2012-01-27 21:59 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5780795f381e 7134826: [macosx] KeyEvent difference between Apple 1.6 and openjdk Reviewed-by: anthony, alexp ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/native/sun/awt/AWTView.m From Alexander.Potochkin at oracle.com Fri Jan 27 10:15:52 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Fri, 27 Jan 2012 22:15:52 +0400 Subject: Review request for 7122250: [macosx] mouseMoved Events test do not respond in JCK-runtime-7 interactive Message-ID: <4F22E9D8.6030904@oracle.com> Hello This is not a real review request, it is more about looking for some good advice from Cocoa experts http://cr.openjdk.java.net/~alexp/7122250/webrev.00/ For some reason java.awt.Window doesn't receive mouseEntered/mouseExited events in our JDK 7 for Mac. (It neither receive them in JDK 6 in some cases, but it is a different story) JFrame works fine, the problem is only with java.awt.Window subclasses (the test case is attached - you can see that no mouseEntered/mouseExited events are received) There is a clearTrackingRect() method called from AWTView.viewDidMoveToWindow which runs twice for JFrame, first with width and height equal to 1 and the next time with the actual size for JWindow it is also called twice but with the initial 1x1 visible size So looks like we need to call clearTrackingRect() at the moment the visible size is really changed. I checked that overriddensetFrameSize() method does the trick. However it doesn't seem to be a good practice and it is also not clear why java.awt.Window is such a special case. Any advice are welcome Thanks and have a great weekend alexp -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bug448.java Url: http://mail.openjdk.java.net/pipermail/macosx-port-dev/attachments/20120127/ab2c1839/bug448.java From amy.y.wang at oracle.com Thu Jan 26 06:41:12 2012 From: amy.y.wang at oracle.com (Amy Y Wang) Date: Thu, 26 Jan 2012 06:41:12 -0800 Subject: 7u-osx not buildable, failing at jfr-orig.jar generation (macosx fails earlier in hotspot) In-Reply-To: <4F2163E4.9010702@oracle.com> References: <4F2163E4.9010702@oracle.com> Message-ID: <4F216608.8000007@oracle.com> David, A P1 bug CR7133124 was filed yesterday, for the same build failure. It failed at 7u-dev build first. I'm working Lana on this one. There are two consecutive builds failed on this on 7u dev. But strangely, my master build all went through this morning. Amy On 1/26/2012 6:32 AM, David Katleman (Oracle) wrote: > I'll be filing a bug later this morning, this is a heads up, in case > someone knows about these already > > So far both linux, solaris-i586 and windows-amd64 have failed, I would > expect the others to follow > > Needless to say, build/promotion of 7u4 b227 based on 7u-osx will be > delayed today. > >> com/oracle/jrockit/jfr com/oracle/jrockit/jfr/client >> com/oracle/jrockit/jfr/management oracle/jrockit/jfr >> oracle/jrockit/jfr/events oracle/jrockit/jfr/openmbean >> oracle/jrockit/jfr/parser oracle/jrockit/jfr/settings >> oracle/jrockit/jfr/tools oracle/jrockit/jfr/util >> oracle/jrockit/jfr/util/log oracle/jrockit/jfr/util/os >> oracle/jrockit/jfr/util/text -J-XX:-PrintVMOptions >> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m >> -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m >> java.util.zip.ZipException: duplicate entry: >> com/oracle/jrockit/jfr/client/ >> at >> java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:175) >> at >> java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:92) >> at sun.tools.jar.Main.addFile(Main.java:683) >> at sun.tools.jar.Main.create(Main.java:437) >> at sun.tools.jar.Main.run(Main.java:160) >> at sun.tools.jar.Main.main(Main.java:1022) >> gnumake[3]: *** >> [/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA/build/linux-amd64/../linux-amd64-fastdebug/tmp/jfr-orig.jar] >> Error 1 >> gnumake[3]: Leaving directory >> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA/jdk/make' >> gnumake[2]: *** [jdk-build] Error 2 >> gnumake[2]: Leaving directory >> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA' >> gnumake[1]: *** [generic_debug_build] Error 2 >> gnumake[1]: Leaving directory >> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA' >> gnumake: *** [build_fastdebug_image] Error 2 >> + gmkexitcode=2 >> + '[' 2 -ne 0 ']' >> + errorExit 'gnumake failed, return code 2' >> + echo 'ERROR: gnumake failed, return code 2' >> ERROR: gnumake failed, return code 2 > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-linux-amd64-product/94/console > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-linux-i586-product/88/console > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-solaris-i586-product/92/console > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-windows-amd64-product/111/console > > > > macosx-amd64 is failing much earlier, in hotspot >> In file included from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp:11, >> from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:9: >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:127: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:130: >> error: 'fio_fd' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:150: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:152: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:152: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:185: >> error: 'fio_fd' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:188: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:194: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:196: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:202: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:204: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:206: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:209: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:211: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:211: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:213: >> error: expected ';' before '(' token >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:215: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:234: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:234: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:236: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:236: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:238: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp: >> In static member function 'static bool FileIO::is_bad_fd(int)': >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:127: >> error: 'BAD_FD' was not declared in this scope >> In file included from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:9: >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp: >> At global scope: >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp:19: >> error: 'filesize' does not name a type >> In file included from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/trace/traceEventTypes.hpp:12, >> from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:10: >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/trace/traceComplexEvent.hpp:35: >> error: 'filesize' does not name a type >> In file included from >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:18: >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:56: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:57: >> error: 'fio_fd' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:62: >> error: 'fio_fd' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:179: >> error: 'filesize' does not name a type >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:189: >> error: 'filesize' has not been declared >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp: >> In constructor 'streamwriter::streamwriter()': >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >> error: class 'streamwriter' does not have any field named 'stream_pos' >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >> error: class 'streamwriter' does not have any field named 'out' >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >> error: 'BAD_FD' was not declared in this scope >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp: >> In member function 'void streamwriter::reset(int)': >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:64: >> error: 'stream_pos' was not declared in this scope >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:65: >> error: 'out' was not declared in this scope >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp: >> In static member function 'static void >> JFREventWriter::write_event(TraceEventId, const void*, countertime, >> countertime)': >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:227: >> error: cast from '_opaque_pthread_t*' to 'u4' loses precision >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp: >> At global scope: >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:274: >> error: 'filesize' does not name a type >> Compiling >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims/evmCompat.cpp >> rm -f evmCompat.o >> llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -DFASTDEBUG >> -I. >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/prims >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/precompiled >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/cpu/x86/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/cpu/x86/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os_cpu/bsd_x86/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os/bsd/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/os/posix/vm >> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os/posix/vm >> -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.0-b11\"" >> -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" >> -DHOTSPOT_BUILD_USER="\"java_re\"" -DHOTSPOT_LIB_ARCH=\"amd64\" >> -DJRE_RELEASE_VERSION="\"1.7.0_04-ea-fastdebug-b227\"" >> -DHOTSPOT_VM_DISTRO="\"Java HotSpot(TM)\"" -DTARGET_OS_FAMILY_bsd >> -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 >> -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 >> -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m64 >> -pipe -Os -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 >> -fno-omit-frame-pointer -DINCLUDE_TRACE -Werror -Wpointer-arith >> -Wconversion -Wsign-compare -DDTRACE_ENABLED -D_XOPEN_SOURCE >> -D_DARWIN_C_SOURCE -c -MMD -MP -MF >> ../generated/dependencies/evmCompat.o.d -o evmCompat.o >> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims/evmCompat.cpp >> >> gnumake[7]: *** [eventwriter.o] Error 1 >> gnumake[7]: *** Waiting for unfinished jobs.... >> gnumake[6]: *** [the_vm] Error 2 >> gnumake[5]: *** [fastdebug] Error 2 >> gnumake[4]: *** [generic_build2] Error 2 >> gnumake[3]: *** [fastdebug] Error 2 >> gnumake[2]: *** [hotspot-build] Error 2 >> gnumake[1]: *** [generic_debug_build] Error 2 >> gnumake: *** [build_fastdebug_image] Error 2 >> + gmkexitcode=2 >> + '[' 2 -ne 0 ']' >> + errorExit 'gnumake failed, return code 2' >> + echo 'ERROR: gnumake failed, return code 2' >> ERROR: gnumake failed, return code 2 > > > > http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-macosx-amd64-product/15/console > > From oleg.pekhovskiy at oracle.com Fri Jan 27 09:41:25 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 27 Jan 2012 21:41:25 +0400 Subject: Code Review Request for CR 7132367 - [macosx] ChoiceMouseWheelTest should be adapted for mac toolkit Message-ID: <4F22E1C5.2000804@oracle.com> Hi guys, Here is the description of CR: http://bt2ws.central.sun.com/CrPrint?id=7132367 Patch with changes attached. Description of the fix: Now this test skips mouse wheeling check over combobox on Mac JDK7 with LWCTookit. Thanks, Oleg. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 7132367.patch Url: http://mail.openjdk.java.net/pipermail/macosx-port-dev/attachments/20120127/aacc4690/7132367.patch From roger.yeung at oracle.com Fri Jan 27 10:53:50 2012 From: roger.yeung at oracle.com (Roger Yeung) Date: Fri, 27 Jan 2012 10:53:50 -0800 Subject: JDK 7 Mac Port Preview b227 Available Message-ID: <4F22F2BE.50008@oracle.com> Hi, The JDK 7 Mac Port Preview b227 is now available: http://jdk7.java.net/macportpreview/ Regards, Roger Y. From paul.hohensee at oracle.com Fri Jan 27 11:13:23 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 27 Jan 2012 14:13:23 -0500 Subject: 7u-osx not buildable, failing at jfr-orig.jar generation (macosx fails earlier in hotspot) In-Reply-To: <4F216608.8000007@oracle.com> References: <4F2163E4.9010702@oracle.com> <4F216608.8000007@oracle.com> Message-ID: <4F22F753.2030704@oracle.com> The fix for 7133124 has been pushed to jdk7u-dev, jdk7u-osx and jdk8/tl. Paul On 1/26/12 9:41 AM, Amy Y Wang wrote: > David, > > A P1 bug CR7133124 was filed yesterday, for the same build failure. > It failed at 7u-dev build first. I'm working Lana on this one. > There are two consecutive builds failed on this on 7u dev. > But strangely, my master build all went through this morning. > Amy > > On 1/26/2012 6:32 AM, David Katleman (Oracle) wrote: >> I'll be filing a bug later this morning, this is a heads up, in case >> someone knows about these already >> >> So far both linux, solaris-i586 and windows-amd64 have failed, I >> would expect the others to follow >> >> Needless to say, build/promotion of 7u4 b227 based on 7u-osx will be >> delayed today. >> >>> com/oracle/jrockit/jfr com/oracle/jrockit/jfr/client >>> com/oracle/jrockit/jfr/management oracle/jrockit/jfr >>> oracle/jrockit/jfr/events oracle/jrockit/jfr/openmbean >>> oracle/jrockit/jfr/parser oracle/jrockit/jfr/settings >>> oracle/jrockit/jfr/tools oracle/jrockit/jfr/util >>> oracle/jrockit/jfr/util/log oracle/jrockit/jfr/util/os >>> oracle/jrockit/jfr/util/text -J-XX:-PrintVMOptions >>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m >>> -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m >>> java.util.zip.ZipException: duplicate entry: >>> com/oracle/jrockit/jfr/client/ >>> at >>> java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:175) >>> at >>> java.util.jar.JarOutputStream.putNextEntry(JarOutputStream.java:92) >>> at sun.tools.jar.Main.addFile(Main.java:683) >>> at sun.tools.jar.Main.create(Main.java:437) >>> at sun.tools.jar.Main.run(Main.java:160) >>> at sun.tools.jar.Main.main(Main.java:1022) >>> gnumake[3]: *** >>> [/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA/build/linux-amd64/../linux-amd64-fastdebug/tmp/jfr-orig.jar] >>> Error 1 >>> gnumake[3]: Leaving directory >>> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA/jdk/make' >>> >>> gnumake[2]: *** [jdk-build] Error 2 >>> gnumake[2]: Leaving directory >>> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA' >>> gnumake[1]: *** [generic_debug_build] Error 2 >>> gnumake[1]: Leaving directory >>> `/HUDSON/workspace/REtestA-2-build-linux-amd64-product/REtestA' >>> gnumake: *** [build_fastdebug_image] Error 2 >>> + gmkexitcode=2 >>> + '[' 2 -ne 0 ']' >>> + errorExit 'gnumake failed, return code 2' >>> + echo 'ERROR: gnumake failed, return code 2' >>> ERROR: gnumake failed, return code 2 >> >> http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-linux-amd64-product/94/console >> >> http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-linux-i586-product/88/console >> >> http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-solaris-i586-product/92/console >> >> http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-windows-amd64-product/111/console >> >> >> >> macosx-amd64 is failing much earlier, in hotspot >>> In file included from >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp:11, >>> from >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:9: >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:127: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:130: >>> error: 'fio_fd' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:150: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:152: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:152: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:185: >>> error: 'fio_fd' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:188: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:194: >>> error: 'filesize' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:196: >>> error: 'filesize' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:202: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:204: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:206: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:209: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:211: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:211: >>> error: 'filesize' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:213: >>> error: expected ';' before '(' token >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:215: >>> error: 'filesize' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:234: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:234: >>> error: 'filesize' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:236: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:236: >>> error: 'filesize' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:238: >>> error: 'filesize' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp: >>> In static member function 'static bool FileIO::is_bad_fd(int)': >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/fileio.hpp:127: >>> error: 'BAD_FD' was not declared in this scope >>> In file included from >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:9: >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp: >>> At global scope: >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.hpp:19: >>> error: 'filesize' does not name a type >>> In file included from >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/trace/traceEventTypes.hpp:12, >>> from >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:10: >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/trace/traceComplexEvent.hpp:35: >>> error: 'filesize' does not name a type >>> In file included from >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:18: >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:56: >>> error: 'filesize' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:57: >>> error: 'fio_fd' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:62: >>> error: 'fio_fd' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:179: >>> error: 'filesize' does not name a type >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:189: >>> error: 'filesize' has not been declared >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp: >>> In constructor 'streamwriter::streamwriter()': >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >>> error: class 'streamwriter' does not have any field named 'stream_pos' >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >>> error: class 'streamwriter' does not have any field named 'out' >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:60: >>> error: 'BAD_FD' was not declared in this scope >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp: >>> In member function 'void streamwriter::reset(int)': >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:64: >>> error: 'stream_pos' was not declared in this scope >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/utilities/streamwriter.hpp:65: >>> error: 'out' was not declared in this scope >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp: >>> In static member function 'static void >>> JFREventWriter::write_event(TraceEventId, const void*, countertime, >>> countertime)': >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:227: >>> error: cast from '_opaque_pthread_t*' to 'u4' loses precision >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp: >>> At global scope: >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/jfr/jvm/eventwriter.cpp:274: >>> error: 'filesize' does not name a type >>> Compiling >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims/evmCompat.cpp >>> rm -f evmCompat.o >>> llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -DFASTDEBUG >>> -I. >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm/prims >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/share/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/precompiled >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/cpu/x86/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/cpu/x86/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os_cpu/bsd_x86/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os/bsd/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/closed/os/posix/vm >>> -I/HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/os/posix/vm >>> -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.0-b11\"" >>> -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" >>> -DHOTSPOT_BUILD_USER="\"java_re\"" -DHOTSPOT_LIB_ARCH=\"amd64\" >>> -DJRE_RELEASE_VERSION="\"1.7.0_04-ea-fastdebug-b227\"" >>> -DHOTSPOT_VM_DISTRO="\"Java HotSpot(TM)\"" -DTARGET_OS_FAMILY_bsd >>> -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 >>> -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 >>> -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti >>> -fno-exceptions -pthread -fcheck-new -m64 -pipe -Os >>> -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 >>> -fno-omit-frame-pointer -DINCLUDE_TRACE -Werror -Wpointer-arith >>> -Wconversion -Wsign-compare -DDTRACE_ENABLED -D_XOPEN_SOURCE >>> -D_DARWIN_C_SOURCE -c -MMD -MP -MF >>> ../generated/dependencies/evmCompat.o.d -o evmCompat.o >>> /HUDSON/workspace/REtestA-2-build-macosx-amd64-product/REtestA/hotspot/src/share/vm/prims/evmCompat.cpp >>> >>> gnumake[7]: *** [eventwriter.o] Error 1 >>> gnumake[7]: *** Waiting for unfinished jobs.... >>> gnumake[6]: *** [the_vm] Error 2 >>> gnumake[5]: *** [fastdebug] Error 2 >>> gnumake[4]: *** [generic_build2] Error 2 >>> gnumake[3]: *** [fastdebug] Error 2 >>> gnumake[2]: *** [hotspot-build] Error 2 >>> gnumake[1]: *** [generic_debug_build] Error 2 >>> gnumake: *** [build_fastdebug_image] Error 2 >>> + gmkexitcode=2 >>> + '[' 2 -ne 0 ']' >>> + errorExit 'gnumake failed, return code 2' >>> + echo 'ERROR: gnumake failed, return code 2' >>> ERROR: gnumake failed, return code 2 >> >> >> >> http://rehudson.us.oracle.com:8080/hudson/view/JDK7/view/RE-test/view/REtestA/job/REtestA-2-build-macosx-amd64-product/15/console >> >> From leonid.romanov at oracle.com Fri Jan 27 12:12:05 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Sat, 28 Jan 2012 00:12:05 +0400 Subject: Review request for MACOSX_PORT-675: VK_DELETE does produce an extraneous character in a TextArea or TextField Message-ID: <8235DC6E-0466-4DE6-9E9D-D7130680E586@oracle.com> Hi, Please review a fix for http://java.net/jira/browse/MACOSX_PORT-675 A bit of background. NsCharToJavaChar is a function contributed by Apple that translates a small subset of NS characters into Java characters. This function is currently unused. This fix does two things: - Puts NsCharToJavaChar back to use - Modifies a table used by NsCharToJavaChar to ensure that NSDeleteFunctionKey and NSDeleteCharacter gets translated regardless of what current modifiers are. webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-568/webrev.00/ Thanks, Leonid. From leonid.romanov at oracle.com Fri Jan 27 14:31:34 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Sat, 28 Jan 2012 02:31:34 +0400 Subject: Review request for MACOSX_PORT-675: VK_DELETE does produce an extraneous character in a TextArea or TextField In-Reply-To: <8235DC6E-0466-4DE6-9E9D-D7130680E586@oracle.com> References: <8235DC6E-0466-4DE6-9E9D-D7130680E586@oracle.com> Message-ID: Oops, the correct webrev is located at: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-675/webrev.00/ On 28.01.2012, at 0:12, Leonid Romanov wrote: > Hi, > Please review a fix for http://java.net/jira/browse/MACOSX_PORT-675 > > A bit of background. NsCharToJavaChar is a function contributed by Apple that translates a small subset of NS characters into Java characters. This function is currently unused. This fix does two things: > - Puts NsCharToJavaChar back to use > - Modifies a table used by NsCharToJavaChar to ensure that NSDeleteFunctionKey and NSDeleteCharacter gets translated regardless of what current modifiers are. > > webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-568/webrev.00/ > > Thanks, > Leonid. > > From alan.bateman at oracle.com Sat Jan 28 03:40:15 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 28 Jan 2012 11:40:15 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7131697: (se) Need AsynchronousChannelProvider implementation for Mac OS X Message-ID: <20120128114059.DCD244724B@hg.openjdk.java.net> Changeset: 5599aa5a4a51 Author: alanb Date: 2012-01-28 11:37 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5599aa5a4a51 7131697: (se) Need AsynchronousChannelProvider implementation for Mac OS X Reviewed-by: michaelm ! make/java/nio/Makefile ! make/java/nio/mapfile-bsd + src/solaris/classes/sun/nio/ch/BsdAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java + src/solaris/classes/sun/nio/ch/KQueue.java + src/solaris/classes/sun/nio/ch/KQueuePort.java + src/solaris/native/sun/nio/ch/KQueue.c + src/solaris/native/sun/nio/ch/KQueuePort.c From swingler at apple.com Sun Jan 29 09:16:22 2012 From: swingler at apple.com (Mike Swingler) Date: Sun, 29 Jan 2012 09:16:22 -0800 Subject: Review request for MACOSX_PORT-675: VK_DELETE does produce an extraneous character in a TextArea or TextField In-Reply-To: References: <8235DC6E-0466-4DE6-9E9D-D7130680E586@oracle.com> Message-ID: <9B5B3E23-73F7-435D-BE99-9E804B7D4BDD@apple.com> Seems reasonable to me. Regards, Mike Swingler Apple Inc. On Jan 27, 2012, at 2:31 PM, Leonid Romanov wrote: > Oops, the correct webrev is located at: > http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-675/webrev.00/ > > On 28.01.2012, at 0:12, Leonid Romanov wrote: > >> Hi, >> Please review a fix for http://java.net/jira/browse/MACOSX_PORT-675 >> >> A bit of background. NsCharToJavaChar is a function contributed by Apple that translates a small subset of NS characters into Java characters. This function is currently unused. This fix does two things: >> - Puts NsCharToJavaChar back to use >> - Modifies a table used by NsCharToJavaChar to ensure that NSDeleteFunctionKey and NSDeleteCharacter gets translated regardless of what current modifiers are. >> >> webrev: http://cr.openjdk.java.net/~leonidr/MACOSX_PORT-568/webrev.00/ >> >> Thanks, >> Leonid. >> >> > From laurent.mihalkovic at gmail.com Sun Jan 29 10:38:23 2012 From: laurent.mihalkovic at gmail.com (L Mihalkovic) Date: Sun, 29 Jan 2012 19:38:23 +0100 Subject: Java 7 screwup In-Reply-To: <3015AB60-236A-45CF-B4D4-32A05A9A60D2@gmail.com> References: <76E5EA67-494D-467A-91BB-8525A2FB747F@talios.com> <3015AB60-236A-45CF-B4D4-32A05A9A60D2@gmail.com> Message-ID: Wouldn't it be nice if OSX Mail had the notion of voiding old outbox contents?! This email stayed dormant for several months on a broken hard-drive until yesterday when the machine was powered again and decided to work... I stil stand in true admiration of the work you are doing, still annoyed by some of Mail's quirks... and having a grand time with jsr292 (I ran into some spurious crashes of the mac port for code that worked on windows, but considering the stage I am at, I can't say if this is macport bug or a lot of forgiveness from the windows version). sorry for the noise cheers On Aug 6, 2011, at 12:29 PM, L Mihalkovic wrote: > As many people pointed out this is not a new issue, but a rather old one that has been pressed forward by the decision to turn some of the dormant optimizations on by default. If you look at the number of major issues Apple has with any new releases of their hardware/software and compare the reaction they trigger in the general public versus what happened in this case, then it is difficult not to draw the conclusion that there is way more going on here than simply technology? JDK 7 is not in production anywhere, and anyone with production responsibilities should be fired on the spot if they took the download and rolled it in prod without further validation in their environment. If there was not an established steady release train of future updates, then yes, I would share the opinion that releasing the JDK as-is was a major issue. But it is not the case, and there will be a number of regular releases that will address this and other issues that will undoubtedly surface? some will be new, and some will again be old issues pressed forward by recent decisions. I would rather have a somewhat work-in-progress released JDK with the a strong commitment to back it, rather than have to wait for another full year until all the kinks are hammered out. I don't like or dislike large corporations the like of Oracle or Apple, but I do have a tremendous amount of respect for the work the engineers at both companies are doing or a daily basis to work on the huge software project they work-on and regularly deliver.. bugs and all. > > Cheers > LM/ > > PS: speaking of bugs that you think might delay releases?. dragging this in-progress email on Lion causes parts of the window to be blurred whenever it touched the side of the screen? really annoying. > > On Aug 5, 2011, at 3:47 PM, Mario Torre wrote: > >> 2011/8/5 John Yeary : >>> As with any major release, there are bound to be bugs. However, the OpenJDK >>> project announced the release and freeze on the code for what would become >>> JDK 7. No one reported any major issues prior to launch. The folks on Apache >>> Lucene/Solr projects could have tested in advance of release and found these >>> issues. This may have prevented the on-time release. >>> >>> I am not blaming the Apache folks, or Oracle. As with any new software, you >>> need to test it. I have not been affected by the bug(s) reported, and can >>> happily continue on my computing way. The workarounds have been released, >>> use them until a fix is out, or alternatively wait and use JDK 6. As noted >>> in the article, these JVM options are disabled in 6 and the bug was present. >>> >>> >>> No one noticed this previously so I surmise that it is a mountain-mole hill >>> issue. >>> >>> John >> >> I also think this is "mountain-mole hill" and in general agree with you. >> >> I don't think that Apache should be responsible for testing OpenJDK bugs though. >> >> This specific issue seems to be quite tricky to get but I wonder if >> this should not have been spotted by the TCK? >> >> Cheers, >> Mario >> -- >> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF >> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF >> >> IcedRobot: www.icedrobot.org >> Proud GNU Classpath developer: http://www.classpath.org/ >> Read About us at: http://planet.classpath.org >> OpenJDK: http://openjdk.java.net/projects/caciocavallo/ >> >> Please, support open standards: >> http://endsoftpatents.org/ > From michael.x.mcmahon at oracle.com Sun Jan 29 12:15:02 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Sun, 29 Jan 2012 20:15:02 +0000 Subject: [jdk7u-osx] Request for approval for CR 7129308: Handle different format of OperatingSystemMXBean.getSystemLoadAverage() output on macosx Message-ID: <4F25A8C6.3040306@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129308 Webrev: http://cr.openjdk.java.net/~juh/7129308/webrev.00/ Author: juh Reviewed by: michaelm Thanks, Michael. From paul.hohensee at oracle.com Sun Jan 29 12:20:53 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Sun, 29 Jan 2012 15:20:53 -0500 Subject: [jdk7u-osx] Request for approval for CR 7129308: Handle different format of OperatingSystemMXBean.getSystemLoadAverage() output on macosx In-Reply-To: <4F25A8C6.3040306@oracle.com> References: <4F25A8C6.3040306@oracle.com> Message-ID: <4F25AA25.7060802@oracle.com> Approved. Paul On 1/29/12 3:15 PM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129308 > > Webrev: http://cr.openjdk.java.net/~juh/7129308/webrev.00/ > > Author: juh > > Reviewed by: michaelm > > Thanks, > Michael. From michael.x.mcmahon at oracle.com Sun Jan 29 12:23:54 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Sun, 29 Jan 2012 20:23:54 +0000 Subject: RFR: 7122794: (macosx) DatagramSocket.disconnect() not working Message-ID: <4F25AADA.6080005@oracle.com> Can I get the following webrev reviewed please. http://cr.openjdk.java.net/~michaelm/7122794/webrev.1/ Thanks, Michael From michael.x.mcmahon at oracle.com Sun Jan 29 12:33:29 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Sun, 29 Jan 2012 20:33:29 +0000 Subject: RFR 7132637: (dc) DatagramChannel multicast tests failing on MacOSX Message-ID: <4F25AD19.6040906@oracle.com> Can I get the following webrev reviewed please? http://cr.openjdk.java.net/~michaelm/7132637/webrev.1/ Thanks Michael From michael.x.mcmahon at oracle.com Sun Jan 29 12:38:05 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Sun, 29 Jan 2012 20:38:05 +0000 Subject: RFR: 7132679: (dc) DatagramChannel.send fails with ECONNREFUSED when not connected (Mac OSX) Message-ID: <4F25AE2D.7060709@oracle.com> Can I get the following webrev (contributed by Alan B) reviewed please? I have reviewed it already. http://cr.openjdk.java.net/~michaelm/7132679/webrev.1/ Thanks Michael. From michael.x.mcmahon at oracle.com Sun Jan 29 12:47:55 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Sun, 29 Jan 2012 20:47:55 +0000 Subject: RFR: 7139772: Implement asynchronous socket channel close on Macosx [Mac OS X] Message-ID: <4F25B07B.3020108@oracle.com> Can I get the following webrev reviewed please? (contributed by Alan B) http://cr.openjdk.java.net/~michaelm/7139772/webrev.1/ Thanks, Michael. From Alan.Bateman at oracle.com Sun Jan 29 12:55:32 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 29 Jan 2012 20:55:32 +0000 Subject: RFR: 7122794: (macosx) DatagramSocket.disconnect() not working In-Reply-To: <4F25AADA.6080005@oracle.com> References: <4F25AADA.6080005@oracle.com> Message-ID: <4F25B244.5090105@oracle.com> On 29/01/2012 20:23, Michael McMahon wrote: > Can I get the following webrev reviewed please. > > http://cr.openjdk.java.net/~michaelm/7122794/webrev.1/ Just so I understand, when connect(2) is used to break the association in the kernel doesn't revert to being unconnected? On the changes then adding a protected method to java.net.DatagramSocketImpl is an API change so I think any flag will need to be pushed down to PlainDatagramSocketImpl. -Alan. From Alan.Bateman at oracle.com Sun Jan 29 13:26:45 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 29 Jan 2012 21:26:45 +0000 Subject: RFR: 7132679: (dc) DatagramChannel.send fails with ECONNREFUSED when not connected (Mac OSX) In-Reply-To: <4F25AE2D.7060709@oracle.com> References: <4F25AE2D.7060709@oracle.com> Message-ID: <4F25B995.5030606@oracle.com> On 29/01/2012 20:38, Michael McMahon wrote: > Can I get the following webrev (contributed by Alan B) reviewed please? > I have reviewed it already. > > http://cr.openjdk.java.net/~michaelm/7132679/webrev.1/ Just as background to this one. Normally a UDP socket must connected in order to receive ICMP errors but on Mac they appear to be returned on unconnected sockets too. The patch simply ignores them when the socket is not connected. -Alan From michael.x.mcmahon at oracle.com Sun Jan 29 13:27:20 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Sun, 29 Jan 2012 21:27:20 +0000 Subject: RFR: 7139772: Implement asynchronous socket channel close on Macosx [Mac OS X] In-Reply-To: <4F25B07B.3020108@oracle.com> References: <4F25B07B.3020108@oracle.com> Message-ID: <4F25B9B8.6090104@oracle.com> Sorry, this change should have referred to CR: 7133499 (fc) FileChannel.read not preempted by asynchronous close on MacOSX Thanks, Michael * *On 29/01/12 20:47, Michael McMahon wrote: > Can I get the following webrev reviewed please? > (contributed by Alan B) > > http://cr.openjdk.java.net/~michaelm/7139772/webrev.1/ > > Thanks, > Michael. From Alan.Bateman at oracle.com Sun Jan 29 13:42:20 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 29 Jan 2012 21:42:20 +0000 Subject: RFR 7132637: (dc) DatagramChannel multicast tests failing on MacOSX In-Reply-To: <4F25AD19.6040906@oracle.com> References: <4F25AD19.6040906@oracle.com> Message-ID: <4F25BD3C.5040603@oracle.com> On 29/01/2012 20:33, Michael McMahon wrote: > Can I get the following webrev reviewed please? > > http://cr.openjdk.java.net/~michaelm/7132637/webrev.1/ Just as background to this. The javadoc is clear that support for source-specific multicast (both include mode and exclude mode) is optional. The changes in this webrev just mean that the block or 3-arg join methods will throw UOE. The return JNI_FALSE in canIPv6SocketJoinIPv4Group0 just means that DatagramChannels to IPv6 sockets can't join IPv4 groups, again something the javadoc is clear is not guaranteed to be supported. Michael - the changes are fine and identical to a patch that I have in my repo too. All I suggest is adding a comment to each ifdef so that readers know what is about. Also I would suggest intending in blockOrUnblock6 to make it easier to read. -Alan From michael.x.mcmahon at oracle.com Sun Jan 29 22:58:02 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 30 Jan 2012 06:58:02 +0000 Subject: 7133476: (fs) Files.readAttributes throws NPE In-Reply-To: <4F22AC12.9030308@oracle.com> References: <4F22AC12.9030308@oracle.com> Message-ID: <4F263F7A.7000500@oracle.com> On 27/01/12 13:52, Alan Bateman wrote: > > Currently Files.readAttributes throws NPE rather than UOE on Mac OS X > when invoked to read DOS attributes. This looks like an issue > introduced upstream in the BSD porting project. To fix this requires > removing BsdFileSystemProvider.readAttributes (the super class > implementation does the right thing already). While I was there I also > removed commented out code that should not be here. The webrev with > the changes is here: > > http://cr.openjdk.java.net/~alanb/7133476/webrev/ > > Thanks, > Alan. Looks good. Thanks, Michael From michael.x.mcmahon at oracle.com Sun Jan 29 23:38:00 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 30 Jan 2012 07:38:00 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7129308: Handle different format of OperatingSystemMXBean.getSystemLoadAverage() output on macosx Message-ID: <20120130073819.657A547277@hg.openjdk.java.net> Changeset: 789287639365 Author: juh Date: 2012-01-30 07:37 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/789287639365 7129308: Handle different format of OperatingSystemMXBean.getSystemLoadAverage() output on macosx Reviewed-by: michaelm ! test/java/lang/management/OperatingSystemMXBean/GetSystemLoadAverage.java From michael.x.mcmahon at oracle.com Sun Jan 29 23:44:10 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 30 Jan 2012 07:44:10 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7134690: remove legacy jnilib support from ClassLoader and System [macosx] Message-ID: <20120130074420.BC6A747278@hg.openjdk.java.net> Changeset: 7929ac999cde Author: michaelm Date: 2012-01-30 07:43 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/7929ac999cde 7134690: remove legacy jnilib support from ClassLoader and System [macosx] Reviewed-by: alanb ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/System.java From michael.x.mcmahon at oracle.com Sun Jan 29 23:58:42 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 30 Jan 2012 07:58:42 +0000 Subject: RFR: 7122794: (macosx) DatagramSocket.disconnect() not working In-Reply-To: <4F25AADA.6080005@oracle.com> References: <4F25AADA.6080005@oracle.com> Message-ID: <4F264DB2.7080606@oracle.com> I have updated this webrev because the original one was unintentionally modifying a public API. The change is the same, but pushed down to an implementation class. http://cr.openjdk.java.net/~michaelm/7122794/webrev.3/ Thanks Michael On 29/01/12 20:23, Michael McMahon wrote: > Can I get the following webrev reviewed please. > > http://cr.openjdk.java.net/~michaelm/7122794/webrev.1/ > > Thanks, > Michael From michael.x.mcmahon at oracle.com Mon Jan 30 00:18:26 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 30 Jan 2012 08:18:26 +0000 Subject: [jdk7u-osx] Request for approval for CR 7132637 (dc) DatagramChannel multicast tests failing on MacOSX Message-ID: <4F265252.10101@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132637 Webrev: http://cr.openjdk.java.net/~michaelm/7132637/webrev.2/ Reviewed by: alanb Thanks, Michael. From michael.x.mcmahon at oracle.com Mon Jan 30 00:23:08 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 30 Jan 2012 08:23:08 +0000 Subject: [jdk7u-osx] Request for approval for CR 7132679: Message-ID: <4F26536C.5000507@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132679 Webrev: http://cr.openjdk.java.net/~michaelm/7132679/webrev.1/ Author: alanb Reviewed by: michaelm Thanks, Michael. From michael.x.mcmahon at oracle.com Mon Jan 30 00:38:01 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 30 Jan 2012 08:38:01 +0000 Subject: RFR: 7133499 (fc) FileChannel.read not preempted by asynchronous close on MacOSX Message-ID: <4F2656E9.9060907@oracle.com> Can I get the following webrev reviewed please? (author Alan Bateman). I have reviewed it already http://cr.openjdk.java.net/~michaelm/7139772/webrev.1/ Thanks, Michael. From dmitry.cherepanov at oracle.com Mon Jan 30 01:50:36 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 30 Jan 2012 12:50:36 +0300 Subject: Review request for 7131793: [macosx] some cleanup in OGL pipeline code In-Reply-To: <15184530-A44F-45DB-B1A8-FC890521D635@apple.com> References: <4F22BFF0.406@oracle.com> <15184530-A44F-45DB-B1A8-FC890521D635@apple.com> Message-ID: <4F2667EC.6000602@oracle.com> Mike Swingler wrote: > On Jan 27, 2012, at 7:17 AM, Dmitry Cherepanov wrote: > >> Hello, >> >> Here's some changes to remove some stale code from the OGL pipeline. >> This code has been introduced as a part of the initial implementation >> for CALayer-based rendering and disabled by the changes for >> MACOSX_PORT-766. >> > > One tiny detail: I'd recommend using -jObjectWithEnv: instead of > -jObject here (because it's a little faster to not re-fetch the env): > + JNFCallVoidMethod(env, [self.javaLayer jObject], jm_drawInCGLContext); Thanks for the suggestion. Here's the new webrev: http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.2/ Thanks, Dmitry > > I'm very glad to see this code getting shorter, and using a > retain/release wrapper around the JNI global refs. > > Looks great, > Mike Swingler > Apple Inc. > From dmitry.cherepanov at oracle.com Mon Jan 30 01:54:56 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 30 Jan 2012 12:54:56 +0300 Subject: [7u-osx] Request for approval for 7131793: [macosx] some cleanup in OGL pipeline code Message-ID: <4F2668F0.4030703@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131793 Webrev: http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.2 Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002537.html Thanks, Dmitry From sergey.bylokhov at oracle.com Mon Jan 30 01:44:55 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 30 Jan 2012 13:44:55 +0400 Subject: [7u-osx] Request for approval for 7131793: [macosx] some cleanup in OGL pipeline code In-Reply-To: <4F2668F0.4030703@oracle.com> References: <4F2668F0.4030703@oracle.com> Message-ID: <4F266697.8070300@oracle.com> Hi Dmitry, I have a question about CGLLayer.m 124JNFCallVoidMethod(env, [self.javaLayer jObjectWithEnv:env], jm_drawInCGLContext); Should we delete a local reference which returned from [self.javaLayer jObjectWithEnv:env]? And check it for null? 30.01.2012 13:54, Dmitry Cherepanov wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131793 > > Webrev: http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.2 > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002537.html > > Thanks, > Dmitry -- Best regards, Sergey. From michael.x.mcmahon at oracle.com Mon Jan 30 01:48:17 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 30 Jan 2012 09:48:17 +0000 Subject: RFR: 7139770: MacOS JCK failures in DatagramSocket and MulticastSocket Message-ID: <4F266761.1060106@oracle.com> Can I get the following webrev reviewed please? http://cr.openjdk.java.net/~michaelm/7139770/webrev.1/ There are two issues. In DatagramSocket the change uses the peekData() api when available, instead of peek(), which in fact doesn't work at all with our own PlainDatagramSocketImpl (it tries to compare InetAddress instances with Inet4Addresses, which always fails, and it only supports IPv4) In MulticastSocket I adjusted the recently added code which sets a default interface. The default interface only needs to be set just prior to joining a multicast group, and then only if an interface has not been set previously. Thanks Michael. From sergey.bylokhov at oracle.com Mon Jan 30 01:52:05 2012 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 30 Jan 2012 13:52:05 +0400 Subject: [7u-osx] Request for approval for 7131793: [macosx] some cleanup in OGL pipeline code In-Reply-To: <4F266697.8070300@oracle.com> References: <4F2668F0.4030703@oracle.com> <4F266697.8070300@oracle.com> Message-ID: <4F266845.8080507@oracle.com> 30.01.2012 13:44, Sergey Bylokhov wrote: > Hi Dmitry, > I have a question about CGLLayer.m > > 124JNFCallVoidMethod(env, [self.javaLayer jObjectWithEnv:env], > jm_drawInCGLContext); > > Should we delete a local reference which returned from [self.javaLayer > jObjectWithEnv:env]? And check it for null? JNFJObjectWrapper.h ...... - (jobject) jObjectWithEnv:(JNIEnv *)env; // returns a new local-ref, must be released with DeleteLocalRef ...... > > > 30.01.2012 13:54, Dmitry Cherepanov wrote: >> This is a request to push the following fix to jdk7u-osx: >> >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131793 >> >> Webrev: http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.2 >> >> Technical review: >> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002537.html >> >> Thanks, >> Dmitry > > -- Best regards, Sergey. From Alan.Bateman at oracle.com Mon Jan 30 02:00:17 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Jan 2012 10:00:17 +0000 Subject: [7u-osx] Request for approval for 7133476: (fs) Files.readAttributes throws NPE Message-ID: <4F266A31.6090403@oracle.com> This is a request to push to the jdk7u/jdk7u-osx forest. CR: http://bugs.sun.com/view_bug.do?bug_id=7133476 Webrev: http://cr.openjdk.java.net/~alanb/7133476/webrev/ Reviewed by: michaelm Thanks, Alan. From michael.x.mcmahon at oracle.com Mon Jan 30 02:00:26 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 30 Jan 2012 10:00:26 +0000 Subject: RFR: 7132699 [macosx] Proxy using for connection to localhost Message-ID: <4F266A3A.5050703@oracle.com> Can I get the following webrev reviewed please? http://cr.openjdk.java.net/~michaelm/7132699/webrev.1/ On Mac, we read the system proxy settings and by default the system sets a proxy bypass list. Unfortunately, this default list doesn't contain some entries (like localhost) which we depend on to be bypassed. So, the fix is to include our own default list together with any additional ones provided by the system. Thanks, Michael. From chris.hegarty at oracle.com Mon Jan 30 02:27:35 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Jan 2012 10:27:35 +0000 Subject: Fwd: Re: RFR: 7122794: (macosx) DatagramSocket.disconnect() not working In-Reply-To: <4F266792.9030907@oracle.com> References: <4F264DB2.7080606@oracle.com> <4F266792.9030907@oracle.com> Message-ID: <4F267097.5000006@oracle.com> Michael, Is it possible to initialize connectDisabled at the Java level using the os.name system property, rather than in native. We do this in other places in the impls ( albeit not for Mac yet ). -Chris. On 30/01/2012 09:49, Alan Bateman wrote: > ..... > > I have updated this webrev because the original one was unintentionally > modifying a public API. The change is the same, but pushed down to an > implementation class. > > http://cr.openjdk.java.net/~michaelm/7122794/webrev.3/ > > Thanks > Michael > > On 29/01/12 20:23, Michael McMahon wrote: >> Can I get the following webrev reviewed please. >> >> http://cr.openjdk.java.net/~michaelm/7122794/webrev.1/ >> >> Thanks, >> Michael > > From anton.tarasov at oracle.com Mon Jan 30 03:42:43 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 30 Jan 2012 14:42:43 +0300 Subject: Review request for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner Message-ID: <4F268233.3090707@oracle.com> Hello, Please review a fix for 7129732. webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ When a focused simple window is getting closed, focus should be transferred to the owner. Thanks, Anton. From artem.ananiev at oracle.com Mon Jan 30 02:51:52 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 30 Jan 2012 14:51:52 +0400 Subject: Review request for 7132809: [macosx] MAXIMIZED_BOTH set before setVisible(true) hides Frame In-Reply-To: <4F21743C.8020709@oracle.com> References: <4F21743C.8020709@oracle.com> Message-ID: <4F267648.7010700@oracle.com> Hi, Anthony, the fix looks fine. A minor comment: can we use peer.getState() instead of (instanceof check + target.getExtendedState()) in CPlatformWindow.setVisible()? Thanks, Artem On 1/26/2012 7:41 PM, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7132809 at: > > http://cr.openjdk.java.net/~anthony/x-11-MaximizedBoth-7132809.0/ > > We shouldn't apply the extended state when a window is hidden. With this > fix the CPlatformWindow.setVisible() re-applies the state when the > window gets shown. > > -- > best regards, > Anthony From alexander.zuev at oracle.com Mon Jan 30 03:51:38 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 30 Jan 2012 14:51:38 +0300 Subject: Code Review Request for CR 7132367 - [macosx] ChoiceMouseWheelTest should be adapted for mac toolkit In-Reply-To: <4F22E1C5.2000804@oracle.com> References: <4F22E1C5.2000804@oracle.com> Message-ID: <4F26844A.2000707@oracle.com> Looks good to me. Approved. On 1/27/12 20:41, Oleg Pekhovskiy wrote: > Hi guys, > > Here is the description of CR: > http://bt2ws.central.sun.com/CrPrint?id=7132367 > > Patch with changes attached. > > Description of the fix: > Now this test skips mouse wheeling check over combobox on Mac JDK7 > with LWCTookit. > > Thanks, > Oleg. From alexander.zuev at oracle.com Mon Jan 30 03:54:31 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 30 Jan 2012 14:54:31 +0300 Subject: review request for 7124399: [macosx] All Swing drag-n-drop tests faild Message-ID: <4F2684F7.2090505@oracle.com> Hello, please review my fix for 7124399: [macosx] All Swing drag-n-drop tests faild Bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124399 Diffs can be found here: http://cr.openjdk.java.net/~kizune/7124399/webrev.00 The idea of the fix is to accurately tracking component entering and leaving and send the corresponding listeners dragRnter/dragExit events. With best regards, Alexander Zuev From artem.ananiev at oracle.com Mon Jan 30 02:58:04 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 30 Jan 2012 14:58:04 +0400 Subject: Code Review Request for CR 7132367 - [macosx] ChoiceMouseWheelTest should be adapted for mac toolkit In-Reply-To: <4F22E1C5.2000804@oracle.com> References: <4F22E1C5.2000804@oracle.com> Message-ID: <4F2677BC.1070209@oracle.com> On 1/27/2012 9:41 PM, Oleg Pekhovskiy wrote: > Hi guys, > > Here is the description of CR: > http://bt2ws.central.sun.com/CrPrint?id=7132367 Here is the right URL: http://bugs.sun.com/view_bug.do?bug_id=7132367 > Patch with changes attached. The fix looks fine. Could you also adjust the comment (and move it to the next line to not exceed 80 chars limit) to mention Mac, please? From the bug evaluation, I see that the test still fails on Mac when mouse wheel is rotated over Choice's drop-down list. Is it correct? Is there a bug filed about it? Thanks, Artem > Description of the fix: > Now this test skips mouse wheeling check over combobox on Mac JDK7 with > LWCTookit. > > Thanks, > Oleg. From dmitry.cherepanov at oracle.com Mon Jan 30 04:06:24 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 30 Jan 2012 15:06:24 +0300 Subject: Review request for 7129825 - [macosx] Native activation is not changed when focusing other frame's owned window In-Reply-To: <4F1ECCE2.4030509@oracle.com> References: <4F1ECCE2.4030509@oracle.com> Message-ID: <4F2687C0.2090703@oracle.com> Hi Anton, The fix looks fine to me. Just one comment - the fix introduces new isActive method in the PlatformWindow interface (and removes parameters from requestWindowFocus). Could you please add some implementation into the CPlatformEmbeddedFrame class (simply returning true should be fine) as the class implements the PlatformWindow interface. Thanks, Dmitry Anton V. Tarasov wrote: > Hello, > > Please review a fix for 7129825. > > webrev: http://cr.openjdk.java.net/~ant/7129825/webrev.0/ > > The fix contains the following changes: > > 1. When a simple window requests focus its owner is properly activated. > > 2. The code that requests focus on a window from LWWindowPeer > initial mouse handler is removed. It duplicates the logic implemented > by LWWindowPeer.handleEvent(). Additionally, a window requests focus > when its unfocusable component is clicked, or its empty spot is clicked. > In this case KeyboardFocusManager sets focus on the window's default > component. > > 3. The nativeIsApplicationActive() method is moved to LWToolkit. > > 4. Two native methods are changed to be called synchronously > (performOnMainThreadWaiting:YES) as they are called from EDT. > > 5. Some minor changes. > > Tested with test/java/awt/Focus/* against regressions. > > Thanks, > Anton. > > From Alan.Bateman at oracle.com Mon Jan 30 03:07:04 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Jan 2012 11:07:04 +0000 Subject: RFR: 7132699 [macosx] Proxy using for connection to localhost In-Reply-To: <4F266A3A.5050703@oracle.com> References: <4F266A3A.5050703@oracle.com> Message-ID: <4F2679D8.9000609@oracle.com> On 30/01/2012 10:00, Michael McMahon wrote: > Can I get the following webrev reviewed please? > > http://cr.openjdk.java.net/~michaelm/7132699/webrev.1/ > > On Mac, we read the system proxy settings and > by default the system sets a proxy bypass list. Unfortunately, this > default list doesn't contain some entries (like localhost) which we > depend > on to be bypassed. So, the fix is to include our own default list > together with > any additional ones provided by the system. I think looks okay and should be safe to use on all platforms (meaning the startsWith("Mac OS") check can be removed). It would be good to get this fix quickly too as that will resolve test failures all over the map that stem from http connections to localhost. -Alan. From alexander.zuev at oracle.com Mon Jan 30 04:09:28 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 30 Jan 2012 15:09:28 +0300 Subject: Code Review Request for CR 7132367 - [macosx] ChoiceMouseWheelTest should be adapted for mac toolkit In-Reply-To: <4F2677BC.1070209@oracle.com> References: <4F22E1C5.2000804@oracle.com> <4F2677BC.1070209@oracle.com> Message-ID: <4F268878.8030103@oracle.com> On 1/30/12 13:58, Artem Ananiev wrote: > > On 1/27/2012 9:41 PM, Oleg Pekhovskiy wrote: >> Hi guys, >> >> Here is the description of CR: >> http://bt2ws.central.sun.com/CrPrint?id=7132367 > > Here is the right URL: > > http://bugs.sun.com/view_bug.do?bug_id=7132367 > >> Patch with changes attached. > > The fix looks fine. Could you also adjust the comment (and move it to > the next line to not exceed 80 chars limit) to mention Mac, please? > > From the bug evaluation, I see that the test still fails on Mac when > mouse wheel is rotated over Choice's drop-down list. Is it correct? Is > there a bug filed about it? Not sure about filed bug but it definitely a regression from apple's jdk6 - when mouse wheel rotated upon the opened combobox popup it is being immediately closed. If there's no such bug in database we have for submit one. > > Thanks, > > Artem > >> Description of the fix: >> Now this test skips mouse wheeling check over combobox on Mac JDK7 with >> LWCTookit. >> >> Thanks, >> Oleg. From michael.x.mcmahon at oracle.com Mon Jan 30 03:52:24 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 30 Jan 2012 11:52:24 +0000 Subject: Fwd: Re: RFR: 7122794: (macosx) DatagramSocket.disconnect() not working In-Reply-To: <4F267097.5000006@oracle.com> References: <4F264DB2.7080606@oracle.com> <4F266792.9030907@oracle.com> <4F267097.5000006@oracle.com> Message-ID: <4F268478.9050102@oracle.com> Chris, Yes, that is more readable. I've updated the webrev here: http://cr.openjdk.java.net/~michaelm/7122794/webrev.4/ Thanks Michael. On 30/01/12 10:27, Chris Hegarty wrote: > Michael, > > Is it possible to initialize connectDisabled at the Java level using > the os.name system property, rather than in native. We do this in > other places in the impls ( albeit not for Mac yet ). > > -Chris. > > On 30/01/2012 09:49, Alan Bateman wrote: >> ..... >> >> I have updated this webrev because the original one was unintentionally >> modifying a public API. The change is the same, but pushed down to an >> implementation class. >> >> http://cr.openjdk.java.net/~michaelm/7122794/webrev.3/ >> >> Thanks >> Michael >> >> On 29/01/12 20:23, Michael McMahon wrote: >>> Can I get the following webrev reviewed please. >>> >>> http://cr.openjdk.java.net/~michaelm/7122794/webrev.1/ >>> >>> Thanks, >>> Michael >> >> From anton.tarasov at oracle.com Mon Jan 30 04:03:06 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 30 Jan 2012 16:03:06 +0400 Subject: Review request for 7129825 - [macosx] Native activation is not changed when focusing other frame's owned window In-Reply-To: <4F2687C0.2090703@oracle.com> References: <4F1ECCE2.4030509@oracle.com> <4F2687C0.2090703@oracle.com> Message-ID: <4F2686FA.80008@oracle.com> On 30.01.2012 16:06, Dmitry Cherepanov wrote: > Hi Anton, > > The fix looks fine to me. Just one comment - the fix introduces new isActive method in the > PlatformWindow interface (and removes parameters from requestWindowFocus). Could you please add > some implementation into the CPlatformEmbeddedFrame class (simply returning true should be fine) > as the class implements the PlatformWindow interface. Sure, I missed it. Here's the updated version: http://cr.openjdk.java.net/~ant/7129825/webrev.1/ Thanks! Anton. > > Thanks, > Dmitry > > Anton V. Tarasov wrote: >> Hello, >> >> Please review a fix for 7129825. >> >> webrev: http://cr.openjdk.java.net/~ant/7129825/webrev.0/ >> >> The fix contains the following changes: >> >> 1. When a simple window requests focus its owner is properly activated. >> >> 2. The code that requests focus on a window from LWWindowPeer >> initial mouse handler is removed. It duplicates the logic implemented >> by LWWindowPeer.handleEvent(). Additionally, a window requests focus >> when its unfocusable component is clicked, or its empty spot is clicked. >> In this case KeyboardFocusManager sets focus on the window's default >> component. >> >> 3. The nativeIsApplicationActive() method is moved to LWToolkit. >> >> 4. Two native methods are changed to be called synchronously >> (performOnMainThreadWaiting:YES) as they are called from EDT. >> >> 5. Some minor changes. >> >> Tested with test/java/awt/Focus/* against regressions. >> >> Thanks, >> Anton. >> >> > From michael.x.mcmahon at oracle.com Mon Jan 30 04:03:58 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 30 Jan 2012 12:03:58 +0000 Subject: [jdk7u-osx] Request for approval for CR 7132699 [macosx] Proxy using for connection to localhost Message-ID: <4F26872E.2010603@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132699 Webrev: http://cr.openjdk.java.net/~michaelm/7132699/webrev.2/ Reviewed by: alanb Thanks, Michael. From anton.tarasov at oracle.com Mon Jan 30 04:05:13 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 30 Jan 2012 16:05:13 +0400 Subject: Review request for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner In-Reply-To: <4F268233.3090707@oracle.com> References: <4F268233.3090707@oracle.com> Message-ID: <4F268779.6040909@oracle.com> A question to the reviewers. Do we still need to invoke on EDT? 236 // it is important to call this method on EDT 237 // to prevent the deadlocks during the painting of the lightweight delegates 238 //TODO: WHY? This is a native-system related call. Perhaps NOT calling 239 // the painting procedure right from the setVisible(), but rather relying 240 // on the native Expose event (or, scheduling the repainting asynchronously) 241 // is better? 242 SwingUtilities.invokeLater(new Runnable() { 243 @Override 244 public void run() { 245 platformWindow.setVisible(visible); Thanks, Anton. On 30.01.2012 15:42, Anton V. Tarasov wrote: > Hello, > > Please review a fix for 7129732. > > webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ > > When a focused simple window is getting closed, focus should be > transferred to the owner. > > Thanks, > Anton. > > From chris.hegarty at oracle.com Mon Jan 30 04:29:08 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Jan 2012 12:29:08 +0000 Subject: Fwd: Re: RFR: 7122794: (macosx) DatagramSocket.disconnect() not working In-Reply-To: <4F268478.9050102@oracle.com> References: <4F264DB2.7080606@oracle.com> <4F266792.9030907@oracle.com> <4F267097.5000006@oracle.com> <4F268478.9050102@oracle.com> Message-ID: <4F268D14.7000004@oracle.com> Looks good, Thanks Michael. -Chris. On 30/01/2012 11:52, Michael McMahon wrote: > Chris, > > Yes, that is more readable. I've updated the webrev here: > > http://cr.openjdk.java.net/~michaelm/7122794/webrev.4/ > > Thanks > Michael. > > On 30/01/12 10:27, Chris Hegarty wrote: >> Michael, >> >> Is it possible to initialize connectDisabled at the Java level using >> the os.name system property, rather than in native. We do this in >> other places in the impls ( albeit not for Mac yet ). >> >> -Chris. >> >> On 30/01/2012 09:49, Alan Bateman wrote: >>> ..... >>> >>> I have updated this webrev because the original one was unintentionally >>> modifying a public API. The change is the same, but pushed down to an >>> implementation class. >>> >>> http://cr.openjdk.java.net/~michaelm/7122794/webrev.3/ >>> >>> Thanks >>> Michael >>> >>> On 29/01/12 20:23, Michael McMahon wrote: >>>> Can I get the following webrev reviewed please. >>>> >>>> http://cr.openjdk.java.net/~michaelm/7122794/webrev.1/ >>>> >>>> Thanks, >>>> Michael >>> >>> > From dmitry.cherepanov at oracle.com Mon Jan 30 05:59:11 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 30 Jan 2012 16:59:11 +0300 Subject: Review request for 7131793: [macosx] some cleanup in OGL pipeline code In-Reply-To: <15184530-A44F-45DB-B1A8-FC890521D635@apple.com> References: <4F22BFF0.406@oracle.com> <15184530-A44F-45DB-B1A8-FC890521D635@apple.com> Message-ID: <4F26A22F.9060001@oracle.com> Mike Swingler wrote: > On Jan 27, 2012, at 7:17 AM, Dmitry Cherepanov wrote: > >> Hello, >> >> Here's some changes to remove some stale code from the OGL pipeline. >> This code has been introduced as a part of the initial implementation >> for CALayer-based rendering and disabled by the changes for >> MACOSX_PORT-766. >> >> http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.1/ >> > > One tiny detail: I'd recommend using -jObjectWithEnv: instead of > -jObject here (because it's a little faster to not re-fetch the env): > + JNFCallVoidMethod(env, [self.javaLayer jObject], jm_drawInCGLContext); On second thought, seems like -jObject simply returns the global reference that the wrapper holds without obtaining the env. What's the reason for re-fetching the env? Thanks, Dmitry From michael.x.mcmahon at oracle.com Mon Jan 30 05:05:16 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 30 Jan 2012 13:05:16 +0000 Subject: [jdk7u-osx] Request for approval for CR 7122794: (macosx) DatagramSocket.disconnect() not working Message-ID: <4F26958C.9020401@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122794 Webrev: http://cr.openjdk.java.net/~michaelm/7122794/webrev.4/ Reviewed by: chegar Thanks, Michael. From paul.hohensee at oracle.com Mon Jan 30 05:35:47 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 30 Jan 2012 08:35:47 -0500 Subject: [jdk7u-osx] Request for approval for CR 7132637 (dc) DatagramChannel multicast tests failing on MacOSX In-Reply-To: <4F265252.10101@oracle.com> References: <4F265252.10101@oracle.com> Message-ID: <4F269CB3.1040504@oracle.com> Approved. Paul On 1/30/12 3:18 AM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132637 > > Webrev: http://cr.openjdk.java.net/~michaelm/7132637/webrev.2/ > > Reviewed by: alanb > > Thanks, > Michael. From paul.hohensee at oracle.com Mon Jan 30 05:36:22 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 30 Jan 2012 08:36:22 -0500 Subject: [jdk7u-osx] Request for approval for CR 7132679: In-Reply-To: <4F26536C.5000507@oracle.com> References: <4F26536C.5000507@oracle.com> Message-ID: <4F269CD6.6070307@oracle.com> Approved. Paul On 1/30/12 3:23 AM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132679 > > Webrev: http://cr.openjdk.java.net/~michaelm/7132679/webrev.1/ > > Author: alanb > > Reviewed by: michaelm > > Thanks, > Michael. From paul.hohensee at oracle.com Mon Jan 30 05:40:20 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 30 Jan 2012 08:40:20 -0500 Subject: [7u-osx] Request for approval for 7133476: (fs) Files.readAttributes throws NPE In-Reply-To: <4F266A31.6090403@oracle.com> References: <4F266A31.6090403@oracle.com> Message-ID: <4F269DC4.5080702@oracle.com> Approved. Paul On 1/30/12 5:00 AM, Alan Bateman wrote: > This is a request to push to the jdk7u/jdk7u-osx forest. > > CR: http://bugs.sun.com/view_bug.do?bug_id=7133476 > > Webrev: http://cr.openjdk.java.net/~alanb/7133476/webrev/ > > Reviewed by: michaelm > > Thanks, > Alan. From paul.hohensee at oracle.com Mon Jan 30 05:41:07 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 30 Jan 2012 08:41:07 -0500 Subject: [jdk7u-osx] Request for approval for CR 7132699 [macosx] Proxy using for connection to localhost In-Reply-To: <4F26872E.2010603@oracle.com> References: <4F26872E.2010603@oracle.com> Message-ID: <4F269DF3.7000103@oracle.com> Approved. Paul On 1/30/12 7:03 AM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132699 > > Webrev: http://cr.openjdk.java.net/~michaelm/7132699/webrev.2/ > > Reviewed by: alanb > > Thanks, > Michael. From michael.x.mcmahon at oracle.com Mon Jan 30 05:41:17 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 30 Jan 2012 13:41:17 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7132637: (dc) DatagramChannel multicast tests failing on MacOSX Message-ID: <20120130134136.3915A47285@hg.openjdk.java.net> Changeset: 63b6953bbcfa Author: michaelm Date: 2012-01-30 13:40 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/63b6953bbcfa 7132637: (dc) DatagramChannel multicast tests failing on MacOSX Reviewed-by: alanb ! src/solaris/native/sun/nio/ch/Net.c From paul.hohensee at oracle.com Mon Jan 30 05:42:04 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 30 Jan 2012 08:42:04 -0500 Subject: [jdk7u-osx] Request for approval for CR 7122794: (macosx) DatagramSocket.disconnect() not working In-Reply-To: <4F26958C.9020401@oracle.com> References: <4F26958C.9020401@oracle.com> Message-ID: <4F269E2C.1040409@oracle.com> Approved. Paul On 1/30/12 8:05 AM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122794 > > Webrev: http://cr.openjdk.java.net/~michaelm/7122794/webrev.4/ > > Reviewed by: chegar > > Thanks, > Michael. From michael.x.mcmahon at oracle.com Mon Jan 30 05:44:12 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 30 Jan 2012 13:44:12 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7132679: (dc) DatagramChannel.send fails with ECONNREFUSED when not connected (Mac OSX) Message-ID: <20120130134422.573CA47286@hg.openjdk.java.net> Changeset: 6f7d14fd7d8f Author: alanb Date: 2012-01-30 13:43 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/6f7d14fd7d8f 7132679: (dc) DatagramChannel.send fails with ECONNREFUSED when not connected (Mac OSX) Reviewed-by: michaelm ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java From michael.x.mcmahon at oracle.com Mon Jan 30 05:48:00 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 30 Jan 2012 13:48:00 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7132699: [macosx] Proxy using for connection to localhost Message-ID: <20120130134810.57A2647287@hg.openjdk.java.net> Changeset: d476c80173a3 Author: michaelm Date: 2012-01-30 13:47 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d476c80173a3 7132699: [macosx] Proxy using for connection to localhost Reviewed-by: alanb ! src/share/classes/sun/net/spi/DefaultProxySelector.java From michael.x.mcmahon at oracle.com Mon Jan 30 05:50:19 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 30 Jan 2012 13:50:19 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7122794: (macosx) DatagramSocket.disconnect() not working Message-ID: <20120130135029.ECF4247288@hg.openjdk.java.net> Changeset: 926b1d1014cf Author: michaelm Date: 2012-01-30 13:49 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/926b1d1014cf 7122794: (macosx) DatagramSocket.disconnect() not working Reviewed-by: chegar ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/DatagramSocket.java From alan.bateman at oracle.com Mon Jan 30 05:53:35 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 30 Jan 2012 13:53:35 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7133476: (fs) Files.readAttributes throws NPE on MacOSX Message-ID: <20120130135346.A33E647289@hg.openjdk.java.net> Changeset: ebeb9c8e0bb8 Author: alanb Date: 2012-01-30 13:52 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/ebeb9c8e0bb8 7133476: (fs) Files.readAttributes throws NPE on MacOSX Reviewed-by: michaelm ! src/solaris/classes/sun/nio/fs/BsdFileStore.java ! src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java From chris.hegarty at oracle.com Mon Jan 30 06:11:54 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Jan 2012 14:11:54 +0000 Subject: RFR: 7139770: MacOS JCK failures in DatagramSocket and MulticastSocket In-Reply-To: <4F266761.1060106@oracle.com> References: <4F266761.1060106@oracle.com> Message-ID: <4F26A52A.9020205@oracle.com> Looks ok to me. -Chris. On 30/01/2012 09:48, Michael McMahon wrote: > Can I get the following webrev reviewed please? > > http://cr.openjdk.java.net/~michaelm/7139770/webrev.1/ > > There are two issues. In DatagramSocket the change uses the peekData() > api when available, instead of peek(), which in fact doesn't work at all > with our own PlainDatagramSocketImpl (it tries to compare InetAddress > instances > with Inet4Addresses, which always fails, and it only supports IPv4) > > In MulticastSocket I adjusted the recently added code which sets > a default interface. The default interface only needs to be set just prior > to joining a multicast group, and then only if an interface has not been > set previously. > > Thanks > Michael. From anthony.petrov at oracle.com Mon Jan 30 06:15:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 30 Jan 2012 18:15:49 +0400 Subject: Review request for 7132809: [macosx] MAXIMIZED_BOTH set before setVisible(true) hides Frame In-Reply-To: <4F267648.7010700@oracle.com> References: <4F21743C.8020709@oracle.com> <4F267648.7010700@oracle.com> Message-ID: <4F26A615.5050201@oracle.com> Hi Artem, Thanks for the review. On 01/30/12 14:51, Artem Ananiev wrote: > the fix looks fine. > > A minor comment: can we use peer.getState() instead of (instanceof check > + target.getExtendedState()) in CPlatformWindow.setVisible()? The LWWindowPeer.getState() returns the LWWindowPeer.windowState field that gets updated only from native notifications (notifyIconify()/notifyZoom()). While the window is hidden, the state isn't changed, and as such the notifications aren't sent which makes the windowState field value stale. As soon as the CPlatformWindow.setVisible(true) is called it needs to read the real current state of the frame, and since the peer's cached value is wrong, we read the state from the target. -- best regards, Anthony > > Thanks, > > Artem > > On 1/26/2012 7:41 PM, Anthony Petrov wrote: >> Hello, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7132809 >> at: >> >> http://cr.openjdk.java.net/~anthony/x-11-MaximizedBoth-7132809.0/ >> >> We shouldn't apply the extended state when a window is hidden. With this >> fix the CPlatformWindow.setVisible() re-applies the state when the >> window gets shown. >> >> -- >> best regards, >> Anthony From anthony.petrov at oracle.com Mon Jan 30 06:18:04 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 30 Jan 2012 18:18:04 +0400 Subject: [7u-osx] Request for approval for 7132809: [macosx] MAXIMIZED_BOTH set before setVisible(true) hides Frame Message-ID: <4F26A69C.503@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132809 http://cr.openjdk.java.net/~anthony/x-11-MaximizedBoth-7132809.0/ Technical review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002500.html -- best regards, Anthony From michael.x.mcmahon at oracle.com Mon Jan 30 06:24:11 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 30 Jan 2012 14:24:11 +0000 Subject: [jdk7u-osx] Request for approval for CR 7139770 MacOS JCK failures in DatagramSocket and MulticastSocket Message-ID: <4F26A80B.8060505@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7139770 Webrev: http://cr.openjdk.java.net/~michaelm/7139770/webrev.1/ Reviewed by: chegar Thanks, Michael. From artem.ananiev at oracle.com Mon Jan 30 06:41:03 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 30 Jan 2012 18:41:03 +0400 Subject: Review request for 7132809: [macosx] MAXIMIZED_BOTH set before setVisible(true) hides Frame In-Reply-To: <4F26A615.5050201@oracle.com> References: <4F21743C.8020709@oracle.com> <4F267648.7010700@oracle.com> <4F26A615.5050201@oracle.com> Message-ID: <4F26ABFF.4030604@oracle.com> On 1/30/2012 6:15 PM, Anthony Petrov wrote: > Hi Artem, > > Thanks for the review. > > On 01/30/12 14:51, Artem Ananiev wrote: >> the fix looks fine. >> >> A minor comment: can we use peer.getState() instead of (instanceof check >> + target.getExtendedState()) in CPlatformWindow.setVisible()? > > The LWWindowPeer.getState() returns the LWWindowPeer.windowState field > that gets updated only from native notifications > (notifyIconify()/notifyZoom()). While the window is hidden, the state > isn't changed, and as such the notifications aren't sent which makes the > windowState field value stale. I'm not sure about it. What I see is that LWWindowPeer.setState() is called from Frame: FramePeer peer = (FramePeer)this.peer; if (peer != null) { peer.setState(state); } At the same time, I don't see where LWWindowPeer.setState() is called from CPlatformWindow. Thanks, Artem > As soon as the CPlatformWindow.setVisible(true) is called it needs to > read the real current state of the frame, and since the peer's cached > value is wrong, we read the state from the target. > > -- > best regards, > Anthony > >> >> Thanks, >> >> Artem >> >> On 1/26/2012 7:41 PM, Anthony Petrov wrote: >>> Hello, >>> >>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7132809 >>> at: >>> >>> http://cr.openjdk.java.net/~anthony/x-11-MaximizedBoth-7132809.0/ >>> >>> We shouldn't apply the extended state when a window is hidden. With this >>> fix the CPlatformWindow.setVisible() re-applies the state when the >>> window gets shown. >>> >>> -- >>> best regards, >>> Anthony From anthony.petrov at oracle.com Mon Jan 30 06:42:59 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 30 Jan 2012 18:42:59 +0400 Subject: Review request for 7132809: [macosx] MAXIMIZED_BOTH set before setVisible(true) hides Frame In-Reply-To: <4F26ABFF.4030604@oracle.com> References: <4F21743C.8020709@oracle.com> <4F267648.7010700@oracle.com> <4F26A615.5050201@oracle.com> <4F26ABFF.4030604@oracle.com> Message-ID: <4F26AC73.4070305@oracle.com> On 01/30/12 18:41, Artem Ananiev wrote: >>> A minor comment: can we use peer.getState() instead of (instanceof check >>> + target.getExtendedState()) in CPlatformWindow.setVisible()? >> >> The LWWindowPeer.getState() returns the LWWindowPeer.windowState field >> that gets updated only from native notifications >> (notifyIconify()/notifyZoom()). While the window is hidden, the state >> isn't changed, and as such the notifications aren't sent which makes the >> windowState field value stale. > > I'm not sure about it. What I see is that LWWindowPeer.setState() is > called from Frame: > > FramePeer peer = (FramePeer)this.peer; > if (peer != null) { > peer.setState(state); > } LWWindowPeer.setState() simply delegates to CPlatformWindow.setWindowState(). If the window is visible, this causes -zoom/-miniaturize native calls, and hence the notifications that results in LWWindowPeer.notifyZoom/notifyIconify() which finally update the LWWindowPeer.windowState. However, if the window is hidden, the CPlatformWindow.setWindowState() is basically a no-op. -- best regards, Anthony > At the same time, I don't see where LWWindowPeer.setState() is called > from CPlatformWindow. > > Thanks, > > Artem > >> As soon as the CPlatformWindow.setVisible(true) is called it needs to >> read the real current state of the frame, and since the peer's cached >> value is wrong, we read the state from the target. >> >> -- >> best regards, >> Anthony >> >>> >>> Thanks, >>> >>> Artem >>> >>> On 1/26/2012 7:41 PM, Anthony Petrov wrote: >>>> Hello, >>>> >>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7132809 >>>> at: >>>> >>>> http://cr.openjdk.java.net/~anthony/x-11-MaximizedBoth-7132809.0/ >>>> >>>> We shouldn't apply the extended state when a window is hidden. With >>>> this >>>> fix the CPlatformWindow.setVisible() re-applies the state when the >>>> window gets shown. >>>> >>>> -- >>>> best regards, >>>> Anthony From anthony.petrov at oracle.com Mon Jan 30 07:30:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 30 Jan 2012 19:30:22 +0400 Subject: Review request for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner In-Reply-To: <4F268779.6040909@oracle.com> References: <4F268233.3090707@oracle.com> <4F268779.6040909@oracle.com> Message-ID: <4F26B78E.9080002@oracle.com> Hi Anton, On 01/30/12 16:05, Anton V. Tarasov wrote: > A question to the reviewers. Do we still need to invoke on EDT? > 236 // it is important to call this method on EDT > 237 // to prevent the deadlocks during the painting of the lightweight > delegates > 238 //TODO: WHY? This is a native-system related call. Perhaps NOT calling > 239 // the painting procedure right from the setVisible(), but rather > relying > 240 // on the native Expose event (or, scheduling the repainting > asynchronously) > 241 // is better? > 242 SwingUtilities.invokeLater(new Runnable() { > 243 @Override > 244 public void run() { > 245 platformWindow.setVisible(visible); This "WHY?..." comment was added by me long time ago. If all the invoked methods may be called on other threads I don't see a reason to dispatch this code to the EDT. However, if you wish to remove this invokeLater(), you'll have to thoroughly test that nothing is broken. We might want to ask Alex (CC'ed) since he added this invokeLater() originally IIRC. Is this still relevant? Doesn't the painting operation gets dispatched to the EDT automatically? May there still be any painting artifacts should the platformWindow.setVisible() be invoked on non-EDT thread? >> Please review a fix for 7129732. >> >> webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ At line 255 a check for !visible is unnecessary since the else branch already ensures that visible is false. Otherwise looks good. -- best regards, Anthony >> >> When a focused simple window is getting closed, focus should be >> transferred to the owner. >> >> Thanks, >> Anton. >> >> > From Alexander.Potochkin at oracle.com Mon Jan 30 07:38:34 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 30 Jan 2012 19:38:34 +0400 Subject: [jdk7u-osx] Request for approval for 7130360: [macosx] Packed JInternalFrame invisible on Aqua L&F Message-ID: <4F26B97A.2060404@oracle.com> This is a request to push the following fix to jdk7u-osx: http://cr.openjdk.java.net/~alexp/7130360/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130360 the fix was approved by anthony Thanks alexp From Alexander.Potochkin at oracle.com Mon Jan 30 07:39:39 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 30 Jan 2012 19:39:39 +0400 Subject: [jdk7u-osx] Request for approval for 7124393: [macosx] JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click Message-ID: <4F26B9BB.7060303@oracle.com> This is a request to push the following fix to jdk7u-osx: http://cr.openjdk.java.net/~alexp/7124393/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124393 the fix was approved by anthony Thanks alexp From Alexander.Potochkin at oracle.com Mon Jan 30 07:42:32 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 30 Jan 2012 19:42:32 +0400 Subject: [jdk7u-osx] Request for approval for 7124387: [macosx] Application freezes on dispose window, created by JFileChooser Message-ID: <4F26BA68.1000105@oracle.com> This is a request to push the following fix to jdk7u-osx: http://cr.openjdk.java.net/~alexp/7124387/webrev.00/ the bug's description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124387 the fix was approved by Artem Thanks alexp From paul.hohensee at oracle.com Mon Jan 30 07:47:07 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 30 Jan 2012 10:47:07 -0500 Subject: [jdk7u-osx] Request for approval for CR 7139770 MacOS JCK failures in DatagramSocket and MulticastSocket In-Reply-To: <4F26A80B.8060505@oracle.com> References: <4F26A80B.8060505@oracle.com> Message-ID: <4F26BB7B.4020609@oracle.com> Approved. Paul On 1/30/12 9:24 AM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7139770 > > Webrev: http://cr.openjdk.java.net/~michaelm/7139770/webrev.1/ > > Reviewed by: chegar > > Thanks, > Michael. From anthony.petrov at oracle.com Mon Jan 30 08:10:38 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 30 Jan 2012 20:10:38 +0400 Subject: Review request for 7132809: [macosx] MAXIMIZED_BOTH set before setVisible(true) hides Frame In-Reply-To: <4F26AC73.4070305@oracle.com> References: <4F21743C.8020709@oracle.com> <4F267648.7010700@oracle.com> <4F26A615.5050201@oracle.com> <4F26ABFF.4030604@oracle.com> <4F26AC73.4070305@oracle.com> Message-ID: <4F26C0FE.9030405@oracle.com> Artem and I have discussed the issue and here's an updated fix: http://cr.openjdk.java.net/~anthony/x-11-MaximizedBoth-7132809.1/ The difference is that we now use peer.getState() in the if (!visible) branch of the extended state handling code in the CPlatformWindow.setVisible(). This is because we really want to cancel out the current state of the window as seen from native perspective - this is what LWWindoePeer.getPeer() returns. However, in the if (visible) branch we must apply the state which the shared code expects for the window, and as such we continue to use the frame.getExtendedState() method there. Other than that there's no other changes. -- best regards, Anthony On 01/30/12 18:42, Anthony Petrov wrote: > On 01/30/12 18:41, Artem Ananiev wrote: >>>> A minor comment: can we use peer.getState() instead of (instanceof >>>> check >>>> + target.getExtendedState()) in CPlatformWindow.setVisible()? >>> >>> The LWWindowPeer.getState() returns the LWWindowPeer.windowState field >>> that gets updated only from native notifications >>> (notifyIconify()/notifyZoom()). While the window is hidden, the state >>> isn't changed, and as such the notifications aren't sent which makes the >>> windowState field value stale. >> >> I'm not sure about it. What I see is that LWWindowPeer.setState() is >> called from Frame: >> >> FramePeer peer = (FramePeer)this.peer; >> if (peer != null) { >> peer.setState(state); >> } > > LWWindowPeer.setState() simply delegates to > CPlatformWindow.setWindowState(). If the window is visible, this causes > -zoom/-miniaturize native calls, and hence the notifications that > results in LWWindowPeer.notifyZoom/notifyIconify() which finally update > the LWWindowPeer.windowState. > > However, if the window is hidden, the CPlatformWindow.setWindowState() > is basically a no-op. > > > -- > best regards, > Anthony > >> At the same time, I don't see where LWWindowPeer.setState() is called >> from CPlatformWindow. >> >> Thanks, >> >> Artem >> >>> As soon as the CPlatformWindow.setVisible(true) is called it needs to >>> read the real current state of the frame, and since the peer's cached >>> value is wrong, we read the state from the target. >>> >>> -- >>> best regards, >>> Anthony >>> >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 1/26/2012 7:41 PM, Anthony Petrov wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7132809 >>>>> at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/x-11-MaximizedBoth-7132809.0/ >>>>> >>>>> We shouldn't apply the extended state when a window is hidden. With >>>>> this >>>>> fix the CPlatformWindow.setVisible() re-applies the state when the >>>>> window gets shown. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony From michael.x.mcmahon at oracle.com Mon Jan 30 08:18:14 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 30 Jan 2012 16:18:14 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7139770: MacOS JCK failures in DatagramSocket and MulticastSocket Message-ID: <20120130161825.92D184728C@hg.openjdk.java.net> Changeset: cb029d9b830a Author: michaelm Date: 2012-01-30 16:17 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/cb029d9b830a 7139770: MacOS JCK failures in DatagramSocket and MulticastSocket Reviewed-by: chegar ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/MulticastSocket.java From Alexander.Potochkin at oracle.com Mon Jan 30 08:46:16 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Mon, 30 Jan 2012 20:46:16 +0400 Subject: review request for 7124399: [macosx] All Swing drag-n-drop tests faild In-Reply-To: <4F2684F7.2090505@oracle.com> References: <4F2684F7.2090505@oracle.com> Message-ID: <4F26C958.30501@oracle.com> Hello Alexander Looks good! Thanks alexp > Hello, > > please review my fix for 7124399: [macosx] All Swing drag-n-drop > tests faild > > Bug description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124399 > > Diffs can be found here: > http://cr.openjdk.java.net/~kizune/7124399/webrev.00 > > The idea of the fix is to accurately tracking component entering and > leaving and send the corresponding listeners dragRnter/dragExit events. > > With best regards, > Alexander Zuev From swingler at apple.com Mon Jan 30 08:47:36 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 30 Jan 2012 08:47:36 -0800 Subject: [7u-osx] Request for approval for 7131793: [macosx] some cleanup in OGL pipeline code In-Reply-To: <4F266845.8080507@oracle.com> References: <4F2668F0.4030703@oracle.com> <4F266697.8070300@oracle.com> <4F266845.8080507@oracle.com> Message-ID: On Jan 30, 2012, at 1:52 AM, Sergey Bylokhov wrote: > 30.01.2012 13:44, Sergey Bylokhov wrote: >> Hi Dmitry, >> I have a question about CGLLayer.m >> >> 124JNFCallVoidMethod(env, [self.javaLayer jObjectWithEnv:env], jm_drawInCGLContext); >> >> Should we delete a local reference which returned from [self.javaLayer jObjectWithEnv:env]? And check it for null? > JNFJObjectWrapper.h > ...... > - (jobject) jObjectWithEnv:(JNIEnv *)env; // returns a new local-ref, must be released with DeleteLocalRef > ...... >> >> >> 30.01.2012 13:54, Dmitry Cherepanov wrote: >>> This is a request to push the following fix to jdk7u-osx: >>> >>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7131793 >>> >>> Webrev: http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.2 >>> >>> Technical review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002537.html >>> >>> Thanks, >>> Dmitry I believe local refs are collected after the scope of the local function returns, so I don't believe it's strictly necessary. Is that right? Regards, Mike Swingler Apple Inc. From swingler at apple.com Mon Jan 30 09:18:42 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 30 Jan 2012 09:18:42 -0800 Subject: Review request for 7131793: [macosx] some cleanup in OGL pipeline code In-Reply-To: <4F26A22F.9060001@oracle.com> References: <4F22BFF0.406@oracle.com> <15184530-A44F-45DB-B1A8-FC890521D635@apple.com> <4F26A22F.9060001@oracle.com> Message-ID: <66F5DDAA-FE6F-448D-86BA-786052B6C9FB@apple.com> On Jan 30, 2012, at 5:59 AM, Dmitry Cherepanov wrote: > Mike Swingler wrote: > >> On Jan 27, 2012, at 7:17 AM, Dmitry Cherepanov wrote: >> >>> Hello, >>> >>> Here's some changes to remove some stale code from the OGL pipeline. This code has been introduced as a part of the initial implementation for CALayer-based rendering and disabled by the changes for MACOSX_PORT-766. >>> >>> http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.1/ >> >> One tiny detail: I'd recommend using -jObjectWithEnv: instead of -jObject here (because it's a little faster to not re-fetch the env): >> + JNFCallVoidMethod(env, [self.javaLayer jObject], jm_drawInCGLContext); > > On second thought, seems like -jObject simply returns the global reference that the wrapper holds without obtaining the env. What's the reason for re-fetching the env? That is correct...we are returning the global env, I had forgot about that. It doesn't seem safe though, if the wrapper gets dealloc'd while the ref is still held in a local. :-/ As is though, I don't think we can change the API at this point. Sorry for the noise, Mike Swingler Apple Inc. From artem.ananiev at oracle.com Mon Jan 30 09:24:24 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 30 Jan 2012 21:24:24 +0400 Subject: [jdk7u-osx] Request for approval for 7130360: [macosx] Packed JInternalFrame invisible on Aqua L&F In-Reply-To: <4F26B97A.2060404@oracle.com> References: <4F26B97A.2060404@oracle.com> Message-ID: <4F26D248.3050601@oracle.com> Approved. On 1/30/2012 7:38 PM, Alexander Potochkin wrote: > This is a request to push the following fix to jdk7u-osx: > http://cr.openjdk.java.net/~alexp/7130360/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7130360 > > the fix was approved by anthony > > Thanks > alexp From artem.ananiev at oracle.com Mon Jan 30 09:27:01 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 30 Jan 2012 21:27:01 +0400 Subject: [jdk7u-osx] Request for approval for 7124393: [macosx] JCheckBox in JTable: checkbox doesn't alaways respond to the first mouse click In-Reply-To: <4F26B9BB.7060303@oracle.com> References: <4F26B9BB.7060303@oracle.com> Message-ID: <4F26D2E5.8080507@oracle.com> Approved. On 1/30/2012 7:39 PM, Alexander Potochkin wrote: > This is a request to push the following fix to jdk7u-osx: > http://cr.openjdk.java.net/~alexp/7124393/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124393 > > the fix was approved by anthony > > Thanks > alexp From artem.ananiev at oracle.com Mon Jan 30 09:27:29 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 30 Jan 2012 21:27:29 +0400 Subject: [jdk7u-osx] Request for approval for 7124387: [macosx] Application freezes on dispose window, created by JFileChooser In-Reply-To: <4F26BA68.1000105@oracle.com> References: <4F26BA68.1000105@oracle.com> Message-ID: <4F26D301.9090601@oracle.com> Approved. On 1/30/2012 7:42 PM, Alexander Potochkin wrote: > This is a request to push the following fix to jdk7u-osx: > http://cr.openjdk.java.net/~alexp/7124387/webrev.00/ > > the bug's description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124387 > > the fix was approved by Artem > > Thanks > alexp From scott.kovatch at oracle.com Mon Jan 30 09:30:00 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Mon, 30 Jan 2012 09:30:00 -0800 Subject: Bundled app launcher changes Message-ID: <01238DD0-65D6-42A5-A69F-E2DCE6B93776@oracle.com> Hello, Greg Brown has been busy working on an Ant task for creating a Mac .app bundle. As a preview, here's an example of it in use: I'm wondering where this should be checked in, though. Building an application bundle from JARs, resources, and launcher stub is really a deployment task as opposed to a pure JDK feature, but Web Start and the plugin are not open sourced so I don't see a public 'deploy' project happening in the near future. We definitely want to push this out so people can start building applications with the Mac JDK. Anyone have an opinion on that? Also, we are working on an simpler version of the launcher code that will reuse more of the generic/command-line launcher code in jdk/src/share/bin/java.c. Kumar Srinivasan checked in a refactoring of the command-line tools so that all of the runloop management, argument parsing, and other setup is now done in JLI_Launch. That means we can rip out the code that duplicates that work in the app launcher and call through to JLI_Launch instead. I started on this and handed it off to Greg. We should have something to share in the next week or so. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From artem.ananiev at oracle.com Mon Jan 30 09:34:13 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 30 Jan 2012 21:34:13 +0400 Subject: Review request for 7132809: [macosx] MAXIMIZED_BOTH set before setVisible(true) hides Frame In-Reply-To: <4F26C0FE.9030405@oracle.com> References: <4F21743C.8020709@oracle.com> <4F267648.7010700@oracle.com> <4F26A615.5050201@oracle.com> <4F26ABFF.4030604@oracle.com> <4F26AC73.4070305@oracle.com> <4F26C0FE.9030405@oracle.com> Message-ID: <4F26D495.2060209@oracle.com> Looks fine. Thanks, Artem On 1/30/2012 8:10 PM, Anthony Petrov wrote: > Artem and I have discussed the issue and here's an updated fix: > > http://cr.openjdk.java.net/~anthony/x-11-MaximizedBoth-7132809.1/ > > The difference is that we now use peer.getState() in the if (!visible) > branch of the extended state handling code in the > CPlatformWindow.setVisible(). This is because we really want to cancel > out the current state of the window as seen from native perspective - > this is what LWWindoePeer.getPeer() returns. > > However, in the if (visible) branch we must apply the state which the > shared code expects for the window, and as such we continue to use the > frame.getExtendedState() method there. > > Other than that there's no other changes. > > -- > best regards, > Anthony > > On 01/30/12 18:42, Anthony Petrov wrote: >> On 01/30/12 18:41, Artem Ananiev wrote: >>>>> A minor comment: can we use peer.getState() instead of (instanceof >>>>> check >>>>> + target.getExtendedState()) in CPlatformWindow.setVisible()? >>>> >>>> The LWWindowPeer.getState() returns the LWWindowPeer.windowState field >>>> that gets updated only from native notifications >>>> (notifyIconify()/notifyZoom()). While the window is hidden, the state >>>> isn't changed, and as such the notifications aren't sent which makes >>>> the >>>> windowState field value stale. >>> >>> I'm not sure about it. What I see is that LWWindowPeer.setState() is >>> called from Frame: >>> >>> FramePeer peer = (FramePeer)this.peer; >>> if (peer != null) { >>> peer.setState(state); >>> } >> >> LWWindowPeer.setState() simply delegates to >> CPlatformWindow.setWindowState(). If the window is visible, this causes >> -zoom/-miniaturize native calls, and hence the notifications that >> results in LWWindowPeer.notifyZoom/notifyIconify() which finally update >> the LWWindowPeer.windowState. >> >> However, if the window is hidden, the CPlatformWindow.setWindowState() >> is basically a no-op. >> >> >> -- >> best regards, >> Anthony >> >>> At the same time, I don't see where LWWindowPeer.setState() is called >>> from CPlatformWindow. >>> >>> Thanks, >>> >>> Artem >>> >>>> As soon as the CPlatformWindow.setVisible(true) is called it needs to >>>> read the real current state of the frame, and since the peer's cached >>>> value is wrong, we read the state from the target. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 1/26/2012 7:41 PM, Anthony Petrov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for >>>>>> http://bugs.sun.com/view_bug.do?bug_id=7132809 >>>>>> at: >>>>>> >>>>>> http://cr.openjdk.java.net/~anthony/x-11-MaximizedBoth-7132809.0/ >>>>>> >>>>>> We shouldn't apply the extended state when a window is hidden. With >>>>>> this >>>>>> fix the CPlatformWindow.setVisible() re-applies the state when the >>>>>> window gets shown. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony From kumar.x.srinivasan at oracle.COM Mon Jan 30 11:06:06 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 30 Jan 2012 11:06:06 -0800 Subject: [7u-osx] Request for review : 7140989: [MacOSX] Test Pack200Test fails on Mac Message-ID: <4F26EA1E.90601@oracle.COM> Hi, Please review a simple fix to increase the residual memory threshold between the pack/unpack iterations, on Macs for whatever reason the residual memory exceeds by a mere 104K, thus causing a false positive, I have verified the residual memory is indeed reclaimed by GC on the next iteration. http://cr.openjdk.java.net/~ksrini/7140989/webrev.0/ Thanks Kumar From kurchi.subhra.hazra at oracle.com Mon Jan 30 11:59:08 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 30 Jan 2012 11:59:08 -0800 Subject: Code Review Request: 7140934: TEST_BUG: closed/java/io/pathNames/GeneralSolaris.java fails on Mac OS X Message-ID: <4F26F68C.1040909@oracle.com> Hi, This is a simple fix to use /private/etc/shadow instead of /etc/shadow for Mac OS X. Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140934 Webrev : http://cr.openjdk.java.net/~khazra/7140934/webrev.00/ Thanks, Kurchi From Alan.Bateman at oracle.com Mon Jan 30 12:11:46 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Jan 2012 20:11:46 +0000 Subject: Code Review Request: 7140934: TEST_BUG: closed/java/io/pathNames/GeneralSolaris.java fails on Mac OS X In-Reply-To: <4F26F68C.1040909@oracle.com> References: <4F26F68C.1040909@oracle.com> Message-ID: <4F26F982.3040705@oracle.com> On 30/01/2012 19:59, Kurchi Hazra wrote: > > Hi, > > This is a simple fix to use /private/etc/shadow instead of /etc/shadow > for Mac OS X. > > > Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140934 > > Webrev : http://cr.openjdk.java.net/~khazra/7140934/webrev.00/ > This looks okay to me, thanks for taking this one. -Alan PS: I notice a couple of other tests haven't been updated to work on Mac. The tests in java/nio/charset/** for example. From michael.x.mcmahon at oracle.com Mon Jan 30 13:01:04 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 30 Jan 2012 21:01:04 +0000 Subject: Code Review Request: 7140934: TEST_BUG: closed/java/io/pathNames/GeneralSolaris.java fails on Mac OS X In-Reply-To: <4F26F68C.1040909@oracle.com> References: <4F26F68C.1040909@oracle.com> Message-ID: <4F270510.6050008@oracle.com> On 30/01/12 19:59, Kurchi Hazra wrote: > > Hi, > > This is a simple fix to use /private/etc/shadow instead of /etc/shadow > for Mac OS X. > > > Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140934 > > Webrev : http://cr.openjdk.java.net/~khazra/7140934/webrev.00/ > > Thanks, > Kurchi > > > Looks good. Thanks, Michael. From kurchi.subhra.hazra at oracle.com Mon Jan 30 13:58:34 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 30 Jan 2012 13:58:34 -0800 Subject: Code Review Request: 7141071: TEST_BUG: update shell scripts in java/nio/charset to detect Mac OS as a valid platform Message-ID: <4F27128A.5000001@oracle.com> Hi, This fix updates two scripts to recognize Mac OS (Darwin) as a valid platform. Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141071 Webrev : http://cr.openjdk.java.net/~khazra/7141071/webrev.00/ Thanks, Kurchi From kurchi.subhra.hazra at oracle.com Mon Jan 30 14:01:04 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 30 Jan 2012 14:01:04 -0800 Subject: [7u4-osx] Request for approval for 7140934 : TEST_BUG: closed/java/io/pathNames/GeneralSolaris.java fails on Mac OS X Message-ID: <4F271320.8010604@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140934 Webrev:http://cr.openjdk.java.net/~khazra/7140934/webrev.00/ Reviewed by: alanb, michaelm This changeset will be pushed on my behalf by Michael McMahon (michaelm). Thanks, Kurchi From kumar.x.srinivasan at oracle.COM Mon Jan 30 14:19:06 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Mon, 30 Jan 2012 14:19:06 -0800 Subject: [7u-osx] Request for review : 7140989: [MacOSX] Test Pack200Test fails on Mac In-Reply-To: <4F26EA1E.90601@oracle.COM> References: <4F26EA1E.90601@oracle.COM> Message-ID: <4F27175A.9050707@oracle.COM> Resending and including jdk7u-dev and John. Thanks Kumar > Hi, > > Please review a simple fix to increase the residual memory > threshold between the pack/unpack iterations, on Macs for > whatever reason the residual memory exceeds by a mere 104K, > thus causing a false positive, I have verified the residual memory > is indeed reclaimed by GC on the next iteration. > > http://cr.openjdk.java.net/~ksrini/7140989/webrev.0/ > > Thanks > Kumar > > > From paul.hohensee at oracle.com Mon Jan 30 15:05:25 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 30 Jan 2012 18:05:25 -0500 Subject: [7u4-osx] Request for approval for 7140934 : TEST_BUG: closed/java/io/pathNames/GeneralSolaris.java fails on Mac OS X In-Reply-To: <4F271320.8010604@oracle.com> References: <4F271320.8010604@oracle.com> Message-ID: <4F272235.6060203@oracle.com> Approved. Paul On 1/30/12 5:01 PM, Kurchi Hazra wrote: > > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7140934 > > Webrev:http://cr.openjdk.java.net/~khazra/7140934/webrev.00/ > > > Reviewed by: alanb, michaelm > > This changeset will be pushed on my behalf by Michael McMahon (michaelm). > > Thanks, > Kurchi > > > From kumar.x.srinivasan at oracle.com Mon Jan 30 19:08:32 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 31 Jan 2012 03:08:32 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7140989: [MacOSX] Test Pack200Test fails on Mac Message-ID: <20120131030856.ED24A47297@hg.openjdk.java.net> Changeset: 92da761e4442 Author: ksrini Date: 2012-01-30 19:07 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/92da761e4442 7140989: [MacOSX] Test Pack200Test fails on Mac Reviewed-by: jrose ! test/tools/pack200/Pack200Test.java From anton.tarasov at oracle.com Tue Jan 31 04:25:51 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 31 Jan 2012 15:25:51 +0300 Subject: [7u-osx] Request for approval for 7129825 - [macosx] Native activation is not changed when focusing other frame's owned window In-Reply-To: <4F22523D.8040708@oracle.com> References: <4F22523D.8040708@oracle.com> Message-ID: <4F27DDCF.903@oracle.com> Additional review was requested. Here is it: Webrev: http://cr.openjdk.java.net/~ant/7129825/webrev.1/ Review: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002596.html Thanks, Anton. On 1/27/12 10:29 AM, Anton V. Tarasov wrote: > Hello, > > A request to push the changes to jdk7u-osx. > Reviewed on macosx-port-dev by Artem Ananiev. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129825 > Webrev: http://cr.openjdk.java.net/~ant/7129825/webrev.0/ > > Technical review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002475.html > > Thanks, > Anton. From anton.tarasov at sun.com Tue Jan 31 00:39:40 2012 From: anton.tarasov at sun.com (anton.tarasov at sun.com) Date: Tue, 31 Jan 2012 08:39:40 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7131196: [macosx] Cmd-Q does not quit a graphical Java app Message-ID: <20120131084007.7A8C7472A7@hg.openjdk.java.net> Changeset: e7370ef55062 Author: ant Date: 2012-01-31 15:38 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/e7370ef55062 7131196: [macosx] Cmd-Q does not quit a graphical Java app Reviewed-by: art ! src/macosx/native/sun/awt/AWTView.m From anton.tarasov at oracle.com Tue Jan 31 05:12:06 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 31 Jan 2012 16:12:06 +0300 Subject: Review request for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner In-Reply-To: <4F26B78E.9080002@oracle.com> References: <4F268233.3090707@oracle.com> <4F268779.6040909@oracle.com> <4F26B78E.9080002@oracle.com> Message-ID: <4F27E8A6.60708@oracle.com> Hi Anthony, On 1/30/12 6:30 PM, Anthony Petrov wrote: > Hi Anton, > > On 01/30/12 16:05, Anton V. Tarasov wrote: >> A question to the reviewers. Do we still need to invoke on EDT? >> 236 // it is important to call this method on EDT >> 237 // to prevent the deadlocks during the painting of the lightweight >> delegates >> 238 //TODO: WHY? This is a native-system related call. Perhaps NOT >> calling >> 239 // the painting procedure right from the setVisible(), but rather >> relying >> 240 // on the native Expose event (or, scheduling the repainting >> asynchronously) >> 241 // is better? >> 242 SwingUtilities.invokeLater(new Runnable() { >> 243 @Override >> 244 public void run() { >> 245 platformWindow.setVisible(visible); > > This "WHY?..." comment was added by me long time ago. If all the > invoked methods may be called on other threads I don't see a reason to > dispatch this code to the EDT. However, if you wish to remove this > invokeLater(), you'll have to thoroughly test that nothing is broken. > > We might want to ask Alex (CC'ed) since he added this invokeLater() > originally IIRC. Is this still relevant? Doesn't the painting > operation gets dispatched to the EDT automatically? May there still be > any painting artifacts should the platformWindow.setVisible() be > invoked on non-EDT thread? Oh, I see that I'm better to separate this investigation (due to the urgency of the fix). Thanks for your comments! > > > >>> Please review a fix for 7129732. >>> >>> webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ > > At line 255 a check for !visible is unnecessary since the else branch > already ensures that visible is false. Indeed. I added the first if-statement and forget to refine the second one. Thanks for catching this. Please, see the improved version: http://cr.openjdk.java.net/~ant/7129732/webrev.1 Thanks, Anton. > > Otherwise looks good. > > -- > best regards, > Anthony > > >>> >>> When a focused simple window is getting closed, focus should be >>> transferred to the owner. >>> >>> Thanks, >>> Anton. >>> >>> >> From dmitry.cherepanov at oracle.com Tue Jan 31 02:23:19 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Tue, 31 Jan 2012 13:23:19 +0300 Subject: Review request for 7129825 - [macosx] Native activation is not changed when focusing other frame's owned window In-Reply-To: <4F2686FA.80008@oracle.com> References: <4F1ECCE2.4030509@oracle.com> <4F2687C0.2090703@oracle.com> <4F2686FA.80008@oracle.com> Message-ID: <4F27C117.80503@oracle.com> Anton V. Tarasov wrote: > On 30.01.2012 16:06, Dmitry Cherepanov wrote: >> Hi Anton, >> >> The fix looks fine to me. Just one comment - the fix introduces new >> isActive method in the PlatformWindow interface (and removes >> parameters from requestWindowFocus). Could you please add some >> implementation into the CPlatformEmbeddedFrame class (simply >> returning true should be fine) as the class implements the >> PlatformWindow interface. > > Sure, I missed it. Here's the updated version: > > http://cr.openjdk.java.net/~ant/7129825/webrev.1/ Looks fine to me. Thanks, Dmitry From artem.ananiev at oracle.com Tue Jan 31 01:47:35 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 31 Jan 2012 13:47:35 +0400 Subject: [7u-osx] Request for approval for 7129825 - [macosx] Native activation is not changed when focusing other frame's owned window In-Reply-To: <4F27DDCF.903@oracle.com> References: <4F22523D.8040708@oracle.com> <4F27DDCF.903@oracle.com> Message-ID: <4F27B8B7.3040809@oracle.com> Approved. On 1/31/2012 4:25 PM, Anton V. Tarasov wrote: > Additional review was requested. Here is it: > > Webrev: http://cr.openjdk.java.net/~ant/7129825/webrev.1/ > Review: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002596.html > > > Thanks, > Anton. > > On 1/27/12 10:29 AM, Anton V. Tarasov wrote: >> Hello, >> >> A request to push the changes to jdk7u-osx. >> Reviewed on macosx-port-dev by Artem Ananiev. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129825 >> Webrev: http://cr.openjdk.java.net/~ant/7129825/webrev.0/ >> >> Technical review: >> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002475.html >> >> >> Thanks, >> Anton. > From artem.ananiev at oracle.com Tue Jan 31 01:53:18 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 31 Jan 2012 13:53:18 +0400 Subject: Review request for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner In-Reply-To: <4F27E8A6.60708@oracle.com> References: <4F268233.3090707@oracle.com> <4F268779.6040909@oracle.com> <4F26B78E.9080002@oracle.com> <4F27E8A6.60708@oracle.com> Message-ID: <4F27BA0E.4000200@oracle.com> The fix looks fine. Unrelated question: should LWWindowPeer.updateFocusableWindowState() be called before platformWindow.setVisible()? Thanks, Artem On 1/31/2012 5:12 PM, Anton V. Tarasov wrote: > Hi Anthony, > > On 1/30/12 6:30 PM, Anthony Petrov wrote: >> Hi Anton, >> >> On 01/30/12 16:05, Anton V. Tarasov wrote: >>> A question to the reviewers. Do we still need to invoke on EDT? >>> 236 // it is important to call this method on EDT >>> 237 // to prevent the deadlocks during the painting of the lightweight >>> delegates >>> 238 //TODO: WHY? This is a native-system related call. Perhaps NOT >>> calling >>> 239 // the painting procedure right from the setVisible(), but rather >>> relying >>> 240 // on the native Expose event (or, scheduling the repainting >>> asynchronously) >>> 241 // is better? >>> 242 SwingUtilities.invokeLater(new Runnable() { >>> 243 @Override >>> 244 public void run() { >>> 245 platformWindow.setVisible(visible); >> >> This "WHY?..." comment was added by me long time ago. If all the >> invoked methods may be called on other threads I don't see a reason to >> dispatch this code to the EDT. However, if you wish to remove this >> invokeLater(), you'll have to thoroughly test that nothing is broken. >> >> We might want to ask Alex (CC'ed) since he added this invokeLater() >> originally IIRC. Is this still relevant? Doesn't the painting >> operation gets dispatched to the EDT automatically? May there still be >> any painting artifacts should the platformWindow.setVisible() be >> invoked on non-EDT thread? > > Oh, I see that I'm better to separate this investigation (due to the > urgency of the fix). Thanks for your comments! > >> >> >> >>>> Please review a fix for 7129732. >>>> >>>> webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ >> >> At line 255 a check for !visible is unnecessary since the else branch >> already ensures that visible is false. > > Indeed. I added the first if-statement and forget to refine the second > one. Thanks for catching this. > > Please, see the improved version: > > http://cr.openjdk.java.net/~ant/7129732/webrev.1 > > Thanks, > Anton. > >> >> Otherwise looks good. >> >> -- >> best regards, >> Anthony >> >> >>>> >>>> When a focused simple window is getting closed, focus should be >>>> transferred to the owner. >>>> >>>> Thanks, >>>> Anton. >>>> >>>> >>> > From michael.x.mcmahon at oracle.com Tue Jan 31 01:53:32 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 31 Jan 2012 09:53:32 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 14 new changesets Message-ID: <20120131095602.076D7472A9@hg.openjdk.java.net> Changeset: d1ab7147ea8a Author: peytoia Date: 2012-01-26 20:20 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d1ab7147ea8a 7017458: (cal) Multithreaded deserialization of Calendar leads to ClassCastException Reviewed-by: okutsu ! src/share/classes/java/util/Calendar.java + test/java/util/Calendar/Bug7017458.java Changeset: c9527f448900 Author: rupashka Date: 2012-01-27 19:51 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/c9527f448900 7010561: Tab text position with Synth based LaF is different to Java 5/6 Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/JTabbedPane/7010561/bug7010561.java Changeset: d3fa6e01d3dc Author: wetmore Date: 2012-01-27 15:01 -0800 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d3fa6e01d3dc 7126889: Incorrect SSLEngine debug output Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/EngineArgs.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh Changeset: 5c06eec3f804 Author: okutsu Date: 2012-01-30 13:37 +0900 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/5c06eec3f804 7130335: Problem with timezone in a SimpleDateFormat Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug7130335.java Changeset: cd80798dc799 Author: peytoia Date: 2012-01-30 16:51 +0900 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/cd80798dc799 7122054: (tz) Windows-only: tzmappings needs update for KB2633952 Reviewed-by: okutsu ! src/windows/lib/tzmappings Changeset: b6359adf1f31 Author: denis Date: 2012-01-30 13:46 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/b6359adf1f31 7078460: JDialog is shown as separate icon on the taskbar Reviewed-by: art ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: 2bd0d00e8729 Author: alexsch Date: 2012-01-30 13:57 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/2bd0d00e8729 7112854: [macosx] closed/javax/swing/JPopupMenu/Test6827786.java unstable on MacOS Reviewed-by: rupashka + test/javax/swing/JPopupMenu/6827786/bug6827786.java Changeset: 93b5aa0c8e8c Author: alexsch Date: 2012-01-30 14:06 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/93b5aa0c8e8c 7116634: [macosx] closed/javax/swing/JTree/6263446/bug6263446Tree.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JTree/6263446/bug6263446.java Changeset: d51b805f59bc Author: alexsch Date: 2012-01-30 14:34 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/d51b805f59bc 7109962: [macosx] closed/javax/swing/JList/6462008/bug6462008.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JList/6462008/bug6462008.java Changeset: cf5ab82c9f2a Author: alexsch Date: 2012-01-30 14:40 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/cf5ab82c9f2a 7105040: [macosx] closed/javax/swing/JPopupMenu/4966112/bug4966112.java deadlocks on MacOS Reviewed-by: rupashka + test/javax/swing/JPopupMenu/4966112/bug4966112.java Changeset: f71e4abab7f6 Author: alexsch Date: 2012-01-30 15:12 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/f71e4abab7f6 7122149: [macosx] closed/javax/swing/UITest/UITest.java fails on MacOS Reviewed-by: rupashka ! src/share/classes/sun/awt/OSInfo.java + test/javax/swing/UITest/UITest.java Changeset: 68a486672cf8 Author: alexsch Date: 2012-01-30 15:20 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/68a486672cf8 7122173: [macosx] Several Regression tests fail on MacOS Reviewed-by: rupashka + test/javax/swing/SwingUtilities/4917669/bug4917669.java + test/javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java + test/javax/swing/text/html/CSS/4530474/bug4530474.java + test/javax/swing/text/html/CSS/4530474/test.css + test/javax/swing/text/html/CSS/4530474/test.html Changeset: 3c97da8e33ec Author: michaelm Date: 2012-01-30 16:27 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/3c97da8e33ec Merge ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java Changeset: 58c548d6b53e Author: michaelm Date: 2012-01-31 09:19 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/58c548d6b53e Merge From leonid.romanov at oracle.com Tue Jan 31 01:58:33 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 31 Jan 2012 13:58:33 +0400 Subject: Review request for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner In-Reply-To: <4F27E8A6.60708@oracle.com> References: <4F268233.3090707@oracle.com> <4F268779.6040909@oracle.com> <4F26B78E.9080002@oracle.com> <4F27E8A6.60708@oracle.com> Message-ID: <3DC2E810-8B73-4EC7-8853-B6BB2B34E2A5@oracle.com> Hi Anton, Regarding your question, see http://java.net/jira/browse/MACOSX_PORT-429 On 31.01.2012, at 17:12, Anton V. Tarasov wrote: > Hi Anthony, > > On 1/30/12 6:30 PM, Anthony Petrov wrote: >> Hi Anton, >> >> On 01/30/12 16:05, Anton V. Tarasov wrote: >>> A question to the reviewers. Do we still need to invoke on EDT? >>> 236 // it is important to call this method on EDT >>> 237 // to prevent the deadlocks during the painting of the lightweight >>> delegates >>> 238 //TODO: WHY? This is a native-system related call. Perhaps NOT calling >>> 239 // the painting procedure right from the setVisible(), but rather >>> relying >>> 240 // on the native Expose event (or, scheduling the repainting >>> asynchronously) >>> 241 // is better? >>> 242 SwingUtilities.invokeLater(new Runnable() { >>> 243 @Override >>> 244 public void run() { >>> 245 platformWindow.setVisible(visible); >> >> This "WHY?..." comment was added by me long time ago. If all the invoked methods may be called on other threads I don't see a reason to dispatch this code to the EDT. However, if you wish to remove this invokeLater(), you'll have to thoroughly test that nothing is broken. >> >> We might want to ask Alex (CC'ed) since he added this invokeLater() originally IIRC. Is this still relevant? Doesn't the painting operation gets dispatched to the EDT automatically? May there still be any painting artifacts should the platformWindow.setVisible() be invoked on non-EDT thread? > > Oh, I see that I'm better to separate this investigation (due to the urgency of the fix). Thanks for your comments! > >> >> >> >>>> Please review a fix for 7129732. >>>> >>>> webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ >> >> At line 255 a check for !visible is unnecessary since the else branch already ensures that visible is false. > > Indeed. I added the first if-statement and forget to refine the second one. Thanks for catching this. > > Please, see the improved version: > > http://cr.openjdk.java.net/~ant/7129732/webrev.1 > > Thanks, > Anton. > >> >> Otherwise looks good. >> >> -- >> best regards, >> Anthony >> >> >>>> >>>> When a focused simple window is getting closed, focus should be >>>> transferred to the owner. >>>> >>>> Thanks, >>>> Anton. >>>> >>>> >>> > From alexey.menkov at oracle.com Tue Jan 31 02:03:04 2012 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 31 Jan 2012 14:03:04 +0400 Subject: Request for review 7124225: [macosx] Input lines support only current sample rate Message-ID: <4F27BC58.60600@oracle.com> Hi all, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7124225 webrev: http://cr.openjdk.java.net/~amenkov/7124225/webrev.00/ Summary of the changes: implemented resampler for TargetDataLine using AudioToolbox/AudioConverter (used only if requested sample rate does not match current device sample rate). regards Alex From alexander.zuev at oracle.com Tue Jan 31 03:31:48 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 31 Jan 2012 14:31:48 +0300 Subject: [7u-osx] Request for approval for 7124399: [macosx] All Swing drag-n-drop tests faild Message-ID: <4F27D124.7030602@oracle.com> Hello, this is request for approval of the push for the change that fixes bug 7124399: [macosx] All Swing drag-n-drop tests faild Bug description is here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124399 Webrev for my diffs can be found here: http://cr.openjdk.java.net/~kizune/7124399/webrev.00 Change was reviewed on the macosx-port-dev public alias and approved by Alexander Potochkin With best regards, Alexander Zuev From dmitry.cherepanov at oracle.com Tue Jan 31 03:36:30 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Tue, 31 Jan 2012 14:36:30 +0300 Subject: Review request for 7131793: [macosx] some cleanup in OGL pipeline code In-Reply-To: <66F5DDAA-FE6F-448D-86BA-786052B6C9FB@apple.com> References: <4F22BFF0.406@oracle.com> <15184530-A44F-45DB-B1A8-FC890521D635@apple.com> <4F26A22F.9060001@oracle.com> <66F5DDAA-FE6F-448D-86BA-786052B6C9FB@apple.com> Message-ID: <4F27D23E.9060601@oracle.com> Mike Swingler wrote: > On Jan 30, 2012, at 5:59 AM, Dmitry Cherepanov wrote: > > >> Mike Swingler wrote: >> >> >>> On Jan 27, 2012, at 7:17 AM, Dmitry Cherepanov wrote: >>> >>> >>>> Hello, >>>> >>>> Here's some changes to remove some stale code from the OGL pipeline. This code has been introduced as a part of the initial implementation for CALayer-based rendering and disabled by the changes for MACOSX_PORT-766. >>>> >>>> http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.1/ >>>> >>> One tiny detail: I'd recommend using -jObjectWithEnv: instead of -jObject here (because it's a little faster to not re-fetch the env): >>> + JNFCallVoidMethod(env, [self.javaLayer jObject], jm_drawInCGLContext); >>> >> On second thought, seems like -jObject simply returns the global reference that the wrapper holds without obtaining the env. What's the reason for re-fetching the env? >> > > That is correct...we are returning the global env, I had forgot about that. It doesn't seem safe though, if the wrapper gets dealloc'd while the ref is still held in a local. :-/ > > As is though, I don't think we can change the API at this point. > Thanks for the clarification. Mike Swingler wrote: > On Jan 30, 2012, at 1:52 AM, Sergey Bylokhov wrote: > >>> 124JNFCallVoidMethod(env, [self.javaLayer jObjectWithEnv:env], jm_drawInCGLContext); >>> >>> Should we delete a local reference which returned from [self.javaLayer jObjectWithEnv:env]? And check it for null? >>> >> JNFJObjectWrapper.h >> ...... >> - (jobject) jObjectWithEnv:(JNIEnv *)env; // returns a new local-ref, must be released with DeleteLocalRef >> ...... >> > I believe local refs are collected after the scope of the local function returns, so I don't believe it's strictly necessary. > > Is that right? > Seems like it's better to explicitly free local references in native callbacks. The doc in http://java.sun.com/docs/books/jni/html/refs.html#27567 ("Freeing Local References" section) describes: "Your native method does not return at all. For example, a native method may enter an infinite event dispatch loop. It is crucial to release local references created inside the loop so that they do not accumulate indefinitely, resulting in a memory leak." Here's the new webrev (with explicit releasing applied) - http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.3/ Thanks, Dmitry From michael.x.mcmahon at oracle.com Tue Jan 31 02:37:20 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 31 Jan 2012 10:37:20 +0000 Subject: RFR: 7129125 TEST_BUG: java/lang/ProcessBuilder/Zombies.java failed on linux with "No such file" Message-ID: <4F27C460.1020202@oracle.com> Can I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/7129125/webrev.1/ Our previous update to this test regressed on Linux. Thanks Michael. From artem.ananiev at oracle.com Tue Jan 31 02:42:34 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 31 Jan 2012 14:42:34 +0400 Subject: [7u-osx] Request for approval for 7124399: [macosx] All Swing drag-n-drop tests faild In-Reply-To: <4F27D124.7030602@oracle.com> References: <4F27D124.7030602@oracle.com> Message-ID: <4F27C59A.20308@oracle.com> Hi, Alex, could you add some comments about the fix to the bug evaluation, please? The problem is obviously about wrong coordinates, but it's completely unclear what exactly is wrong. Thanks, Artem On 1/31/2012 3:31 PM, Alexander Zuev wrote: > Hello, > > this is request for approval of the push for the change that fixes bug > 7124399: [macosx] All Swing drag-n-drop tests faild > > Bug description is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124399 > > Webrev for my diffs can be found here: > http://cr.openjdk.java.net/~kizune/7124399/webrev.00 > > Change was reviewed on the macosx-port-dev public alias and approved by > Alexander Potochkin > > With best regards, > Alexander Zuev From Alan.Bateman at oracle.com Tue Jan 31 02:57:57 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Jan 2012 10:57:57 +0000 Subject: RFR: 7129125 TEST_BUG: java/lang/ProcessBuilder/Zombies.java failed on linux with "No such file" In-Reply-To: <4F27C460.1020202@oracle.com> References: <4F27C460.1020202@oracle.com> Message-ID: <4F27C935.8020501@oracle.com> On 31/01/2012 10:37, Michael McMahon wrote: > Can I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/7129125/webrev.1/ > > Our previous update to this test regressed on Linux. Looks fine to me. -Alan From michael.x.mcmahon at oracle.com Tue Jan 31 03:03:06 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 31 Jan 2012 11:03:06 +0000 Subject: [jdk7u-osx] Request for approval for CR 7129125 TEST_BUG: java/lang/ProcessBuilder/Zombies.java failed on linux with "No such file" Message-ID: <4F27CA6A.9060003@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129125 Webrev: http://cr.openjdk.java.net/~michaelm/7129125/webrev.1/ Reviewed by: alanb Thanks, Michael. From artem.ananiev at oracle.com Tue Jan 31 03:10:31 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 31 Jan 2012 15:10:31 +0400 Subject: Review request for 7131793: [macosx] some cleanup in OGL pipeline code In-Reply-To: <4F27D23E.9060601@oracle.com> References: <4F22BFF0.406@oracle.com> <15184530-A44F-45DB-B1A8-FC890521D635@apple.com> <4F26A22F.9060001@oracle.com> <66F5DDAA-FE6F-448D-86BA-786052B6C9FB@apple.com> <4F27D23E.9060601@oracle.com> Message-ID: <4F27CC27.1020508@oracle.com> Looks fine. Thanks, Artem On 1/31/2012 3:36 PM, Dmitry Cherepanov wrote: > Mike Swingler wrote: >> On Jan 30, 2012, at 5:59 AM, Dmitry Cherepanov wrote: >> >>> Mike Swingler wrote: >>> >>>> On Jan 27, 2012, at 7:17 AM, Dmitry Cherepanov wrote: >>>> >>>>> Hello, >>>>> >>>>> Here's some changes to remove some stale code from the OGL >>>>> pipeline. This code has been introduced as a part of the initial >>>>> implementation for CALayer-based rendering and disabled by the >>>>> changes for MACOSX_PORT-766. >>>>> >>>>> http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.1/ >>>>> >>>> One tiny detail: I'd recommend using -jObjectWithEnv: instead of >>>> -jObject here (because it's a little faster to not re-fetch the env): >>>> + JNFCallVoidMethod(env, [self.javaLayer jObject], >>>> jm_drawInCGLContext); >>> On second thought, seems like -jObject simply returns the global >>> reference that the wrapper holds without obtaining the env. What's >>> the reason for re-fetching the env? >> >> That is correct...we are returning the global env, I had forgot about >> that. It doesn't seem safe though, if the wrapper gets dealloc'd while >> the ref is still held in a local. :-/ >> >> As is though, I don't think we can change the API at this point. > Thanks for the clarification. > > Mike Swingler wrote: >> On Jan 30, 2012, at 1:52 AM, Sergey Bylokhov wrote: >>>> 124JNFCallVoidMethod(env, [self.javaLayer jObjectWithEnv:env], >>>> jm_drawInCGLContext); >>>> >>>> Should we delete a local reference which returned from >>>> [self.javaLayer jObjectWithEnv:env]? And check it for null? >>> JNFJObjectWrapper.h >>> ...... >>> - (jobject) jObjectWithEnv:(JNIEnv *)env; // returns a new local-ref, >>> must be released with DeleteLocalRef >>> ...... >> I believe local refs are collected after the scope of the local >> function returns, so I don't believe it's strictly necessary. >> >> Is that right? > Seems like it's better to explicitly free local references in native > callbacks. The doc in > http://java.sun.com/docs/books/jni/html/refs.html#27567 ("Freeing Local > References" section) describes: > > "Your native method does not return at all. For example, a native method > may enter an infinite event dispatch loop. It is crucial to release > local references created inside the loop so that they do not accumulate > indefinitely, resulting in a memory leak." > > Here's the new webrev (with explicit releasing applied) - > http://cr.openjdk.java.net/~dcherepanov/7131793/webrev.3/ > > Thanks, > Dmitry > From alexander.zuev at oracle.com Tue Jan 31 04:13:18 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 31 Jan 2012 15:13:18 +0300 Subject: [7u-osx] Request for approval for 7124399: [macosx] All Swing drag-n-drop tests faild In-Reply-To: <4F27C59A.20308@oracle.com> References: <4F27D124.7030602@oracle.com> <4F27C59A.20308@oracle.com> Message-ID: <4F27DADE.8030308@oracle.com> Artem, just done it. WBR, Alex On 1/31/12 13:42, Artem Ananiev wrote: > Hi, Alex, > > could you add some comments about the fix to the bug evaluation, > please? The problem is obviously about wrong coordinates, but it's > completely unclear what exactly is wrong. > > Thanks, > > Artem > > On 1/31/2012 3:31 PM, Alexander Zuev wrote: >> Hello, >> >> this is request for approval of the push for the change that fixes bug >> 7124399: [macosx] All Swing drag-n-drop tests faild >> >> Bug description is here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124399 >> >> Webrev for my diffs can be found here: >> http://cr.openjdk.java.net/~kizune/7124399/webrev.00 >> >> Change was reviewed on the macosx-port-dev public alias and approved by >> Alexander Potochkin >> >> With best regards, >> Alexander Zuev From artem.ananiev at oracle.com Tue Jan 31 03:15:51 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 31 Jan 2012 15:15:51 +0400 Subject: [7u-osx] Request for approval for 7124399: [macosx] All Swing drag-n-drop tests faild In-Reply-To: <4F27DADE.8030308@oracle.com> References: <4F27D124.7030602@oracle.com> <4F27C59A.20308@oracle.com> <4F27DADE.8030308@oracle.com> Message-ID: <4F27CD67.2060702@oracle.com> On 1/31/2012 4:13 PM, Alexander Zuev wrote: > Artem, > > just done it. OK, thanks. Approved. Artem > WBR, > Alex > > On 1/31/12 13:42, Artem Ananiev wrote: >> Hi, Alex, >> >> could you add some comments about the fix to the bug evaluation, >> please? The problem is obviously about wrong coordinates, but it's >> completely unclear what exactly is wrong. >> >> Thanks, >> >> Artem >> >> On 1/31/2012 3:31 PM, Alexander Zuev wrote: >>> Hello, >>> >>> this is request for approval of the push for the change that fixes bug >>> 7124399: [macosx] All Swing drag-n-drop tests faild >>> >>> Bug description is here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124399 >>> >>> Webrev for my diffs can be found here: >>> http://cr.openjdk.java.net/~kizune/7124399/webrev.00 >>> >>> Change was reviewed on the macosx-port-dev public alias and approved by >>> Alexander Potochkin >>> >>> With best regards, >>> Alexander Zuev > From anthony.petrov at oracle.com Tue Jan 31 03:37:50 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 31 Jan 2012 15:37:50 +0400 Subject: Review request for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner In-Reply-To: <3DC2E810-8B73-4EC7-8853-B6BB2B34E2A5@oracle.com> References: <4F268233.3090707@oracle.com> <4F268779.6040909@oracle.com> <4F26B78E.9080002@oracle.com> <4F27E8A6.60708@oracle.com> <3DC2E810-8B73-4EC7-8853-B6BB2B34E2A5@oracle.com> Message-ID: <4F27D28E.9010207@oracle.com> Thanks for the ling, Leonid. Since both disposing and showing/hiding must happen on the AppKit thread, I think it makes sense to dispatch the operations directly to that thread rather than using the EDT for this purpose. But again, this change requires very careful testing. -- best regards, Anthony On 1/31/2012 1:58 PM, Leonid Romanov wrote: > Hi Anton, > Regarding your question, see > http://java.net/jira/browse/MACOSX_PORT-429 > > > On 31.01.2012, at 17:12, Anton V. Tarasov wrote: > >> Hi Anthony, >> >> On 1/30/12 6:30 PM, Anthony Petrov wrote: >>> Hi Anton, >>> >>> On 01/30/12 16:05, Anton V. Tarasov wrote: >>>> A question to the reviewers. Do we still need to invoke on EDT? >>>> 236 // it is important to call this method on EDT >>>> 237 // to prevent the deadlocks during the painting of the lightweight >>>> delegates >>>> 238 //TODO: WHY? This is a native-system related call. Perhaps NOT calling >>>> 239 // the painting procedure right from the setVisible(), but rather >>>> relying >>>> 240 // on the native Expose event (or, scheduling the repainting >>>> asynchronously) >>>> 241 // is better? >>>> 242 SwingUtilities.invokeLater(new Runnable() { >>>> 243 @Override >>>> 244 public void run() { >>>> 245 platformWindow.setVisible(visible); >>> This "WHY?..." comment was added by me long time ago. If all the invoked methods may be called on other threads I don't see a reason to dispatch this code to the EDT. However, if you wish to remove this invokeLater(), you'll have to thoroughly test that nothing is broken. >>> >>> We might want to ask Alex (CC'ed) since he added this invokeLater() originally IIRC. Is this still relevant? Doesn't the painting operation gets dispatched to the EDT automatically? May there still be any painting artifacts should the platformWindow.setVisible() be invoked on non-EDT thread? >> Oh, I see that I'm better to separate this investigation (due to the urgency of the fix). Thanks for your comments! >> >>> >>> >>>>> Please review a fix for 7129732. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ >>> At line 255 a check for !visible is unnecessary since the else branch already ensures that visible is false. >> Indeed. I added the first if-statement and forget to refine the second one. Thanks for catching this. >> >> Please, see the improved version: >> >> http://cr.openjdk.java.net/~ant/7129732/webrev.1 >> >> Thanks, >> Anton. >> >>> Otherwise looks good. >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>>>> When a focused simple window is getting closed, focus should be >>>>> transferred to the owner. >>>>> >>>>> Thanks, >>>>> Anton. >>>>> >>>>> > From anthony.petrov at oracle.com Tue Jan 31 03:38:20 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 31 Jan 2012 15:38:20 +0400 Subject: Review request for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner In-Reply-To: <4F27E8A6.60708@oracle.com> References: <4F268233.3090707@oracle.com> <4F268779.6040909@oracle.com> <4F26B78E.9080002@oracle.com> <4F27E8A6.60708@oracle.com> Message-ID: <4F27D2AC.4040503@oracle.com> On 1/31/2012 5:12 PM, Anton V. Tarasov wrote: >>>> Please review a fix for 7129732. >>>> >>>> webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ >> >> At line 255 a check for !visible is unnecessary since the else branch >> already ensures that visible is false. > > Indeed. I added the first if-statement and forget to refine the second > one. Thanks for catching this. > > Please, see the improved version: > > http://cr.openjdk.java.net/~ant/7129732/webrev.1 Looks fine. -- best regards, Anthony > > Thanks, > Anton. > >> >> Otherwise looks good. >> >> -- >> best regards, >> Anthony >> >> >>>> >>>> When a focused simple window is getting closed, focus should be >>>> transferred to the owner. >>>> >>>> Thanks, >>>> Anton. >>>> >>>> >>> > From anthony.petrov at oracle.com Tue Jan 31 03:45:13 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 31 Jan 2012 15:45:13 +0400 Subject: [7u-osx] Request for approval for 7132809: [macosx] MAXIMIZED_BOTH set before setVisible(true) hides Frame Message-ID: <4F27D449.7040304@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132809 http://cr.openjdk.java.net/~anthony/x-11-MaximizedBoth-7132809.1/ Technical review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002500.html -- best regards, Anthony From anthony.petrov at oracle.com Tue Jan 31 03:50:46 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 31 Jan 2012 15:50:46 +0400 Subject: Review request for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner In-Reply-To: <4F27D28E.9010207@oracle.com> References: <4F268233.3090707@oracle.com> <4F268779.6040909@oracle.com> <4F26B78E.9080002@oracle.com> <4F27E8A6.60708@oracle.com> <3DC2E810-8B73-4EC7-8853-B6BB2B34E2A5@oracle.com> <4F27D28E.9010207@oracle.com> Message-ID: <4F27D596.9050201@oracle.com> On 1/31/2012 3:37 PM, Anthony Petrov wrote: > Thanks for the ling, Leonid. Since both disposing and showing/hiding s/ling/link/ -- best regards, Anthony > must happen on the AppKit thread, I think it makes sense to dispatch the > operations directly to that thread rather than using the EDT for this > purpose. > > But again, this change requires very careful testing. > > -- > best regards, > Anthony > > On 1/31/2012 1:58 PM, Leonid Romanov wrote: >> Hi Anton, >> Regarding your question, see >> http://java.net/jira/browse/MACOSX_PORT-429 >> >> >> On 31.01.2012, at 17:12, Anton V. Tarasov wrote: >> >>> Hi Anthony, >>> >>> On 1/30/12 6:30 PM, Anthony Petrov wrote: >>>> Hi Anton, >>>> >>>> On 01/30/12 16:05, Anton V. Tarasov wrote: >>>>> A question to the reviewers. Do we still need to invoke on EDT? >>>>> 236 // it is important to call this method on EDT >>>>> 237 // to prevent the deadlocks during the painting of the lightweight >>>>> delegates >>>>> 238 //TODO: WHY? This is a native-system related call. Perhaps NOT >>>>> calling >>>>> 239 // the painting procedure right from the setVisible(), but rather >>>>> relying >>>>> 240 // on the native Expose event (or, scheduling the repainting >>>>> asynchronously) >>>>> 241 // is better? >>>>> 242 SwingUtilities.invokeLater(new Runnable() { >>>>> 243 @Override >>>>> 244 public void run() { >>>>> 245 platformWindow.setVisible(visible); >>>> This "WHY?..." comment was added by me long time ago. If all the >>>> invoked methods may be called on other threads I don't see a reason >>>> to dispatch this code to the EDT. However, if you wish to remove >>>> this invokeLater(), you'll have to thoroughly test that nothing is >>>> broken. >>>> >>>> We might want to ask Alex (CC'ed) since he added this invokeLater() >>>> originally IIRC. Is this still relevant? Doesn't the painting >>>> operation gets dispatched to the EDT automatically? May there still >>>> be any painting artifacts should the platformWindow.setVisible() be >>>> invoked on non-EDT thread? >>> Oh, I see that I'm better to separate this investigation (due to the >>> urgency of the fix). Thanks for your comments! >>> >>>> >>>> >>>>>> Please review a fix for 7129732. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ >>>> At line 255 a check for !visible is unnecessary since the else >>>> branch already ensures that visible is false. >>> Indeed. I added the first if-statement and forget to refine the >>> second one. Thanks for catching this. >>> >>> Please, see the improved version: >>> >>> http://cr.openjdk.java.net/~ant/7129732/webrev.1 >>> >>> Thanks, >>> Anton. >>> >>>> Otherwise looks good. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> >>>>>> When a focused simple window is getting closed, focus should be >>>>>> transferred to the owner. >>>>>> >>>>>> Thanks, >>>>>> Anton. >>>>>> >>>>>> >> From alexander.zuev at oracle.com Tue Jan 31 05:14:27 2012 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 31 Jan 2012 13:14:27 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7124399: [macosx] All Swing drag-n-drop tests faild Message-ID: <20120131131441.7DAB5472AF@hg.openjdk.java.net> Changeset: 4c06f31fd3a2 Author: kizune Date: 2012-01-31 17:15 +0300 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/4c06f31fd3a2 7124399: [macosx] All Swing drag-n-drop tests faild Reviewed-by: alexp ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java ! src/macosx/native/sun/awt/CDropTarget.m From anton.tarasov at oracle.com Tue Jan 31 05:45:18 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 31 Jan 2012 17:45:18 +0400 Subject: Review request for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner In-Reply-To: <4F27BA0E.4000200@oracle.com> References: <4F268233.3090707@oracle.com> <4F268779.6040909@oracle.com> <4F26B78E.9080002@oracle.com> <4F27E8A6.60708@oracle.com> <4F27BA0E.4000200@oracle.com> Message-ID: <4F27F06E.5090305@oracle.com> On 31.01.2012 13:53, Artem Ananiev wrote: > > The fix looks fine. > > Unrelated question: should LWWindowPeer.updateFocusableWindowState() be called before > platformWindow.setVisible()? Due to a simple window is unfocusable in terms of cocoa, its showing doesn't make it focused. So, the order of the above calls is actually unimportant. What is important is to call updateFocusableWindowState() before changeFocusedWindow(...). Thanks, Anton. > > Thanks, > > Artem > > On 1/31/2012 5:12 PM, Anton V. Tarasov wrote: >> Hi Anthony, >> >> On 1/30/12 6:30 PM, Anthony Petrov wrote: >>> Hi Anton, >>> >>> On 01/30/12 16:05, Anton V. Tarasov wrote: >>>> A question to the reviewers. Do we still need to invoke on EDT? >>>> 236 // it is important to call this method on EDT >>>> 237 // to prevent the deadlocks during the painting of the lightweight >>>> delegates >>>> 238 //TODO: WHY? This is a native-system related call. Perhaps NOT >>>> calling >>>> 239 // the painting procedure right from the setVisible(), but rather >>>> relying >>>> 240 // on the native Expose event (or, scheduling the repainting >>>> asynchronously) >>>> 241 // is better? >>>> 242 SwingUtilities.invokeLater(new Runnable() { >>>> 243 @Override >>>> 244 public void run() { >>>> 245 platformWindow.setVisible(visible); >>> >>> This "WHY?..." comment was added by me long time ago. If all the >>> invoked methods may be called on other threads I don't see a reason to >>> dispatch this code to the EDT. However, if you wish to remove this >>> invokeLater(), you'll have to thoroughly test that nothing is broken. >>> >>> We might want to ask Alex (CC'ed) since he added this invokeLater() >>> originally IIRC. Is this still relevant? Doesn't the painting >>> operation gets dispatched to the EDT automatically? May there still be >>> any painting artifacts should the platformWindow.setVisible() be >>> invoked on non-EDT thread? >> >> Oh, I see that I'm better to separate this investigation (due to the >> urgency of the fix). Thanks for your comments! >> >>> >>> >>> >>>>> Please review a fix for 7129732. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ >>> >>> At line 255 a check for !visible is unnecessary since the else branch >>> already ensures that visible is false. >> >> Indeed. I added the first if-statement and forget to refine the second >> one. Thanks for catching this. >> >> Please, see the improved version: >> >> http://cr.openjdk.java.net/~ant/7129732/webrev.1 >> >> Thanks, >> Anton. >> >>> >>> Otherwise looks good. >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>>>> >>>>> When a focused simple window is getting closed, focus should be >>>>> transferred to the owner. >>>>> >>>>> Thanks, >>>>> Anton. >>>>> >>>>> >>>> >> From anton.tarasov at oracle.com Tue Jan 31 05:48:40 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 31 Jan 2012 17:48:40 +0400 Subject: Review request for 7129732 - [macosx] JCK failure: no focus transfer back to Window owner In-Reply-To: <3DC2E810-8B73-4EC7-8853-B6BB2B34E2A5@oracle.com> References: <4F268233.3090707@oracle.com> <4F268779.6040909@oracle.com> <4F26B78E.9080002@oracle.com> <4F27E8A6.60708@oracle.com> <3DC2E810-8B73-4EC7-8853-B6BB2B34E2A5@oracle.com> Message-ID: <4F27F138.6090605@oracle.com> Hi Leonid, Thanks for the reference. I thought it's better yet to separate this issue from this CR (as it turned to be not a simple question). Thanks, Anton. On 31.01.2012 13:58, Leonid Romanov wrote: > Hi Anton, > Regarding your question, see > http://java.net/jira/browse/MACOSX_PORT-429 > > > On 31.01.2012, at 17:12, Anton V. Tarasov wrote: > >> Hi Anthony, >> >> On 1/30/12 6:30 PM, Anthony Petrov wrote: >>> Hi Anton, >>> >>> On 01/30/12 16:05, Anton V. Tarasov wrote: >>>> A question to the reviewers. Do we still need to invoke on EDT? >>>> 236 // it is important to call this method on EDT >>>> 237 // to prevent the deadlocks during the painting of the lightweight >>>> delegates >>>> 238 //TODO: WHY? This is a native-system related call. Perhaps NOT calling >>>> 239 // the painting procedure right from the setVisible(), but rather >>>> relying >>>> 240 // on the native Expose event (or, scheduling the repainting >>>> asynchronously) >>>> 241 // is better? >>>> 242 SwingUtilities.invokeLater(new Runnable() { >>>> 243 @Override >>>> 244 public void run() { >>>> 245 platformWindow.setVisible(visible); >>> This "WHY?..." comment was added by me long time ago. If all the invoked methods may be called on other threads I don't see a reason to dispatch this code to the EDT. However, if you wish to remove this invokeLater(), you'll have to thoroughly test that nothing is broken. >>> >>> We might want to ask Alex (CC'ed) since he added this invokeLater() originally IIRC. Is this still relevant? Doesn't the painting operation gets dispatched to the EDT automatically? May there still be any painting artifacts should the platformWindow.setVisible() be invoked on non-EDT thread? >> Oh, I see that I'm better to separate this investigation (due to the urgency of the fix). Thanks for your comments! >> >>> >>> >>>>> Please review a fix for 7129732. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ant/7129732/webrev.0/ >>> At line 255 a check for !visible is unnecessary since the else branch already ensures that visible is false. >> Indeed. I added the first if-statement and forget to refine the second one. Thanks for catching this. >> >> Please, see the improved version: >> >> http://cr.openjdk.java.net/~ant/7129732/webrev.1 >> >> Thanks, >> Anton. >> >>> Otherwise looks good. >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>>>> When a focused simple window is getting closed, focus should be >>>>> transferred to the owner. >>>>> >>>>> Thanks, >>>>> Anton. >>>>> >>>>> From paul.hohensee at oracle.com Tue Jan 31 06:24:42 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 31 Jan 2012 09:24:42 -0500 Subject: [jdk7u-osx] Request for approval for CR 7129125 TEST_BUG: java/lang/ProcessBuilder/Zombies.java failed on linux with "No such file" In-Reply-To: <4F27CA6A.9060003@oracle.com> References: <4F27CA6A.9060003@oracle.com> Message-ID: <4F27F9AA.80405@oracle.com> Approved. Paul On 1/31/12 6:03 AM, Michael McMahon wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129125 > > Webrev: http://cr.openjdk.java.net/~michaelm/7129125/webrev.1/ > > Reviewed by: alanb > > Thanks, > Michael. From michael.x.mcmahon at oracle.com Tue Jan 31 06:27:24 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 31 Jan 2012 14:27:24 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 2 new changesets Message-ID: <20120131142754.19A09472B1@hg.openjdk.java.net> Changeset: afcc933a944e Author: michaelm Date: 2012-01-31 14:26 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/afcc933a944e 7129125: TEST_BUG: java/lang/ProcessBuilder/Zombies.java failed on linux with "No such file" Reviewed-by: alanb ! test/java/lang/ProcessBuilder/Zombies.java Changeset: 42a19b1e0a7b Author: michaelm Date: 2012-01-31 14:26 +0000 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/42a19b1e0a7b Merge From artem.ananiev at oracle.com Tue Jan 31 06:36:10 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 31 Jan 2012 18:36:10 +0400 Subject: [7u-osx] Request for approval for 7132809: [macosx] MAXIMIZED_BOTH set before setVisible(true) hides Frame In-Reply-To: <4F27D449.7040304@oracle.com> References: <4F27D449.7040304@oracle.com> Message-ID: <4F27FC5A.4050404@oracle.com> Approved. On 1/31/2012 3:45 PM, Anthony Petrov wrote: > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132809 > > http://cr.openjdk.java.net/~anthony/x-11-MaximizedBoth-7132809.1/ > > Technical review thread: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002500.html > > > -- > best regards, > Anthony > From oleg.pekhovskiy at oracle.com Tue Jan 31 06:58:50 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Tue, 31 Jan 2012 18:58:50 +0400 Subject: Code Review Request for CR 7132367 (v1) - [macosx] ChoiceMouseWheelTest should be adapted for mac toolkit Message-ID: <4F2801AA.6050205@oracle.com> Hi guys, here is the second version of fix for the CR: http://bugs.sun.com/view_bug.do?bug_id=7132367 Comments regarding test behavior for Mac platform added. Issue 7141296 about improper mouse wheel work for combobox's drop-down list added. Patch with changes attached. Thanks, Oleg -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 7132367.patch Url: http://mail.openjdk.java.net/pipermail/macosx-port-dev/attachments/20120131/129599a1/7132367-0001.patch From anthony.petrov at oracle.com Tue Jan 31 07:57:18 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 31 Jan 2012 19:57:18 +0400 Subject: Review request for 7122250: [macosx] mouseMoved Events test do not respond in JCK-runtime-7 interactive Message-ID: <4F280F5E.2020209@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7122250 at: http://cr.openjdk.java.net/~anthony/x-13-mouseEnterExit-7122250.0/ The root cause of the issue is that AWTView is missing an overridden -updateTrackingAreas method that should update the tracking rectangle. Adding the override resolves the issue: the mouseEntered/Exited events for Window/JWindow instances start to be delivered to Java app. -- best regards, Anthony From alexander.zuev at oracle.com Tue Jan 31 08:04:16 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 31 Jan 2012 20:04:16 +0400 Subject: Review request for 7122250: [macosx] mouseMoved Events test do not respond in JCK-runtime-7 interactive In-Reply-To: <4F280F5E.2020209@oracle.com> References: <4F280F5E.2020209@oracle.com> Message-ID: Looks great. With best regards, Alexander Zuev 31.01.2012, ? 19:57, Anthony Petrov ???????(?): > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7122250 at: > > http://cr.openjdk.java.net/~anthony/x-13-mouseEnterExit-7122250.0/ > > The root cause of the issue is that AWTView is missing an overridden -updateTrackingAreas method that should update the tracking rectangle. Adding the override resolves the issue: the mouseEntered/Exited events for Window/JWindow instances start to be delivered to Java app. > > -- > best regards, > Anthony From anthony.petrov at oracle.com Tue Jan 31 08:18:01 2012 From: anthony.petrov at oracle.com (anthony.petrov at oracle.com) Date: Tue, 31 Jan 2012 16:18:01 +0000 Subject: hg: jdk7u/jdk7u-osx/jdk: 7132809: [macosx] MAXIMIZED_BOTH set before setVisible(true) hides Frame Message-ID: <20120131161824.82107472B6@hg.openjdk.java.net> Changeset: 611d9bf5b908 Author: anthony Date: 2012-01-31 20:17 +0400 URL: http://hg.openjdk.java.net/jdk7u/jdk7u-osx/jdk/rev/611d9bf5b908 7132809: [macosx] MAXIMIZED_BOTH set before setVisible(true) hides Frame Summary: Apply the extended state only when window is visible Reviewed-by: art ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java From Alexander.Potochkin at oracle.com Tue Jan 31 08:35:51 2012 From: Alexander.Potochkin at oracle.com (Alexander Potochkin) Date: Tue, 31 Jan 2012 20:35:51 +0400 Subject: Review request for 7122250: [macosx] mouseMoved Events test do not respond in JCK-runtime-7 interactive In-Reply-To: <4F280F5E.2020209@oracle.com> References: <4F280F5E.2020209@oracle.com> Message-ID: <4F281867.7050803@oracle.com> Hello Anthony I tested the fix, it works like a charm! Thanks alexp > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7122250 > at: > > http://cr.openjdk.java.net/~anthony/x-13-mouseEnterExit-7122250.0/ > > The root cause of the issue is that AWTView is missing an overridden > -updateTrackingAreas method that should update the tracking rectangle. > Adding the override resolves the issue: the mouseEntered/Exited events > for Window/JWindow instances start to be delivered to Java app. > > -- > best regards, > Anthony From anthony.petrov at oracle.com Tue Jan 31 09:01:18 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 31 Jan 2012 21:01:18 +0400 Subject: [7u-osx] Request for approval for 7122250: [macosx] mouseMoved Events test do not respond in JCK-runtime-7 interactive Message-ID: <4F281E5E.3020204@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122250 http://cr.openjdk.java.net/~anthony/x-13-mouseEnterExit-7122250.0/ Technical review thread: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002671.html -- best regards, Anthony From dmitry.cherepanov at oracle.com Tue Jan 31 11:04:38 2012 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Tue, 31 Jan 2012 22:04:38 +0300 Subject: Review request for 7124236: [macosx] Some components lost shadows after the latest fix of translucent windows. Message-ID: <4F283B46.5030401@oracle.com> The cause of the problem with broken shadows is that currently NSWindow's background color is [NSWindow clearColor] and it makes shadows invisible. The fix implements Mike's suggestion and now we draw pure transparent pixels into a CALayer so that the native background color will be visible through transparent areas of the CALayer. http://cr.openjdk.java.net/~dcherepanov/7124236/webrev.0/ Thanks, Dmitry From kurchi.subhra.hazra at oracle.com Tue Jan 31 10:41:05 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 31 Jan 2012 10:41:05 -0800 Subject: Code Review Request: 7141071: TEST_BUG: update shell scripts in java/nio/charset to detect Mac OS as a valid platform Message-ID: <4F2835C1.9000400@oracle.com> Resending this request. - Kurchi -------- Original Message -------- Subject: Code Review Request: 7141071: TEST_BUG: update shell scripts in java/nio/charset to detect Mac OS as a valid platform Date: Mon, 30 Jan 2012 13:58:34 -0800 From: Kurchi Hazra Organization: Oracle Corporation To: macosx-port-dev at openjdk.java.net Hi, This fix updates two scripts to recognize Mac OS (Darwin) as a valid platform. Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141071 Webrev : http://cr.openjdk.java.net/~khazra/7141071/webrev.00/ Thanks, Kurchi From Alan.Bateman at oracle.com Tue Jan 31 10:51:10 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Jan 2012 18:51:10 +0000 Subject: Code Review Request: 7141071: TEST_BUG: update shell scripts in java/nio/charset to detect Mac OS as a valid platform In-Reply-To: <4F2835C1.9000400@oracle.com> References: <4F2835C1.9000400@oracle.com> Message-ID: <4F28381E.1050704@oracle.com> On 31/01/2012 18:41, Kurchi Hazra wrote: > : > > > Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141071 > > Webrev : http://cr.openjdk.java.net/~khazra/7141071/webrev.00/ There's a comment in CheckSJISMappingProp.sh that mentions Linux and Solaris that should probably be updated. Otherwise looks good to me. -Alan From swingler at apple.com Tue Jan 31 10:52:49 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 31 Jan 2012 10:52:49 -0800 Subject: Review request for 7124236: [macosx] Some components lost shadows after the latest fix of translucent windows. In-Reply-To: <4F283B46.5030401@oracle.com> References: <4F283B46.5030401@oracle.com> Message-ID: On Jan 31, 2012, at 11:04 AM, Dmitry Cherepanov wrote: > The cause of the problem with broken shadows is that currently NSWindow's background color is [NSWindow clearColor] and it makes shadows invisible. The fix implements Mike's suggestion and now we draw pure transparent pixels into a CALayer so that the native background color will be visible through transparent areas of the CALayer. > > http://cr.openjdk.java.net/~dcherepanov/7124236/webrev.0/ Looks great. Cheers, Mike Swingler Apple Inc. From kurchi.subhra.hazra at oracle.com Tue Jan 31 11:07:27 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 31 Jan 2012 11:07:27 -0800 Subject: Code Review Request: 7141071: TEST_BUG: update shell scripts in java/nio/charset to detect Mac OS as a valid platform In-Reply-To: <4F28381E.1050704@oracle.com> References: <4F2835C1.9000400@oracle.com> <4F28381E.1050704@oracle.com> Message-ID: <4F283BEF.6050101@oracle.com> Updated webrev: http://cr.openjdk.java.net/~khazra/7141071/webrev.01/ - Kurchi On 1/31/2012 10:51 AM, Alan Bateman wrote: > On 31/01/2012 18:41, Kurchi Hazra wrote: >> : >> >> >> Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141071 >> >> Webrev : http://cr.openjdk.java.net/~khazra/7141071/webrev.00/ > There's a comment in CheckSJISMappingProp.sh that mentions Linux and > Solaris that should probably be updated. Otherwise looks good to me. > > -Alan -- -Kurchi From kurchi.subhra.hazra at oracle.com Tue Jan 31 11:42:05 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 31 Jan 2012 11:42:05 -0800 Subject: Code Review Request: 7141413: [macosx] Regression test java/rmi/registry/readTest/readTest.sh failing on Mac OS X Message-ID: <4F28440D.3040904@oracle.com> Hi, This fix updates readTest.sh file to recognize Mac OS (Darwin) as a valid platform. Bug :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141413 Webrev :http://cr.openjdk.java.net/~khazra/7141413/webrev.00/ Thanks, Kurchi From Alan.Bateman at oracle.com Tue Jan 31 12:08:09 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Jan 2012 20:08:09 +0000 Subject: Code Review Request: 7141071: TEST_BUG: update shell scripts in java/nio/charset to detect Mac OS as a valid platform In-Reply-To: <4F283BEF.6050101@oracle.com> References: <4F2835C1.9000400@oracle.com> <4F28381E.1050704@oracle.com> <4F283BEF.6050101@oracle.com> Message-ID: <4F284A29.9050207@oracle.com> On 31/01/2012 19:07, Kurchi Hazra wrote: > Updated webrev: http://cr.openjdk.java.net/~khazra/7141071/webrev.01/ > > - Kurchi > Looks fine. From alexander.zuev at oracle.com Tue Jan 31 12:10:33 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 01 Feb 2012 00:10:33 +0400 Subject: Review request for 7124236: [macosx] Some components lost shadows after the latest fix of translucent windows. In-Reply-To: <4F283B46.5030401@oracle.com> References: <4F283B46.5030401@oracle.com> Message-ID: <4F284AB9.8090206@oracle.com> Dmitry, looks great for me. WBR, Alex On 31.01.2012 23:04, Dmitry Cherepanov wrote: > The cause of the problem with broken shadows is that currently > NSWindow's background color is [NSWindow clearColor] and it makes > shadows invisible. The fix implements Mike's suggestion and now we > draw pure transparent pixels into a CALayer so that the native > background color will be visible through transparent areas of the > CALayer. > > http://cr.openjdk.java.net/~dcherepanov/7124236/webrev.0/ > > Thanks, > Dmitry > From Alan.Bateman at oracle.com Tue Jan 31 12:11:16 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Jan 2012 20:11:16 +0000 Subject: Code Review Request: 7141413: [macosx] Regression test java/rmi/registry/readTest/readTest.sh failing on Mac OS X In-Reply-To: <4F28440D.3040904@oracle.com> References: <4F28440D.3040904@oracle.com> Message-ID: <4F284AE4.9020406@oracle.com> On 31/01/2012 19:42, Kurchi Hazra wrote: > > Hi, > > This fix updates readTest.sh file to recognize Mac OS (Darwin) as a > valid platform. > > > Bug :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141413 > > Webrev :http://cr.openjdk.java.net/~khazra/7141413/webrev.00/ > Looks fine to me. -Alan From kurchi.subhra.hazra at oracle.com Tue Jan 31 12:40:27 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 31 Jan 2012 12:40:27 -0800 Subject: Code Review Request: 7141465:[macosx] com/sun/jdi/PrivateTransportTest.sh fails on Mac OS X Message-ID: <4F2851BB.1030902@oracle.com> Hi, This fix updates com/sun/jdi/PrivateTransportTest.sh file to run on Mac OS (Darwin). Bug :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141465 Webrev :http://cr.openjdk.java.net/~khazra/7141465/webrev.00/ Thanks, Kurchi From Alan.Bateman at oracle.com Tue Jan 31 12:50:34 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Jan 2012 20:50:34 +0000 Subject: 7141462: ProblemList.txt updates to exclude tests that cause test runs to hang [macosx] Message-ID: <4F28541A.6080004@oracle.com> Currently it's not possible to run some of the test targets that run the tests in agentvm mode, in particular the jdk_util and jdk_nio make file targets can cause jtreg to hang. I've looked briefly into these issues and see that there are at least three separate issues: 1. Asynchronous close of FileChannel operations as this is not fully implemented on Mac, in particular dup2 will hang if another thread is doing a blocking operation 2. A rouge test spins doing System.gc (this test is fixed in jdk8, just not back-ported jdk7u). 3. A strange hang loading libawt when Class.forName("") triggers the load. In order to make some progress I would like the test that cause these issues to the ProblemList. All it means is that they excluded when running the tests via the Makefile. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/7141462/webrev/ Thanks, Alan. From Alan.Bateman at oracle.com Tue Jan 31 12:56:39 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Jan 2012 20:56:39 +0000 Subject: Code Review Request: 7141465:[macosx] com/sun/jdi/PrivateTransportTest.sh fails on Mac OS X In-Reply-To: <4F2851BB.1030902@oracle.com> References: <4F2851BB.1030902@oracle.com> Message-ID: <4F285587.8040706@oracle.com> On 31/01/2012 20:40, Kurchi Hazra wrote: > > Hi, > > This fix updates com/sun/jdi/PrivateTransportTest.sh file to run on > Mac OS (Darwin). > > > Bug :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141465 > > Webrev :http://cr.openjdk.java.net/~khazra/7141465/webrev.00/ I'mnot sure that ${TESTJAVA}/j2sdk-image/1.7.0.jdk/Contents/Home/jre is right, shouldn't TESTJAVA point to the Home directory? The rest of it looks okay to me. -Alan From scott.kovatch at oracle.com Tue Jan 31 13:22:54 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 31 Jan 2012 13:22:54 -0800 Subject: Code Review Request: 7141465:[macosx] com/sun/jdi/PrivateTransportTest.sh fails on Mac OS X In-Reply-To: <4F285587.8040706@oracle.com> References: <4F2851BB.1030902@oracle.com> <4F285587.8040706@oracle.com> Message-ID: On Jan 31, 2012, at 12:56 PM, Alan Bateman wrote: > On 31/01/2012 20:40, Kurchi Hazra wrote: >> >> Hi, >> >> This fix updates com/sun/jdi/PrivateTransportTest.sh file to run on Mac OS (Darwin). >> >> >> Bug :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141465 >> >> Webrev :http://cr.openjdk.java.net/~khazra/7141465/webrev.00/ > I'mnot sure that ${TESTJAVA}/j2sdk-image/1.7.0.jdk/Contents/Home/jre is right, shouldn't TESTJAVA point to the Home directory? The rest of it looks okay to me. This will break, eventually. We need to adjust the build so the bundled JDK is built to j2sdk-bundles, and j2sdk-image remains stable throughout the build. It will also break if the name of the bundle changes, which is also planned. See 7133768 and 7128699, respectively. -- Scott K. From kurchi.subhra.hazra at oracle.com Tue Jan 31 13:42:29 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 31 Jan 2012 13:42:29 -0800 Subject: Code Review Request: 7141465:[macosx] com/sun/jdi/PrivateTransportTest.sh fails on Mac OS X In-Reply-To: References: <4F2851BB.1030902@oracle.com> <4F285587.8040706@oracle.com> Message-ID: <4F286045.6060609@oracle.com> Right, I did not need to change jreloc at all. Updated webrev: http://cr.openjdk.java.net/~khazra/7141465/webrev.02 - Kurchi On 1/31/2012 1:22 PM, Scott Kovatch wrote: > On Jan 31, 2012, at 12:56 PM, Alan Bateman wrote: > >> On 31/01/2012 20:40, Kurchi Hazra wrote: >>> Hi, >>> >>> This fix updates com/sun/jdi/PrivateTransportTest.sh file to run on Mac OS (Darwin). >>> >>> >>> Bug :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141465 >>> >>> Webrev :http://cr.openjdk.java.net/~khazra/7141465/webrev.00/ >> I'mnot sure that ${TESTJAVA}/j2sdk-image/1.7.0.jdk/Contents/Home/jre is right, shouldn't TESTJAVA point to the Home directory? The rest of it looks okay to me. > This will break, eventually. We need to adjust the build so the bundled JDK is built to j2sdk-bundles, and j2sdk-image remains stable throughout the build. It will also break if the name of the bundle changes, which is also planned. See 7133768 and 7128699, respectively. > > -- Scott K. > -- -Kurchi From kurchi.subhra.hazra at oracle.com Tue Jan 31 13:52:20 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 31 Jan 2012 13:52:20 -0800 Subject: [7u4-osx] Request for approval for 7141071 : TEST_BUG: TEST_BUG: update shell scripts in java/nio/charset to detect Mac OS as a valid platform Message-ID: <4F286294.4000805@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141071 Webrev:http://cr.openjdk.java.net/~khazra/7141071/webrev.01/ Reviewed by: alanb This changeset will be pushed on my behalf by Michael McMahon (michaelm). Thanks, Kurchi From kurchi.subhra.hazra at oracle.com Tue Jan 31 13:58:36 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 31 Jan 2012 13:58:36 -0800 Subject: [7u4-osx] Request for approval for 7141413 : [macosx] Regression test java/rmi/registry/readTest/readTest.sh failing on Mac OS X Message-ID: <4F28640C.6050401@oracle.com> This is a request to push the following fix to jdk7u-osx: CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141413 Webrev:http://cr.openjdk.java.net/~khazra/7141413/webrev.00/ Reviewed by: alanb This changeset will be pushed on my behalf by Michael McMahon (michaelm). Thanks, Kurchi From swingler at apple.com Tue Jan 31 14:18:45 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 31 Jan 2012 14:18:45 -0800 Subject: Bundled app launcher changes In-Reply-To: <01238DD0-65D6-42A5-A69F-E2DCE6B93776@oracle.com> References: <01238DD0-65D6-42A5-A69F-E2DCE6B93776@oracle.com> Message-ID: <9B09FE7E-34D0-4BC4-A679-AB4F507C8062@apple.com> On Jan 30, 2012, at 9:30 AM, Scott Kovatch wrote: > Hello, > > Greg Brown has been busy working on an Ant task for creating a Mac .app bundle. As a preview, here's an example of it in use: > > name="SwingSet2" > displayname="SwingSet 2" > identifier="com.oracle.javax.swing.SwingSet2" > icon="JavaAppLauncher/resources/GenericApp.icns" > shortversion="1.0" > runtime="${env.JAVA_HOME}/../.." The "runtime" should only be specified if you are providing a full path to a different one. Also, there should be a way to specify if you only want to bundle the JRE, or if you need a full JDK. This will change the output tag in the Info.plist, and will change what is copied from what location. > mainclass="SwingSet2"> > > > > > There should be a way to add a number of jars to the classpath, which will implicitly get copied into (bundle)/Contents/Java. Is that just by adding more tags? Should there be an affordance for specifying non-jar/non-classpath resources that should also get copied into (bundle)/Contents/Java? It may make sense to provide a tag for art or other Mac-specific resources to be copied into (bundle).app/Contents/Resources. Or perhaps just a tag that takes a source and a destination. I'm also not wild about the tag name . That may be ambiguous with some sort of jar coalescing. Perhaps , or . Any other suggestions? I know you can't support this on non-Mac builders, but you should definitely plan to provide a codesigncert= argument which will sign the primary stub executable with a provided certificate. This will be Very Important to some developers. > I'm wondering where this should be checked in, though. Building an application bundle from JARs, resources, and launcher stub is really a deployment task as opposed to a pure JDK feature, but Web Start and the plugin are not open sourced so I don't see a public 'deploy' project happening in the near future. We definitely want to push this out so people can start building applications with the Mac JDK. Anyone have an opinion on that? Currently, the bundling/stub building stuff is in jdk/src/macosx/bundle in the source. That seems as good of a place as any at the moment. As far as where the physical artifacts go, I think (bundle).jdk/Contents/Home/lib/ makes sense, since other JDK tools like jconsole, tools.jar, and the .idl files live there. > Also, we are working on an simpler version of the launcher code that will reuse more of the generic/command-line launcher code in jdk/src/share/bin/java.c. Kumar Srinivasan checked in a refactoring of the command-line tools so that all of the runloop management, argument parsing, and other setup is now done in JLI_Launch. That means we can rip out the code that duplicates that work in the app launcher and call through to JLI_Launch instead. I started on this and handed it off to Greg. We should have something to share in the next week or so. Cool. I always wanted to take a hatchet to JLI_Launch(), but I'm glad someone else is on the hook for making sure it doesn't break on all the other platforms. :-) Regards, Mike Swingler Apple Inc. From paul.hohensee at oracle.com Tue Jan 31 15:40:28 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 31 Jan 2012 18:40:28 -0500 Subject: [7u4-osx] Request for approval for 7141071 : TEST_BUG: TEST_BUG: update shell scripts in java/nio/charset to detect Mac OS as a valid platform In-Reply-To: <4F286294.4000805@oracle.com> References: <4F286294.4000805@oracle.com> Message-ID: <4F287BEC.3040509@oracle.com> Approved. Paul On 1/31/12 4:52 PM, Kurchi Hazra wrote: > > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141071 > > Webrev:http://cr.openjdk.java.net/~khazra/7141071/webrev.01/ > > > Reviewed by: alanb > > This changeset will be pushed on my behalf by Michael McMahon (michaelm). > > Thanks, > Kurchi > > > > From mik3hall at gmail.com Tue Jan 31 15:45:27 2012 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 31 Jan 2012 17:45:27 -0600 Subject: Bundled app launcher changes In-Reply-To: <9B09FE7E-34D0-4BC4-A679-AB4F507C8062@apple.com> References: <01238DD0-65D6-42A5-A69F-E2DCE6B93776@oracle.com> <9B09FE7E-34D0-4BC4-A679-AB4F507C8062@apple.com> Message-ID: <680DB46D-50E4-4E8C-9672-9F5E6AB2B662@gmail.com> On Jan 31, 2012, at 4:18 PM, Mike Swingler wrote: > There should be a way to add a number of jars to the classpath, which will implicitly get copied into (bundle)/Contents/Java. Is that just by adding more tags? Should there be an affordance for specifying non-jar/non-classpath resources that should also get copied into (bundle)/Contents/Java? It may make sense to provide a tag for art or other Mac-specific resources to be copied into (bundle).app/Contents/Resources. Or perhaps just a tag that takes a source and a destination. > > I'm also not wild about the tag name . That may be ambiguous with some sort of jar coalescing. Perhaps , or . Any other suggestions? > > I know you can't support this on non-Mac builders, but you should definitely plan to provide a codesigncert= argument which will sign the primary stub executable with a provided certificate. This will be Very Important to some developers. It might be worth browsing http://informagen.com/JarBundler/ for ideas on tag names. This had some users who might be comfortable with some continuations. I used Apple's Jar Bundler so not really a big concern to me. An existant example of where this was already done for prior OS X java applications anyhow. From paul.hohensee at oracle.com Tue Jan 31 15:45:45 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 31 Jan 2012 18:45:45 -0500 Subject: [7u4-osx] Request for approval for 7141413 : [macosx] Regression test java/rmi/registry/readTest/readTest.sh failing on Mac OS X In-Reply-To: <4F28640C.6050401@oracle.com> References: <4F28640C.6050401@oracle.com> Message-ID: <4F287D29.2050801@oracle.com> Approved. Paul On 1/31/12 4:58 PM, Kurchi Hazra wrote: > > This is a request to push the following fix to jdk7u-osx: > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7141413 > > Webrev:http://cr.openjdk.java.net/~khazra/7141413/webrev.00/ > > > Reviewed by: alanb > > This changeset will be pushed on my behalf by Michael McMahon (michaelm). > > Thanks, > Kurchi > > > > >