From paul_t100 at fastmail.fm Fri Oct 5 05:07:23 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 05 Oct 2012 13:07:23 +0100 Subject: OSX not placing windows of Swing application in a sensible location Message-ID: <506ECD7B.1050901@fastmail.fm> Using 1.7.0_10-ea-b08 I made a change in the code of my Gui application so that instead of trying to centre windows myself I let the OS choose where to out it, this works okay for Windows, but it doesn't look right to me on OSX. Windows: First window displays in the left handcorner, but not right in the corner Open another window within the application the window is displayed so that it overlaps the first window but its top left hand corner is slightly down and to the right. OSX First window displays right in the top left hand corner Open another window , displays in exactly the same place completely obscuring the first window. I don't know what the behaviour should be on OSX but this appears incorrect Paul From anthony.petrov at oracle.com Fri Oct 5 05:30:25 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 05 Oct 2012 16:30:25 +0400 Subject: OSX not placing windows of Swing application in a sensible location In-Reply-To: <506ECD7B.1050901@fastmail.fm> References: <506ECD7B.1050901@fastmail.fm> Message-ID: <506ED2E1.5050303@oracle.com> Please file a bug at http://bugs.sun.com/ -- best regards, Anthony On 10/5/2012 4:07 PM, Paul Taylor wrote: > Using 1.7.0_10-ea-b08 > > I made a change in the code of my Gui application so that instead of > trying to centre windows myself I let the OS choose where to out it, > this works okay for Windows, but it doesn't look right to me on OSX. > > Windows: > > First window displays in the left handcorner, but not right in the corner > Open another window within the application the window is displayed so > that it overlaps the first window but its top left hand corner is > slightly down and to the right. > > OSX > First window displays right in the top left hand corner > Open another window , displays in exactly the same place completely > obscuring the first window. > > > I don't know what the behaviour should be on OSX but this appears incorrect > > Paul From steve at weblite.ca Sat Oct 6 14:08:49 2012 From: steve at weblite.ca (Steve Hannah) Date: Sat, 6 Oct 2012 14:08:49 -0700 Subject: JNI wrapper for NSSavePanel Message-ID: Hi all, I'm trying create a JNI wrapper function for NSSavePanel. I'm trying to figure out why it causes a crash with EXC_BAD_ACCESS if I wrap the method with JNF_COCOA_ENTER(env) and JNF_COCOA_EXIT(env), but works fine if I just wrap it in @autoreleasepool {}. I have posted source for both versions of the method at https://gist.github.com/3846116. Can anyone give me some pointers on where I'm going wrong. I suspect that I'm using JNF_COCOA_ENTER/EXIT improperly. Thanks for any responses. -Steve -- Steve Hannah Web Lite Solutions Corp. From steve at weblite.ca Sat Oct 6 14:56:53 2012 From: steve at weblite.ca (Steve Hannah) Date: Sat, 6 Oct 2012 14:56:53 -0700 Subject: JDK 7 default log file location on Mountain Lion Message-ID: Hi all, On Lion and earlier, all output to System.out or System.err (including exceptions) would be visible in console. On mountain lion, I can't seem to find where this output is logged by default (i.e. if I go to Console and click "All messages", it doesn't report any output from my apps). Does anyone know where this has moved? Thanks for your help. -Steve From paul_t100 at fastmail.fm Sat Oct 6 15:07:17 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sat, 06 Oct 2012 23:07:17 +0100 Subject: JDK 7 default log file location on Mountain Lion In-Reply-To: References: Message-ID: <5070AB95.1050806@fastmail.fm> On 06/10/2012 22:56, Steve Hannah wrote: > Hi all, > > On Lion and earlier, all output to System.out or System.err (including > exceptions) would be visible in console. On mountain lion, I can't seem to > find where this output is logged by default (i.e. if I go to Console and > click "All messages", it doesn't report any output from my apps). Does > anyone know where this has moved? > > Thanks for your help. > > -Steve > No, but I raised the same issue on the Apple Java mailing list and although no definietive answer I dont think the problem is with Java 7 port, it also exists for Java 6 Paul From mik3hall at gmail.com Sat Oct 6 15:11:48 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 6 Oct 2012 17:11:48 -0500 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: Message-ID: On Oct 6, 2012, at 4:08 PM, Steve Hannah wrote: > I have posted source for both versions of the method at > https://gist.github.com/3846116. How about throwing a retain on path and see if it makes a difference? Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From steve at weblite.ca Sat Oct 6 15:56:37 2012 From: steve at weblite.ca (Steve Hannah) Date: Sat, 6 Oct 2012 15:56:37 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: Message-ID: Hi Michael, Thanks for the suggestion. After some more investigation I have found that, the problem is that the library is not being loaded at all, so the bad access is from the attempt to call the native method at all. So it looks like it is a problem with the JNF symbols being used. (I.e. I changed the method so that it contains nothing but a return NULL (between the JNF_COCOA_ENTER and JNF_COCOA_EXIT calls), and I get the same crash. I still don't understand why it's having the problem, but at least I understand that the problem is nothing to do with the content in the body of the method. The problem is with the JNF_COCOA_ENTER and EXIT calls themselves. Thanks for your help. Best regards Steve On Sat, Oct 6, 2012 at 3:11 PM, Michael Hall wrote: > On Oct 6, 2012, at 4:08 PM, Steve Hannah wrote: > > > I have posted source for both versions of the method at > > https://gist.github.com/3846116. > > How about throwing a retain on path and see if it makes a difference? > > Michael Hall > > trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz > > HalfPipe Java 6/7 shell app > http://www195.pair.com/mik3hall/index.html#halfpipe > > AppConverter convert Apple jvm to openjdk apps > http://www195.pair.com/mik3hall/index.html#appconverter > > > > > -- Steve Hannah Web Lite Solutions Corp. From mik3hall at gmail.com Sat Oct 6 16:03:57 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 6 Oct 2012 18:03:57 -0500 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: Message-ID: <5F27B036-6708-42EF-A7BD-D6ED57515354@gmail.com> On Oct 6, 2012, at 5:56 PM, Steve Hannah wrote: > So it looks like it is a problem with the JNF symbols being used Are you linking in the JavaNativeFoundation framework? Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From swingler at apple.com Sat Oct 6 16:06:26 2012 From: swingler at apple.com (Mike Swingler) Date: Sat, 06 Oct 2012 16:06:26 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: Message-ID: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> On Oct 6, 2012, at 3:11 PM, Michael Hall wrote: > On Oct 6, 2012, at 4:08 PM, Steve Hannah wrote: > >> I have posted source for both versions of the method at >> https://gist.github.com/3846116. > > How about throwing a retain on path and see if it makes a difference? The "path" is not an Obj-C object, it's a JNI jstring pointer, you can't retain it. I'd actually recommend using JNFNSToJavaString(), instead of manually fetching out the UTF8String and then using the raw JNI. JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - they also catch ObjC exceptions and re-throw them as Java runtime exceptions. Do you have the backtrace of where you are crashing when using JNF_COCOA_ENTER/EXIT? Also, are you doing anything special to run this JNI method on the main AppKit thread (or are you using SWT)? If not, you may want to use +[JNFRunLoop performOnMainThreadWaiting:withBlock:], which will block the current thread, run your block on the main thread (safe for AppKit), and then continue execution of your Java thread when the block returns. Just a few thoughts, Mike Swingler Apple Inc. From steve at weblite.ca Sat Oct 6 17:05:49 2012 From: steve at weblite.ca (Steve Hannah) Date: Sat, 6 Oct 2012 17:05:49 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> Message-ID: On Sat, Oct 6, 2012 at 4:06 PM, Mike Swingler wrote: > On Oct 6, 2012, at 3:11 PM, Michael Hall wrote: > > > On Oct 6, 2012, at 4:08 PM, Steve Hannah wrote: > > > >> I have posted source for both versions of the method at > >> https://gist.github.com/3846116. > > > > How about throwing a retain on path and see if it makes a difference? > > The "path" is not an Obj-C object, it's a JNI jstring pointer, you can't > retain it. > > I'd actually recommend using JNFNSToJavaString(), instead of manually > fetching out the UTF8String and then using the raw JNI. > Thanks. I planned to make that change once I got JNF_COCOA_ENTER/EXIT working. > > JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - they > also catch ObjC exceptions and re-throw them as Java runtime exceptions. > > Do you have the backtrace of where you are crashing when using > JNF_COCOA_ENTER/EXIT? > I do, but I'm having difficulty making heads or tails from it. I'm also struggling with getting logging information out on the Java side as I'm working on a Mountain Lion machine and I can't find where System.out and System.err are logged by default... and the sandbox is making it difficult for me to set a log location manually... (anything that runs or fails before or during the setting of a custom log location is not logged). > > Also, are you doing anything special to run this JNI method on the main > AppKit thread (or are you using SWT)? Ah.. I hadn't thought of that, but yes. I'm overriding the java.awt.FileDialog class's setVisible() method to display this as a modal dialog. > If not, you may want to use +[JNFRunLoop > performOnMainThreadWaiting:withBlock:], which will block the current > thread, run your block on the main thread (safe for AppKit), and then > continue execution of your Java thread when the block returns. > I'll give this a shot. Thanks for the suggestions. Best regards Steve > > Just a few thoughts, > Mike Swingler > Apple Inc. > > -- Steve Hannah Web Lite Solutions Corp. From swingler at apple.com Sat Oct 6 18:45:24 2012 From: swingler at apple.com (Mike Swingler) Date: Sat, 06 Oct 2012 18:45:24 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> Message-ID: <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> On Oct 6, 2012, at 5:05 PM, Steve Hannah wrote: > On Sat, Oct 6, 2012 at 4:06 PM, Mike Swingler wrote: > On Oct 6, 2012, at 3:11 PM, Michael Hall wrote: > > > On Oct 6, 2012, at 4:08 PM, Steve Hannah wrote: > > > >> I have posted source for both versions of the method at > >> https://gist.github.com/3846116. > > > > How about throwing a retain on path and see if it makes a difference? > > The "path" is not an Obj-C object, it's a JNI jstring pointer, you can't retain it. > > I'd actually recommend using JNFNSToJavaString(), instead of manually fetching out the UTF8String and then using the raw JNI. > Thanks. I planned to make that change once I got JNF_COCOA_ENTER/EXIT working. Are you building/running the app from Xcode? You could try setting a breakpoint to inspect the local state. > > JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - they also catch ObjC exceptions and re-throw them as Java runtime exceptions. > > Do you have the backtrace of where you are crashing when using JNF_COCOA_ENTER/EXIT? > I do, but I'm having difficulty making heads or tails from it. I'm also struggling with getting logging information out on the Java side as I'm working on a Mountain Lion machine and I can't find where System.out and System.err are logged by default... and the sandbox is making it difficult for me to set a log location manually... (anything that runs or fails before or during the setting of a custom log location is not logged). I think (but I'm not certain) that this is the way it is now on Lion and Mountain Lion - output logged to stdout/stderr directly (including the JVM System.out/err) just goes to /dev/null unless you run the primary executable from a shell or some other parent process that gives it a TTY. Otherwise, the only thing that gets logged to the system console comes through ASL, like NSLog(). Of course, I may be completely off on this, but perhaps this is explaining what you are seeing. > Also, are you doing anything special to run this JNI method on the main AppKit thread (or are you using SWT)? > Ah.. I hadn't thought of that, but yes. I'm overriding the java.awt.FileDialog class's setVisible() method to display this as a modal dialog. > > If not, you may want to use +[JNFRunLoop performOnMainThreadWaiting:withBlock:], which will block the current thread, run your block on the main thread (safe for AppKit), and then continue execution of your Java thread when the block returns. > > I'll give this a shot. > > Thanks for the suggestions. No problem. Please do always think of the threading considerations when writing JNI. We try to let you not worry about exceptions and autorelease pools if you use JNF, but threading is still something you have to think through when you get JNI and Cocoa tangled together. Best of luck, Mike Swingler Apple Inc. From steve at weblite.ca Sun Oct 7 07:40:17 2012 From: steve at weblite.ca (Steve Hannah) Date: Sun, 7 Oct 2012 07:40:17 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> Message-ID: > Are you building/running the app from Xcode? You could try setting a > breakpoint to inspect the local state. > > I'm building the JNI library in XCode, but the application I'm building in Netbeans and packaging using Marco's port of AppBundler. I've experimented with threading issues and don't think that is the problem now in this case, but still don't know what is the problem. I have modified the example to make it simpler. The following code does not work: JNIEXPORT jstring JNICALL Java_ca_weblite_mactools_Sandbox_saveDialog (JNIEnv *env, jobject jthis, jstring title, jstring extension){ //JNF_COCOA_ENTER(<#env#>); return JNFNSToJavaString(env, @"/Users/shannah/Downloads/out2.pdf"); //JNF_COCOA_EXIT(env); } If I uncomment the JNF_COCOA_ENTER/EXIT lines, it works properly. I have my Java logging working now so I can follow the progress with println statements right up until it calls the native method. I get a crash at that point. It doesn't even enter the native method (i.e. if I put a print statement first line, nothing happens. It almost seems like putting the JNF_COCOA_ENTER/EXIT calls inside the method some somehow changes the method signature so that Java can no longer find the correct method to call at runtime.... but that doesn't seem possible. Given my inexperience with XCode, I suspect that it could be a problem with the way I'm building/linking the JNI library. The fact that calls to JNFNSToJavaString() work makes me thing that the JavaNativeFoundation is correctly linked (?). Note: I'm going through this exercise to try and write the code with JNF_COCOA_ENTER/EXIT because, despite the fact that the library worked perfectly the way it was on Mountain Lion, it doesn't work on Lion, so I'm trying to cover all of my bases to figure out why. When I got stuck at this step, I figured it's worth finding out what this problem is just in case it's related to the Lion problem. I'm building it with settings: Base SDK: Latest OS X (OS X 10.8) Deployment Target: OS X 10..7 (although I've tried 10.6 and 10.8 with same results). Any other suggestions or tips, much appreciated. Best regards Steve >> JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - they >> also catch ObjC exceptions and re-throw them as Java runtime exceptions. >> >> Do you have the backtrace of where you are crashing when using >> JNF_COCOA_ENTER/EXIT? >> > I do, but I'm having difficulty making heads or tails from it. I'm also > struggling with getting logging information out on the Java side as I'm > working on a Mountain Lion machine and I can't find where System.out and > System.err are logged by default... and the sandbox is making it difficult > for me to set a log location manually... (anything that runs or fails > before or during the setting of a custom log location is not logged). > > > I think (but I'm not certain) that this is the way it is now on Lion and > Mountain Lion - output logged to stdout/stderr directly (including the JVM > System.out/err) just goes to /dev/null unless you run the primary > executable from a shell or some other parent process that gives it a TTY. > Otherwise, the only thing that gets logged to the system console comes > through ASL, like NSLog(). Of course, I may be completely off on this, but > perhaps this is explaining what you are seeing. > > Also, are you doing anything special to run this JNI method on the main >> AppKit thread (or are you using SWT)? > > Ah.. I hadn't thought of that, but yes. I'm overriding the > java.awt.FileDialog class's setVisible() method to display this as a modal > dialog. > > >> If not, you may want to use +[JNFRunLoop >> performOnMainThreadWaiting:withBlock:], which will block the current >> thread, run your block on the main thread (safe for AppKit), and then >> continue execution of your Java thread when the block returns. >> > > I'll give this a shot. > > Thanks for the suggestions. > > > No problem. Please do always think of the threading considerations when > writing JNI. We try to let you not worry about exceptions and autorelease > pools if you use JNF, but threading is still something you have to think > through when you get JNI and Cocoa tangled together. > > Best of luck, > Mike Swingler > Apple Inc. > > -- Steve Hannah Web Lite Solutions Corp. From steve at weblite.ca Sun Oct 7 08:01:28 2012 From: steve at weblite.ca (Steve Hannah) Date: Sun, 7 Oct 2012 08:01:28 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> Message-ID: In case it offers insight, this is the backtrace of the thread that crashed: hread 23 Crashed:: Java: Thread-2 0 libsystem_kernel.dylib 0x00007fff8a043212 __pthread_kill + 10 1 libsystem_c.dylib 0x00007fff87e93b34 pthread_kill + 90 2 libsystem_c.dylib 0x00007fff87ed7dfa abort + 143 3 libjvm.dylib 0x0000000108d47a9f os::abort(bool) + 25 4 libjvm.dylib 0x0000000108e3435e VMError::report_and_die() + 2306 5 libjvm.dylib 0x0000000108d49193 JVM_handle_bsd_signal + 1073 6 libsystem_c.dylib 0x00007fff87e8092a _sigtramp + 26 7 libobjc.A.dylib 0x00007fff898d33ee objc_retain + 14 8 ??? 0x000000010959cf90 0 + 4451848080 9 ??? 0x0000000109591333 0 + 4451799859 10 ??? 0x000000010958b4f7 0 + 4451775735 11 libjvm.dylib 0x0000000108c1f083 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 12 libjvm.dylib 0x0000000108c1ee50 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 13 libjvm.dylib 0x0000000108d88062 Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 2506 14 libjvm.dylib 0x0000000108d884ba Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*) + 360 15 libjvm.dylib 0x0000000108c4f99b JVM_InvokeMethod + 352 16 ??? 0x000000010959cf90 0 + 4451848080 17 ??? 0x0000000109591333 0 + 4451799859 18 ??? 0x0000000109591333 0 + 4451799859 19 ??? 0x00000001095919e1 0 + 4451801569 20 ??? 0x0000000109591333 0 + 4451799859 21 ??? 0x0000000109591333 0 + 4451799859 22 ??? 0x0000000109591333 0 + 4451799859 23 ??? 0x0000000109591333 0 + 4451799859 24 ??? 0x0000000109591333 0 + 4451799859 25 ??? 0x0000000109591333 0 + 4451799859 26 ??? 0x0000000109591333 0 + 4451799859 27 ??? 0x0000000109591333 0 + 4451799859 28 ??? 0x0000000109591333 0 + 4451799859 29 ??? 0x0000000109591333 0 + 4451799859 30 ??? 0x0000000109591333 0 + 4451799859 31 ??? 0x0000000109591333 0 + 4451799859 32 ??? 0x0000000109591333 0 + 4451799859 33 ??? 0x0000000109591333 0 + 4451799859 34 ??? 0x0000000109591333 0 + 4451799859 35 ??? 0x0000000109591333 0 + 4451799859 36 ??? 0x0000000109591158 0 + 4451799384 37 ??? 0x0000000109591158 0 + 4451799384 38 ??? 0x0000000109591806 0 + 4451801094 39 ??? 0x000000010958b4f7 0 + 4451775735 40 libjvm.dylib 0x0000000108c1f083 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 41 libjvm.dylib 0x0000000108c1f560 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256 42 libjvm.dylib 0x0000000108c1f69a JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 43 libjvm.dylib 0x0000000108c52504 thread_entry(JavaThread*, Thread*) + 169 44 libjvm.dylib 0x0000000108e09f74 JavaThread::thread_main_inner() + 134 45 libjvm.dylib 0x0000000108e0b413 JavaThread::run() + 369 46 libjvm.dylib 0x0000000108d47fc1 java_start(Thread*) + 173 47 libsystem_c.dylib 0x00007fff87e92782 _pthread_start + 327 48 libsystem_c.dylib 0x00007fff87e7f1c1 thread_start + 13 Best regards Steve On Sun, Oct 7, 2012 at 7:40 AM, Steve Hannah wrote: > > Are you building/running the app from Xcode? You could try setting a >> breakpoint to inspect the local state. >> >> > I'm building the JNI library in XCode, but the application I'm building in > Netbeans and packaging using Marco's port of AppBundler. > > I've experimented with threading issues and don't think that is the > problem now in this case, but still don't know what is the problem. I have > modified the example to make it simpler. > > The following code does not work: > > JNIEXPORT jstring JNICALL Java_ca_weblite_mactools_Sandbox_saveDialog > > (JNIEnv *env, jobject jthis, jstring title, jstring extension){ > > //JNF_COCOA_ENTER(<#env#>); > > return JNFNSToJavaString(env, @"/Users/shannah/Downloads/out2.pdf"); > > //JNF_COCOA_EXIT(env); > } > > If I uncomment the JNF_COCOA_ENTER/EXIT lines, it works properly. > > I have my Java logging working now so I can follow the progress with > println statements right up until it calls the native method. I get a > crash at that point. It doesn't even enter the native method (i.e. if I > put a print statement first line, nothing happens. > > It almost seems like putting the JNF_COCOA_ENTER/EXIT calls inside the > method some somehow changes the method signature so that Java can no longer > find the correct method to call at runtime.... but that doesn't seem > possible. > > Given my inexperience with XCode, I suspect that it could be a problem > with the way I'm building/linking the JNI library. The fact that calls to > JNFNSToJavaString() work makes me thing that the JavaNativeFoundation is > correctly linked (?). > > Note: I'm going through this exercise to try and write the code with > JNF_COCOA_ENTER/EXIT because, despite the fact that the library worked > perfectly the way it was on Mountain Lion, it doesn't work on Lion, so I'm > trying to cover all of my bases to figure out why. When I got stuck at > this step, I figured it's worth finding out what this problem is just in > case it's related to the Lion problem. > > I'm building it with settings: > Base SDK: Latest OS X (OS X 10.8) > Deployment Target: OS X 10..7 (although I've tried 10.6 and 10.8 with > same results). > > > Any other suggestions or tips, much appreciated. > > > Best regards > > Steve > > >>> JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - they >>> also catch ObjC exceptions and re-throw them as Java runtime exceptions. >>> >>> Do you have the backtrace of where you are crashing when using >>> JNF_COCOA_ENTER/EXIT? >>> >> I do, but I'm having difficulty making heads or tails from it. I'm also >> struggling with getting logging information out on the Java side as I'm >> working on a Mountain Lion machine and I can't find where System.out and >> System.err are logged by default... and the sandbox is making it difficult >> for me to set a log location manually... (anything that runs or fails >> before or during the setting of a custom log location is not logged). >> >> >> I think (but I'm not certain) that this is the way it is now on Lion and >> Mountain Lion - output logged to stdout/stderr directly (including the JVM >> System.out/err) just goes to /dev/null unless you run the primary >> executable from a shell or some other parent process that gives it a TTY. >> Otherwise, the only thing that gets logged to the system console comes >> through ASL, like NSLog(). Of course, I may be completely off on this, but >> perhaps this is explaining what you are seeing. >> >> Also, are you doing anything special to run this JNI method on the main >>> AppKit thread (or are you using SWT)? >> >> Ah.. I hadn't thought of that, but yes. I'm overriding the >> java.awt.FileDialog class's setVisible() method to display this as a modal >> dialog. >> >> >>> If not, you may want to use +[JNFRunLoop >>> performOnMainThreadWaiting:withBlock:], which will block the current >>> thread, run your block on the main thread (safe for AppKit), and then >>> continue execution of your Java thread when the block returns. >>> >> >> I'll give this a shot. >> >> Thanks for the suggestions. >> >> >> No problem. Please do always think of the threading considerations when >> writing JNI. We try to let you not worry about exceptions and autorelease >> pools if you use JNF, but threading is still something you have to think >> through when you get JNI and Cocoa tangled together. >> >> Best of luck, >> Mike Swingler >> Apple Inc. >> >> > > > -- > Steve Hannah > Web Lite Solutions Corp. > > -- Steve Hannah Web Lite Solutions Corp. From mik3hall at gmail.com Sun Oct 7 11:00:30 2012 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 7 Oct 2012 13:00:30 -0500 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> Message-ID: <11833446-266F-4D9E-8ADD-AC04F35B1ACA@gmail.com> On Oct 7, 2012, at 9:40 AM, Steve Hannah wrote: > JNIEXPORT jstring JNICALL Java_ca_weblite_mactools_Sandbox_saveDialog > > (JNIEnv *env, jobject jthis, jstring title, jstring extension){ > > //JNF_COCOA_ENTER(<#env#>); > > return JNFNSToJavaString(env, @"/Users/shannah/Downloads/out2.pdf"); > > //JNF_COCOA_EXIT(env); > } > > If I uncomment the JNF_COCOA_ENTER/EXIT lines, it works properly. I'm not sure what you mean by if you uncomment it works properly? That's what you want isn't it? The macros establish and tear down the environment for things like JNFNSToJavaString to work is my understanding. I just noticed too that your instruction is a return so it won't hit the JNF_COCOA_EXIT. Not sure either what that might do, but probably best to save the return, fall through the EXIT macro, and then do the return with the saved value. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From steve at weblite.ca Sun Oct 7 13:42:30 2012 From: steve at weblite.ca (Steve Hannah) Date: Sun, 7 Oct 2012 13:42:30 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: <11833446-266F-4D9E-8ADD-AC04F35B1ACA@gmail.com> References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> <11833446-266F-4D9E-8ADD-AC04F35B1ACA@gmail.com> Message-ID: Oops that was a typo. It should've said "if I uncomment the JNF_COCOA_ENTER/EXIT lines, it DOESN'T work properly." -Steve On Sunday, October 7, 2012, Michael Hall wrote: > On Oct 7, 2012, at 9:40 AM, Steve Hannah wrote: > > > JNIEXPORT jstring JNICALL Java_ca_weblite_mactools_Sandbox_saveDialog > > > > (JNIEnv *env, jobject jthis, jstring title, jstring extension){ > > > > //JNF_COCOA_ENTER(<#env#>); > > > > return JNFNSToJavaString(env, @"/Users/shannah/Downloads/out2.pdf"); > > > > //JNF_COCOA_EXIT(env); > > } > > > > If I uncomment the JNF_COCOA_ENTER/EXIT lines, it works properly. > > I'm not sure what you mean by if you uncomment it works properly? That's > what you want isn't it? The macros establish and tear down the environment > for things like JNFNSToJavaString to work is my understanding. > I just noticed too that your instruction is a return so it won't hit the > JNF_COCOA_EXIT. > Not sure either what that might do, but probably best to save the return, > fall through the EXIT macro, and then do the return with the saved value. > > Michael Hall > > trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz > > HalfPipe Java 6/7 shell app > http://www195.pair.com/mik3hall/index.html#halfpipe > > AppConverter convert Apple jvm to openjdk apps > http://www195.pair.com/mik3hall/index.html#appconverter > > > -- Steve Hannah Web Lite Solutions Corp. From swingler at apple.com Sun Oct 7 14:35:19 2012 From: swingler at apple.com (Mike Swingler) Date: Sun, 07 Oct 2012 14:35:19 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> Message-ID: <17A3153E-D19D-4FA7-AF5A-51B55765FABB@apple.com> On Oct 7, 2012, at 7:40 AM, Steve Hannah wrote: > Are you building/running the app from Xcode? You could try setting a breakpoint to inspect the local state. > > I'm building the JNI library in XCode, but the application I'm building in Netbeans and packaging using Marco's port of AppBundler. > > I've experimented with threading issues and don't think that is the problem now in this case, but still don't know what is the problem. I have modified the example to make it simpler. > > The following code does not work: > JNIEXPORT jstring JNICALL Java_ca_weblite_mactools_Sandbox_saveDialog > > (JNIEnv *env, jobject jthis, jstring title, jstring extension){ > > //JNF_COCOA_ENTER(<#env#>); > > return JNFNSToJavaString(env, @"/Users/shannah/Downloads/out2.pdf"); > > //JNF_COCOA_EXIT(env); > > } This is not a valid C function based on the return type - in the case where an error occurs, the return value of this function is undefined and will likely be whatever garbage is left on the stack (isn't Xcode warning/erroring about this like crazy???). You need a "return NULL;" at the very end so that the JNI return value will be defined in the case where you don't make it to the first return. > If I uncomment the JNF_COCOA_ENTER/EXIT lines, it works properly. > > I have my Java logging working now so I can follow the progress with println statements right up until it calls the native method. I get a crash at that point. It doesn't even enter the native method (i.e. if I put a print statement first line, nothing happens. > > It almost seems like putting the JNF_COCOA_ENTER/EXIT calls inside the method some somehow changes the method signature so that Java can no longer find the correct method to call at runtime.... but that doesn't seem possible. Are you sure the library is even getting built and loaded? Can you make a plain JNI function next to this one that contains nothing but a simple "fprintf(stderr, "test\n");" in it? Call that first, and see if the library is even loaded. > Given my inexperience with XCode, I suspect that it could be a problem with the way I'm building/linking the JNI library. The fact that calls to JNFNSToJavaString() work makes me thing that the JavaNativeFoundation is correctly linked (?). It may be getting hauled in by Java 7 itself, and not explicitly linked. If you don't have the JavaNativeFounation.framework explicitly linked in the target that builds your library, that would also cause the compiler to infer that the JNF_COCOA_ENTER/EXIT macros are actually functions, and treat them as undeclared/unlinked entities. > Note: I'm going through this exercise to try and write the code with JNF_COCOA_ENTER/EXIT because, despite the fact that the library worked perfectly the way it was on Mountain Lion, it doesn't work on Lion, so I'm trying to cover all of my bases to figure out why. When I got stuck at this step, I figured it's worth finding out what this problem is just in case it's related to the Lion problem. > > I'm building it with settings: > Base SDK: Latest OS X (OS X 10.8) > Deployment Target: OS X 10..7 (although I've tried 10.6 and 10.8 with same results). Run otool -L on your library, and make sure the full path to JavaNativeFoundation.framework is printed out. If it isn't, you are only picking up the symbols inside of it by accident. Regards, Mike Swingler Apple Inc. > Any other suggestions or tips, much appreciated. > > > Best regards > > Steve > >> >> JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - they also catch ObjC exceptions and re-throw them as Java runtime exceptions. >> >> Do you have the backtrace of where you are crashing when using JNF_COCOA_ENTER/EXIT? >> I do, but I'm having difficulty making heads or tails from it. I'm also struggling with getting logging information out on the Java side as I'm working on a Mountain Lion machine and I can't find where System.out and System.err are logged by default... and the sandbox is making it difficult for me to set a log location manually... (anything that runs or fails before or during the setting of a custom log location is not logged). > > I think (but I'm not certain) that this is the way it is now on Lion and Mountain Lion - output logged to stdout/stderr directly (including the JVM System.out/err) just goes to /dev/null unless you run the primary executable from a shell or some other parent process that gives it a TTY. Otherwise, the only thing that gets logged to the system console comes through ASL, like NSLog(). Of course, I may be completely off on this, but perhaps this is explaining what you are seeing. > >> Also, are you doing anything special to run this JNI method on the main AppKit thread (or are you using SWT)? >> Ah.. I hadn't thought of that, but yes. I'm overriding the java.awt.FileDialog class's setVisible() method to display this as a modal dialog. >> >> If not, you may want to use +[JNFRunLoop performOnMainThreadWaiting:withBlock:], which will block the current thread, run your block on the main thread (safe for AppKit), and then continue execution of your Java thread when the block returns. >> >> I'll give this a shot. >> >> Thanks for the suggestions. > > No problem. Please do always think of the threading considerations when writing JNI. We try to let you not worry about exceptions and autorelease pools if you use JNF, but threading is still something you have to think through when you get JNI and Cocoa tangled together. > > Best of luck, > Mike Swingler > Apple Inc. > > > > > -- > Steve Hannah > Web Lite Solutions Corp. > From steve at weblite.ca Sun Oct 7 15:05:22 2012 From: steve at weblite.ca (Steve Hannah) Date: Sun, 7 Oct 2012 15:05:22 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: <17A3153E-D19D-4FA7-AF5A-51B55765FABB@apple.com> References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> <17A3153E-D19D-4FA7-AF5A-51B55765FABB@apple.com> Message-ID: This is not a valid C function based on the return type - in the case where > an error occurs, the return value of this function is undefined and will > likely be whatever garbage is left on the stack (isn't Xcode > warning/erroring about this like crazy???). You need a "return NULL;" at > the very end so that the JNI return value will be defined in the case where > you don't make it to the first return. > > Thanks for the tip, I'll add the null return and see if that helps. (No Xcode didn't complain... no warnings, no errors, "build succeeded"). > > Are you sure the library is even getting built and loaded? Can you make a > plain JNI function next to this one that contains nothing but a simple > "fprintf(stderr, "test\n");" in it? Call that first, and see if the library > is even loaded. > > Yes. The library is getting built and loaded. I have 2 other JNI methods that are working properly (but only if I don't wrap them in JNF_COCOA_ENTER/EXIT). In my java logging I output the string result of another one of the methods just before calling this one and it outputs fine. > Given my inexperience with XCode, I suspect that it could be a problem > with the way I'm building/linking the JNI library. The fact that calls to > JNFNSToJavaString() work makes me thing that the JavaNativeFoundation is > correctly linked (?). > > > It may be getting hauled in by Java 7 itself, and not explicitly linked. > If you don't have the JavaNativeFounation.framework explicitly linked in > the target that builds your library, that would also cause the compiler to > infer that the JNF_COCOA_ENTER/EXIT macros are actually functions, and > treat them as undeclared/unlinked entities. > > Run otool -L on your library, and make sure the full path to > JavaNativeFoundation.framework is printed out. If it isn't, you are only > picking up the symbols inside of it by accident. > Thanks... I'll try that. Best regards Steve > > Regards, > Mike Swingler > Apple Inc. > > Any other suggestions or tips, much appreciated. > > > Best regards > > Steve > > >>> JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - they >>> also catch ObjC exceptions and re-throw them as Java runtime exceptions. >>> >>> Do you have the backtrace of where you are crashing when using >>> JNF_COCOA_ENTER/EXIT? >>> >> I do, but I'm having difficulty making heads or tails from it. I'm also >> struggling with getting logging information out on the Java side as I'm >> working on a Mountain Lion machine and I can't find where System.out and >> System.err are logged by default... and the sandbox is making it difficult >> for me to set a log location manually... (anything that runs or fails >> before or during the setting of a custom log location is not logged). >> >> >> I think (but I'm not certain) that this is the way it is now on Lion and >> Mountain Lion - output logged to stdout/stderr directly (including the JVM >> System.out/err) just goes to /dev/null unless you run the primary >> executable from a shell or some other parent process that gives it a TTY. >> Otherwise, the only thing that gets logged to the system console comes >> through ASL, like NSLog(). Of course, I may be completely off on this, but >> perhaps this is explaining what you are seeing. >> >> Also, are you doing anything special to run this JNI method on the main >>> AppKit thread (or are you using SWT)? >> >> Ah.. I hadn't thought of that, but yes. I'm overriding the >> java.awt.FileDialog class's setVisible() method to display this as a modal >> dialog. >> >> >>> If not, you may want to use +[JNFRunLoop >>> performOnMainThreadWaiting:withBlock:], which will block the current >>> thread, run your block on the main thread (safe for AppKit), and then >>> continue execution of your Java thread when the block returns. >>> >> >> I'll give this a shot. >> >> Thanks for the suggestions. >> >> >> No problem. Please do always think of the threading considerations when >> writing JNI. We try to let you not worry about exceptions and autorelease >> pools if you use JNF, but threading is still something you have to think >> through when you get JNI and Cocoa tangled together. >> >> Best of luck, >> Mike Swingler >> Apple Inc. >> >> > > > -- > Steve Hannah > Web Lite Solutions Corp. > > > -- Steve Hannah Web Lite Solutions Corp. From steve at weblite.ca Sun Oct 7 18:42:44 2012 From: steve at weblite.ca (Steve Hannah) Date: Sun, 7 Oct 2012 18:42:44 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> <17A3153E-D19D-4FA7-AF5A-51B55765FABB@apple.com> Message-ID: OK. I have made the following change to the method: JNIEXPORT jstring JNICALL Java_ca_weblite_mactools_Sandbox_saveDialog (JNIEnv *env, jobject jthis, jstring title, jstring extension){ JNF_COCOA_ENTER(<#env#>); return JNFNSToJavaString(env, @"/Users/shannah/Downloads/out2.pdf"); JNF_COCOA_EXIT(env); return NULL; } It still crashes. Here are some of the crash details. Process: JavaAppLauncher [13397] Path: /Users/USER/Documents/*/MyApp.app/Contents/MacOS/JavaAppLauncher Identifier: ca.myidentifier Version: 1.9.32 (1.9.32) Code Type: X86-64 (Native) Parent Process: launchd [140] User ID: 501 Date/Time: 2012-10-07 18:20:23.789 -0700 OS Version: Mac OS X 10.8.1 (12B19) Report Version: 10 Crashed Thread: 25 Java: Thread-2 Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 VM Regions Near 0x20: --> __TEXT 0000000103466000-000000010346a000 [ 16K] r-x/rwx SM=COW /Users/USER/Documents/*/MyApp.app/Contents/MacOS/JavaAppLauncher Application Specific Information: abort() called And the thread that crashed: Thread 25 Crashed:: Java: Thread-2 0 libsystem_kernel.dylib 0x00007fff8a043212 __pthread_kill + 10 1 libsystem_c.dylib 0x00007fff87e93b34 pthread_kill + 90 2 libsystem_c.dylib 0x00007fff87ed7dfa abort + 143 3 libjvm.dylib 0x0000000103a12a9f os::abort(bool) + 25 4 libjvm.dylib 0x0000000103aff35e VMError::report_and_die() + 2306 5 libjvm.dylib 0x0000000103a14193 JVM_handle_bsd_signal + 1073 6 libsystem_c.dylib 0x00007fff87e8092a _sigtramp + 26 7 libobjc.A.dylib 0x00007fff898d33ee objc_retain + 14 8 ??? 0x0000000104267f90 0 + 4364599184 9 ??? 0x000000010425c333 0 + 4364550963 10 ??? 0x00000001042564f7 0 + 4364526839 11 libjvm.dylib 0x00000001038ea083 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 12 libjvm.dylib 0x00000001038e9e50 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 13 libjvm.dylib 0x0000000103a53062 Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 2506 14 libjvm.dylib 0x0000000103a534ba Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*) + 360 15 libjvm.dylib 0x000000010391a99b JVM_InvokeMethod + 352 16 ??? 0x0000000104267f90 0 + 4364599184 17 ??? 0x000000010425c333 0 + 4364550963 18 ??? 0x000000010425c333 0 + 4364550963 19 ??? 0x000000010425c9e1 0 + 4364552673 20 ??? 0x000000010425c333 0 + 4364550963 21 ??? 0x000000010425c333 0 + 4364550963 22 ??? 0x000000010425c333 0 + 4364550963 23 ??? 0x000000010425c333 0 + 4364550963 24 ??? 0x000000010425c333 0 + 4364550963 25 ??? 0x000000010425c333 0 + 4364550963 26 ??? 0x000000010425c333 0 + 4364550963 27 ??? 0x000000010425c333 0 + 4364550963 28 ??? 0x000000010425c333 0 + 4364550963 29 ??? 0x000000010425c333 0 + 4364550963 30 ??? 0x000000010425c333 0 + 4364550963 31 ??? 0x000000010425c333 0 + 4364550963 32 ??? 0x000000010425c333 0 + 4364550963 33 ??? 0x000000010425c333 0 + 4364550963 34 ??? 0x000000010425c333 0 + 4364550963 35 ??? 0x000000010425c333 0 + 4364550963 36 ??? 0x000000010425c158 0 + 4364550488 37 ??? 0x000000010425c158 0 + 4364550488 38 ??? 0x000000010425c806 0 + 4364552198 39 ??? 0x00000001042564f7 0 + 4364526839 40 libjvm.dylib 0x00000001038ea083 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 41 libjvm.dylib 0x00000001038ea560 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256 42 libjvm.dylib 0x00000001038ea69a JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 43 libjvm.dylib 0x000000010391d504 thread_entry(JavaThread*, Thread*) + 169 44 libjvm.dylib 0x0000000103ad4f74 JavaThread::thread_main_inner() + 134 45 libjvm.dylib 0x0000000103ad6413 JavaThread::run() + 369 46 libjvm.dylib 0x0000000103a12fc1 java_start(Thread*) + 173 47 libsystem_c.dylib 0x00007fff87e92782 _pthread_start + 327 48 libsystem_c.dylib 0x00007fff87e7f1c1 thread_start + 13 I ran otool -L on the library to check that the JavaNativeFoundation was being linked and it looks like it is. It's output is as follows: macbook-air-2:MacTools shannah$ otool -L libmactools.dylib libmactools.dylib: /usr/local/lib/JSandbox.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 19.0.0) /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1187.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 945.0.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.0.0) Does this information provide any clues that I might be missing? Thanks for all your help so far. Best regards Steve On Sun, Oct 7, 2012 at 3:05 PM, Steve Hannah wrote: > > This is not a valid C function based on the return type - in the case >> where an error occurs, the return value of this function is undefined and >> will likely be whatever garbage is left on the stack (isn't Xcode >> warning/erroring about this like crazy???). You need a "return NULL;" at >> the very end so that the JNI return value will be defined in the case where >> you don't make it to the first return. >> >> Thanks for the tip, I'll add the null return and see if that helps. (No > Xcode didn't complain... no warnings, no errors, "build succeeded"). > >> >> Are you sure the library is even getting built and loaded? Can you make a >> plain JNI function next to this one that contains nothing but a simple >> "fprintf(stderr, "test\n");" in it? Call that first, and see if the library >> is even loaded. >> >> Yes. The library is getting built and loaded. I have 2 other JNI > methods that are working properly (but only if I don't wrap them in > JNF_COCOA_ENTER/EXIT). In my java logging I output the string result of > another one of the methods just before calling this one and it outputs fine. > > >> Given my inexperience with XCode, I suspect that it could be a problem >> with the way I'm building/linking the JNI library. The fact that calls to >> JNFNSToJavaString() work makes me thing that the JavaNativeFoundation is >> correctly linked (?). >> >> >> It may be getting hauled in by Java 7 itself, and not explicitly linked. >> If you don't have the JavaNativeFounation.framework explicitly linked in >> the target that builds your library, that would also cause the compiler to >> infer that the JNF_COCOA_ENTER/EXIT macros are actually functions, and >> treat them as undeclared/unlinked entities. >> >> Run otool -L on your library, and make sure the full path to >> JavaNativeFoundation.framework is printed out. If it isn't, you are only >> picking up the symbols inside of it by accident. >> > > Thanks... I'll try that. > > Best regards > > Steve > > >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> Any other suggestions or tips, much appreciated. >> >> >> Best regards >> >> Steve >> >> >>>> JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - they >>>> also catch ObjC exceptions and re-throw them as Java runtime exceptions. >>>> >>>> Do you have the backtrace of where you are crashing when using >>>> JNF_COCOA_ENTER/EXIT? >>>> >>> I do, but I'm having difficulty making heads or tails from it. I'm also >>> struggling with getting logging information out on the Java side as I'm >>> working on a Mountain Lion machine and I can't find where System.out and >>> System.err are logged by default... and the sandbox is making it difficult >>> for me to set a log location manually... (anything that runs or fails >>> before or during the setting of a custom log location is not logged). >>> >>> >>> I think (but I'm not certain) that this is the way it is now on Lion and >>> Mountain Lion - output logged to stdout/stderr directly (including the JVM >>> System.out/err) just goes to /dev/null unless you run the primary >>> executable from a shell or some other parent process that gives it a TTY. >>> Otherwise, the only thing that gets logged to the system console comes >>> through ASL, like NSLog(). Of course, I may be completely off on this, but >>> perhaps this is explaining what you are seeing. >>> >>> Also, are you doing anything special to run this JNI method on the main >>>> AppKit thread (or are you using SWT)? >>> >>> Ah.. I hadn't thought of that, but yes. I'm overriding the >>> java.awt.FileDialog class's setVisible() method to display this as a modal >>> dialog. >>> >>> >>>> If not, you may want to use +[JNFRunLoop >>>> performOnMainThreadWaiting:withBlock:], which will block the current >>>> thread, run your block on the main thread (safe for AppKit), and then >>>> continue execution of your Java thread when the block returns. >>>> >>> >>> I'll give this a shot. >>> >>> Thanks for the suggestions. >>> >>> >>> No problem. Please do always think of the threading considerations when >>> writing JNI. We try to let you not worry about exceptions and autorelease >>> pools if you use JNF, but threading is still something you have to think >>> through when you get JNI and Cocoa tangled together. >>> >>> Best of luck, >>> Mike Swingler >>> Apple Inc. >>> >>> >> >> >> -- >> Steve Hannah >> Web Lite Solutions Corp. >> >> >> > > > -- > Steve Hannah > Web Lite Solutions Corp. > > -- Steve Hannah Web Lite Solutions Corp. From steve at weblite.ca Sun Oct 7 20:37:14 2012 From: steve at weblite.ca (Steve Hannah) Date: Sun, 7 Oct 2012 20:37:14 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> <17A3153E-D19D-4FA7-AF5A-51B55765FABB@apple.com> Message-ID: Another note: I just linked it to the JavaVM framework and JavaNativeFoundationFramework by right clicking on the "Other Frameworks" folder in the file tree of XCode, and selecting "Add Files to myproject", then proceeded to select: /System/Library/Frameworks/JavaVM and /System/Library/Frameworks/JavaVM/Frameworks/JavaNativeFoundation. This is my first JNI library, so it is possible I erred somewhere here. E.g. is it possible I linked against a framework for Java 6 when it needs to be for Java 7? -Steve On Sun, Oct 7, 2012 at 6:42 PM, Steve Hannah wrote: > OK. I have made the following change to the method: > > > JNIEXPORT jstring JNICALL Java_ca_weblite_mactools_Sandbox_saveDialog > > (JNIEnv *env, jobject jthis, jstring title, jstring extension){ > > JNF_COCOA_ENTER(<#env#>); > > return JNFNSToJavaString(env, @"/Users/shannah/Downloads/out2.pdf"); > > JNF_COCOA_EXIT(env); > > return NULL; > } > > It still crashes. Here are some of the crash details. > > Process: JavaAppLauncher [13397] > Path: > /Users/USER/Documents/*/MyApp.app/Contents/MacOS/JavaAppLauncher > Identifier: ca.myidentifier > Version: 1.9.32 (1.9.32) > Code Type: X86-64 (Native) > Parent Process: launchd [140] > User ID: 501 > > Date/Time: 2012-10-07 18:20:23.789 -0700 > OS Version: Mac OS X 10.8.1 (12B19) > Report Version: 10 > > Crashed Thread: 25 Java: Thread-2 > > Exception Type: EXC_BAD_ACCESS (SIGABRT) > Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 > > VM Regions Near 0x20: > --> > __TEXT 0000000103466000-000000010346a000 [ 16K] > r-x/rwx SM=COW > /Users/USER/Documents/*/MyApp.app/Contents/MacOS/JavaAppLauncher > > Application Specific Information: > abort() called > > > And the thread that crashed: > > Thread 25 Crashed:: Java: Thread-2 > 0 libsystem_kernel.dylib 0x00007fff8a043212 __pthread_kill + 10 > 1 libsystem_c.dylib 0x00007fff87e93b34 pthread_kill + 90 > 2 libsystem_c.dylib 0x00007fff87ed7dfa abort + 143 > 3 libjvm.dylib 0x0000000103a12a9f os::abort(bool) + 25 > 4 libjvm.dylib 0x0000000103aff35e > VMError::report_and_die() + 2306 > 5 libjvm.dylib 0x0000000103a14193 > JVM_handle_bsd_signal + 1073 > 6 libsystem_c.dylib 0x00007fff87e8092a _sigtramp + 26 > 7 libobjc.A.dylib 0x00007fff898d33ee objc_retain + 14 > 8 ??? 0x0000000104267f90 0 + 4364599184 > 9 ??? 0x000000010425c333 0 + 4364550963 > 10 ??? 0x00000001042564f7 0 + 4364526839 > 11 libjvm.dylib 0x00000001038ea083 > JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > Thread*) + 557 > 12 libjvm.dylib 0x00000001038e9e50 > JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 13 libjvm.dylib 0x0000000103a53062 > Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool, > objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 2506 > 14 libjvm.dylib 0x0000000103a534ba > Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*) + 360 > 15 libjvm.dylib 0x000000010391a99b JVM_InvokeMethod + > 352 > 16 ??? 0x0000000104267f90 0 + 4364599184 > 17 ??? 0x000000010425c333 0 + 4364550963 > 18 ??? 0x000000010425c333 0 + 4364550963 > 19 ??? 0x000000010425c9e1 0 + 4364552673 > 20 ??? 0x000000010425c333 0 + 4364550963 > 21 ??? 0x000000010425c333 0 + 4364550963 > 22 ??? 0x000000010425c333 0 + 4364550963 > 23 ??? 0x000000010425c333 0 + 4364550963 > 24 ??? 0x000000010425c333 0 + 4364550963 > 25 ??? 0x000000010425c333 0 + 4364550963 > 26 ??? 0x000000010425c333 0 + 4364550963 > 27 ??? 0x000000010425c333 0 + 4364550963 > 28 ??? 0x000000010425c333 0 + 4364550963 > 29 ??? 0x000000010425c333 0 + 4364550963 > 30 ??? 0x000000010425c333 0 + 4364550963 > 31 ??? 0x000000010425c333 0 + 4364550963 > 32 ??? 0x000000010425c333 0 + 4364550963 > 33 ??? 0x000000010425c333 0 + 4364550963 > 34 ??? 0x000000010425c333 0 + 4364550963 > 35 ??? 0x000000010425c333 0 + 4364550963 > 36 ??? 0x000000010425c158 0 + 4364550488 > 37 ??? 0x000000010425c158 0 + 4364550488 > 38 ??? 0x000000010425c806 0 + 4364552198 > 39 ??? 0x00000001042564f7 0 + 4364526839 > 40 libjvm.dylib 0x00000001038ea083 > JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > Thread*) + 557 > 41 libjvm.dylib 0x00000001038ea560 > JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, > JavaCallArguments*, Thread*) + 256 > 42 libjvm.dylib 0x00000001038ea69a > JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, > Thread*) + 74 > 43 libjvm.dylib 0x000000010391d504 > thread_entry(JavaThread*, Thread*) + 169 > 44 libjvm.dylib 0x0000000103ad4f74 > JavaThread::thread_main_inner() + 134 > 45 libjvm.dylib 0x0000000103ad6413 JavaThread::run() + > 369 > 46 libjvm.dylib 0x0000000103a12fc1 java_start(Thread*) > + 173 > 47 libsystem_c.dylib 0x00007fff87e92782 _pthread_start + 327 > 48 libsystem_c.dylib 0x00007fff87e7f1c1 thread_start + 13 > > > > I ran otool -L on the library to check that the JavaNativeFoundation was > being linked and it looks like it is. It's output is as follows: > > macbook-air-2:MacTools shannah$ otool -L libmactools.dylib > libmactools.dylib: > /usr/local/lib/JSandbox.dylib (compatibility version 1.0.0, current > version 1.0.0) > /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation > (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa > (compatibility version 1.0.0, current version 19.0.0) > /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM > (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit > (compatibility version 45.0.0, current version 1187.0.0) > /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation > (compatibility version 300.0.0, current version 945.0.0) > /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version > 228.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 169.3.0) > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > (compatibility version 150.0.0, current version 744.0.0) > > > Does this information provide any clues that I might be missing? > > Thanks for all your help so far. > > Best regards > > Steve > > > On Sun, Oct 7, 2012 at 3:05 PM, Steve Hannah wrote: > > > >> >> This is not a valid C function based on the return type - in the case >>> where an error occurs, the return value of this function is undefined and >>> will likely be whatever garbage is left on the stack (isn't Xcode >>> warning/erroring about this like crazy???). You need a "return NULL;" at >>> the very end so that the JNI return value will be defined in the case where >>> you don't make it to the first return. >>> >>> Thanks for the tip, I'll add the null return and see if that helps. (No >> Xcode didn't complain... no warnings, no errors, "build succeeded"). >> >>> >>> Are you sure the library is even getting built and loaded? Can you make >>> a plain JNI function next to this one that contains nothing but a simple >>> "fprintf(stderr, "test\n");" in it? Call that first, and see if the library >>> is even loaded. >>> >>> Yes. The library is getting built and loaded. I have 2 other JNI >> methods that are working properly (but only if I don't wrap them in >> JNF_COCOA_ENTER/EXIT). In my java logging I output the string result of >> another one of the methods just before calling this one and it outputs fine. >> >> >>> Given my inexperience with XCode, I suspect that it could be a problem >>> with the way I'm building/linking the JNI library. The fact that calls to >>> JNFNSToJavaString() work makes me thing that the JavaNativeFoundation is >>> correctly linked (?). >>> >>> >>> It may be getting hauled in by Java 7 itself, and not explicitly linked. >>> If you don't have the JavaNativeFounation.framework explicitly linked in >>> the target that builds your library, that would also cause the compiler to >>> infer that the JNF_COCOA_ENTER/EXIT macros are actually functions, and >>> treat them as undeclared/unlinked entities. >>> >>> Run otool -L on your library, and make sure the full path to >>> JavaNativeFoundation.framework is printed out. If it isn't, you are only >>> picking up the symbols inside of it by accident. >>> >> >> Thanks... I'll try that. >> >> Best regards >> >> Steve >> >> >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> >>> Any other suggestions or tips, much appreciated. >>> >>> >>> Best regards >>> >>> Steve >>> >>> >>>>> JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - >>>>> they also catch ObjC exceptions and re-throw them as Java runtime >>>>> exceptions. >>>>> >>>>> Do you have the backtrace of where you are crashing when using >>>>> JNF_COCOA_ENTER/EXIT? >>>>> >>>> I do, but I'm having difficulty making heads or tails from it. I'm >>>> also struggling with getting logging information out on the Java side as >>>> I'm working on a Mountain Lion machine and I can't find where System.out >>>> and System.err are logged by default... and the sandbox is making it >>>> difficult for me to set a log location manually... (anything that runs or >>>> fails before or during the setting of a custom log location is not logged). >>>> >>>> >>>> I think (but I'm not certain) that this is the way it is now on Lion >>>> and Mountain Lion - output logged to stdout/stderr directly (including the >>>> JVM System.out/err) just goes to /dev/null unless you run the primary >>>> executable from a shell or some other parent process that gives it a TTY. >>>> Otherwise, the only thing that gets logged to the system console comes >>>> through ASL, like NSLog(). Of course, I may be completely off on this, but >>>> perhaps this is explaining what you are seeing. >>>> >>>> Also, are you doing anything special to run this JNI method on the main >>>>> AppKit thread (or are you using SWT)? >>>> >>>> Ah.. I hadn't thought of that, but yes. I'm overriding the >>>> java.awt.FileDialog class's setVisible() method to display this as a modal >>>> dialog. >>>> >>>> >>>>> If not, you may want to use +[JNFRunLoop >>>>> performOnMainThreadWaiting:withBlock:], which will block the current >>>>> thread, run your block on the main thread (safe for AppKit), and then >>>>> continue execution of your Java thread when the block returns. >>>>> >>>> >>>> I'll give this a shot. >>>> >>>> Thanks for the suggestions. >>>> >>>> >>>> No problem. Please do always think of the threading considerations when >>>> writing JNI. We try to let you not worry about exceptions and autorelease >>>> pools if you use JNF, but threading is still something you have to think >>>> through when you get JNI and Cocoa tangled together. >>>> >>>> Best of luck, >>>> Mike Swingler >>>> Apple Inc. >>>> >>>> >>> >>> >>> -- >>> Steve Hannah >>> Web Lite Solutions Corp. >>> >>> >>> >> >> >> -- >> Steve Hannah >> Web Lite Solutions Corp. >> >> > > > -- > Steve Hannah > Web Lite Solutions Corp. > > -- Steve Hannah Web Lite Solutions Corp. From swingler at apple.com Sun Oct 7 21:19:00 2012 From: swingler at apple.com (Mike Swingler) Date: Sun, 07 Oct 2012 21:19:00 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> <17A3153E-D19D-4FA7-AF5A-51B55765FABB@apple.com> Message-ID: <49ACFF32-5E28-4D3F-9EB2-CD933E55DA2D@apple.com> If you are using Java 7, DO NOT link the JavaVM.framework, ONLY the JavaNativeFoundation.framework. If you need to find jni.h, you need to pass the path to the "include" directory inside of your Java 7 JDK. I still don't understand how what looks like Java code is calling objc_retain() directly (and immediately dying on what is obviously a bad address). Could you try wrapping the body of this JNI function inside a new wrapper function, and calling the new wrapper from the existing JNI function? It would be interesting to know if you could see the actual JNI function itself, or the wrapper in the crashing stack. Also, double-check that the signature of your JNI function in C exactly matches the signature of the function in Java. You may have a parameter or type mis-match. And one more long-shot: are you compiling your JNI library as ARC, or manual retain/release? I very much doubt that JNF will work correctly with compiler-generated ARC calls...but I could be surprised. Regards, Mike Swingler Apple Inc. On Oct 7, 2012, at 8:37 PM, Steve Hannah wrote: > Another note: I just linked it to the JavaVM framework and JavaNativeFoundationFramework by right clicking on the "Other Frameworks" folder in the file tree of XCode, and selecting "Add Files to myproject", then proceeded to select: > /System/Library/Frameworks/JavaVM > and > /System/Library/Frameworks/JavaVM/Frameworks/JavaNativeFoundation. > > This is my first JNI library, so it is possible I erred somewhere here. E.g. is it possible I linked against a framework for Java 6 when it needs to be for Java 7? > > -Steve > > On Sun, Oct 7, 2012 at 6:42 PM, Steve Hannah wrote: > OK. I have made the following change to the method: > > > > JNIEXPORT jstring JNICALL Java_ca_weblite_mactools_Sandbox_saveDialog > > (JNIEnv *env, jobject jthis, jstring title, jstring extension){ > > JNF_COCOA_ENTER(<#env#>); > > return JNFNSToJavaString(env, @"/Users/shannah/Downloads/out2.pdf"); > > JNF_COCOA_EXIT(env); > > return NULL; > > } > > It still crashes. Here are some of the crash details. > > Process: JavaAppLauncher [13397] > Path: /Users/USER/Documents/*/MyApp.app/Contents/MacOS/JavaAppLauncher > Identifier: ca.myidentifier > Version: 1.9.32 (1.9.32) > Code Type: X86-64 (Native) > Parent Process: launchd [140] > User ID: 501 > > Date/Time: 2012-10-07 18:20:23.789 -0700 > OS Version: Mac OS X 10.8.1 (12B19) > Report Version: 10 > > Crashed Thread: 25 Java: Thread-2 > > Exception Type: EXC_BAD_ACCESS (SIGABRT) > Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 > > VM Regions Near 0x20: > --> > __TEXT 0000000103466000-000000010346a000 [ 16K] r-x/rwx SM=COW /Users/USER/Documents/*/MyApp.app/Contents/MacOS/JavaAppLauncher > > Application Specific Information: > abort() called > > > And the thread that crashed: > > Thread 25 Crashed:: Java: Thread-2 > 0 libsystem_kernel.dylib 0x00007fff8a043212 __pthread_kill + 10 > 1 libsystem_c.dylib 0x00007fff87e93b34 pthread_kill + 90 > 2 libsystem_c.dylib 0x00007fff87ed7dfa abort + 143 > 3 libjvm.dylib 0x0000000103a12a9f os::abort(bool) + 25 > 4 libjvm.dylib 0x0000000103aff35e VMError::report_and_die() + 2306 > 5 libjvm.dylib 0x0000000103a14193 JVM_handle_bsd_signal + 1073 > 6 libsystem_c.dylib 0x00007fff87e8092a _sigtramp + 26 > 7 libobjc.A.dylib 0x00007fff898d33ee objc_retain + 14 > 8 ??? 0x0000000104267f90 0 + 4364599184 > 9 ??? 0x000000010425c333 0 + 4364550963 > 10 ??? 0x00000001042564f7 0 + 4364526839 > 11 libjvm.dylib 0x00000001038ea083 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 > 12 libjvm.dylib 0x00000001038e9e50 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 > 13 libjvm.dylib 0x0000000103a53062 Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 2506 > 14 libjvm.dylib 0x0000000103a534ba Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*) + 360 > 15 libjvm.dylib 0x000000010391a99b JVM_InvokeMethod + 352 > 16 ??? 0x0000000104267f90 0 + 4364599184 > 17 ??? 0x000000010425c333 0 + 4364550963 > 18 ??? 0x000000010425c333 0 + 4364550963 > 19 ??? 0x000000010425c9e1 0 + 4364552673 > 20 ??? 0x000000010425c333 0 + 4364550963 > 21 ??? 0x000000010425c333 0 + 4364550963 > 22 ??? 0x000000010425c333 0 + 4364550963 > 23 ??? 0x000000010425c333 0 + 4364550963 > 24 ??? 0x000000010425c333 0 + 4364550963 > 25 ??? 0x000000010425c333 0 + 4364550963 > 26 ??? 0x000000010425c333 0 + 4364550963 > 27 ??? 0x000000010425c333 0 + 4364550963 > 28 ??? 0x000000010425c333 0 + 4364550963 > 29 ??? 0x000000010425c333 0 + 4364550963 > 30 ??? 0x000000010425c333 0 + 4364550963 > 31 ??? 0x000000010425c333 0 + 4364550963 > 32 ??? 0x000000010425c333 0 + 4364550963 > 33 ??? 0x000000010425c333 0 + 4364550963 > 34 ??? 0x000000010425c333 0 + 4364550963 > 35 ??? 0x000000010425c333 0 + 4364550963 > 36 ??? 0x000000010425c158 0 + 4364550488 > 37 ??? 0x000000010425c158 0 + 4364550488 > 38 ??? 0x000000010425c806 0 + 4364552198 > 39 ??? 0x00000001042564f7 0 + 4364526839 > 40 libjvm.dylib 0x00000001038ea083 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557 > 41 libjvm.dylib 0x00000001038ea560 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256 > 42 libjvm.dylib 0x00000001038ea69a JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 > 43 libjvm.dylib 0x000000010391d504 thread_entry(JavaThread*, Thread*) + 169 > 44 libjvm.dylib 0x0000000103ad4f74 JavaThread::thread_main_inner() + 134 > 45 libjvm.dylib 0x0000000103ad6413 JavaThread::run() + 369 > 46 libjvm.dylib 0x0000000103a12fc1 java_start(Thread*) + 173 > 47 libsystem_c.dylib 0x00007fff87e92782 _pthread_start + 327 > 48 libsystem_c.dylib 0x00007fff87e7f1c1 thread_start + 13 > > > > I ran otool -L on the library to check that the JavaNativeFoundation was being linked and it looks like it is. It's output is as follows: > > macbook-air-2:MacTools shannah$ otool -L libmactools.dylib > libmactools.dylib: > /usr/local/lib/JSandbox.dylib (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 19.0.0) > /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1187.0.0) > /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 945.0.0) > /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.0.0) > > > Does this information provide any clues that I might be missing? > > Thanks for all your help so far. > > Best regards > > Steve > > > On Sun, Oct 7, 2012 at 3:05 PM, Steve Hannah wrote: > > > > This is not a valid C function based on the return type - in the case where an error occurs, the return value of this function is undefined and will likely be whatever garbage is left on the stack (isn't Xcode warning/erroring about this like crazy???). You need a "return NULL;" at the very end so that the JNI return value will be defined in the case where you don't make it to the first return. > > Thanks for the tip, I'll add the null return and see if that helps. (No Xcode didn't complain... no warnings, no errors, "build succeeded"). > > Are you sure the library is even getting built and loaded? Can you make a plain JNI function next to this one that contains nothing but a simple "fprintf(stderr, "test\n");" in it? Call that first, and see if the library is even loaded. > > Yes. The library is getting built and loaded. I have 2 other JNI methods that are working properly (but only if I don't wrap them in JNF_COCOA_ENTER/EXIT). In my java logging I output the string result of another one of the methods just before calling this one and it outputs fine. > >> Given my inexperience with XCode, I suspect that it could be a problem with the way I'm building/linking the JNI library. The fact that calls to JNFNSToJavaString() work makes me thing that the JavaNativeFoundation is correctly linked (?). > > It may be getting hauled in by Java 7 itself, and not explicitly linked. If you don't have the JavaNativeFounation.framework explicitly linked in the target that builds your library, that would also cause the compiler to infer that the JNF_COCOA_ENTER/EXIT macros are actually functions, and treat them as undeclared/unlinked entities. > > Run otool -L on your library, and make sure the full path to JavaNativeFoundation.framework is printed out. If it isn't, you are only picking up the symbols inside of it by accident. > > Thanks... I'll try that. > > Best regards > > Steve > > > Regards, > Mike Swingler > Apple Inc. > >> Any other suggestions or tips, much appreciated. >> >> >> Best regards >> >> Steve >> >>> >>> JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - they also catch ObjC exceptions and re-throw them as Java runtime exceptions. >>> >>> Do you have the backtrace of where you are crashing when using JNF_COCOA_ENTER/EXIT? >>> I do, but I'm having difficulty making heads or tails from it. I'm also struggling with getting logging information out on the Java side as I'm working on a Mountain Lion machine and I can't find where System.out and System.err are logged by default... and the sandbox is making it difficult for me to set a log location manually... (anything that runs or fails before or during the setting of a custom log location is not logged). >> >> I think (but I'm not certain) that this is the way it is now on Lion and Mountain Lion - output logged to stdout/stderr directly (including the JVM System.out/err) just goes to /dev/null unless you run the primary executable from a shell or some other parent process that gives it a TTY. Otherwise, the only thing that gets logged to the system console comes through ASL, like NSLog(). Of course, I may be completely off on this, but perhaps this is explaining what you are seeing. >> >>> Also, are you doing anything special to run this JNI method on the main AppKit thread (or are you using SWT)? >>> Ah.. I hadn't thought of that, but yes. I'm overriding the java.awt.FileDialog class's setVisible() method to display this as a modal dialog. >>> >>> If not, you may want to use +[JNFRunLoop performOnMainThreadWaiting:withBlock:], which will block the current thread, run your block on the main thread (safe for AppKit), and then continue execution of your Java thread when the block returns. >>> >>> I'll give this a shot. >>> >>> Thanks for the suggestions. >> >> No problem. Please do always think of the threading considerations when writing JNI. We try to let you not worry about exceptions and autorelease pools if you use JNF, but threading is still something you have to think through when you get JNI and Cocoa tangled together. >> >> Best of luck, >> Mike Swingler >> Apple Inc. >> >> >> >> >> -- >> Steve Hannah >> Web Lite Solutions Corp. >> > > > > > -- > Steve Hannah > Web Lite Solutions Corp. > > > > > -- > Steve Hannah > Web Lite Solutions Corp. > > > > > -- > Steve Hannah > Web Lite Solutions Corp. > From steve at weblite.ca Sun Oct 7 22:44:51 2012 From: steve at weblite.ca (Steve Hannah) Date: Sun, 7 Oct 2012 22:44:51 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: <49ACFF32-5E28-4D3F-9EB2-CD933E55DA2D@apple.com> References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> <17A3153E-D19D-4FA7-AF5A-51B55765FABB@apple.com> <49ACFF32-5E28-4D3F-9EB2-CD933E55DA2D@apple.com> Message-ID: > And one more long-shot: are you compiling your JNI library as ARC, or > manual retain/release? I very much doubt that JNF will work correctly with > compiler-generated ARC calls...but I could be surprised. > > Your long shot was the money shot! ARC was turned on. After disabling it, everything works as it should. Thank you so much for your help. It is quite likely that I would have had to spend a month of Sundays solving this problem if not for your help on this. Best regards Steve > Regards, > Mike Swingler > Apple Inc. > > On Oct 7, 2012, at 8:37 PM, Steve Hannah wrote: > > Another note: I just linked it to the JavaVM framework and > JavaNativeFoundationFramework by right clicking on the "Other Frameworks" > folder in the file tree of XCode, and selecting "Add Files to myproject", > then proceeded to select: > /System/Library/Frameworks/JavaVM > and > /System/Library/Frameworks/JavaVM/Frameworks/JavaNativeFoundation. > > This is my first JNI library, so it is possible I erred somewhere here. > E.g. is it possible I linked against a framework for Java 6 when it needs > to be for Java 7? > > -Steve > > On Sun, Oct 7, 2012 at 6:42 PM, Steve Hannah wrote: > >> OK. I have made the following change to the method: >> >> >> JNIEXPORT jstring JNICALL Java_ca_weblite_mactools_Sandbox_saveDialog >> >> (JNIEnv *env, jobject jthis, jstring title, jstring extension){ >> >> JNF_COCOA_ENTER(<#env#>); >> >> return JNFNSToJavaString(env, @"/Users/shannah/Downloads/out2.pdf"); >> >> JNF_COCOA_EXIT(env); >> >> return NULL; >> } >> >> It still crashes. Here are some of the crash details. >> >> Process: JavaAppLauncher [13397] >> Path: >> /Users/USER/Documents/*/MyApp.app/Contents/MacOS/JavaAppLauncher >> Identifier: ca.myidentifier >> Version: 1.9.32 (1.9.32) >> Code Type: X86-64 (Native) >> Parent Process: launchd [140] >> User ID: 501 >> >> Date/Time: 2012-10-07 18:20:23.789 -0700 >> OS Version: Mac OS X 10.8.1 (12B19) >> Report Version: 10 >> >> Crashed Thread: 25 Java: Thread-2 >> >> Exception Type: EXC_BAD_ACCESS (SIGABRT) >> Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 >> >> VM Regions Near 0x20: >> --> >> __TEXT 0000000103466000-000000010346a000 [ 16K] >> r-x/rwx SM=COW >> /Users/USER/Documents/*/MyApp.app/Contents/MacOS/JavaAppLauncher >> >> Application Specific Information: >> abort() called >> >> >> And the thread that crashed: >> >> Thread 25 Crashed:: Java: Thread-2 >> 0 libsystem_kernel.dylib 0x00007fff8a043212 __pthread_kill + 10 >> 1 libsystem_c.dylib 0x00007fff87e93b34 pthread_kill + 90 >> 2 libsystem_c.dylib 0x00007fff87ed7dfa abort + 143 >> 3 libjvm.dylib 0x0000000103a12a9f os::abort(bool) + >> 25 >> 4 libjvm.dylib 0x0000000103aff35e >> VMError::report_and_die() + 2306 >> 5 libjvm.dylib 0x0000000103a14193 >> JVM_handle_bsd_signal + 1073 >> 6 libsystem_c.dylib 0x00007fff87e8092a _sigtramp + 26 >> 7 libobjc.A.dylib 0x00007fff898d33ee objc_retain + 14 >> 8 ??? 0x0000000104267f90 0 + 4364599184 >> 9 ??? 0x000000010425c333 0 + 4364550963 >> 10 ??? 0x00000001042564f7 0 + 4364526839 >> 11 libjvm.dylib 0x00000001038ea083 >> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 557 >> 12 libjvm.dylib 0x00000001038e9e50 >> JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40 >> 13 libjvm.dylib 0x0000000103a53062 >> Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool, >> objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 2506 >> 14 libjvm.dylib 0x0000000103a534ba >> Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*) + 360 >> 15 libjvm.dylib 0x000000010391a99b JVM_InvokeMethod + >> 352 >> 16 ??? 0x0000000104267f90 0 + 4364599184 >> 17 ??? 0x000000010425c333 0 + 4364550963 >> 18 ??? 0x000000010425c333 0 + 4364550963 >> 19 ??? 0x000000010425c9e1 0 + 4364552673 >> 20 ??? 0x000000010425c333 0 + 4364550963 >> 21 ??? 0x000000010425c333 0 + 4364550963 >> 22 ??? 0x000000010425c333 0 + 4364550963 >> 23 ??? 0x000000010425c333 0 + 4364550963 >> 24 ??? 0x000000010425c333 0 + 4364550963 >> 25 ??? 0x000000010425c333 0 + 4364550963 >> 26 ??? 0x000000010425c333 0 + 4364550963 >> 27 ??? 0x000000010425c333 0 + 4364550963 >> 28 ??? 0x000000010425c333 0 + 4364550963 >> 29 ??? 0x000000010425c333 0 + 4364550963 >> 30 ??? 0x000000010425c333 0 + 4364550963 >> 31 ??? 0x000000010425c333 0 + 4364550963 >> 32 ??? 0x000000010425c333 0 + 4364550963 >> 33 ??? 0x000000010425c333 0 + 4364550963 >> 34 ??? 0x000000010425c333 0 + 4364550963 >> 35 ??? 0x000000010425c333 0 + 4364550963 >> 36 ??? 0x000000010425c158 0 + 4364550488 >> 37 ??? 0x000000010425c158 0 + 4364550488 >> 38 ??? 0x000000010425c806 0 + 4364552198 >> 39 ??? 0x00000001042564f7 0 + 4364526839 >> 40 libjvm.dylib 0x00000001038ea083 >> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, >> Thread*) + 557 >> 41 libjvm.dylib 0x00000001038ea560 >> JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, >> JavaCallArguments*, Thread*) + 256 >> 42 libjvm.dylib 0x00000001038ea69a >> JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, >> Thread*) + 74 >> 43 libjvm.dylib 0x000000010391d504 >> thread_entry(JavaThread*, Thread*) + 169 >> 44 libjvm.dylib 0x0000000103ad4f74 >> JavaThread::thread_main_inner() + 134 >> 45 libjvm.dylib 0x0000000103ad6413 JavaThread::run() >> + 369 >> 46 libjvm.dylib 0x0000000103a12fc1 >> java_start(Thread*) + 173 >> 47 libsystem_c.dylib 0x00007fff87e92782 _pthread_start + 327 >> 48 libsystem_c.dylib 0x00007fff87e7f1c1 thread_start + 13 >> >> >> >> I ran otool -L on the library to check that the JavaNativeFoundation was >> being linked and it looks like it is. It's output is as follows: >> >> macbook-air-2:MacTools shannah$ otool -L libmactools.dylib >> libmactools.dylib: >> /usr/local/lib/JSandbox.dylib (compatibility version 1.0.0, current >> version 1.0.0) >> /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation >> (compatibility version 1.0.0, current version 1.0.0) >> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa >> (compatibility version 1.0.0, current version 19.0.0) >> /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM >> (compatibility version 1.0.0, current version 1.0.0) >> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit >> (compatibility version 45.0.0, current version 1187.0.0) >> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation >> (compatibility version 300.0.0, current version 945.0.0) >> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version >> 228.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version >> 169.3.0) >> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation >> (compatibility version 150.0.0, current version 744.0.0) >> >> >> Does this information provide any clues that I might be missing? >> >> Thanks for all your help so far. >> >> Best regards >> >> Steve >> >> >> On Sun, Oct 7, 2012 at 3:05 PM, Steve Hannah wrote: >> >> >> >>> >>> This is not a valid C function based on the return type - in the case >>>> where an error occurs, the return value of this function is undefined and >>>> will likely be whatever garbage is left on the stack (isn't Xcode >>>> warning/erroring about this like crazy???). You need a "return NULL;" at >>>> the very end so that the JNI return value will be defined in the case where >>>> you don't make it to the first return. >>>> >>>> Thanks for the tip, I'll add the null return and see if that helps. >>> (No Xcode didn't complain... no warnings, no errors, "build succeeded"). >>> >>>> >>>> Are you sure the library is even getting built and loaded? Can you make >>>> a plain JNI function next to this one that contains nothing but a simple >>>> "fprintf(stderr, "test\n");" in it? Call that first, and see if the library >>>> is even loaded. >>>> >>>> Yes. The library is getting built and loaded. I have 2 other JNI >>> methods that are working properly (but only if I don't wrap them in >>> JNF_COCOA_ENTER/EXIT). In my java logging I output the string result of >>> another one of the methods just before calling this one and it outputs fine. >>> >>> >>>> Given my inexperience with XCode, I suspect that it could be a problem >>>> with the way I'm building/linking the JNI library. The fact that calls to >>>> JNFNSToJavaString() work makes me thing that the JavaNativeFoundation is >>>> correctly linked (?). >>>> >>>> >>>> It may be getting hauled in by Java 7 itself, and not explicitly >>>> linked. If you don't have the JavaNativeFounation.framework explicitly >>>> linked in the target that builds your library, that would also cause the >>>> compiler to infer that the JNF_COCOA_ENTER/EXIT macros are actually >>>> functions, and treat them as undeclared/unlinked entities. >>>> >>>> Run otool -L on your library, and make sure the full path to >>>> JavaNativeFoundation.framework is printed out. If it isn't, you are only >>>> picking up the symbols inside of it by accident. >>>> >>> >>> Thanks... I'll try that. >>> >>> Best regards >>> >>> Steve >>> >>> >>>> >>>> Regards, >>>> Mike Swingler >>>> Apple Inc. >>>> >>>> Any other suggestions or tips, much appreciated. >>>> >>>> >>>> Best regards >>>> >>>> Steve >>>> >>>> >>>>>> JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - >>>>>> they also catch ObjC exceptions and re-throw them as Java runtime >>>>>> exceptions. >>>>>> >>>>>> Do you have the backtrace of where you are crashing when using >>>>>> JNF_COCOA_ENTER/EXIT? >>>>>> >>>>> I do, but I'm having difficulty making heads or tails from it. I'm >>>>> also struggling with getting logging information out on the Java side as >>>>> I'm working on a Mountain Lion machine and I can't find where System.out >>>>> and System.err are logged by default... and the sandbox is making it >>>>> difficult for me to set a log location manually... (anything that runs or >>>>> fails before or during the setting of a custom log location is not logged). >>>>> >>>>> >>>>> I think (but I'm not certain) that this is the way it is now on Lion >>>>> and Mountain Lion - output logged to stdout/stderr directly (including the >>>>> JVM System.out/err) just goes to /dev/null unless you run the primary >>>>> executable from a shell or some other parent process that gives it a TTY. >>>>> Otherwise, the only thing that gets logged to the system console comes >>>>> through ASL, like NSLog(). Of course, I may be completely off on this, but >>>>> perhaps this is explaining what you are seeing. >>>>> >>>>> Also, are you doing anything special to run this JNI method on the >>>>>> main AppKit thread (or are you using SWT)? >>>>> >>>>> Ah.. I hadn't thought of that, but yes. I'm overriding the >>>>> java.awt.FileDialog class's setVisible() method to display this as a modal >>>>> dialog. >>>>> >>>>> >>>>>> If not, you may want to use +[JNFRunLoop >>>>>> performOnMainThreadWaiting:withBlock:], which will block the current >>>>>> thread, run your block on the main thread (safe for AppKit), and then >>>>>> continue execution of your Java thread when the block returns. >>>>>> >>>>> >>>>> I'll give this a shot. >>>>> >>>>> Thanks for the suggestions. >>>>> >>>>> >>>>> No problem. Please do always think of the threading considerations >>>>> when writing JNI. We try to let you not worry about exceptions and >>>>> autorelease pools if you use JNF, but threading is still something you have >>>>> to think through when you get JNI and Cocoa tangled together. >>>>> >>>>> Best of luck, >>>>> Mike Swingler >>>>> Apple Inc. >>>>> >>>>> >>>> >>>> >>>> -- >>>> Steve Hannah >>>> Web Lite Solutions Corp. >>>> >>>> >>>> >>> >>> >>> -- >>> Steve Hannah >>> Web Lite Solutions Corp. >>> >>> >> >> >> -- >> Steve Hannah >> Web Lite Solutions Corp. >> >> > > > -- > Steve Hannah > Web Lite Solutions Corp. > > > -- Steve Hannah Web Lite Solutions Corp. From swingler at apple.com Sun Oct 7 23:26:31 2012 From: swingler at apple.com (Mike Swingler) Date: Sun, 07 Oct 2012 23:26:31 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> <17A3153E-D19D-4FA7-AF5A-51B55765FABB@apple.com> <49ACFF32-5E28-4D3F-9EB2-CD933E55DA2D@apple.com> Message-ID: On Oct 7, 2012, at 10:44 PM, Steve Hannah wrote: > And one more long-shot: are you compiling your JNI library as ARC, or manual retain/release? I very much doubt that JNF will work correctly with compiler-generated ARC calls...but I could be surprised. > > Your long shot was the money shot! ARC was turned on. After disabling it, everything works as it should. Thank you so much for your help. It is quite likely that I would have had to spend a month of Sundays solving this problem if not for your help on this. Awesome. Something about that raw objc_retain() straight out of the generated Java call was bugging me, and in retrospect I should have recognized it as the blatant preamble/postscript that gets generated around and in functions that are built with ARC. Suffice it to say, this is fair warning against those who would try to mix JNI and ARC. For now, don't. Just stick with MRR. Perhaps the JNF functions and macros could be sufficiently decorated with clang attributes to avoid this kind of problem, but I'd have to really think through the edge cases of how ARC interacts with the JNF autorelease pool management to be sure we got it right. If this is actually of any interest to anyone out there in the real world, please feel free to file a bug at - though, if using MRR is good enough, maybe it's just good enough. Always happy to help, Mike Swingler Apple Inc. From jcpalmer at rochester.rr.com Mon Oct 8 13:44:55 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Mon, 8 Oct 2012 16:44:55 -0400 Subject: getting quartz fonts & Java 6 sound effects Message-ID: <146700F8-0347-4CAD-BD8F-DBDF60244D4E@rochester.rr.com> I might be getting a little picky, but has anyone reported that fonts and sounds are inferior to Java 6? Using JWS, I specify apple.awt.graphics.UseQuartz=true for 1.6. I am using the default font: com.apple.laf.AquaFonts$DerivedUIResourceFont[family=Lucida Grande,name=Lucida Grande,style=plain,size=13] I guess I could pull out the UseQuartz and make them look the same, but thought I should at least send this note. Sound wise, I put in some sound effects to correspond to some events. The Java 6 versions are just so much better, especially for the SYNTH_STRINGS_2 instrument, index 51. This is not going to stop implementation, but I was just wondering. Jeff Palmer From steve at weblite.ca Mon Oct 8 14:12:26 2012 From: steve at weblite.ca (Steve Hannah) Date: Mon, 8 Oct 2012 14:12:26 -0700 Subject: JNI wrapper for NSSavePanel In-Reply-To: References: <1A426C9A-4A4D-4C40-BF25-C4F57175CC0F@apple.com> <1D5E85E1-4D91-45F1-849B-4DA3F77551A6@apple.com> <17A3153E-D19D-4FA7-AF5A-51B55765FABB@apple.com> <49ACFF32-5E28-4D3F-9EB2-CD933E55DA2D@apple.com> Message-ID: I have written a short tutorial on this, my first adventure with JNI, so that others might be able to learn from my failures. http://www.shannah.ca/blog/?p=217 Thanks again for all the help. Steve On Sun, Oct 7, 2012 at 11:26 PM, Mike Swingler wrote: > On Oct 7, 2012, at 10:44 PM, Steve Hannah wrote: > > And one more long-shot: are you compiling your JNI library as ARC, or >> manual retain/release? I very much doubt that JNF will work correctly with >> compiler-generated ARC calls...but I could be surprised. >> > > Your long shot was the money shot! ARC was turned on. After disabling > it, everything works as it should. Thank you so much for your help. It is > quite likely that I would have had to spend a month of Sundays solving this > problem if not for your help on this. > > > Awesome. Something about that raw objc_retain() straight out of the > generated Java call was bugging me, and in retrospect I should have > recognized it as the blatant preamble/postscript that gets generated around > and in functions that are built with ARC. > > Suffice it to say, this is fair warning against those who would try to mix > JNI and ARC. For now, don't. Just stick with MRR. > > Perhaps the JNF functions and macros could be sufficiently decorated with > clang attributes to avoid this kind of problem, but I'd have to really > think through the edge cases of how ARC interacts with the JNF autorelease > pool management to be sure we got it right. If this is actually of any > interest to anyone out there in the real world, please feel free to file a > bug at - though, if using MRR is good > enough, maybe it's just good enough. > > Always happy to help, > Mike Swingler > Apple Inc. > > -- Steve Hannah Web Lite Solutions Corp. From alexander.zuev at oracle.com Tue Oct 9 01:35:58 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 09 Oct 2012 12:35:58 +0400 Subject: [8] Please review fix for 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test Message-ID: <5073E1EE.80403@oracle.com> Hello, please review my fix for CR 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test The NPE happens because we do not check the passed argument to null before using it. The correct exception according to the specification should be IllegalArgumentException. Bug description is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175704 Webrev can be found here: http://cr.openjdk.java.net/~kizune/7175704/webrev.00 With best regards, Alex From paul_t100 at fastmail.fm Tue Oct 9 02:40:02 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 09 Oct 2012 10:40:02 +0100 Subject: OSX not placing windows of Swing application in a sensible location In-Reply-To: <506ED2E1.5050303@oracle.com> References: <506ECD7B.1050901@fastmail.fm> <506ED2E1.5050303@oracle.com> Message-ID: <5073F0F2.5040107@fastmail.fm> On 05/10/2012 13:30, Anthony Petrov wrote: > Please file a bug at http://bugs.sun.com/ > > -- > best regards, > Anthony Bugs submitted (funny that the url is sun and bugs.oracle.com doesnt exist) Whilst waiting for it to be confirmed, here is the test case FYI import javax.swing.*; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; class Test { public static void main(final String[] args) throws Exception { setupScreen(); } public static void setupScreen() throws Exception { UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); JFrame frame = new JFrame("test"); JButton button = new JButton("go"); button.addActionListener( new ActionListener() { @Override public void actionPerformed(ActionEvent e) { JDialog dialog = new JDialog(); dialog.add(new JTextArea(20,20)); dialog.pack(); dialog.setVisible(true); } } ); frame.setLocationByPlatform(true); frame.add(button); frame.pack(); frame.setVisible(true); } } From alexander.zuev at oracle.com Tue Oct 9 02:43:43 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 09 Oct 2012 13:43:43 +0400 Subject: getting quartz fonts & Java 6 sound effects In-Reply-To: <146700F8-0347-4CAD-BD8F-DBDF60244D4E@rochester.rr.com> References: <146700F8-0347-4CAD-BD8F-DBDF60244D4E@rochester.rr.com> Message-ID: <5073F1CF.7010602@oracle.com> Jeff, unfortunately we don't support quartz for the on-screen rendering in Java 7 so UseQuartz=true does not do any difference. As for the sound - using the JavaSoundDemo from the Apple Developer Extras i definitely noticed a difference in the sound of the Synth Strings 2 instrument - Apple version has much more complexity. I will raise that concern with our media expert. With best regards, Alexander Zuev On 10/9/12 24:44, Jeff Palmer wrote: > I might be getting a little picky, but has anyone reported that fonts and sounds are inferior to Java 6? Using JWS, I specify apple.awt.graphics.UseQuartz=true for 1.6. I am using the default font: > > com.apple.laf.AquaFonts$DerivedUIResourceFont[family=Lucida Grande,name=Lucida Grande,style=plain,size=13] > > I guess I could pull out the UseQuartz and make them look the same, but thought I should at least send this note. > > Sound wise, I put in some sound effects to correspond to some events. The Java 6 versions are just so much better, especially for the SYNTH_STRINGS_2 instrument, index 51. > > This is not going to stop implementation, but I was just wondering. > > Jeff Palmer > From paul_t100 at fastmail.fm Tue Oct 9 03:04:32 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 09 Oct 2012 11:04:32 +0100 Subject: getting quartz fonts & Java 6 sound effects In-Reply-To: <5073F1CF.7010602@oracle.com> References: <146700F8-0347-4CAD-BD8F-DBDF60244D4E@rochester.rr.com> <5073F1CF.7010602@oracle.com> Message-ID: <5073F6B0.1080509@fastmail.fm> On 09/10/2012 10:43, Alexander Zuev wrote: > Jeff, > > unfortunately we don't support quartz for the on-screen rendering in > Java 7 so UseQuartz=true does not > do any difference. As for the sound - using the JavaSoundDemo from the > Apple Developer Extras i > definitely noticed a difference in the sound of the Synth Strings 2 > instrument - Apple version has much > more complexity. I will raise that concern with our media expert. > > With best regards, > Alexander Zuev > Is the lack of Quatrz support a temporary decision or permanent, could you give us the reasoning behind this ? Paul > On 10/9/12 24:44, Jeff Palmer wrote: >> I might be getting a little picky, but has anyone reported that fonts >> and sounds are inferior to Java 6? Using JWS, I specify >> apple.awt.graphics.UseQuartz=true for 1.6. I am using the default font: >> >> com.apple.laf.AquaFonts$DerivedUIResourceFont[family=Lucida >> Grande,name=Lucida Grande,style=plain,size=13] >> >> I guess I could pull out the UseQuartz and make them look the same, >> but thought I should at least send this note. >> >> Sound wise, I put in some sound effects to correspond to some >> events. The Java 6 versions are just so much better, especially for >> the SYNTH_STRINGS_2 instrument, index 51. >> >> This is not going to stop implementation, but I was just wondering. >> >> Jeff Palmer >> > > From Sergey.Bylokhov at oracle.com Tue Oct 9 03:12:40 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 09 Oct 2012 14:12:40 +0400 Subject: [8] Please review fix for 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test In-Reply-To: <5073E1EE.80403@oracle.com> References: <5073E1EE.80403@oracle.com> Message-ID: <5073F898.70304@oracle.com> Hi, Alexander On win32 anx X11 we have another exception text message "Invalid display mode", also there is additional check in getMatchingDisplayMode() is it unnecessary on the macosx? 09.10.2012 12:35, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7175704: [macosx] "8" PIT: NPE in > GetDisplayMode fullscreen test > > The NPE happens because we do not check the passed argument to null > before using it. The correct exception according to the specification > should be IllegalArgumentException. > > Bug description is: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175704 > Webrev can be found here: > http://cr.openjdk.java.net/~kizune/7175704/webrev.00 > > With best regards, > Alex -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Oct 9 03:23:23 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 09 Oct 2012 14:23:23 +0400 Subject: OSX not placing windows of Swing application in a sensible location In-Reply-To: <5073F0F2.5040107@fastmail.fm> References: <506ECD7B.1050901@fastmail.fm> <506ED2E1.5050303@oracle.com> <5073F0F2.5040107@fastmail.fm> Message-ID: <5073FB1B.1000306@oracle.com> Thanks. We'll take a look at it once the bug is in our bug tracking system. -- best regards, Anthony On 10/9/2012 1:40 PM, Paul Taylor wrote: > On 05/10/2012 13:30, Anthony Petrov wrote: >> Please file a bug at http://bugs.sun.com/ >> >> -- >> best regards, >> Anthony > Bugs submitted (funny that the url is sun and bugs.oracle.com doesnt exist) > > Whilst waiting for it to be confirmed, here is the test case FYI > > import javax.swing.*; > import java.awt.event.ActionEvent; > import java.awt.event.ActionListener; > > class Test > { > public static void main(final String[] args) throws Exception > { > setupScreen(); > } > > > public static void setupScreen() throws Exception > { > UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); > JFrame frame = new JFrame("test"); > JButton button = new JButton("go"); > button.addActionListener( > new ActionListener() > { > @Override > public void actionPerformed(ActionEvent e) > { > JDialog dialog = new JDialog(); > dialog.add(new JTextArea(20,20)); > dialog.pack(); > dialog.setVisible(true); > } > } > ); > frame.setLocationByPlatform(true); > frame.add(button); > frame.pack(); > frame.setVisible(true); > } > } From alexander.zuev at oracle.com Tue Oct 9 03:25:13 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 09 Oct 2012 14:25:13 +0400 Subject: [8] Please review fix for 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test In-Reply-To: <5073F898.70304@oracle.com> References: <5073E1EE.80403@oracle.com> <5073F898.70304@oracle.com> Message-ID: <5073FB89.8050903@oracle.com> Sergey, the text message is not specified in the documentation and the new one is already used on MacOS X in the jdk7 so i would let it be as it is for consistency. The check in obtaining matching display mode is already performed in the native code: In CGraphicsDevice.m : CGDisplayModeRef closestMatch = getBestModeForParameters(allModes, (int)w, (int)h, (int)bpp, (int)refrate); if (closestMatch != NULL) { ... } else { [JNFException raise:env as:kIllegalArgumentException reason:"Invalid display mode"]; } With best regards, Alexander Zuev On 10/9/12 14:12, Sergey Bylokhov wrote: > Hi, Alexander > On win32 anx X11 we have another exception text message "Invalid > display mode", also there is additional check in > getMatchingDisplayMode() is it unnecessary on the macosx? > > 09.10.2012 12:35, Alexander Zuev wrote: >> Hello, >> >> please review my fix for CR 7175704: [macosx] "8" PIT: NPE in >> GetDisplayMode fullscreen test >> >> The NPE happens because we do not check the passed argument to null >> before using it. The correct exception according to the specification >> should be IllegalArgumentException. >> >> Bug description is: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175704 >> Webrev can be found here: >> http://cr.openjdk.java.net/~kizune/7175704/webrev.00 >> >> With best regards, >> Alex > > From Sergey.Bylokhov at oracle.com Tue Oct 9 03:31:54 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 09 Oct 2012 14:31:54 +0400 Subject: [8] Please review fix for 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test In-Reply-To: <5073FB89.8050903@oracle.com> References: <5073E1EE.80403@oracle.com> <5073F898.70304@oracle.com> <5073FB89.8050903@oracle.com> Message-ID: <5073FD1A.1040706@oracle.com> 09.10.2012 14:25, Alexander Zuev wrote: > Sergey, > > the text message is not specified in the documentation and the new > one is already used on MacOS X > in the jdk7 so i would let it be as it is for consistency. I don't see a reason not to unify it across tolkits. Why we should use different text on different platforms? > The check in obtaining matching display mode is already performed in > the native code: > In CGraphicsDevice.m : > > CGDisplayModeRef closestMatch = getBestModeForParameters(allModes, > (int)w, (int)h, (int)bpp, (int)refrate); > if (closestMatch != NULL) { > ... > } else { > [JNFException raise:env as:kIllegalArgumentException > reason:"Invalid display mode"]; > } > > With best regards, > Alexander Zuev > > On 10/9/12 14:12, Sergey Bylokhov wrote: >> Hi, Alexander >> On win32 anx X11 we have another exception text message "Invalid >> display mode", also there is additional check in >> getMatchingDisplayMode() is it unnecessary on the macosx? >> >> 09.10.2012 12:35, Alexander Zuev wrote: >>> Hello, >>> >>> please review my fix for CR 7175704: [macosx] "8" PIT: NPE in >>> GetDisplayMode fullscreen test >>> >>> The NPE happens because we do not check the passed argument to >>> null before using it. The correct exception according to the >>> specification should be IllegalArgumentException. >>> >>> Bug description is: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175704 >>> Webrev can be found here: >>> http://cr.openjdk.java.net/~kizune/7175704/webrev.00 >>> >>> With best regards, >>> Alex >> >> > -- Best regards, Sergey. From alexander.zuev at oracle.com Tue Oct 9 03:34:29 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 09 Oct 2012 14:34:29 +0400 Subject: [8] Please review fix for 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test In-Reply-To: <5073FD1A.1040706@oracle.com> References: <5073E1EE.80403@oracle.com> <5073F898.70304@oracle.com> <5073FB89.8050903@oracle.com> <5073FD1A.1040706@oracle.com> Message-ID: <5073FDB5.6060801@oracle.com> On 10/9/12 14:31, Sergey Bylokhov wrote: > 09.10.2012 14:25, Alexander Zuev wrote: >> Sergey, >> >> the text message is not specified in the documentation and the new >> one is already used on MacOS X >> in the jdk7 so i would let it be as it is for consistency. > I don't see a reason not to unify it across tolkits. Why we should use > different text on different platforms? Ok, you convinced me - i will change the text to the "Invalid display mode" before the push - don't think it is such a big change that i need to recreate the webrev. >> The check in obtaining matching display mode is already performed in >> the native code: >> In CGraphicsDevice.m : >> >> CGDisplayModeRef closestMatch = >> getBestModeForParameters(allModes, (int)w, (int)h, (int)bpp, >> (int)refrate); >> if (closestMatch != NULL) { >> ... >> } else { >> [JNFException raise:env as:kIllegalArgumentException >> reason:"Invalid display mode"]; >> } >> >> With best regards, >> Alexander Zuev >> >> On 10/9/12 14:12, Sergey Bylokhov wrote: >>> Hi, Alexander >>> On win32 anx X11 we have another exception text message "Invalid >>> display mode", also there is additional check in >>> getMatchingDisplayMode() is it unnecessary on the macosx? >>> >>> 09.10.2012 12:35, Alexander Zuev wrote: >>>> Hello, >>>> >>>> please review my fix for CR 7175704: [macosx] "8" PIT: NPE in >>>> GetDisplayMode fullscreen test >>>> >>>> The NPE happens because we do not check the passed argument to >>>> null before using it. The correct exception according to the >>>> specification should be IllegalArgumentException. >>>> >>>> Bug description is: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175704 >>>> Webrev can be found here: >>>> http://cr.openjdk.java.net/~kizune/7175704/webrev.00 >>>> >>>> With best regards, >>>> Alex >>> >>> >> > > From Sergey.Bylokhov at oracle.com Tue Oct 9 03:35:27 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 09 Oct 2012 14:35:27 +0400 Subject: [8] Please review fix for 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test In-Reply-To: <5073FD1A.1040706@oracle.com> References: <5073E1EE.80403@oracle.com> <5073F898.70304@oracle.com> <5073FB89.8050903@oracle.com> <5073FD1A.1040706@oracle.com> Message-ID: <5073FDEF.8040102@oracle.com> Also why we don't throw IllegalStateException("Must be in fullscreen mode in order to set display mode") when getFullScreenWindow==null? 09.10.2012 14:31, Sergey Bylokhov wrote: > 09.10.2012 14:25, Alexander Zuev wrote: >> Sergey, >> >> the text message is not specified in the documentation and the new >> one is already used on MacOS X >> in the jdk7 so i would let it be as it is for consistency. > I don't see a reason not to unify it across tolkits. Why we should use > different text on different platforms? >> The check in obtaining matching display mode is already performed in >> the native code: >> In CGraphicsDevice.m : >> >> CGDisplayModeRef closestMatch = >> getBestModeForParameters(allModes, (int)w, (int)h, (int)bpp, >> (int)refrate); >> if (closestMatch != NULL) { >> ... >> } else { >> [JNFException raise:env as:kIllegalArgumentException >> reason:"Invalid display mode"]; >> } >> >> With best regards, >> Alexander Zuev >> >> On 10/9/12 14:12, Sergey Bylokhov wrote: >>> Hi, Alexander >>> On win32 anx X11 we have another exception text message "Invalid >>> display mode", also there is additional check in >>> getMatchingDisplayMode() is it unnecessary on the macosx? >>> >>> 09.10.2012 12:35, Alexander Zuev wrote: >>>> Hello, >>>> >>>> please review my fix for CR 7175704: [macosx] "8" PIT: NPE in >>>> GetDisplayMode fullscreen test >>>> >>>> The NPE happens because we do not check the passed argument to >>>> null before using it. The correct exception according to the >>>> specification should be IllegalArgumentException. >>>> >>>> Bug description is: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175704 >>>> Webrev can be found here: >>>> http://cr.openjdk.java.net/~kizune/7175704/webrev.00 >>>> >>>> With best regards, >>>> Alex >>> >>> >> > > -- Best regards, Sergey. From alexander.zuev at oracle.com Tue Oct 9 03:38:18 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 09 Oct 2012 14:38:18 +0400 Subject: [8] Please review fix for 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test In-Reply-To: <5073FDEF.8040102@oracle.com> References: <5073E1EE.80403@oracle.com> <5073F898.70304@oracle.com> <5073FB89.8050903@oracle.com> <5073FD1A.1040706@oracle.com> <5073FDEF.8040102@oracle.com> Message-ID: <5073FE9A.3040206@oracle.com> Because on Mac we are currently supporting display mode change operation in non-fullscreen mode. On 10/9/12 14:35, Sergey Bylokhov wrote: > Also why we don't throw IllegalStateException("Must be in fullscreen > mode in order to set display mode") when getFullScreenWindow==null? > > 09.10.2012 14:31, Sergey Bylokhov wrote: >> 09.10.2012 14:25, Alexander Zuev wrote: >>> Sergey, >>> >>> the text message is not specified in the documentation and the new >>> one is already used on MacOS X >>> in the jdk7 so i would let it be as it is for consistency. >> I don't see a reason not to unify it across tolkits. Why we should >> use different text on different platforms? >>> The check in obtaining matching display mode is already performed in >>> the native code: >>> In CGraphicsDevice.m : >>> >>> CGDisplayModeRef closestMatch = >>> getBestModeForParameters(allModes, (int)w, (int)h, (int)bpp, >>> (int)refrate); >>> if (closestMatch != NULL) { >>> ... >>> } else { >>> [JNFException raise:env as:kIllegalArgumentException >>> reason:"Invalid display mode"]; >>> } >>> >>> With best regards, >>> Alexander Zuev >>> >>> On 10/9/12 14:12, Sergey Bylokhov wrote: >>>> Hi, Alexander >>>> On win32 anx X11 we have another exception text message "Invalid >>>> display mode", also there is additional check in >>>> getMatchingDisplayMode() is it unnecessary on the macosx? >>>> >>>> 09.10.2012 12:35, Alexander Zuev wrote: >>>>> Hello, >>>>> >>>>> please review my fix for CR 7175704: [macosx] "8" PIT: NPE in >>>>> GetDisplayMode fullscreen test >>>>> >>>>> The NPE happens because we do not check the passed argument to >>>>> null before using it. The correct exception according to the >>>>> specification should be IllegalArgumentException. >>>>> >>>>> Bug description is: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175704 >>>>> Webrev can be found here: >>>>> http://cr.openjdk.java.net/~kizune/7175704/webrev.00 >>>>> >>>>> With best regards, >>>>> Alex >>>> >>>> >>> >> >> > > From Sergey.Bylokhov at oracle.com Tue Oct 9 03:45:52 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 09 Oct 2012 14:45:52 +0400 Subject: [8] Please review fix for 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test In-Reply-To: <5073FE9A.3040206@oracle.com> References: <5073E1EE.80403@oracle.com> <5073F898.70304@oracle.com> <5073FB89.8050903@oracle.com> <5073FD1A.1040706@oracle.com> <5073FDEF.8040102@oracle.com> <5073FE9A.3040206@oracle.com> Message-ID: <50740060.6030502@oracle.com> Thanks for clarification. Fix looks good. 09.10.2012 14:38, Alexander Zuev wrote: > Because on Mac we are currently supporting display mode change > operation in non-fullscreen mode. > > On 10/9/12 14:35, Sergey Bylokhov wrote: >> Also why we don't throw IllegalStateException("Must be in fullscreen >> mode in order to set display mode") when getFullScreenWindow==null? >> >> 09.10.2012 14:31, Sergey Bylokhov wrote: >>> 09.10.2012 14:25, Alexander Zuev wrote: >>>> Sergey, >>>> >>>> the text message is not specified in the documentation and the >>>> new one is already used on MacOS X >>>> in the jdk7 so i would let it be as it is for consistency. >>> I don't see a reason not to unify it across tolkits. Why we should >>> use different text on different platforms? >>>> The check in obtaining matching display mode is already performed >>>> in the native code: >>>> In CGraphicsDevice.m : >>>> >>>> CGDisplayModeRef closestMatch = >>>> getBestModeForParameters(allModes, (int)w, (int)h, (int)bpp, >>>> (int)refrate); >>>> if (closestMatch != NULL) { >>>> ... >>>> } else { >>>> [JNFException raise:env as:kIllegalArgumentException >>>> reason:"Invalid display mode"]; >>>> } >>>> >>>> With best regards, >>>> Alexander Zuev >>>> >>>> On 10/9/12 14:12, Sergey Bylokhov wrote: >>>>> Hi, Alexander >>>>> On win32 anx X11 we have another exception text message "Invalid >>>>> display mode", also there is additional check in >>>>> getMatchingDisplayMode() is it unnecessary on the macosx? >>>>> >>>>> 09.10.2012 12:35, Alexander Zuev wrote: >>>>>> Hello, >>>>>> >>>>>> please review my fix for CR 7175704: [macosx] "8" PIT: NPE in >>>>>> GetDisplayMode fullscreen test >>>>>> >>>>>> The NPE happens because we do not check the passed argument to >>>>>> null before using it. The correct exception according to the >>>>>> specification should be IllegalArgumentException. >>>>>> >>>>>> Bug description is: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175704 >>>>>> Webrev can be found here: >>>>>> http://cr.openjdk.java.net/~kizune/7175704/webrev.00 >>>>>> >>>>>> With best regards, >>>>>> Alex >>>>> >>>>> >>>> >>> >>> >> >> > -- Best regards, Sergey. From alexander.zuev at oracle.com Tue Oct 9 04:42:03 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 09 Oct 2012 15:42:03 +0400 Subject: getting quartz fonts & Java 6 sound effects In-Reply-To: <5073F6B0.1080509@fastmail.fm> References: <146700F8-0347-4CAD-BD8F-DBDF60244D4E@rochester.rr.com> <5073F1CF.7010602@oracle.com> <5073F6B0.1080509@fastmail.fm> Message-ID: <50740D8B.40804@oracle.com> Paul, On 10/9/12 14:04, Paul Taylor wrote: > On 09/10/2012 10:43, Alexander Zuev wrote: >> Jeff, >> >> unfortunately we don't support quartz for the on-screen rendering >> in Java 7 so UseQuartz=true does not >> do any difference. As for the sound - using the JavaSoundDemo from >> the Apple Developer Extras i >> definitely noticed a difference in the sound of the Synth Strings 2 >> instrument - Apple version has much >> more complexity. I will raise that concern with our media expert. >> >> With best regards, >> Alexander Zuev >> > Is the lack of Quatrz support a temporary decision or permanent, could > you give us the reasoning behind this ? I'm afraid it's permanent. The reason is the different architecture of the AWT components in Java 6 and Java 7. On Java 6 AWT components were backed by the native controls who had options to be rendered differently whereas on Java 7 they are backed by software rendered controls (basically Swing components with Aqua LaF) and turning the UseQuartz option on and off does not change rendering process. BTW, as far as i can see the main difference between quartz and cocoa renderings are that in quartz mode fonts are rendered with LCD subpixel rendering off. The similar results might be achieved by changing text rendering hints in Java 7 - see included with Java 7 demo Font2DTest for the different hints and the results they take on the the rendering of various fonts. With best regards, Alexander Zuev > > Paul >> On 10/9/12 24:44, Jeff Palmer wrote: >>> I might be getting a little picky, but has anyone reported that >>> fonts and sounds are inferior to Java 6? Using JWS, I specify >>> apple.awt.graphics.UseQuartz=true for 1.6. I am using the default font: >>> >>> com.apple.laf.AquaFonts$DerivedUIResourceFont[family=Lucida >>> Grande,name=Lucida Grande,style=plain,size=13] >>> >>> I guess I could pull out the UseQuartz and make them look the same, >>> but thought I should at least send this note. >>> >>> Sound wise, I put in some sound effects to correspond to some >>> events. The Java 6 versions are just so much better, especially for >>> the SYNTH_STRINGS_2 instrument, index 51. >>> >>> This is not going to stop implementation, but I was just wondering. >>> >>> Jeff Palmer >>> >> >> > From jcpalmer at rochester.rr.com Tue Oct 9 09:33:16 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Tue, 9 Oct 2012 12:33:16 -0400 Subject: getting quartz fonts & Java 6 sound effects In-Reply-To: <50740D8B.40804@oracle.com> References: <146700F8-0347-4CAD-BD8F-DBDF60244D4E@rochester.rr.com> <5073F1CF.7010602@oracle.com> <5073F6B0.1080509@fastmail.fm> <50740D8B.40804@oracle.com> Message-ID: <15723516-047B-4FF3-9624-9E09BAFF5EF4@rochester.rr.com> Alexander, Thanks. On the chance that something might be done to MIDI or instruments, would this also be noticed in other operating systems? I always thought the Windows instruments did not sound as good as Apples, but thought it could be attributed to different OS or specific hardware. With these 2 on the same machine & OS, it is a definite apples to apples comparison. As far as fonts go, most apps will be hard pressed to notice the difference. I am doing some very custom things which exaggerates the difference. The sub pixel rendering off comment gave me a few idea, thanks. Do not think text rendering hints are going to work with controls like JLabel, though. Wouldn't you have to : wrapper it override paintComponent() cast to Graphics2D, and change text rendering hints call super.paintComponent() But maybe it would not be too bad if you could just over-ride paint() of your JFrame, & do above. Are hints transferred in Graphics.create(x, y, w, h) that is called in paintChildren? JavaDoc is silent on that. Looking at source code, eventually an abstract create() is called. Does not look good. Thanks, Jeff Palmer On Oct 9, 2012, at 7:42 AM, Alexander Zuev wrote: > Paul, > > On 10/9/12 14:04, Paul Taylor wrote: >> On 09/10/2012 10:43, Alexander Zuev wrote: >>> Jeff, >>> >>> unfortunately we don't support quartz for the on-screen rendering in Java 7 so UseQuartz=true does not >>> do any difference. As for the sound - using the JavaSoundDemo from the Apple Developer Extras i >>> definitely noticed a difference in the sound of the Synth Strings 2 instrument - Apple version has much >>> more complexity. I will raise that concern with our media expert. >>> >>> With best regards, >>> Alexander Zuev >>> >> Is the lack of Quatrz support a temporary decision or permanent, could you give us the reasoning behind this ? > I'm afraid it's permanent. The reason is the different architecture of the AWT components in Java 6 and Java 7. On Java 6 > AWT components were backed by the native controls who had options to be rendered differently whereas on Java 7 > they are backed by software rendered controls (basically Swing components with Aqua LaF) and turning the UseQuartz > option on and off does not change rendering process. > > BTW, as far as i can see the main difference between quartz and cocoa renderings are that in quartz mode fonts are rendered with LCD subpixel rendering off. The similar results might be achieved by changing text rendering hints in Java 7 - see included with Java 7 demo Font2DTest for the different hints and the results they take on the the rendering of various fonts. > > With best regards, > Alexander Zuev >> >> Paul >>> On 10/9/12 24:44, Jeff Palmer wrote: >>>> I might be getting a little picky, but has anyone reported that fonts and sounds are inferior to Java 6? Using JWS, I specify apple.awt.graphics.UseQuartz=true for 1.6. I am using the default font: >>>> >>>> com.apple.laf.AquaFonts$DerivedUIResourceFont[family=Lucida Grande,name=Lucida Grande,style=plain,size=13] >>>> >>>> I guess I could pull out the UseQuartz and make them look the same, but thought I should at least send this note. >>>> >>>> Sound wise, I put in some sound effects to correspond to some events. The Java 6 versions are just so much better, especially for the SYNTH_STRINGS_2 instrument, index 51. >>>> >>>> This is not going to stop implementation, but I was just wondering. >>>> >>>> Jeff Palmer >>>> >>> >>> >> > From leonid.romanov at oracle.com Tue Oct 9 09:36:34 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 9 Oct 2012 20:36:34 +0400 Subject: [8] Review request for 7124321: [macosx] TrayIcon MouseListener is never triggered Message-ID: <8292CA53-C9F1-4E80-B85F-4A5736BA563A@oracle.com> Hi, This is a forward port for an old JDK 7 fix which for some reasons hasn't made into JDK 8. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124321 Webrev: http://cr.openjdk.java.net/~leonidr/7124321/webrev.02/ Thanks, Leonid. From anthony.petrov at oracle.com Tue Oct 9 09:40:55 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 09 Oct 2012 20:40:55 +0400 Subject: [8] Review request for 7124321: [macosx] TrayIcon MouseListener is never triggered In-Reply-To: <8292CA53-C9F1-4E80-B85F-4A5736BA563A@oracle.com> References: <8292CA53-C9F1-4E80-B85F-4A5736BA563A@oracle.com> Message-ID: <50745397.8050009@oracle.com> Looks fine. -- best regards, Anthony On 10/9/2012 8:36 PM, Leonid Romanov wrote: > Hi, > This is a forward port for an old JDK 7 fix which for some reasons > hasn't made into JDK 8. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124321 > Webrev: http://cr.openjdk.java.net/~leonidr/7124321/webrev.02/ > > Thanks, > Leonid. From thorkelsson at sidelinesports.com Tue Oct 9 08:47:52 2012 From: thorkelsson at sidelinesports.com (Thorkelsson) Date: Tue, 9 Oct 2012 17:47:52 +0200 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac References: Message-ID: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> Hi, My name is Agust Thorkelsson and I'm the owner of a company called Sideline Sports. We produce software for professional sport coaches. We have encountered a huge problem that we can't seem to find a workaround for. We have customers in many countries in Europe and almost all of them have non-english characters in filenames of files they use in our systems. The Java 7 upgrade for Mac basically renders our software unusable. This is only on Mac. Scott Kovatch instructed me to file a bug for this and e-mail this address for a discussion. I'm hoping you have some kind of workaround you can let us know about. It would be much appreciated! The filed bug can be seen beneath. I'm sure this bug breaks a lot of Java software here in Europe and not in a clean way either. File.exists() is a popular method to use. Again, thanks for any help you can give. Best regards, Agust Agust Thorkelsson Sideline Sports thorkelsson at sidelinesports.com www.sidelinesports.com Mobile: +46 (0) 704 244 359 Office: +46 (0) 40 692 7942 Begin forwarded message: > From: ?orvaldur Bl?ndal > Subject: Fw: Your Report (Review ID: 2356502) - File.exists() does not work on mac for non-English characters > Date: 9 oktober 2012 14:22:08 CEST > To: "Thorkelsson" > > > ----- Original Message ----- From: > To: > Sent: Tuesday, October 09, 2012 12:21 PM > Subject: Your Report (Review ID: 2356502) - File.exists() does not work on mac for non-English characters > > > Date Created: Tue Oct 09 06:21:15 MDT 2012 > Type: bug > Customer Name: ?orvaldur Bl?ndal > Customer Email: thorvaldur at sidelinesports.com > SDN ID: > status: Waiting > Category: java > Subcategory: classes_io > Company: Sideline Sports > release: 7 > hardware: x86 > OSversion: macosx > priority: 3 > Synopsis: File.exists() does not work on mac for non-English characters > Description: > FULL PRODUCT VERSION : > java.specification.vendor=Oracle Corporation > java.runtime.version=1.7.0_10-ea-b10 > java.version=1.7.0_10-ea > file.encoding.pkg=sun.io > > > ADDITIONAL OS VERSION INFORMATION : > os.name=Mac OS X > os.version=10.8.1 > > > EXTRA RELEVANT SYSTEM CONFIGURATION : > My Computer is in Icelandic. This also happens to a friend of mine in Sweden. > > A DESCRIPTION OF THE PROBLEM : > Hi. > > Files (with non-English characters) that are returned by a File dialog return false from exists() if I double-click my jar. But if I run the jar from a terminal, exists() returns true. > > I'm using > os.name=Mac OS X > os.version=10.8.1 > > I made a small test program. It opens a file dialog where I can select Files. It's much more successful if I run it from a terminal. I also tried to webstart it and run it from Netbeans. No success. > > I think this is related to these things: > http://stackoverflow.com/questions/12509532/encoding-issues-on-java-7-file-names-in-os-x > http://javafx-jira.kenai.com/browse/RT-23836 > > The System.properties are quite different. > > When I run from terminal by typing "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java" -jar TestProject.jar: > java.specification.vendor=Oracle Corporation > java.runtime.version=1.7.0_10-ea-b10 > java.version=1.7.0_10-ea > file.encoding.pkg=sun.io > user.country=IS > sun.jnu.encoding=UTF-8 > file.encoding=UTF-8 > user.language=is > > When I double-click the jar in Finder: > java.specification.vendor=Oracle Corporation > java.runtime.version=1.7.0_10-ea-b10 > java.version=1.7.0_10-ea > file.encoding.pkg=sun.io > user.country=IS > sun.jnu.encoding=US-ASCII > file.encoding=US-ASCII > user.language=is > > > REGRESSION. Last worked in version 7 > > STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : > Just deploy and run the attached code on a computer that contains files with atypical names. Like ???.mp3. > > File.exists() does not work if you double-click a jar or webstart it. > > EXPECTED VERSUS ACTUAL BEHAVIOR : > EXPECTED - > I expected Files that are returned by a File Dialog to exist(). > ACTUAL - > They did not. > > REPRODUCIBILITY : > This bug can be reproduced always. > > ---------- BEGIN SOURCE ---------- > package testproject; > > import java.awt.FileDialog; > import java.io.File; > import java.util.Iterator; > import java.util.Map.Entry; > import javax.swing.JFrame; > import javax.swing.JOptionPane; > import javax.swing.JScrollPane; > import javax.swing.JTextArea; > import javax.swing.SwingUtilities; > > public class TestProject > { > public static void main(String[] args) throws Exception > { > SwingUtilities.invokeLater(new Runnable() > { > @Override > public void run() > { > new TestProject(); > } > }); > } > > public TestProject() > { > StringBuilder props = new StringBuilder(); > Iterator> iter = System.getProperties().entrySet().iterator(); > while (iter.hasNext()) > { > Entry next = iter.next(); > props.append(next.getKey().toString()).append("=").append(next.getValue().toString()).append(System.getProperty("line.separator")); > } > > JFrame frameProps = new JFrame("System Properties"); > frameProps.getContentPane().add(new JScrollPane(new JTextArea(props.toString()))); > frameProps.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > frameProps.pack(); > frameProps.setVisible(true); > > FileDialog fd = new FileDialog(frameProps); > fd.setMode(FileDialog.LOAD); > > while (true) > { > fd.setVisible(true); > String selDir = fd.getDirectory(); > String selFilename = fd.getFile(); > if (selDir == null || selFilename == null) > break; > > File selected = new File(selDir, selFilename); > if (selected == null) > JOptionPane.showMessageDialog(frameProps, "file was null"); > else if (selected.exists()) > JOptionPane.showMessageDialog(frameProps, selected.getAbsolutePath() + " exists"); > else > JOptionPane.showMessageDialog(frameProps, selected.getAbsolutePath() + " does not exist exists"); > } > } > } > > ---------- END SOURCE ---------- > workaround: > comments: (company - Sideline Sports , email - thorvaldur at sidelinesports.com) > From Alan.Bateman at oracle.com Tue Oct 9 10:35:05 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 09 Oct 2012 18:35:05 +0100 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> Message-ID: <50746049.1080203@oracle.com> On 09/10/2012 16:47, Thorkelsson wrote: > Hi, > > My name is Agust Thorkelsson and I'm the owner of a company called Sideline Sports. We produce software for professional sport coaches. We have encountered a huge problem that we can't seem to find a workaround for. > > We have customers in many countries in Europe and almost all of them have non-english characters in filenames of files they use in our systems. > > The Java 7 upgrade for Mac basically renders our software unusable. This is only on Mac. > > Scott Kovatch instructed me to file a bug for this and e-mail this address for a discussion. I'm hoping you have some kind of workaround you can let us know about. It would be much appreciated! The filed bug can be seen beneath. > > I'm sure this bug breaks a lot of Java software here in Europe and not in a clean way either. File.exists() is a popular method to use. > Can you try jdk8 and tell us if this resolves the issue you are seeing? jdk8 has the changes for 7130915. -Alan. From Alan.Bateman at oracle.com Wed Oct 10 01:53:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Oct 2012 09:53:54 +0100 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: <1D9514D101F84ED3A7B00952B931D1CB@hagi> References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> Message-ID: <507537A2.9070103@oracle.com> On 09/10/2012 21:21, ?orvaldur Bl?ndal wrote: > Hi Alan and thanks for the suggestion. > > I downloaded version 1.8.0-ea-b59 and unfortunately it's the same. > And this is not just about the exists()-method. I can't create a > FileInputStream or anything like that. > I can also tell you that files with atypical names are not seen at all > in JFileChooser. I have to use java.awt.FileDialog. See attached picture. > > Note: I made a mistake when I said in the report that it previously > worked in version 7. I meant to say version 6. > I'll bet this is related to your locale, you can print out the value of the file.encoding property? -Alan. From dkocher at sudo.ch Wed Oct 10 02:35:48 2012 From: dkocher at sudo.ch (David Kocher) Date: Wed, 10 Oct 2012 11:35:48 +0200 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: <507537A2.9070103@oracle.com> References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> Message-ID: <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> This issue is being discussed in http://java.net/jira/browse/MACOSX_PORT-165. I will attach a test case again for the non believers. -- David On 10.10.2012, at 10:53, Alan Bateman wrote: > On 09/10/2012 21:21, ?orvaldur Bl?ndal wrote: >> Hi Alan and thanks for the suggestion. >> >> I downloaded version 1.8.0-ea-b59 and unfortunately it's the same. >> And this is not just about the exists()-method. I can't create a FileInputStream or anything like that. >> I can also tell you that files with atypical names are not seen at all in JFileChooser. I have to use java.awt.FileDialog. See attached picture. >> >> Note: I made a mistake when I said in the report that it previously worked in version 7. I meant to say version 6. >> > I'll bet this is related to your locale, you can print out the value of the file.encoding property? > > -Alan. > From dkocher at sudo.ch Wed Oct 10 02:51:58 2012 From: dkocher at sudo.ch (David Kocher) Date: Wed, 10 Oct 2012 11:51:58 +0200 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <502802EF.1070908@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> <502802EF.1070908@oracle.com> Message-ID: It does not. On 12.08.2012, at 21:24, Alan Bateman wrote: > On 12/08/2012 18:55, David Kocher wrote: >> Ping. >> >> On 27.06.2012, at 09:28, David Kocher wrote: >> >>> I welcome this issue is getting some serious attention then. When will this be backported to 7u? >>> >>> -- David >>> > Have you done any testing with the latest jdk8 build to verify that it addresses the problem that you are seeing? > > -Alan. > From alexander.zuev at oracle.com Wed Oct 10 02:56:12 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 10 Oct 2012 13:56:12 +0400 Subject: [8] Review request for 7124321: [macosx] TrayIcon MouseListener is never triggered In-Reply-To: <8292CA53-C9F1-4E80-B85F-4A5736BA563A@oracle.com> References: <8292CA53-C9F1-4E80-B85F-4A5736BA563A@oracle.com> Message-ID: <5075463C.6020201@oracle.com> Looks good to me. On 10/9/12 20:36, Leonid Romanov wrote: > Hi, > This is a forward port for an old JDK 7 fix which for some reasons hasn't made into JDK 8. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124321 > Webrev: http://cr.openjdk.java.net/~leonidr/7124321/webrev.02/ > > Thanks, > Leonid. From leonid.romanov at oracle.com Wed Oct 10 03:04:41 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 10 Oct 2012 14:04:41 +0400 Subject: [8] Please review fix for 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test In-Reply-To: <5073FE9A.3040206@oracle.com> References: <5073E1EE.80403@oracle.com> <5073F898.70304@oracle.com> <5073FB89.8050903@oracle.com> <5073FD1A.1040706@oracle.com> <5073FDEF.8040102@oracle.com> <5073FE9A.3040206@oracle.com> Message-ID: Looks good. On 09.10.2012, at 14:38, Alexander Zuev wrote: > Because on Mac we are currently supporting display mode change operation in non-fullscreen mode. > > On 10/9/12 14:35, Sergey Bylokhov wrote: >> Also why we don't throw IllegalStateException("Must be in fullscreen mode in order to set display mode") when getFullScreenWindow==null? >> >> 09.10.2012 14:31, Sergey Bylokhov wrote: >>> 09.10.2012 14:25, Alexander Zuev wrote: >>>> Sergey, >>>> >>>> the text message is not specified in the documentation and the new one is already used on MacOS X >>>> in the jdk7 so i would let it be as it is for consistency. >>> I don't see a reason not to unify it across tolkits. Why we should use different text on different platforms? >>>> The check in obtaining matching display mode is already performed in the native code: >>>> In CGraphicsDevice.m : >>>> >>>> CGDisplayModeRef closestMatch = getBestModeForParameters(allModes, (int)w, (int)h, (int)bpp, (int)refrate); >>>> if (closestMatch != NULL) { >>>> ... >>>> } else { >>>> [JNFException raise:env as:kIllegalArgumentException reason:"Invalid display mode"]; >>>> } >>>> >>>> With best regards, >>>> Alexander Zuev >>>> >>>> On 10/9/12 14:12, Sergey Bylokhov wrote: >>>>> Hi, Alexander >>>>> On win32 anx X11 we have another exception text message "Invalid display mode", also there is additional check in getMatchingDisplayMode() is it unnecessary on the macosx? >>>>> >>>>> 09.10.2012 12:35, Alexander Zuev wrote: >>>>>> Hello, >>>>>> >>>>>> please review my fix for CR 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test >>>>>> >>>>>> The NPE happens because we do not check the passed argument to null before using it. The correct exception according to the specification should be IllegalArgumentException. >>>>>> >>>>>> Bug description is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175704 >>>>>> Webrev can be found here: http://cr.openjdk.java.net/~kizune/7175704/webrev.00 >>>>>> >>>>>> With best regards, >>>>>> Alex >>>>> >>>>> >>>> >>> >>> >> >> > From Alan.Bateman at oracle.com Wed Oct 10 03:23:08 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Oct 2012 11:23:08 +0100 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> <502802EF.1070908@oracle.com> Message-ID: <50754C8C.7090708@oracle.com> On 10/10/2012 10:51, David Kocher wrote: > It does not. Thanks for checking, I think the issues that you and others are running into is something else, probably locale->encoding related. -Alan From dkocher at sudo.ch Wed Oct 10 04:41:15 2012 From: dkocher at sudo.ch (David Kocher) Date: Wed, 10 Oct 2012 13:41:15 +0200 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> Message-ID: <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> Agust, My workaround is to use NSFFileManager instead (with bridging through JNA or JNI). -- David On 10.10.2012, at 13:16, Thorkelsson wrote: > Thanks for this link David. > > I can see that this bug was marked critical for a year ago, but then I don't know what happens. Obviously it's a tough one. > > But just some feedback for all from a company perspective. At the risk of stating the obvious: This bug is really killing us. We can't release a huge upgrade depending on Java 7 (because of use of the JavaFX 2.2) because of this. We've been trying to workaround this bug for more than a week now without success. We just can't believe that this is something that is out in an official Java release. That's why we've been trying everything to find out what could be wrong on our side. But it doesn't seem to be that way (still don't believe it?) > > I can understand that this has slipped by before because Java 7 hasn't been out long for the Mac. But if it is the way that this is in the release, it will start affecting people quickly. > > This doesn't add to the solution, so I will not write more about it. But please, to those who have the influence, do everything you can to get this into the next update. We are here to help with anything regarding testing or reproducing the bug. > > And of course, if anyone has a workaround, it would be greatly appreciated to learn about it! > > Thanks, > > Agust > > > Agust Thorkelsson > Sideline Sports > thorkelsson at sidelinesports.com > www.sidelinesports.com > Mobile: +46 (0) 704 244 359 > EU Office: +46 (0) 40 692 7942 > > > On 10 okt 2012, at 11:35, David Kocher wrote: > >> This issue is being discussed in http://java.net/jira/browse/MACOSX_PORT-165. I will attach a test case again for the non believers. >> >> -- David >> >> On 10.10.2012, at 10:53, Alan Bateman wrote: >> >>> On 09/10/2012 21:21, ?orvaldur Bl?ndal wrote: >>>> Hi Alan and thanks for the suggestion. >>>> >>>> I downloaded version 1.8.0-ea-b59 and unfortunately it's the same. >>>> And this is not just about the exists()-method. I can't create a FileInputStream or anything like that. >>>> I can also tell you that files with atypical names are not seen at all in JFileChooser. I have to use java.awt.FileDialog. See attached picture. >>>> >>>> Note: I made a mistake when I said in the report that it previously worked in version 7. I meant to say version 6. >>>> >>> I'll bet this is related to your locale, you can print out the value of the file.encoding property? >>> >>> -Alan. >>> >> > From dkocher at sudo.ch Wed Oct 10 04:42:29 2012 From: dkocher at sudo.ch (David Kocher) Date: Wed, 10 Oct 2012 13:42:29 +0200 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <50754C8C.7090708@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> <502802EF.1070908@oracle.com> <50754C8C.7090708@oracle.com> Message-ID: Please see the test cases attached to http://java.net/jira/browse/MACOSX_PORT-165. -- David On 10.10.2012, at 12:23, Alan Bateman wrote: > On 10/10/2012 10:51, David Kocher wrote: >> It does not. > Thanks for checking, I think the issues that you and others are running into is something else, probably locale->encoding related. > > -Alan > From Alan.Bateman at oracle.com Wed Oct 10 04:45:20 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Oct 2012 12:45:20 +0100 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> Message-ID: <50755FD0.1040608@oracle.com> On 10/10/2012 12:16, Thorkelsson wrote: > Thanks for this link David. > > I can see that this bug was marked critical for a year ago, but then I > don't know what happens. Obviously it's a tough one. > > But just some feedback for all from a company perspective. At the risk > of stating the obvious: This bug is really killing us. We can't > release a huge upgrade depending on Java 7 (because of use of the > JavaFX 2.2) because of this. We've been trying to workaround this bug > for more than a week now without success. We just can't believe that > this is something that is out in an official Java release. That's why > we've been trying everything to find out what could be wrong on our > side. But it doesn't seem to be that way (still don't believe it?) > > I can understand that this has slipped by before because Java 7 hasn't > been out long for the Mac. But if it is the way that this is in the > release, it will start affecting people quickly. > I don't know anything about the JIRA instance on java.net but it would be great if someone could submit a bug to bugs.sun.com with a link to it. Also the last comment at the end seems to be with a build of jigsaw/jigsaw which is jdk8-b48 so it doesn't have the changes for 7130915 that went into b51. I saw someone else jumped in saying they see the issue with b59 but it may be something else. -Alan From alexander.zuev at oracle.com Wed Oct 10 07:45:25 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 10 Oct 2012 18:45:25 +0400 Subject: [7u12] Review request for 7196547: [macosx] Implement dead key detection for KeyEvent In-Reply-To: <5065A70C.9070909@oracle.com> References: <5065A70C.9070909@oracle.com> Message-ID: <50758A05.1040606@oracle.com> Looks Ok to me. On 9/28/12 17:33, Alexander Scherbatiy wrote: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196547 > webrev: http://cr.openjdk.java.net/~alexsch/7196547/webrev7.00 > > This is a backport of the issue from the JDK 8 to JDK 7u12 > > The only changes are that calls to NsCharToJavaVirtualKeyCode methods > are updated because some key events are processed on the native level > in JDK 7. > The updated NsCharToJavaVirtualKeyCode calls use the isDeadChar=NO > parameter because finally the dead keys are retrieved from the > nsToJavaKeyInfo in the handleKeyEvent method from the > CPlatformResponder class. > > JDK 8 fix description: > > The characters method from the NSEvent class returns an empty string > for dead keys. > The fix uses the UCKeyTranslate() method to know a dead key state > from the key code and key modifiers on the first step, > and dead key state and space key to know the dead key char actual > value on the second step. > > > Thanks, > Alexandr. > From xueming.shen at oracle.com Wed Oct 10 08:56:07 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 10 Oct 2012 08:56:07 -0700 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> <502802EF.1070908@oracle.com> Message-ID: <50759A97.7040101@oracle.com> Hi David, Is it possible to provide a little more info regarding your runtime env? I understand the frustration, me too:-) as I thought we had fixed this particular issue in JDK8, just waiting for the timing to back port. But it appears this might not be the case. To help us to get to the bottom of the issue, can you tell us (1) which macos you are running, snow leopard, lion? (2) the output of locale (3) the output of your testing case, no -D setting at command line. Thanks, -Sherman On 10/10/2012 2:51 AM, David Kocher wrote: > It does not. > > On 12.08.2012, at 21:24, Alan Bateman wrote: > >> On 12/08/2012 18:55, David Kocher wrote: >>> Ping. >>> >>> On 27.06.2012, at 09:28, David Kocher wrote: >>> >>>> I welcome this issue is getting some serious attention then. When will this be backported to 7u? >>>> >>>> -- David >>>> >> Have you done any testing with the latest jdk8 build to verify that it addresses the problem that you are seeing? >> >> -Alan. >> From scott.kovatch at oracle.com Wed Oct 10 08:58:29 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 10 Oct 2012 08:58:29 -0700 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> Message-ID: We fixed/worked around this in the plugin by setting the environment variable LC_CTYPE to UTF-8. Given that file names are in UTF-8 by default on OS X this seems unnecessary to me, but there you go. -- Scott K. On Oct 10, 2012, at 4:41 AM, David Kocher wrote: > Agust, > > My workaround is to use NSFFileManager instead (with bridging through JNA or JNI). > > -- David > > On 10.10.2012, at 13:16, Thorkelsson wrote: > >> Thanks for this link David. >> >> I can see that this bug was marked critical for a year ago, but then I don't know what happens. Obviously it's a tough one. >> >> But just some feedback for all from a company perspective. At the risk of stating the obvious: This bug is really killing us. We can't release a huge upgrade depending on Java 7 (because of use of the JavaFX 2.2) because of this. We've been trying to workaround this bug for more than a week now without success. We just can't believe that this is something that is out in an official Java release. That's why we've been trying everything to find out what could be wrong on our side. But it doesn't seem to be that way (still don't believe it?) >> >> I can understand that this has slipped by before because Java 7 hasn't been out long for the Mac. But if it is the way that this is in the release, it will start affecting people quickly. >> >> This doesn't add to the solution, so I will not write more about it. But please, to those who have the influence, do everything you can to get this into the next update. We are here to help with anything regarding testing or reproducing the bug. >> >> And of course, if anyone has a workaround, it would be greatly appreciated to learn about it! >> >> Thanks, >> >> Agust >> >> >> Agust Thorkelsson >> Sideline Sports >> thorkelsson at sidelinesports.com >> www.sidelinesports.com >> Mobile: +46 (0) 704 244 359 >> EU Office: +46 (0) 40 692 7942 >> >> >> On 10 okt 2012, at 11:35, David Kocher wrote: >> >>> This issue is being discussed in http://java.net/jira/browse/MACOSX_PORT-165. I will attach a test case again for the non believers. >>> >>> -- David >>> >>> On 10.10.2012, at 10:53, Alan Bateman wrote: >>> >>>> On 09/10/2012 21:21, ?orvaldur Bl?ndal wrote: >>>>> Hi Alan and thanks for the suggestion. >>>>> >>>>> I downloaded version 1.8.0-ea-b59 and unfortunately it's the same. >>>>> And this is not just about the exists()-method. I can't create a FileInputStream or anything like that. >>>>> I can also tell you that files with atypical names are not seen at all in JFileChooser. I have to use java.awt.FileDialog. See attached picture. >>>>> >>>>> Note: I made a mistake when I said in the report that it previously worked in version 7. I meant to say version 6. >>>>> >>>> I'll bet this is related to your locale, you can print out the value of the file.encoding property? >>>> >>>> -Alan. >>>> >>> >> > From dkocher at sudo.ch Wed Oct 10 09:01:41 2012 From: dkocher at sudo.ch (David Kocher) Date: Wed, 10 Oct 2012 18:01:41 +0200 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <50759A97.7040101@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> <502802EF.1070908@oracle.com> <50759A97.7040101@oracle.com> Message-ID: <29FACB40-3BFD-41C8-8B5C-5FA5A68671FC@sudo.ch> The testcase attached to the ticket is successful on 1.8.0-b56. See MACOSX_PORT-165 for a reproducable test case. -- David On 10.10.2012, at 17:56, Xueming Shen wrote: > Hi David, > > Is it possible to provide a little more info regarding your runtime env? I understand the > frustration, me too:-) as I thought we had fixed this particular issue in JDK8, just waiting > for the timing to back port. But it appears this might not be the case. To help us to get > to the bottom of the issue, can you tell us > > (1) which macos you are running, snow leopard, lion? > (2) the output of locale > (3) the output of your testing case, no -D setting at command line. > > Thanks, > -Sherman > > > On 10/10/2012 2:51 AM, David Kocher wrote: >> It does not. >> >> On 12.08.2012, at 21:24, Alan Bateman wrote: >> >>> On 12/08/2012 18:55, David Kocher wrote: >>>> Ping. >>>> >>>> On 27.06.2012, at 09:28, David Kocher wrote: >>>> >>>>> I welcome this issue is getting some serious attention then. When will this be backported to 7u? >>>>> >>>>> -- David >>>>> >>> Have you done any testing with the latest jdk8 build to verify that it addresses the problem that you are seeing? >>> >>> -Alan. >>> > From Alan.Bateman at oracle.com Wed Oct 10 09:09:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Oct 2012 17:09:59 +0100 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <29FACB40-3BFD-41C8-8B5C-5FA5A68671FC@sudo.ch> References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> <502802EF.1070908@oracle.com> <50759A97.7040101@oracle.com> <29FACB40-3BFD-41C8-8B5C-5FA5A68671FC@sudo.ch> Message-ID: <50759DD7.4000006@oracle.com> On 10/10/2012 17:01, David Kocher wrote: > The testcase attached to the ticket is successful on 1.8.0-b56. See MACOSX_PORT-165 for a reproducable test case. > > -- David > Just so we're clear, are you saying that the problem exists or does not exist with jdk8-b56? The changes went into b51. One of the comments on the JIRA seems to be a jigsaw build and from the date is probably b48 so it doesn't have the changes. -Alan From alexander.zuev at oracle.com Wed Oct 10 09:21:03 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 10 Oct 2012 20:21:03 +0400 Subject: getting quartz fonts & Java 6 sound effects In-Reply-To: <15723516-047B-4FF3-9624-9E09BAFF5EF4@rochester.rr.com> References: <146700F8-0347-4CAD-BD8F-DBDF60244D4E@rochester.rr.com> <5073F1CF.7010602@oracle.com> <5073F6B0.1080509@fastmail.fm> <50740D8B.40804@oracle.com> <15723516-047B-4FF3-9624-9E09BAFF5EF4@rochester.rr.com> Message-ID: <5075A06F.7050306@oracle.com> Jeff, On 10/9/12 20:33, Jeff Palmer wrote: > Alexander, > Thanks. On the chance that something might be done to MIDI or > instruments, would this also be noticed in other operating systems? > I always thought the Windows instruments did not sound as good as > Apples, but thought it could be attributed to different OS or specific > hardware. With these 2 on the same machine & OS, it is a definite > apples to apples comparison. I did consulted with our media specialist, here's his resume: the problem is that in java 7 we have changed the MIDI synthesizer. The old one worked with the proprietary instrument bank format. The new synthesizer works with any DLS or SF2 sound bank formats but the bank that comes with it by default is a generated one and is simpler than the one came with java 6. However you may use any existing sound bank - just put it into the {jre.home}/lib/audio folder and java will recognize it on the next start and will use it instead of the generated one. As i said any SF2 or DLS bank will work on any operating system. > As far as fonts go, most apps will be hard pressed to notice the > difference. I am doing some very custom things which exaggerates the > difference. The sub pixel rendering off comment gave me a few idea, > thanks. Do not think text rendering hints are going to work with > controls like JLabel, though. Wouldn't you have to : > > * wrapper it > * override paintComponent() > * cast to Graphics2D, and change text rendering hints > * call super.paintComponent() > I'm afraid that's the only approach as of now - currently there is no way in jdk7 to change font rendering hints for the components hierarchy. With best regards, Alexander Zuev > > On Oct 9, 2012, at 7:42 AM, Alexander Zuev wrote: > >> Paul, >> >> On 10/9/12 14:04, Paul Taylor wrote: >>> On 09/10/2012 10:43, Alexander Zuev wrote: >>>> Jeff, >>>> >>>> unfortunately we don't support quartz for the on-screen rendering >>>> in Java 7 so UseQuartz=true does not >>>> do any difference. As for the sound - using the JavaSoundDemo from >>>> the Apple Developer Extras i >>>> definitely noticed a difference in the sound of the Synth Strings 2 >>>> instrument - Apple version has much >>>> more complexity. I will raise that concern with our media expert. >>>> >>>> With best regards, >>>> Alexander Zuev >>>> >>> Is the lack of Quatrz support a temporary decision or permanent, >>> could you give us the reasoning behind this ? >> I'm afraid it's permanent. The reason is the different architecture >> of the AWT components in Java 6 and Java 7. On Java 6 >> AWT components were backed by the native controls who had options to >> be rendered differently whereas on Java 7 >> they are backed by software rendered controls (basically Swing >> components with Aqua LaF) and turning the UseQuartz >> option on and off does not change rendering process. >> >> BTW, as far as i can see the main difference between quartz and cocoa >> renderings are that in quartz mode fonts are rendered with LCD >> subpixel rendering off. The similar results might be achieved by >> changing text rendering hints in Java 7 - see included with Java 7 >> demo Font2DTest for the different hints and the results they take on >> the the rendering of various fonts. >> >> With best regards, >> Alexander Zuev >>> >>> Paul >>>> On 10/9/12 24:44, Jeff Palmer wrote: >>>>> I might be getting a little picky, but has anyone reported that >>>>> fonts and sounds are inferior to Java 6? Using JWS, I specify >>>>> apple.awt.graphics.UseQuartz=true for 1.6. I am using the default >>>>> font: >>>>> >>>>> com.apple.laf.AquaFonts$DerivedUIResourceFont[family=Lucida >>>>> Grande,name=Lucida Grande,style=plain,size=13] >>>>> >>>>> I guess I could pull out the UseQuartz and make them look the >>>>> same, but thought I should at least send this note. >>>>> >>>>> Sound wise, I put in some sound effects to correspond to some >>>>> events. The Java 6 versions are just so much better, especially >>>>> for the SYNTH_STRINGS_2 instrument, index 51. >>>>> >>>>> This is not going to stop implementation, but I was just wondering. >>>>> >>>>> Jeff Palmer >>>>> >>>> >>>> >>> >> > From dkocher at sudo.ch Wed Oct 10 09:30:09 2012 From: dkocher at sudo.ch (David Kocher) Date: Wed, 10 Oct 2012 18:30:09 +0200 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <50759DD7.4000006@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> <502802EF.1070908@oracle.com> <50759A97.7040101@oracle.com> <29FACB40-3BFD-41C8-8B5C-5FA5A68671FC@sudo.ch> <50759DD7.4000006@oracle.com> Message-ID: On 10.10.2012, at 18:09, Alan Bateman wrote: > On 10/10/2012 17:01, David Kocher wrote: >> The testcase attached to the ticket is successful on 1.8.0-b56. See MACOSX_PORT-165 for a reproducable test case. >> >> -- David >> > Just so we're clear, are you saying that the problem exists or does not exist with jdk8-b56? The changes went into b51. One of the comments on the JIRA seems to be a jigsaw build and from the date is probably b48 so it doesn't have the changes. > > -Alan > The testcase is successful on 1.8.0-b56 but fails with 1.8.0-b48 (jigsaw) and 1.7.0_07. From Alan.Bateman at oracle.com Wed Oct 10 09:32:15 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Oct 2012 17:32:15 +0100 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> <502802EF.1070908@oracle.com> <50759A97.7040101@oracle.com> <29FACB40-3BFD-41C8-8B5C-5FA5A68671FC@sudo.ch> <50759DD7.4000006@oracle.com> Message-ID: <5075A30F.4050309@oracle.com> On 10/10/2012 17:30, David Kocher wrote: > On 10.10.2012, at 18:09, Alan Bateman wrote: > >> On 10/10/2012 17:01, David Kocher wrote: >>> The testcase attached to the ticket is successful on 1.8.0-b56. See MACOSX_PORT-165 for a reproducable test case. >>> >>> -- David >>> >> Just so we're clear, are you saying that the problem exists or does not exist with jdk8-b56? The changes went into b51. One of the comments on the JIRA seems to be a jigsaw build and from the date is probably b48 so it doesn't have the changes. >> >> -Alan >> > > The testcase is successful on 1.8.0-b56 but fails with 1.8.0-b48 (jigsaw) and 1.7.0_07. Thanks, now things are starting to make sense as 7130915 went into jdk8-b51. -Alan From philip.race at oracle.com Wed Oct 10 09:43:42 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Oct 2012 09:43:42 -0700 Subject: getting quartz fonts & Java 6 sound effects In-Reply-To: <15723516-047B-4FF3-9624-9E09BAFF5EF4@rochester.rr.com> References: <146700F8-0347-4CAD-BD8F-DBDF60244D4E@rochester.rr.com> <5073F1CF.7010602@oracle.com> <5073F6B0.1080509@fastmail.fm> <50740D8B.40804@oracle.com> <15723516-047B-4FF3-9624-9E09BAFF5EF4@rochester.rr.com> Message-ID: <5075A5BE.6090909@oracle.com> I don't think the text rendering hints are going to work to get LCD sub-pixel text. I recall Mike Swingler said he had written code to get LCD glyphs but it didn't work for some reason he didn't have time to get to the bottom of. I looked briefly at the code which is using OS X APIs so if Mike didn't have any luck I figured it wasn't going to be any easier for me :-) Other than that I am not sure how 'different' the glyphs from the Quartz pipeline and the new pipeline would be since they are generated by a call to CGContextShowGlyphsAtPoint(). -phil. On 10/9/2012 9:33 AM, Jeff Palmer wrote: > Alexander, > Thanks. On the chance that something might be done to MIDI or instruments, would this also be noticed in other operating systems? I always thought the Windows instruments did not sound as good as Apples, but thought it could be attributed to different OS or specific hardware. With these 2 on the same machine& OS, it is a definite apples to apples comparison. > > As far as fonts go, most apps will be hard pressed to notice the difference. I am doing some very custom things which exaggerates the difference. The sub pixel rendering off comment gave me a few idea, thanks. Do not think text rendering hints are going to work with controls like JLabel, though. Wouldn't you have to : > wrapper it > override paintComponent() > cast to Graphics2D, and change text rendering hints > call super.paintComponent() > > But maybe it would not be too bad if you could just over-ride paint() of your JFrame,& do above. Are hints transferred in Graphics.create(x, y, w, h) that is called in paintChildren? JavaDoc is silent on that. Looking at source code, eventually an abstract create() is called. Does not look good. > > Thanks, > Jeff Palmer > > > On Oct 9, 2012, at 7:42 AM, Alexander Zuev wrote: > >> Paul, >> >> On 10/9/12 14:04, Paul Taylor wrote: >>> On 09/10/2012 10:43, Alexander Zuev wrote: >>>> Jeff, >>>> >>>> unfortunately we don't support quartz for the on-screen rendering in Java 7 so UseQuartz=true does not >>>> do any difference. As for the sound - using the JavaSoundDemo from the Apple Developer Extras i >>>> definitely noticed a difference in the sound of the Synth Strings 2 instrument - Apple version has much >>>> more complexity. I will raise that concern with our media expert. >>>> >>>> With best regards, >>>> Alexander Zuev >>>> >>> Is the lack of Quatrz support a temporary decision or permanent, could you give us the reasoning behind this ? >> I'm afraid it's permanent. The reason is the different architecture of the AWT components in Java 6 and Java 7. On Java 6 >> AWT components were backed by the native controls who had options to be rendered differently whereas on Java 7 >> they are backed by software rendered controls (basically Swing components with Aqua LaF) and turning the UseQuartz >> option on and off does not change rendering process. >> >> BTW, as far as i can see the main difference between quartz and cocoa renderings are that in quartz mode fonts are rendered with LCD subpixel rendering off. The similar results might be achieved by changing text rendering hints in Java 7 - see included with Java 7 demo Font2DTest for the different hints and the results they take on the the rendering of various fonts. >> >> With best regards, >> Alexander Zuev >>> Paul >>>> On 10/9/12 24:44, Jeff Palmer wrote: >>>>> I might be getting a little picky, but has anyone reported that fonts and sounds are inferior to Java 6? Using JWS, I specify apple.awt.graphics.UseQuartz=true for 1.6. I am using the default font: >>>>> >>>>> com.apple.laf.AquaFonts$DerivedUIResourceFont[family=Lucida Grande,name=Lucida Grande,style=plain,size=13] >>>>> >>>>> I guess I could pull out the UseQuartz and make them look the same, but thought I should at least send this note. >>>>> >>>>> Sound wise, I put in some sound effects to correspond to some events. The Java 6 versions are just so much better, especially for the SYNTH_STRINGS_2 instrument, index 51. >>>>> >>>>> This is not going to stop implementation, but I was just wondering. >>>>> >>>>> Jeff Palmer >>>>> >>>> From Sergey.Bylokhov at oracle.com Thu Oct 11 04:44:19 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 11 Oct 2012 15:44:19 +0400 Subject: hg: macosx-port/macosx-port/jdk: Some cleanup in CAOpenGLLayer prototype (including extracting layer code into CGLLayer.h|m and removing stale code) In-Reply-To: <20110901091210.1D49F47298@hg.openjdk.java.net> References: <20110901091210.1D49F47298@hg.openjdk.java.net> Message-ID: <5076B113.7080008@oracle.com> Hi Mike, Phil, Dmitry, Scott. I have a question about our CALayer implementation. According to the code below we use layer-backed NSView. AWTView.m: [self setWantsLayer: YES]; [self.layer addSublayer: (CALayer *)cglLayer]; But in the documentation for NSView.setWantsLayer: "When using layer-backed views you should never interact directly with the layer" So we use layer-backed NSView and add our CAOpenGLLayer to the backed layer as sublayer. Because of that we use NSView.drawRect and CAOpenGLLayer.drawInCGLContext simultaneously, I guess this is incorrect. Is this configuration supported by Apple? Should we change our implementation to layer-hosting view or probably we can use layer-backed view with appropriate NSView.makeBackingLayer()? 01.09.2011 13:11, dmitry.cherepanov at oracle.com wrote: > Changeset: c6eecbe2396f > Author: dcherepanov > Date: 2011-09-01 13:08 +0400 > URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/c6eecbe2396f > > Some cleanup in CAOpenGLLayer prototype (including extracting layer code into CGLLayer.h|m and removing stale code) > > ! make/sun/lwawt/FILES_c_macosx.gmk > ! make/sun/lwawt/FILES_c_macosx.gmk.all > ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java > - src/macosx/classes/sun/java2d/opengl/CGLRenderQueue.java > ! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java > ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java > ! src/macosx/native/sun/awt/AWTView.h > ! src/macosx/native/sun/awt/AWTView.m > ! src/macosx/native/sun/awt/ThreadUtilities.m > ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m > + src/macosx/native/sun/java2d/opengl/CGLLayer.h > + src/macosx/native/sun/java2d/opengl/CGLLayer.m > ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m > ! src/share/classes/sun/java2d/opengl/OGLRenderQueue.java > ! src/share/classes/sun/java2d/pipe/BufferedContext.java > ! src/share/native/sun/java2d/opengl/OGLSurfaceData.h > - test/experimental/layers/ButtonTest.java > -- Best regards, Sergey. From Alan.Bateman at oracle.com Thu Oct 11 05:09:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Oct 2012 13:09:59 +0100 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <50755FD0.1040608@oracle.com> Message-ID: <5076B717.4070008@oracle.com> On 11/10/2012 13:06, ?orvaldur Bl?ndal wrote: > @Alan I registered 2356502 on bugs.sun.com that has a link to the > JIRA-case. David Kocher reports that the issue that he was seeing is resolved in jdk8 (recent builds). Have you tried jdk8? -Alan From alexandr.scherbatiy at oracle.com Thu Oct 11 07:17:30 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 11 Oct 2012 18:17:30 +0400 Subject: [7u12] Review request for 7199180: [macosx] Dead keys handling for input methods Message-ID: <5076D4FA.1070002@oracle.com> This is a direct backport of the fix from the JDK 8 to JDK 7u12 bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7199180 webrev: http://cr.openjdk.java.net/~alexsch/7199180/webrev.01/ Key events which have marked text are processed by the interpretKeyEvents method and so they are filtered for the deliverJavaKeyEventHelper method. However we need to process dead key events which also set marked text flag to generate dead key pressed event. - The JDK crash is fixed The TISGetInputSourceProperty returns nill property for the dead key combination in the Chinese Pynyin. The fix ignores the dead keys which does not have the input source property. - The realSync() is added before the state checking in the test - The test is renamed to have the first capital letter. Thanks, Alexandr. From anthony.petrov at oracle.com Thu Oct 11 07:37:41 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 11 Oct 2012 18:37:41 +0400 Subject: [7u12] Review request for 7199180: [macosx] Dead keys handling for input methods In-Reply-To: <5076D4FA.1070002@oracle.com> References: <5076D4FA.1070002@oracle.com> Message-ID: <5076D9B5.4070301@oracle.com> The fix looks good. Just one suggestion to the style: src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java > 163 if(testChar == 0){ Please insert spaces before '(' and after ')'. No need to resend a new webrev with this change. -- best regards, Anthony On 10/11/12 18:17, Alexander Scherbatiy wrote: > > This is a direct backport of the fix from the JDK 8 to JDK 7u12 > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7199180 > webrev: http://cr.openjdk.java.net/~alexsch/7199180/webrev.01/ > > Key events which have marked text are processed by the > interpretKeyEvents method and so they are filtered for the > deliverJavaKeyEventHelper method. > However we need to process dead key events which also set marked text > flag to generate dead key pressed event. > > - The JDK crash is fixed > The TISGetInputSourceProperty returns nill property for the dead key > combination in the Chinese Pynyin. > The fix ignores the dead keys which does not have the input source > property. > > - The realSync() is added before the state checking in the test > - The test is renamed to have the first capital letter. > > Thanks, > Alexandr. > From scott.kovatch at oracle.com Thu Oct 11 08:13:28 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Thu, 11 Oct 2012 08:13:28 -0700 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: <8E651DC660254CB7849A5AECEB52CE01@hagi> References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <351FD100-A136-4F3F-AC47-9BCF46079E69@sudo.ch> <8E651DC660254CB7849A5AECEB52CE01@hagi> Message-ID: <910639E8-7C04-4858-98A1-89DE3B139811@oracle.com> That's not a bad solution for the short term. I'm not aware of any way to set an environment variable in a JNLP file. Does your application ask for all-permissions? If so you could use a native library to set it. We need to set this in javaws. I'll make sure I file a bug and fix it, since it's easy to do in the javaws native launcher. -- Scott K. On Oct 11, 2012, at 5:05 AM, ?orvaldur Bl?ndal wrote: > Thanks Scott. > > The LC_TYPE makes all the difference. The problem is that I don't know how to pass it to a webstarted program. Do you know how? > > The only thing I've come up with is to have a tiny webstarted program that calls javaws (with LC_TYPE in the environment) that starts the real jnlp. Something like this dirty dirty hack: > > public static void main(String[] args) throws Exception > { > String wsUrl = null; > for (String arg : args) > if (arg.startsWith("wsUrl=")) > wsUrl = arg.substring("wsUrl=".length()); > > final ProcessBuilder pb = new ProcessBuilder("/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/javaws", wsUrl); > pb.environment().put("LC_CTYPE", "UTF-8"); > > Thread t = new Thread() > { > public void run() > { > try > { > pb.start(); > } > catch (Throwable e) > { > e.printStackTrace(); > } > finally > { > System.exit(0); > } > } > }; > t.setDaemon(false); > t.start(); > } > > > ----- Original Message ----- From: "Scott Kovatch" > To: "David Kocher" > Cc: "Thorkelsson" ; "?orvaldur Bl?ndal" ; > Sent: Wednesday, October 10, 2012 3:58 PM > Subject: Re: File.exists() does not work on mac for non-English characters on Java 7 on Mac > > > We fixed/worked around this in the plugin by setting the environment variable LC_CTYPE to UTF-8. Given that file names are in UTF-8 by default on OS X this seems unnecessary to me, but there you go. > > -- Scott K. From swingler at apple.com Thu Oct 11 18:09:16 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 11 Oct 2012 18:09:16 -0700 Subject: hg: macosx-port/macosx-port/jdk: Some cleanup in CAOpenGLLayer prototype (including extracting layer code into CGLLayer.h|m and removing stale code) In-Reply-To: <5076B113.7080008@oracle.com> References: <20110901091210.1D49F47298@hg.openjdk.java.net> <5076B113.7080008@oracle.com> Message-ID: <6EE749CF-9E35-4F5E-9207-42E4A64ABEF1@apple.com> If you were a regular Cocoa app that had standard NSButtons, NSTextFields, and NSScrollViews, I'd say yes - you are doing it wrong...but since you tightly control your own view hierarchy, I don't think this is a problem. The CAOpenGLLayer breaks a lot of the standard rules anyway, and standard NSViews don't render into it anyway. Perhaps overriding your own -[NSView makeBackingLayer] a better approach - but unless you suspect this is actually a source of bugs or leaks, I'd say don't worry about it. Regards, Mike Swingler Apple Inc. On Oct 11, 2012, at 4:44 AM, Sergey Bylokhov wrote: > Hi Mike, Phil, Dmitry, Scott. > > I have a question about our CALayer implementation. According to the code below we use layer-backed NSView. > AWTView.m: > [self setWantsLayer: YES]; > [self.layer addSublayer: (CALayer *)cglLayer]; > But in the documentation for NSView.setWantsLayer: "When using layer-backed views you should never interact directly with the layer" > So we use layer-backed NSView and add our CAOpenGLLayer to the backed layer as sublayer. > Because of that we use NSView.drawRect and CAOpenGLLayer.drawInCGLContext simultaneously, I guess this is incorrect. > Is this configuration supported by Apple? > Should we change our implementation to layer-hosting view or probably we can use layer-backed view with appropriate NSView.makeBackingLayer()? > > 01.09.2011 13:11, dmitry.cherepanov at oracle.com wrote: >> Changeset: c6eecbe2396f >> Author: dcherepanov >> Date: 2011-09-01 13:08 +0400 >> URL: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/c6eecbe2396f >> >> Some cleanup in CAOpenGLLayer prototype (including extracting layer code into CGLLayer.h|m and removing stale code) >> >> ! make/sun/lwawt/FILES_c_macosx.gmk >> ! make/sun/lwawt/FILES_c_macosx.gmk.all >> ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java >> - src/macosx/classes/sun/java2d/opengl/CGLRenderQueue.java >> ! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java >> ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java >> ! src/macosx/native/sun/awt/AWTView.h >> ! src/macosx/native/sun/awt/AWTView.m >> ! src/macosx/native/sun/awt/ThreadUtilities.m >> ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m >> + src/macosx/native/sun/java2d/opengl/CGLLayer.h >> + src/macosx/native/sun/java2d/opengl/CGLLayer.m >> ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m >> ! src/share/classes/sun/java2d/opengl/OGLRenderQueue.java >> ! src/share/classes/sun/java2d/pipe/BufferedContext.java >> ! src/share/native/sun/java2d/opengl/OGLSurfaceData.h >> - test/experimental/layers/ButtonTest.java >> > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Fri Oct 12 10:48:57 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 12 Oct 2012 21:48:57 +0400 Subject: [8] Request for review: 7124520 [macosx] re:6373505 Toolkit.getScreenResolution() != GraphicsConfiguration.getNormalizingTransform() Message-ID: <50785809.2050603@oracle.com> Hi Everyone, Please review the fix. LWCToolkit.getScreenResolution() now returns current horizontal resolution instead of default constant + small cleanup. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124520 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124520/webrev.00 -- Best regards, Sergey. From daniel.daugherty at oracle.com Fri Oct 12 14:21:37 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 12 Oct 2012 15:21:37 -0600 Subject: Why MACOSX_UNIVERSAL == true by default? In-Reply-To: <5078840B.2070005@oracle.com> References: <5078840B.2070005@oracle.com> Message-ID: <507889E1.1090707@oracle.com> Adding macosx-port-dev at ... to the thread... On 10/12/12 2:56 PM, Vladimir Ivanov wrote: > Hi, > > Does anybody know/remember why MACOSX_UNIVERSAL=true by default? Yes. :-) > I'm asking, because JDK layout on MacOS X differs from other platforms > and to make export_*_jdk build targets work correctly, you need to > specify ALT_MACOSX_UNIVERSAL=false. > > I'd like to fix that (change default value to false), but I have no > idea why it was set to true in the first place. Jim Melvin restored Universal build support into HotSpot. However, the rest of the JDK did not follow suit. As far as I know/remember, only the hotspot repo supports Universal build at the moment. Dan > > Best regards, > Vladimir Ivanov From david.holmes at oracle.com Fri Oct 12 15:39:57 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 13 Oct 2012 08:39:57 +1000 Subject: Why MACOSX_UNIVERSAL == true by default? In-Reply-To: <507889E1.1090707@oracle.com> References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com> Message-ID: <50789C3D.90302@oracle.com> Also see: http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-January/005153.html re Jim's updates. David On 13/10/2012 7:21 AM, Daniel D. Daugherty wrote: > Adding macosx-port-dev at ... to the thread... > > > On 10/12/12 2:56 PM, Vladimir Ivanov wrote: >> Hi, >> >> Does anybody know/remember why MACOSX_UNIVERSAL=true by default? > > Yes. :-) > > >> I'm asking, because JDK layout on MacOS X differs from other platforms >> and to make export_*_jdk build targets work correctly, you need to >> specify ALT_MACOSX_UNIVERSAL=false. >> >> I'd like to fix that (change default value to false), but I have no >> idea why it was set to true in the first place. > > Jim Melvin restored Universal build support into HotSpot. However, > the rest of the JDK did not follow suit. As far as I know/remember, > only the hotspot repo supports Universal build at the moment. > > Dan > >> >> Best regards, >> Vladimir Ivanov From henri.gomez at gmail.com Sat Oct 13 01:08:09 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sat, 13 Oct 2012 10:08:09 +0200 Subject: Why MACOSX_UNIVERSAL == true by default? In-Reply-To: <507889E1.1090707@oracle.com> References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com> Message-ID: > Adding macosx-port-dev at ... to the thread... > > > On 10/12/12 2:56 PM, Vladimir Ivanov wrote: >> >> Hi, >> >> Does anybody know/remember why MACOSX_UNIVERSAL=true by default? > > > Yes. :-) > > >> I'm asking, because JDK layout on MacOS X differs from other platforms and >> to make export_*_jdk build targets work correctly, you need to specify >> ALT_MACOSX_UNIVERSAL=false. >> >> I'd like to fix that (change default value to false), but I have no idea >> why it was set to true in the first place. > > > Jim Melvin restored Universal build support into HotSpot. However, > the rest of the JDK did not follow suit. As far as I know/remember, > only the hotspot repo supports Universal build at the moment. Good news but there is still problems using OpenJDK 7 on OSX with -d32. I build universal packages with this added patches (http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch) and check if 32bits support is available back on OSX. Sadly I still get errors with Jenkins (test app) when using -d32. Anyboby willing to take a look in it ? # # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0xa) at pc=0x00e54875, pid=15221, tid=5891 # # JRE version: 7.0 # Java VM: OpenJDK Server VM (23.6-b03 mixed mode bsd-x86 ) # Problematic frame: # J sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/henri/Documents/jenkins/hs_err_pid15221.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Abort trap: 6 From henri.gomez at gmail.com Sat Oct 13 01:12:07 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sat, 13 Oct 2012 10:12:07 +0200 Subject: Why MACOSX_UNIVERSAL == true by default? In-Reply-To: References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com> Message-ID: error log attached if someone want to dig into it. core file available if needed 2012/10/13 Henri Gomez : >> Adding macosx-port-dev at ... to the thread... >> >> >> On 10/12/12 2:56 PM, Vladimir Ivanov wrote: >>> >>> Hi, >>> >>> Does anybody know/remember why MACOSX_UNIVERSAL=true by default? >> >> >> Yes. :-) >> >> >>> I'm asking, because JDK layout on MacOS X differs from other platforms and >>> to make export_*_jdk build targets work correctly, you need to specify >>> ALT_MACOSX_UNIVERSAL=false. >>> >>> I'd like to fix that (change default value to false), but I have no idea >>> why it was set to true in the first place. >> >> >> Jim Melvin restored Universal build support into HotSpot. However, >> the rest of the JDK did not follow suit. As far as I know/remember, >> only the hotspot repo supports Universal build at the moment. > > Good news but there is still problems using OpenJDK 7 on OSX with -d32. > > I build universal packages with this added patches > (http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/universal-build.patch) > and check if 32bits support is available back on OSX. > > Sadly I still get errors with Jenkins (test app) when using -d32. > Anyboby willing to take a look in it ? > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGBUS (0xa) at pc=0x00e54875, pid=15221, tid=5891 > # > # JRE version: 7.0 > # Java VM: OpenJDK Server VM (23.6-b03 mixed mode bsd-x86 ) > # Problematic frame: > # J sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; > # > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /Users/henri/Documents/jenkins/hs_err_pid15221.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > Abort trap: 6 From marco.dinacci at gmail.com Sat Oct 13 01:29:22 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Sat, 13 Oct 2012 09:29:22 +0100 Subject: Why MACOSX_UNIVERSAL == true by default? In-Reply-To: References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com> Message-ID: Hi, > Sadly I still get errors with Jenkins (test app) when using -d32. > Anyboby willing to take a look in it ? > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGBUS (0xa) at pc=0x00e54875, pid=15221, tid=5891 > # > # JRE version: 7.0 > # Java VM: OpenJDK Server VM (23.6-b03 mixed mode bsd-x86 ) > # Problematic frame: > # J sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; > # I encountered the same issue on OSX Leopard with a JDK7u compiled with Henry's universal patch. For the moment I use this workaround: -XX:CompileCommand=exclude,sun/nio/cs/StreamDecoder,read However after solving this crash another follows (sorry can't remember the details now), which I prevent using: -XX:-UseLoopPredicate -XX:-LoopLimitCheck Best, Marco From henri.gomez at gmail.com Sat Oct 13 03:44:56 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sat, 13 Oct 2012 12:44:56 +0200 Subject: Why MACOSX_UNIVERSAL == true by default? In-Reply-To: References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com> Message-ID: Marco, you're using openjdk-build-project packages on Leopard (10.5) ? And in 32bits mode (-d32) ? This is very interesting After -XX:CompileCommand=exclude,sun/nio/cs/StreamDecoder,read and -XX:-UseLoopPredicate -XX:-LoopLimitCheck did your JVM crash again ? 2012/10/13 Marco Dinacci : > Hi, > >> Sadly I still get errors with Jenkins (test app) when using -d32. >> Anyboby willing to take a look in it ? >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGBUS (0xa) at pc=0x00e54875, pid=15221, tid=5891 >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK Server VM (23.6-b03 mixed mode bsd-x86 ) >> # Problematic frame: >> # J sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; >> # > > I encountered the same issue on OSX Leopard with a JDK7u compiled with > Henry's universal patch. > For the moment I use this workaround: > > -XX:CompileCommand=exclude,sun/nio/cs/StreamDecoder,read > > However after solving this crash another follows (sorry can't remember > the details now), which I prevent using: > > -XX:-UseLoopPredicate -XX:-LoopLimitCheck > > > Best, > Marco From marco.dinacci at gmail.com Sat Oct 13 04:59:26 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Sat, 13 Oct 2012 12:59:26 +0100 Subject: Why MACOSX_UNIVERSAL == true by default? In-Reply-To: References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com> Message-ID: Hi, > Marco, you're using openjdk-build-project packages on Leopard (10.5) ? > And in 32bits mode (-d32) ? Sorry I meant *Snow* Leopard (10.6). I use my own package to which I added your universal build patch, I didn't specifically launch the JVM in 32bits mode but I experienced exactly the same crash you reported when testing on 10.6.6 64bits. It happens systematically because every user we have using Snow Leopard has the same crash. Adding the options I wrote in the previous post "fixes" it. Best, Marco From henri.gomez at gmail.com Sat Oct 13 06:03:56 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sat, 13 Oct 2012 15:03:56 +0200 Subject: Why MACOSX_UNIVERSAL == true by default? In-Reply-To: References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com> Message-ID: > Sorry I meant *Snow* Leopard (10.6). Ok, 10.5 shouldn't works due to some missing libs > I use my own package to which I added your universal build patch, I > didn't specifically launch the JVM in 32bits mode but I experienced > exactly the same crash you reported when testing on 10.6.6 64bits. It > happens systematically because every user we have using Snow Leopard > has the same crash. Adding the options I wrote in the previous post > "fixes" it. Special package ? Is it available, especially build sources. I tried your options and it didn't fix my problems, my use case is simple, Apache Tomcat 7.0.32 with Jenkins 1.485. No way, it still crash ;( From henri.gomez at gmail.com Sat Oct 13 06:09:49 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sat, 13 Oct 2012 15:09:49 +0200 Subject: ALT_FREETYPE_LIB and relocation Message-ID: Hi to all, I'm trying to remove OSX dependencies on X11. fontmanager require freetype which in turn require X11 on SnowLeopard and Lion. Problem, there is no more X11 on Mountain Lion and XQuartz is proposed by Apple alert during runtime. I used a trick available for Linux, defining ALT_FREETYPE_LIB_PATH and ALT_FREETYPE_HEADERS_PATH. export ALT_FREETYPE_LIB_PATH=$DROP_DIR/freetype/lib export ALT_FREETYPE_HEADERS_PATH=$DROP_DIR/freetype/include I built freetype 2.4.10 on OSX (no X11 required) and provided ALT_FREETYPE_LIB_PATH and ALT_FREETYPE_HEADERS_PATH at make time. But fontmanager reference freetype dylib in path whereas freetype is included in delivery for Linux. libfontmanager.dylib: @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0) /Users/henri/Documents/jenkins/data/DROP_DIR/freetype/lib/libfreetype.6.dylib (compatibility version 15.0.0, current version 15.1.0) @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) So we should have instead libfreetype.6.dylib copied under ire and referenced with @rpath like this : libfontmanager.dylib: @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0) @@rpath/libfreetype.6.dylib (compatibility version 15.0.0, current version 15.1.0) @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) Did someone works on this or should I provide a fix for OpenJDK 7, 8 and others ? From henri.gomez at gmail.com Sat Oct 13 14:20:47 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sat, 13 Oct 2012 23:20:47 +0200 Subject: ALT_FREETYPE_LIB and relocation In-Reply-To: References: Message-ID: Question for OpenJDK build gurus around : I'm hacking jdk/make/sun/font/Makefile for FreeType problem on ML and I wonder how I could make this part alone, and not full OpenJDK make (ie : make ALLOW_DOWNLOADS=true SA_APPLE_BOOT_JAVA=true ALWAYS_PASS_TEST_GAMMA=true ...) How could I run make for this part only ? Thanks 2012/10/13 Henri Gomez : > Hi to all, > > I'm trying to remove OSX dependencies on X11. > fontmanager require freetype which in turn require X11 on SnowLeopard and Lion. > Problem, there is no more X11 on Mountain Lion and XQuartz is proposed > by Apple alert during runtime. > > I used a trick available for Linux, defining ALT_FREETYPE_LIB_PATH and > ALT_FREETYPE_HEADERS_PATH. > > export ALT_FREETYPE_LIB_PATH=$DROP_DIR/freetype/lib > export ALT_FREETYPE_HEADERS_PATH=$DROP_DIR/freetype/include > > I built freetype 2.4.10 on OSX (no X11 required) and provided > ALT_FREETYPE_LIB_PATH and ALT_FREETYPE_HEADERS_PATH at make time. > But fontmanager reference freetype dylib in path whereas freetype is > included in delivery for Linux. > > libfontmanager.dylib: > @rpath/libfontmanager.dylib (compatibility version 1.0.0, > current version 1.0.0) > /Users/henri/Documents/jenkins/data/DROP_DIR/freetype/lib/libfreetype.6.dylib > (compatibility version 15.0.0, current version 15.1.0) > @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 159.1.0) > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, > current version 52.0.0) > @rpath/libjava.dylib (compatibility version 1.0.0, current > version 1.0.0) > @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) > > So we should have instead libfreetype.6.dylib copied under ire and > referenced with @rpath like this : > > libfontmanager.dylib: > @rpath/libfontmanager.dylib (compatibility version 1.0.0, > current version 1.0.0) > @@rpath/libfreetype.6.dylib (compatibility version 15.0.0, > current version 15.1.0) > @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 159.1.0) > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, > current version 52.0.0) > @rpath/libjava.dylib (compatibility version 1.0.0, current > version 1.0.0) > @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) > > Did someone works on this or should I provide a fix for OpenJDK 7, 8 > and others ? From henri.gomez at gmail.com Sat Oct 13 14:29:27 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sat, 13 Oct 2012 23:29:27 +0200 Subject: Freetype in Mountain Lion and higher In-Reply-To: <4FA16196.3070702@oracle.com> References: <4FA12273.60906@oracle.com> <4FA1552B.90402@oracle.com> <4FA16196.3070702@oracle.com> Message-ID: Back on this old thread, FreeType and OSX. In jdk/make/common/Defs.gmk, I see : ifdef ALT_FREETYPE_LIB_PATH FREETYPE_LIB_PATH = $(ALT_FREETYPE_LIB_PATH) ifeq ($(PLATFORM), macosx) USING_SYSTEM_FT_LIB=true endif else Why USING_SYSTEM_FT_LIB is set to true when ALT_FREETYPE_LIB_PATH is defined ? ALT_FREETYPE_LIB_PATH is used when a non system lib is provided and should be copied/embedded in OpenJDK. Bug ? 2012/5/2 Phil Race : > I think .6 probably was to ensure we are getting a version was expect. > If it was something else it might be a red flag to check all worked as > expected. > > There's also the infamous freetype_check program which ensured the > actual freetype version, not the library version, was what we expected. > At the time we did the work platforms which had fonts with embedded > bitmaps were *dead* with freetype. Expect an infinite loop on start up. > > The plan was to have pre-built freetype libs which would be imported > and delivered along with JDK, but *allow* Linux distros to set a variable > USING_SYSTEM_FT_LIB to say not to do that .. > > I am not sure I see why we need another variable (EMBEDDING_EXTERNAL_FT_LIB) > to say not to not do that ... > > For OS X including a copy is absolutely the way to go, and I blocked on > this a few months ago because I didn't have the cycles to go figure out > how to fix the freetype build for OS X, which hardwires into itself the > dylib > path where it expects to be installed and that code linked against it must > use, to be standard location. > > That seemed to me to be the only issue that seemed to require anything > except perhaps very, very minor makefile tweaking. > > -phil. > > > On 5/2/2012 9:01 AM, Henri Gomez wrote: >>>> >>>> ifeq ($(USING_SYSTEM_FT_LIB), false) >>>> FREETYPE_LIB = >>>> $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX).6 >>>> endif >>> >>> >>> I'd defer the answer to 2D folks. I can only speculate that this must be >>> a >>> minimum required version. Perhaps the makefiles logic might be enhanced >>> in >>> this area. >> >> Yep, I spent some time on this makefile and it seems incomplete. >> ie : >> >> >> $(FREETYPE_LIB): >> $(CP) >> $(FREETYPE_LIB_PATH)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX) $@ >> endif >> >> This goal make me think copy of Freetype library was planned, but need >> some more tweaking. >> >> ifeq ($(PLATFORM), windows) >> FREETYPE_LIB = >> $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX) >> OTHER_LDLIBS += $(FREETYPE_LIB_PATH)/freetype.lib >> else >> ifeq ($(USING_SYSTEM_FT_LIB), false) >> FREETYPE_LIB = >> $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX).6 >> endif >> OTHER_LDLIBS += -L$(FREETYPE_LIB_PATH) -lfreetype >> endif >> >> ... >> >> # >> # Libraries to link, and other C flags. >> # >> >> ifeq ($(PLATFORM), macosx)) >> OTHER_INCLUDES += -I$(X11_PATH)/include >> OTHER_LDLIBS += -lawt $(LIBM) $(LIBCXX) >> ifeq ($(OS_VENDOR),Apple) >> # XXXDARWIN Match BSD/Linux behavior -- the mawt.dylib symbols will >> # be available at runtime. >> OTHER_LDLIBS += -undefined dynamic_lookup >> endif >> else >> ifeq ($(PLATFORM), solaris) >> # Note that on Solaris, fontmanager is built against the headless >> library. >> LDFLAGS += -L$(LIBDIR)/$(LIBARCH)/headless >> OTHER_LDLIBS += -lawt -L$(LIBDIR)/$(LIBARCH)/xawt -lmawt -lc $(LIBM) >> $(LIBCXX) >> else # PLATFORM is linux >> OTHER_LDLIBS += -lawt $(LIBM) $(LIBCXX) >> ifeq ("$(CC_VER_MAJOR)", "3") >> OTHER_LDLIBS += -Wl,-Bstatic -lgcc_eh -Wl,-Bdynamic >> endif >> endif >> endif >> >> Makefile may need some cleanup to split it between using system FT lib >> and copying (embedding) provided external FT LIB (via >> ALT_FREETYPE_HEADERS_PATH and ALT_FREETYPE_LIB_PATH) >> >> It will be clearer by using 2 vars. >> >> One exist, USING_SYSTEM_FT_LIB, new one could be >> EMBEDDING_EXTERNAL_FT_LIB. >> >> My 0.01$ > > From henri.gomez at gmail.com Sun Oct 14 13:29:42 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sun, 14 Oct 2012 22:29:42 +0200 Subject: Request for review : FreeType embedded in OSX packages Message-ID: Hi to all, libfontmanager requires freetype. In SnowLeopard and Lion, Freetype is and since Mountain Lion Here's a patch for OpenJDK 7 and OSX to embed FreeType in build when ALT_FREETYPE_LIB_PATH is defined. Patch will get libfreetype.dylib under ALT_FREETYPE_LIB_PATH and copy it in jre/lib and libfontmanager.dylib will reference it via @rpath. Sample output here : build/macosx-universal/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib: @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0) @rpath/libfreetype.dylib (compatibility version 16.0.0, current version 16.0.0) @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) I build FreeType 2.4.10 like this : ./configure --prefix=$DROP_DIR/freetype CC=/usr/bin/clang 'CFLAGS=-pipe -Os -arch i386 -arch x86_64' \ 'LDFLAGS=-arch i386 -arch x86_64' CXX=/usr/bin/clang++ 'CXXFLAGS=-pipe -Os -arch i386 -arch x86_64' \ --disable-static --with-old-mac-fonts cp $DROP_DIR/freetype/lib/libfreetype.6.dylib $DROP_DIR/freetype/lib/libfreetype.dylib install_name_tool -id @rpath/libfreetype.dylib $DROP_DIR/freetype/lib/libfreetype.dylib otool -L libfreetype.lib : build/macosx-universal/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home/jre/lib/libfreetype.dylib: @rpath/libfreetype.dylib (compatibility version 16.0.0, current version 16.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 53.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 41.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.21.0) Patch done against latest jdk7u. Thanks to review From henri.gomez at gmail.com Sun Oct 14 15:53:45 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 15 Oct 2012 00:53:45 +0200 Subject: Request for review : FreeType embedded in OSX packages In-Reply-To: References: Message-ID: Here is a second patch. This patch a stock libfreetype.dylib (aka without install_name_tool hack) which make sanity test pass. install_name_tool is now done at build time. I released an OpenJDK 7 with Freetype 2.4.10 embedded here : OpenJDK-OSX-1.7-universal-u-jdk-u10-b09-20121015.dmg Thanks for new patch review 2012/10/14 Henri Gomez > Hi to all, > > libfontmanager requires freetype. > In SnowLeopard and Lion, Freetype is and since Mountain Lion > Here's a patch for OpenJDK 7 and OSX to embed FreeType in build when > ALT_FREETYPE_LIB_PATH is defined. > > Patch will get libfreetype.dylib under ALT_FREETYPE_LIB_PATH and copy it > in jre/lib and libfontmanager.dylib will reference it via @rpath. > > Sample output here : > > > build/macosx-universal/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib: > @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version > 1.0.0) > @rpath/libfreetype.dylib (compatibility version 16.0.0, current version > 16.0.0) > @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 159.1.0) > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version > 52.0.0) > @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) > @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) > > I build FreeType 2.4.10 like this : > > ./configure --prefix=$DROP_DIR/freetype CC=/usr/bin/clang 'CFLAGS=-pipe > -Os -arch i386 -arch x86_64' \ > 'LDFLAGS=-arch i386 -arch x86_64' CXX=/usr/bin/clang++ 'CXXFLAGS=-pipe -Os > -arch i386 -arch x86_64' \ > --disable-static --with-old-mac-fonts > > cp $DROP_DIR/freetype/lib/libfreetype.6.dylib > $DROP_DIR/freetype/lib/libfreetype.dylib > install_name_tool -id @rpath/libfreetype.dylib > $DROP_DIR/freetype/lib/libfreetype.dylib > > otool -L libfreetype.lib : > > > build/macosx-universal/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home/jre/lib/libfreetype.dylib: > @rpath/libfreetype.dylib (compatibility version 16.0.0, current version > 16.0.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) > /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version > 1.0.5) > /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices > (compatibility version 1.0.0, current version 53.0.0) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices > (compatibility version 1.0.0, current version 41.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 159.1.0) > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > (compatibility version 150.0.0, current version 635.21.0) > > Patch done against latest jdk7u. > > Thanks to review > From henri.gomez at gmail.com Mon Oct 15 00:53:43 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 15 Oct 2012 09:53:43 +0200 Subject: Request for review : FreeType embedded in OSX packages In-Reply-To: References: Message-ID: If you didn't get patch, it's available on openjdk-osx-build SVN : http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/freetype-osx.patch Cheers 2012/10/15 Henri Gomez > > Here is a second patch. > > This patch a stock libfreetype.dylib (aka without install_name_tool hack) which make sanity test pass. > install_name_tool is now done at build time. > > I released an OpenJDK 7 with Freetype 2.4.10 embedded here : > > OpenJDK-OSX-1.7-universal-u-jdk-u10-b09-20121015.dmg > > Thanks for new patch review > > 2012/10/14 Henri Gomez >> >> Hi to all, >> >> libfontmanager requires freetype. >> In SnowLeopard and Lion, Freetype is and since Mountain Lion >> Here's a patch for OpenJDK 7 and OSX to embed FreeType in build when ALT_FREETYPE_LIB_PATH is defined. >> >> Patch will get libfreetype.dylib under ALT_FREETYPE_LIB_PATH and copy it in jre/lib and libfontmanager.dylib will reference it via @rpath. >> >> Sample output here : >> >> build/macosx-universal/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib: >> @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0) >> @rpath/libfreetype.dylib (compatibility version 16.0.0, current version 16.0.0) >> @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) >> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) >> @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) >> @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) >> >> I build FreeType 2.4.10 like this : >> >> ./configure --prefix=$DROP_DIR/freetype CC=/usr/bin/clang 'CFLAGS=-pipe -Os -arch i386 -arch x86_64' \ >> 'LDFLAGS=-arch i386 -arch x86_64' CXX=/usr/bin/clang++ 'CXXFLAGS=-pipe -Os -arch i386 -arch x86_64' \ >> --disable-static --with-old-mac-fonts >> >> cp $DROP_DIR/freetype/lib/libfreetype.6.dylib $DROP_DIR/freetype/lib/libfreetype.dylib >> install_name_tool -id @rpath/libfreetype.dylib $DROP_DIR/freetype/lib/libfreetype.dylib >> >> otool -L libfreetype.lib : >> >> build/macosx-universal/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home/jre/lib/libfreetype.dylib: >> @rpath/libfreetype.dylib (compatibility version 16.0.0, current version 16.0.0) >> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) >> /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) >> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 53.0.0) >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 41.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) >> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.21.0) >> >> Patch done against latest jdk7u. >> >> Thanks to review > > From anthony.petrov at oracle.com Mon Oct 15 07:08:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 15 Oct 2012 18:08:22 +0400 Subject: [8] Request for review: 7124520 [macosx] re:6373505 Toolkit.getScreenResolution() != GraphicsConfiguration.getNormalizingTransform() In-Reply-To: <50785809.2050603@oracle.com> References: <50785809.2050603@oracle.com> Message-ID: <507C18D6.2050108@oracle.com> Hi Sergey, The fix looks good. -- best regards, Anthony On 10/12/12 21:48, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > > LWCToolkit.getScreenResolution() now returns current horizontal > resolution instead of default constant + small cleanup. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124520 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124520/webrev.00 > From vladimir.x.ivanov at oracle.com Mon Oct 15 08:50:56 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 15 Oct 2012 19:50:56 +0400 Subject: Why MACOSX_UNIVERSAL == true by default? In-Reply-To: <507889E1.1090707@oracle.com> References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com> Message-ID: <507C30E0.4070205@oracle.com> Thanks everybody for the background information! Are there any objections to set MACOSX_UNIVERSAL=false by default during Hotspot build then? Best regards, Vladimir Ivanov On 10/13/12 01:21, Daniel D. Daugherty wrote: > Adding macosx-port-dev at ... to the thread... > > > On 10/12/12 2:56 PM, Vladimir Ivanov wrote: >> Hi, >> >> Does anybody know/remember why MACOSX_UNIVERSAL=true by default? > > Yes. :-) > > >> I'm asking, because JDK layout on MacOS X differs from other platforms >> and to make export_*_jdk build targets work correctly, you need to >> specify ALT_MACOSX_UNIVERSAL=false. >> >> I'd like to fix that (change default value to false), but I have no >> idea why it was set to true in the first place. > > Jim Melvin restored Universal build support into HotSpot. However, > the rest of the JDK did not follow suit. As far as I know/remember, > only the hotspot repo supports Universal build at the moment. > > Dan > >> >> Best regards, >> Vladimir Ivanov From swingler at apple.com Mon Oct 15 10:40:39 2012 From: swingler at apple.com (Mike Swingler) Date: Mon, 15 Oct 2012 10:40:39 -0700 Subject: Request for review : FreeType embedded in OSX packages In-Reply-To: References: Message-ID: Looks good to me. I'm glad to see this is finally getting some attention. Regards, Mike Swingler Apple Inc. On Oct 15, 2012, at 12:53 AM, Henri Gomez wrote: > If you didn't get patch, it's available on openjdk-osx-build SVN : > > http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/freetype-osx.patch > > Cheers > > 2012/10/15 Henri Gomez >> >> Here is a second patch. >> >> This patch a stock libfreetype.dylib (aka without install_name_tool hack) which make sanity test pass. >> install_name_tool is now done at build time. >> >> I released an OpenJDK 7 with Freetype 2.4.10 embedded here : >> >> OpenJDK-OSX-1.7-universal-u-jdk-u10-b09-20121015.dmg >> >> Thanks for new patch review >> >> 2012/10/14 Henri Gomez >>> >>> Hi to all, >>> >>> libfontmanager requires freetype. >>> In SnowLeopard and Lion, Freetype is and since Mountain Lion >>> Here's a patch for OpenJDK 7 and OSX to embed FreeType in build when ALT_FREETYPE_LIB_PATH is defined. >>> >>> Patch will get libfreetype.dylib under ALT_FREETYPE_LIB_PATH and copy it in jre/lib and libfontmanager.dylib will reference it via @rpath. >>> >>> Sample output here : >>> >>> build/macosx-universal/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib: >>> @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0) >>> @rpath/libfreetype.dylib (compatibility version 16.0.0, current version 16.0.0) >>> @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) >>> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) >>> @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) >>> @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) >>> >>> I build FreeType 2.4.10 like this : >>> >>> ./configure --prefix=$DROP_DIR/freetype CC=/usr/bin/clang 'CFLAGS=-pipe -Os -arch i386 -arch x86_64' \ >>> 'LDFLAGS=-arch i386 -arch x86_64' CXX=/usr/bin/clang++ 'CXXFLAGS=-pipe -Os -arch i386 -arch x86_64' \ >>> --disable-static --with-old-mac-fonts >>> >>> cp $DROP_DIR/freetype/lib/libfreetype.6.dylib $DROP_DIR/freetype/lib/libfreetype.dylib >>> install_name_tool -id @rpath/libfreetype.dylib $DROP_DIR/freetype/lib/libfreetype.dylib >>> >>> otool -L libfreetype.lib : >>> >>> build/macosx-universal/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home/jre/lib/libfreetype.dylib: >>> @rpath/libfreetype.dylib (compatibility version 16.0.0, current version 16.0.0) >>> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) >>> /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) >>> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 53.0.0) >>> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 41.0.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) >>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.21.0) >>> >>> Patch done against latest jdk7u. >>> >>> Thanks to review >> >> From alexander.zuev at oracle.com Mon Oct 15 10:45:09 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 15 Oct 2012 21:45:09 +0400 Subject: [8] Request for review: 7124520 [macosx] re:6373505 Toolkit.getScreenResolution() != GraphicsConfiguration.getNormalizingTransform() In-Reply-To: <50785809.2050603@oracle.com> References: <50785809.2050603@oracle.com> Message-ID: <507C4BA5.2050406@oracle.com> Sergey, looks fine to me. With best regards, Alex On 10/12/12 21:48, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > > LWCToolkit.getScreenResolution() now returns current horizontal > resolution instead of default constant + small cleanup. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124520 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7124520/webrev.00 > From henri.gomez at gmail.com Mon Oct 15 11:24:02 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 15 Oct 2012 20:24:02 +0200 Subject: Request for review : FreeType embedded in OSX packages In-Reply-To: References: Message-ID: Thanks Mike. Hope it will be applied to OpenJDK 7, 8 and more so Mountain Lion won't require X11 or XQuartz. Any advices on how to build Freetype, ie configure options ? I used : ./configure --prefix=$DROP_DIR/freetype CC=/usr/bin/clang 'CFLAGS=-pipe -Os -arch i386 -arch x86_64' \ 'LDFLAGS=-arch i386 -arch x86_64' CXX=/usr/bin/clang++ 'CXXFLAGS=-pipe -Os -arch i386 -arch x86_64' \ --disable-static --with-old-mac-fonts Wondering if --with-old-mac-fonts is needed. Cheers 2012/10/15 Mike Swingler : > Looks good to me. I'm glad to see this is finally getting some attention. > > Regards, > Mike Swingler > Apple Inc. > > On Oct 15, 2012, at 12:53 AM, Henri Gomez wrote: > >> If you didn't get patch, it's available on openjdk-osx-build SVN : >> >> http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk7u-osx/freetype-osx.patch >> >> Cheers >> >> 2012/10/15 Henri Gomez >>> >>> Here is a second patch. >>> >>> This patch a stock libfreetype.dylib (aka without install_name_tool hack) which make sanity test pass. >>> install_name_tool is now done at build time. >>> >>> I released an OpenJDK 7 with Freetype 2.4.10 embedded here : >>> >>> OpenJDK-OSX-1.7-universal-u-jdk-u10-b09-20121015.dmg >>> >>> Thanks for new patch review >>> >>> 2012/10/14 Henri Gomez >>>> >>>> Hi to all, >>>> >>>> libfontmanager requires freetype. >>>> In SnowLeopard and Lion, Freetype is and since Mountain Lion >>>> Here's a patch for OpenJDK 7 and OSX to embed FreeType in build when ALT_FREETYPE_LIB_PATH is defined. >>>> >>>> Patch will get libfreetype.dylib under ALT_FREETYPE_LIB_PATH and copy it in jre/lib and libfontmanager.dylib will reference it via @rpath. >>>> >>>> Sample output here : >>>> >>>> build/macosx-universal/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib: >>>> @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0) >>>> @rpath/libfreetype.dylib (compatibility version 16.0.0, current version 16.0.0) >>>> @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) >>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) >>>> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) >>>> @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) >>>> @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) >>>> >>>> I build FreeType 2.4.10 like this : >>>> >>>> ./configure --prefix=$DROP_DIR/freetype CC=/usr/bin/clang 'CFLAGS=-pipe -Os -arch i386 -arch x86_64' \ >>>> 'LDFLAGS=-arch i386 -arch x86_64' CXX=/usr/bin/clang++ 'CXXFLAGS=-pipe -Os -arch i386 -arch x86_64' \ >>>> --disable-static --with-old-mac-fonts >>>> >>>> cp $DROP_DIR/freetype/lib/libfreetype.6.dylib $DROP_DIR/freetype/lib/libfreetype.dylib >>>> install_name_tool -id @rpath/libfreetype.dylib $DROP_DIR/freetype/lib/libfreetype.dylib >>>> >>>> otool -L libfreetype.lib : >>>> >>>> build/macosx-universal/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home/jre/lib/libfreetype.dylib: >>>> @rpath/libfreetype.dylib (compatibility version 16.0.0, current version 16.0.0) >>>> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) >>>> /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) >>>> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 53.0.0) >>>> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 41.0.0) >>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) >>>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.21.0) >>>> >>>> Patch done against latest jdk7u. >>>> >>>> Thanks to review >>> >>> > From dkocher at sudo.ch Tue Oct 16 05:42:14 2012 From: dkocher at sudo.ch (David Kocher) Date: Tue, 16 Oct 2012 14:42:14 +0200 Subject: Why MACOSX_UNIVERSAL == true by default? In-Reply-To: References: <5078840B.2070005@oracle.com> <507889E1.1090707@oracle.com> Message-ID: <4247F66C-68B0-4A8A-9BA7-6D15276F21C8@sudo.ch> This issue was originally filed in MACOSX_PORT-104 [1]. I can still reproduce and if someone at Oracle could have a look into it that would be great. Originally reported 07/Jun/11 02:31 AM. -- David [1] http://java.net/jira/browse/MACOSX_PORT-104 On 13.10.2012, at 10:29, Marco Dinacci wrote: > Hi, > >> Sadly I still get errors with Jenkins (test app) when using -d32. >> Anyboby willing to take a look in it ? >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGBUS (0xa) at pc=0x00e54875, pid=15221, tid=5891 >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK Server VM (23.6-b03 mixed mode bsd-x86 ) >> # Problematic frame: >> # J sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource; >> # > > I encountered the same issue on OSX Leopard with a JDK7u compiled with > Henry's universal patch. > For the moment I use this workaround: > > -XX:CompileCommand=exclude,sun/nio/cs/StreamDecoder,read > > However after solving this crash another follows (sorry can't remember > the details now), which I prevent using: > > -XX:-UseLoopPredicate -XX:-LoopLimitCheck > > > Best, > Marco > From dkocher at sudo.ch Tue Oct 16 08:33:14 2012 From: dkocher at sudo.ch (David Kocher) Date: Tue, 16 Oct 2012 17:33:14 +0200 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: <5076B717.4070008@oracle.com> References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <50755FD0.1040608@oracle.com> <5076B717.4070008@oracle.com> Message-ID: On 11.10.2012, at 14:09, Alan Bateman wrote: > On 11/10/2012 13:06, ?orvaldur Bl?ndal wrote: >> @Alan I registered 2356502 on bugs.sun.com that has a link to the JIRA-case. > David Kocher reports that the issue that he was seeing is resolved in jdk8 (recent builds). Have you tried jdk8? > > -Alan The question remains when this will be backported to JDK 7. -- David From henri.gomez at gmail.com Tue Oct 16 09:02:43 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 16 Oct 2012 18:02:43 +0200 Subject: Request for review : FreeType embedded in OSX packages In-Reply-To: References: Message-ID: >2012/10/15 Henri Gomez : > Thanks Mike. > > Hope it will be applied to OpenJDK 7, 8 and more so Mountain Lion > won't require X11 or XQuartz. What about this patch ? Will it be included ? For informations I also worked on patchs for : * jdk8 : http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk8-osx/freetype-osx.patch * lambda : http://openjdk-osx-build.googlecode.com/svn/trunk/patches-lambda-osx/freetype-osx.patch * jigsaw : http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jigsaw-osx/freetype-osx.patch FYI, openjdk-osx-build project produce right now all of its packages with FreeType embedded. Cheers From scott.kovatch at oracle.com Tue Oct 16 15:17:40 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 16 Oct 2012 15:17:40 -0700 Subject: Request for review : FreeType embedded in OSX packages In-Reply-To: References: Message-ID: On Oct 16, 2012, at 9:02 AM, Henri Gomez wrote: >> 2012/10/15 Henri Gomez : >> Thanks Mike. >> >> Hope it will be applied to OpenJDK 7, 8 and more so Mountain Lion >> won't require X11 or XQuartz. > > What about this patch ? > Does the JDK still build properly if you installed X11 and do not have your own copy of libfreetype? I think that having the option of building with a non-system-provided libfreetype.dylib is a good idea, but the main nightly builds will continue to use X11 or XQuartz' library for the time being. To that end, a few comments. In: +++ jdk/make/common/Defs.gmk 2012-10-16 09:36:11.000000000 +0200 @@ -180,7 +180,7 @@ ifdef ALT_FREETYPE_LIB_PATH FREETYPE_LIB_PATH = $(ALT_FREETYPE_LIB_PATH) ifeq ($(PLATFORM), macosx) - USING_SYSTEM_FT_LIB=true + USING_SYSTEM_FT_LIB=false endif -------- you could just get rid of the entire ifeq block, since USING_SYSTEM_FT_LIB was initialized to false. In jdk/make/sun/font/Makefile: -------- - FREETYPE_LIB = $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX).6 + ifeq ($(PLATFORM), macosx) + FREETYPE_LIB = $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX) + OTHER_LDLIBS += -lfreetype + else + FREETYPE_LIB = $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX).6 + OTHER_LDLIBS += -L$(FREETYPE_LIB_PATH) -lfreetype + endif endif - OTHER_LDLIBS += -L$(FREETYPE_LIB_PATH) -lfreetype --------- I don't think you want to remove '-L$(FREETYPE_LIB_PATH)' in the macosx case. If it was overridden by ALT_FREETYPE_LIB_PATH the build won't be able to find the pre-build libfreetype.dylib. And if you still want to use the system-provided libfreetype you have to give it the path to the X11 libraries. > Will it be included ? > > For informations I also worked on patchs for : > > * jdk8 : http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jdk8-osx/freetype-osx.patch > * lambda : http://openjdk-osx-build.googlecode.com/svn/trunk/patches-lambda-osx/freetype-osx.patch > * jigsaw : http://openjdk-osx-build.googlecode.com/svn/trunk/patches-jigsaw-osx/freetype-osx.patch > > FYI, openjdk-osx-build project produce right now all of its packages > with FreeType embedded. You need to create a bug at describing what you want to change, and then attach a new patch. Mike's review plus one other will be enough to get it into JDK 8. JDK 7u will need two reviewers, since I think the Java2D team owns this part of the code. (I cc'd Phil Race). -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From ahughes at redhat.com Tue Oct 16 16:46:30 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 16 Oct 2012 19:46:30 -0400 (EDT) Subject: Request for review : FreeType embedded in OSX packages In-Reply-To: Message-ID: <237720890.1335164.1350431190515.JavaMail.root@redhat.com> ----- Original Message ----- > Hi to all, > > libfontmanager requires freetype. > In SnowLeopard and Lion, Freetype is and since Mountain Lion > Here's a patch for OpenJDK 7 and OSX to embed FreeType in build when > ALT_FREETYPE_LIB_PATH is defined. > > Patch will get libfreetype.dylib under ALT_FREETYPE_LIB_PATH and copy > it in > jre/lib and libfontmanager.dylib will reference it via @rpath. > > Sample output here : > > build/macosx-universal/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib: > @rpath/libfontmanager.dylib (compatibility version 1.0.0, current > version > 1.0.0) > @rpath/libfreetype.dylib (compatibility version 16.0.0, current > version > 16.0.0) > @rpath/libawt.dylib (compatibility version 1.0.0, current version > 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version > 159.1.0) > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current > version > 52.0.0) > @rpath/libjava.dylib (compatibility version 1.0.0, current version > 1.0.0) > @rpath/libjvm.dylib (compatibility version 1.0.0, current version > 1.0.0) > > I build FreeType 2.4.10 like this : > > ./configure --prefix=$DROP_DIR/freetype CC=/usr/bin/clang > 'CFLAGS=-pipe -Os > -arch i386 -arch x86_64' \ > 'LDFLAGS=-arch i386 -arch x86_64' CXX=/usr/bin/clang++ > 'CXXFLAGS=-pipe -Os > -arch i386 -arch x86_64' \ > --disable-static --with-old-mac-fonts > > cp $DROP_DIR/freetype/lib/libfreetype.6.dylib > $DROP_DIR/freetype/lib/libfreetype.dylib > install_name_tool -id @rpath/libfreetype.dylib > $DROP_DIR/freetype/lib/libfreetype.dylib > > otool -L libfreetype.lib : > > build/macosx-universal/j2sdk-bundle/jdk1.7.0.jdk/Contents/Home/jre/lib/libfreetype.dylib: > @rpath/libfreetype.dylib (compatibility version 16.0.0, current > version > 16.0.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version > 1.2.5) > /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current > version > 1.0.5) > /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices > (compatibility version 1.0.0, current version 53.0.0) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices > (compatibility version 1.0.0, current version 41.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version > 159.1.0) > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > (compatibility version 150.0.0, current version 635.21.0) > > Patch done against latest jdk7u. > > Thanks to review > Can you please not cross-post to multiple mailing lists? This should be reviewed first by macosx-port-dev for OpenJDK8, then a second proposal made for backport to 7u. I'm receiving three copies of each post here. As to the patch, from the point of view of building on GNU/Linux, from reading the patch, it won't affect our builds so it's fine by me. We definitely don't want freetype being copied into trees on GNU/Linux. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From henri.gomez at gmail.com Tue Oct 16 23:00:50 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 17 Oct 2012 08:00:50 +0200 Subject: Request for review : FreeType embedded in OSX packages In-Reply-To: References: Message-ID: > Does the JDK still build properly if you installed X11 and do not have your own copy of libfreetype? I think that having the option of building with a non-system-provided libfreetype.dylib is a good idea, but the main nightly builds will continue to use X11 or XQuartz' library for the time being. On my Lion build system, X11 is still installed but I activate my own copy of FreeType (2.4.10) by defining ALT_FREETYPE_LIB_PATH and ALT_FREETYPE_INCLUDE in old build, and it's this version who is used for build and embedding > To that end, a few comments. In: > > +++ jdk/make/common/Defs.gmk 2012-10-16 09:36:11.000000000 +0200 > @@ -180,7 +180,7 @@ > ifdef ALT_FREETYPE_LIB_PATH > FREETYPE_LIB_PATH = $(ALT_FREETYPE_LIB_PATH) > ifeq ($(PLATFORM), macosx) > - USING_SYSTEM_FT_LIB=true > + USING_SYSTEM_FT_LIB=false > endif > -------- > > you could just get rid of the entire ifeq block, since USING_SYSTEM_FT_LIB was initialized to false. > > In jdk/make/sun/font/Makefile: > -------- > - FREETYPE_LIB = $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX).6 > + ifeq ($(PLATFORM), macosx) > + FREETYPE_LIB = $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX) > + OTHER_LDLIBS += -lfreetype > + else > + FREETYPE_LIB = $(LIB_LOCATION)/$(LIB_PREFIX)freetype.$(LIBRARY_SUFFIX).6 > + OTHER_LDLIBS += -L$(FREETYPE_LIB_PATH) -lfreetype > + endif > endif > - OTHER_LDLIBS += -L$(FREETYPE_LIB_PATH) -lfreetype > --------- When we set USING_SYSTEM_FT_LIB to false, provide FreeType lib (or dylib for OSX), will be copied and here I just set the correct name for freetypelib, ie libfreetype.dylib on OSX. I could eventually also be libfreetype.6.dylib but certainly not libfreetype.dylib.6 which is more Linux way to handle lib versions. > I don't think you want to remove '-L$(FREETYPE_LIB_PATH)' in the macosx case. If it was overridden by ALT_FREETYPE_LIB_PATH the build won't be able to find the pre-build libfreetype.dylib. And if you still want to use the system-provided libfreetype you have to give it the path to the X11 libraries. Are you sure ? It's not found inside build lib like -ljava for example which is not deployed on system of course. I used install_name_tool in copy block to set @rpath to have libfreetype set as expected. > You need to create a bug at describing what you want to change, and then attach a new patch. Mike's review plus one other will be enough to get it into JDK 8. JDK 7u will need two reviewers, since I think the Java2D team owns this part of the code. (I cc'd Phil Race). Nobody ever created such bug ? I remember Phil Race and Mike discussed about embedding FreeType in OSX build in May 2012. I'm unsure other code/patch reviews for JDK7, 8 or MacOSXPort also have a bugreport associated but may be I miss something. If a bug ticket is absolutely required, I'll fill one. BTW, my own packages in openjdk-osx-build already use this patch so there is no more urgency for me, I provided them here to have them included in official repos but I could live with my own set of patches as I do for other parts. From henri.gomez at gmail.com Tue Oct 16 23:03:16 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 17 Oct 2012 08:03:16 +0200 Subject: Request for review : FreeType embedded in OSX packages In-Reply-To: <237720890.1335164.1350431190515.JavaMail.root@redhat.com> References: <237720890.1335164.1350431190515.JavaMail.root@redhat.com> Message-ID: > Can you please not cross-post to multiple mailing lists? This should be reviewed first > by macosx-port-dev for OpenJDK8, then a second proposal made for backport to 7u. I'm > receiving three copies of each post here. Oups my bad, I'll be more carefull next time. > As to the patch, from the point of view of building on GNU/Linux, from reading the patch, it won't > affect our builds so it's fine by me. We definitely don't want freetype being copied into > trees on GNU/Linux. I agree. BTWl CentOS/RHEL 5 require FreeType to be embedded since these distros don't provide FT 2.4.x, it's the way I do it in obuildfactory for CentOS/RHEL 5. From henri.gomez at gmail.com Wed Oct 17 01:11:01 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 17 Oct 2012 10:11:01 +0200 Subject: Request for review : FreeType embedded in OSX packages In-Reply-To: References: Message-ID: > You need to create a bug at describing what you want to change, and then attach a new patch. Mike's review plus one other will be enough to get it into JDK 8. JDK 7u will need two reviewers, since I think the Java2D team owns this part of the code. (I cc'd Phil Race). Ticket created : #2361569 Link to patches provided inside From henri.gomez at gmail.com Wed Oct 17 07:45:13 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 17 Oct 2012 16:45:13 +0200 Subject: Oracle Java 7u9 and libfontmanager Message-ID: I just took a look into Oracle Java 7u9. otool report no dependencies on freetype. /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/jre/lib/libfontmanager.dylib: @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0) @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) How is it possible ? From philip.race at oracle.com Wed Oct 17 09:18:55 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Oct 2012 09:18:55 -0700 Subject: Request for review : FreeType embedded in OSX packages In-Reply-To: References: Message-ID: <507EDA6F.9090304@oracle.com> On 10/17/12 1:11 AM, Henri Gomez wrote: >> You need to create a bug at describing what you want to change, and then attach a new patch. Mike's review plus one other will be enough to get it into JDK 8. JDK 7u will need two reviewers, since I think the Java2D team owns this part of the code. (I cc'd Phil Race). > Ticket created : #2361569 > > Link to patches provided inside What number is that ? I think its just an incident. I will file a JIRA bug on this shortly .. but I had tried the patch yesterday and FWIW it doesn't seem to remove "build" dependency on the system libfreetype .. I don't think anything you did caused this because it would already fail for me in the sanity check at the beginning but a complete fix would address this too where it seems the ALT_ path is not making it through to tools/freetypecheck/Makefile dyld: Library not loaded: /usr/local/lib/libfreetype.6.dylib Referenced from: /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck Reason: image not found make[2]: *** [all] Trace/BPT trap: 5 .. .. ERROR: FreeType version 2.3.0 or higher is required. /bin/mkdir -p /openjdk8/2d/build/macosx-x86_64/btbins rm -f /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck Failed to build freetypecheck. Exiting because of the above error(s). ----- Also did you try this in the old and new build systems ? Finally, the way we build internally I guess our jprt and R/E builds of openjdk on OS X (if the latter were tried at all) should be made capable of using a custom freetype build. I think they can be ignorant of this change for now, but without creating a build and making them use it they will still spit out builds which rely on the system freetype -phil. From philip.race at oracle.com Wed Oct 17 09:27:51 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Oct 2012 09:27:51 -0700 Subject: [OpenJDK 2D-Dev] Request for review : FreeType embedded in OSX packages In-Reply-To: <507EDA6F.9090304@oracle.com> References: <507EDA6F.9090304@oracle.com> Message-ID: <507EDC87.5060505@oracle.com> PS .. I could be misremembering or misunderstanding but the other obstacle I ran into when I looked at this (ages ago) was that the freetype I built was expecting to be installed in a specific location. I didn't think it was enough to tell the JDK build to look for the freetype lib, it seemed that the freetype.dylib was fussy about where it was placed. Could you also check that your build works and really loads *your* version of the lib - try using a Postscript Type 1 font via Font.createFont(), that should trigger it. -phil. On 10/17/12 9:18 AM, Phil Race wrote: > On 10/17/12 1:11 AM, Henri Gomez wrote: >>> You need to create a bug at >>> describing what you want to change, and then attach a new patch. >>> Mike's review plus one other will be enough to get it into JDK 8. >>> JDK 7u will need two reviewers, since I think the Java2D team owns >>> this part of the code. (I cc'd Phil Race). >> Ticket created : #2361569 >> >> Link to patches provided inside > > What number is that ? I think its just an incident. I will file a JIRA > bug > on this shortly .. but I had tried the patch yesterday and FWIW it > doesn't > seem to remove "build" dependency on the system libfreetype .. > I don't think anything you did caused this because it would already fail > for me in the sanity check at the beginning but a complete fix would > address this too where it seems the ALT_ path is not making it through > to tools/freetypecheck/Makefile > > dyld: Library not loaded: /usr/local/lib/libfreetype.6.dylib > Referenced from: > /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck > Reason: image not found > make[2]: *** [all] Trace/BPT trap: 5 > .. > .. > ERROR: FreeType version 2.3.0 or higher is required. > /bin/mkdir -p /openjdk8/2d/build/macosx-x86_64/btbins > rm -f /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck > /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck > Failed to build freetypecheck. > > Exiting because of the above error(s). > ----- > > Also did you try this in the old and new build systems ? > > Finally, the way we build internally I guess our jprt and R/E builds of > openjdk on OS X (if the latter were tried at all) should be made capable > of using a custom freetype build. I think they can be ignorant of > this change for now, but without creating a build and making them use > it they will still spit out builds which rely on the system freetype > > -phil. > > From philip.race at oracle.com Wed Oct 17 09:28:33 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Oct 2012 09:28:33 -0700 Subject: Oracle Java 7u9 and libfontmanager In-Reply-To: References: Message-ID: <507EDCB1.30503@oracle.com> Because we use our own closed font library : libt2k. -phil. On 10/17/12 7:45 AM, Henri Gomez wrote: > I just took a look into Oracle Java 7u9. > > otool report no dependencies on freetype. > > /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/jre/lib/libfontmanager.dylib: > @rpath/libfontmanager.dylib (compatibility version 1.0.0, current > version 1.0.0) > @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 159.1.0) > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current > version 52.0.0) > @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) > @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) > > How is it possible ? From jcpalmer at rochester.rr.com Wed Oct 17 10:10:27 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Wed, 17 Oct 2012 13:10:27 -0400 Subject: Has the bug database moved? Message-ID: <0FCF6165-A5E7-413F-81D7-AA805A850D6F@rochester.rr.com> I submitted a bug Friday to the old bugs.sun.com. I knew this was going away, no great loss since it was showing its age, but never saw anything official. Saw this url mentioned in the apple DL that pointed to java.net/jjira. From there I click on links and see bugs in a completely different format. The question is where should bugs be submitted? If it is not bugs.sun.com, a redirection might be good. Thanks, Jeff Palmer From henri.gomez at gmail.com Wed Oct 17 10:30:22 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 17 Oct 2012 19:30:22 +0200 Subject: Request for review : FreeType embedded in OSX packages In-Reply-To: <507EDA6F.9090304@oracle.com> References: <507EDA6F.9090304@oracle.com> Message-ID: <23CFCEDD-6939-4A58-A9DF-6CA59857C1CF@gmail.com> Only tried it with old build system. Le 17 oct. 2012 ? 18:18, Phil Race a ?crit : > On 10/17/12 1:11 AM, Henri Gomez wrote: >>> You need to create a bug at describing what you want to change, and then attach a new patch. Mike's review plus one other will be enough to get it into JDK 8. JDK 7u will need two reviewers, since I think the Java2D team owns this part of the code. (I cc'd Phil Race). >> Ticket created : #2361569 >> >> Link to patches provided inside > > What number is that ? I think its just an incident. I will file a JIRA bug > on this shortly .. but I had tried the patch yesterday and FWIW it doesn't > seem to remove "build" dependency on the system libfreetype .. > I don't think anything you did caused this because it would already fail > for me in the sanity check at the beginning but a complete fix would > address this too where it seems the ALT_ path is not making it through > to tools/freetypecheck/Makefile > > dyld: Library not loaded: /usr/local/lib/libfreetype.6.dylib > Referenced from: /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck > Reason: image not found > make[2]: *** [all] Trace/BPT trap: 5 > .. > .. > ERROR: FreeType version 2.3.0 or higher is required. > /bin/mkdir -p /openjdk8/2d/build/macosx-x86_64/btbins > rm -f /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck > /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck > Failed to build freetypecheck. > > Exiting because of the above error(s). > ----- > > Also did you try this in the old and new build systems ? > > Finally, the way we build internally I guess our jprt and R/E builds of > openjdk on OS X (if the latter were tried at all) should be made capable > of using a custom freetype build. I think they can be ignorant of > this change for now, but without creating a build and making them use > it they will still spit out builds which rely on the system freetype > > -phil. > > From henri.gomez at gmail.com Wed Oct 17 10:31:07 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 17 Oct 2012 19:31:07 +0200 Subject: [OpenJDK 2D-Dev] Request for review : FreeType embedded in OSX packages In-Reply-To: <507EDC87.5060505@oracle.com> References: <507EDA6F.9090304@oracle.com> <507EDC87.5060505@oracle.com> Message-ID: Any sample java code available ? Le 17 oct. 2012 ? 18:27, Phil Race a ?crit : > PS .. I could be misremembering or misunderstanding but the other > obstacle I ran into when I looked at this (ages ago) was that the freetype > I built was expecting to be installed in a specific location. I didn't > think it was enough to tell the JDK build to look for the freetype lib, > it seemed that the freetype.dylib was fussy about where it was placed. > Could you also check that your build works and really loads *your* > version of the lib - try using a Postscript Type 1 font via Font.createFont(), > that should trigger it. > > -phil. > > On 10/17/12 9:18 AM, Phil Race wrote: >> On 10/17/12 1:11 AM, Henri Gomez wrote: >>>> You need to create a bug at describing what you want to change, and then attach a new patch. Mike's review plus one other will be enough to get it into JDK 8. JDK 7u will need two reviewers, since I think the Java2D team owns this part of the code. (I cc'd Phil Race). >>> Ticket created : #2361569 >>> >>> Link to patches provided inside >> >> What number is that ? I think its just an incident. I will file a JIRA bug >> on this shortly .. but I had tried the patch yesterday and FWIW it doesn't >> seem to remove "build" dependency on the system libfreetype .. >> I don't think anything you did caused this because it would already fail >> for me in the sanity check at the beginning but a complete fix would >> address this too where it seems the ALT_ path is not making it through >> to tools/freetypecheck/Makefile >> >> dyld: Library not loaded: /usr/local/lib/libfreetype.6.dylib >> Referenced from: /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck >> Reason: image not found >> make[2]: *** [all] Trace/BPT trap: 5 >> .. >> .. >> ERROR: FreeType version 2.3.0 or higher is required. >> /bin/mkdir -p /openjdk8/2d/build/macosx-x86_64/btbins >> rm -f /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck >> /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck >> Failed to build freetypecheck. >> >> Exiting because of the above error(s). >> ----- >> >> Also did you try this in the old and new build systems ? >> >> Finally, the way we build internally I guess our jprt and R/E builds of >> openjdk on OS X (if the latter were tried at all) should be made capable >> of using a custom freetype build. I think they can be ignorant of >> this change for now, but without creating a build and making them use >> it they will still spit out builds which rely on the system freetype >> >> -phil. > From henri.gomez at gmail.com Wed Oct 17 10:31:27 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 17 Oct 2012 19:31:27 +0200 Subject: Oracle Java 7u9 and libfontmanager In-Reply-To: <507EDCB1.30503@oracle.com> References: <507EDCB1.30503@oracle.com> Message-ID: <078CDE9A-38E4-4A44-A018-3897C6396B0E@gmail.com> Ah ok. Thanks Le 17 oct. 2012 ? 18:28, Phil Race a ?crit : > Because we use our own closed font library : libt2k. > > -phil. > > On 10/17/12 7:45 AM, Henri Gomez wrote: >> I just took a look into Oracle Java 7u9. >> >> otool report no dependencies on freetype. >> >> /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/jre/lib/libfontmanager.dylib: >> @rpath/libfontmanager.dylib (compatibility version 1.0.0, current >> version 1.0.0) >> @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >> version 159.1.0) >> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current >> version 52.0.0) >> @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0) >> @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0) >> >> How is it possible ? > From jcpalmer at rochester.rr.com Wed Oct 17 10:33:11 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Wed, 17 Oct 2012 13:33:11 -0400 Subject: Has the bug database moved? In-Reply-To: <0FCF6165-A5E7-413F-81D7-AA805A850D6F@rochester.rr.com> References: <0FCF6165-A5E7-413F-81D7-AA805A850D6F@rochester.rr.com> Message-ID: I read the next batch of messages from the apple DL (getting them usually at 3PM EST in a combined message), and see the jjira was just temporary. Figures I only spot it after it is no longer in use. I guess I am ok then. Thanks, Jeff Palmer On Oct 17, 2012, at 1:10 PM, Jeff Palmer wrote: > I submitted a bug Friday to the old bugs.sun.com. I knew this was going away, no great loss since it was showing its age, but never saw anything official. Saw this url mentioned in the apple DL that pointed to java.net/jjira. From there I click on links and see bugs in a completely different format. > > The question is where should bugs be submitted? If it is not bugs.sun.com, a redirection might be good. > > Thanks, > > Jeff Palmer From martijnverburg at gmail.com Wed Oct 17 10:35:42 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 17 Oct 2012 18:35:42 +0100 Subject: Has the bug database moved? In-Reply-To: <0FCF6165-A5E7-413F-81D7-AA805A850D6F@rochester.rr.com> References: <0FCF6165-A5E7-413F-81D7-AA805A850D6F@rochester.rr.com> Message-ID: It's still the same URL for now. Cheers, Martijn On Wednesday, 17 October 2012, Jeff Palmer wrote: > I submitted a bug Friday to the old bugs.sun.com. I knew this was going > away, no great loss since it was showing its age, but never saw anything > official. Saw this url mentioned in the apple DL that pointed to > java.net/jjira. From there I click on links and see bugs in a completely > different format. > > The question is where should bugs be submitted? If it is not bugs.sun.com, > a redirection might be good. > > Thanks, > > Jeff Palmer From philip.race at oracle.com Wed Oct 17 10:40:43 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Oct 2012 10:40:43 -0700 Subject: [OpenJDK 2D-Dev] Request for review : FreeType embedded in OSX packages In-Reply-To: References: <507EDA6F.9090304@oracle.com> <507EDC87.5060505@oracle.com> Message-ID: <507EED9B.8040706@oracle.com> I filed : (JDK-8001065) [macosx] OpenJDK on OS X should use bundled freetype, not one from the system Sample code is just import java.awt.Font; public class CreateFont { public static void main(String args[]) throws Exception { Font f = Font.createFont(Font|.TYPE1_FONT, new java.io.File("mytype1font.pfa")); } } You can get a font from ||| any of a gazillion places .. there'll be plenty on almost any Linux you have handy. -phil. On 10/17/2012 10:31 AM, Henri Gomez wrote: > Any sample java code available ? > > Le 17 oct. 2012 ? 18:27, Phil Race a ?crit : > >> PS .. I could be misremembering or misunderstanding but the other >> obstacle I ran into when I looked at this (ages ago) was that the freetype >> I built was expecting to be installed in a specific location. I didn't >> think it was enough to tell the JDK build to look for the freetype lib, >> it seemed that the freetype.dylib was fussy about where it was placed. >> Could you also check that your build works and really loads *your* >> version of the lib - try using a Postscript Type 1 font via Font.createFont(), >> that should trigger it. >> >> -phil. >> >> On 10/17/12 9:18 AM, Phil Race wrote: >>> On 10/17/12 1:11 AM, Henri Gomez wrote: >>>>> You need to create a bug at describing what you want to change, and then attach a new patch. Mike's review plus one other will be enough to get it into JDK 8. JDK 7u will need two reviewers, since I think the Java2D team owns this part of the code. (I cc'd Phil Race). >>>> Ticket created : #2361569 >>>> >>>> Link to patches provided inside >>> What number is that ? I think its just an incident. I will file a JIRA bug >>> on this shortly .. but I had tried the patch yesterday and FWIW it doesn't >>> seem to remove "build" dependency on the system libfreetype .. >>> I don't think anything you did caused this because it would already fail >>> for me in the sanity check at the beginning but a complete fix would >>> address this too where it seems the ALT_ path is not making it through >>> to tools/freetypecheck/Makefile >>> >>> dyld: Library not loaded: /usr/local/lib/libfreetype.6.dylib >>> Referenced from: /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck >>> Reason: image not found >>> make[2]: *** [all] Trace/BPT trap: 5 >>> .. >>> .. >>> ERROR: FreeType version 2.3.0 or higher is required. >>> /bin/mkdir -p /openjdk8/2d/build/macosx-x86_64/btbins >>> rm -f /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck >>> /openjdk8/2d/build/macosx-x86_64/btbins/freetype_versioncheck >>> Failed to build freetypecheck. >>> >>> Exiting because of the above error(s). >>> ----- >>> >>> Also did you try this in the old and new build systems ? >>> >>> Finally, the way we build internally I guess our jprt and R/E builds of >>> openjdk on OS X (if the latter were tried at all) should be made capable >>> of using a custom freetype build. I think they can be ignorant of >>> this change for now, but without creating a build and making them use >>> it they will still spit out builds which rely on the system freetype >>> >>> -phil. From henri.gomez at gmail.com Wed Oct 17 11:27:04 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 17 Oct 2012 20:27:04 +0200 Subject: [OpenJDK 2D-Dev] Request for review : FreeType embedded in OSX packages In-Reply-To: <507EED9B.8040706@oracle.com> References: <507EDA6F.9090304@oracle.com> <507EDC87.5060505@oracle.com> <507EED9B.8040706@oracle.com> Message-ID: 2012/10/17 Phil Race : > I filed : (JDK-8001065) [macosx] OpenJDK on OS X should use bundled > freetype, not one from the system > > Sample code is just > > import java.awt.Font; > public class CreateFont { > > public static void main(String args[]) throws Exception { > Font f = Font.createFont(Font|.TYPE1_FONT, new > java.io.File("mytype1font.pfa")); > } > } > > > You can get a font from ||| > any > of a gazillion places .. there'll be plenty > on almost any Linux you have handy. I tried with a .pfb file, from http://www.ctan.org/tex-archive/fonts/ and its works with Java 7u9, OpenJDK 7 and OpenJDK 8. From paul_t100 at fastmail.fm Wed Oct 17 11:32:34 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Wed, 17 Oct 2012 19:32:34 +0100 Subject: MacPort JIRA Tracker no longer active Message-ID: <507EF9C2.5010905@fastmail.fm> Hi Now that OSX bugs can be applied to bugs database shouldnt all the issues the macport JIRA system be closed, its confusing having both systems. Paul From henri.gomez at gmail.com Wed Oct 17 11:32:41 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 17 Oct 2012 20:32:41 +0200 Subject: [OpenJDK 2D-Dev] Request for review : FreeType embedded in OSX packages In-Reply-To: References: <507EDA6F.9090304@oracle.com> <507EDC87.5060505@oracle.com> <507EED9B.8040706@oracle.com> Message-ID: >> You can get a font from ||| >> any >> of a gazillion places .. there'll be plenty >> on almost any Linux you have handy. > > I tried with a .pfb file, from http://www.ctan.org/tex-archive/fonts/ > and its works with Java 7u9, OpenJDK 7 and OpenJDK 8. I tried with .pfa file, it works fine also :) From philip.race at oracle.com Wed Oct 17 11:42:36 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Oct 2012 11:42:36 -0700 Subject: Has the bug database moved? In-Reply-To: References: <0FCF6165-A5E7-413F-81D7-AA805A850D6F@rochester.rr.com> Message-ID: <507EFC1C.9040606@oracle.com> Let me try and clarify a few things :- The Java group at Oracle has just switched from our old Sun-originated internal bug tracking system (bugster) to a new *internal* instance of JIRA (jbs) You can't get access to that JIRA from outside Oracle - yet ! bugs.sun.com still exists and files what we call "incidents" as it has done for maybe 10 years now .. into yet-another system - the incident tracking system. The number you get is therefor a "incident manager" ID. Not the final bug id. That system had a tool which had "click one button" capability to forward verified incidents into the real bugtracking system - bugster when you would get the real bug ID. But for the last 2 or 3 years, for many "subcomponents" (eg classes_2d) it was even better - your incident went directly into bugster, got a real bugID right off the bat when you submitted. Now however, and for a little while to come, Incident Manager has no way to forward incidents into the new JIRA It has become a "manual" process - involving a person doing copy/paste. This will get fixed but right now I think it means that your incident is less likely to get prompt attention. If you need to file a JDK bug as an OpenJDK developer, particularly if you need a bug ID for a fix, your best bet is to just ask someone at Oracle. This *will* get better, but we had to switch to the new JIRA before bugster was switched off. Finally, the java.net/jira is not the right JIRA except for the specific openjdk projects which are using it. And the OS X port used it at first, but now its moved into OpenJDK, bugs there (java.net/jira) are not tracked. Everything that needed to be, was moved in to the main bug database many months ago .. -phil. On 10/17/2012 10:35 AM, Martijn Verburg wrote: > It's still the same URL for now. > > Cheers, > Martijn > > On Wednesday, 17 October 2012, Jeff Palmer wrote: > >> I submitted a bug Friday to the old bugs.sun.com. I knew this was going >> away, no great loss since it was showing its age, but never saw anything >> official. Saw this url mentioned in the apple DL that pointed to >> java.net/jjira. From there I click on links and see bugs in a completely >> different format. >> >> The question is where should bugs be submitted? If it is not bugs.sun.com, >> a redirection might be good. >> >> Thanks, >> >> Jeff Palmer From philip.race at oracle.com Wed Oct 17 11:45:45 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Oct 2012 11:45:45 -0700 Subject: MacPort JIRA Tracker no longer active In-Reply-To: <507EF9C2.5010905@fastmail.fm> References: <507EF9C2.5010905@fastmail.fm> Message-ID: <507EFCD9.4090207@oracle.com> More to the point, it should be read-only, if it isn't already. I am not sure who (Artem?) can do that. -phil. On 10/17/2012 11:32 AM, Paul Taylor wrote: > Hi > > Now that OSX bugs can be applied to bugs database shouldnt all the > issues the macport JIRA system be closed, its confusing having both > systems. > > Paul From dkocher at sudo.ch Wed Oct 17 12:29:32 2012 From: dkocher at sudo.ch (David Kocher) Date: Wed, 17 Oct 2012 21:29:32 +0200 Subject: Has the bug database moved? In-Reply-To: <507EFC1C.9040606@oracle.com> References: <0FCF6165-A5E7-413F-81D7-AA805A850D6F@rochester.rr.com> <507EFC1C.9040606@oracle.com> Message-ID: <7D123FA6-55E1-47FC-87C8-4ACF1F5A09EC@sudo.ch> But as I mentioned before on this list, the OS X port was left open with no updates to the existing issues users have filed. The open issues are in a unknown state with no feedback from Oracle developers. This is quite frustrating for users reporting issues and trying to help track down issues. You should at least close these issues with a reference to the new bug on bugs.sun.com. Without this it is nearly impossible to find the issues in bugs.sun.com with its humilitating user interface. -- David On 17.10.2012, at 20:42, Phil Race wrote: > Let me try and clarify a few things :- > > The Java group at Oracle has just switched from our old Sun-originated > internal bug tracking system (bugster) to a new *internal* instance of JIRA (jbs) > You can't get access to that JIRA from outside Oracle - yet ! > > bugs.sun.com still exists and files what we call "incidents" > as it has done for maybe 10 years now .. into yet-another > system - the incident tracking system. The number you get is therefor > a "incident manager" ID. Not the final bug id. > > That system had a tool which had "click one button" capability > to forward verified incidents into the real bugtracking system - bugster > when you would get the real bug ID. > > But for the last 2 or 3 years, for many "subcomponents" (eg classes_2d) > it was even better - your incident went directly into bugster, got > a real bugID right off the bat when you submitted. > > Now however, and for a little while to come, Incident Manager > has no way to forward incidents into the new JIRA > > It has become a "manual" process - involving a person doing copy/paste. > This will get fixed but right now I think it means that your incident is > less likely to get prompt attention. > > If you need to file a JDK bug as an OpenJDK developer, particularly > if you need a bug ID for a fix, your best bet is to just ask someone at Oracle. > > This *will* get better, but we had to switch to the new JIRA before > bugster was switched off. > > Finally, the java.net/jira is not the right JIRA except for the specific > openjdk projects which are using it. And the OS X port used it at first, > but now its moved into OpenJDK, bugs there (java.net/jira) are not tracked. > Everything that needed to be, was moved in to the main bug database > many months ago .. > > -phil. > > > > > On 10/17/2012 10:35 AM, Martijn Verburg wrote: >> It's still the same URL for now. >> >> Cheers, >> Martijn >> >> On Wednesday, 17 October 2012, Jeff Palmer wrote: >> >>> I submitted a bug Friday to the old bugs.sun.com. I knew this was going >>> away, no great loss since it was showing its age, but never saw anything >>> official. Saw this url mentioned in the apple DL that pointed to >>> java.net/jjira. From there I click on links and see bugs in a completely >>> different format. >>> >>> The question is where should bugs be submitted? If it is not bugs.sun.com, >>> a redirection might be good. >>> >>> Thanks, >>> >>> Jeff Palmer > From philip.race at oracle.com Wed Oct 17 13:00:55 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Oct 2012 13:00:55 -0700 Subject: Has the bug database moved? In-Reply-To: <7D123FA6-55E1-47FC-87C8-4ACF1F5A09EC@sudo.ch> References: <0FCF6165-A5E7-413F-81D7-AA805A850D6F@rochester.rr.com> <507EFC1C.9040606@oracle.com> <7D123FA6-55E1-47FC-87C8-4ACF1F5A09EC@sudo.ch> Message-ID: <507F0E77.1070203@oracle.com> On 10/17/2012 12:29 PM, David Kocher wrote: > But as I mentioned before on this list, the OS X port was left open with no updates to the existing issues users have filed. The open issues are in a unknown state with no feedback from Oracle developers. This is quite frustrating for users reporting issues and trying to help track down issues. I don't disagree, but the action of doing that is not my in my control. I don't even know for sure who owns it. All I can say is that the wiki http://openjdk.java.net/projects/macosx-port/ refers to it as "Old Mac OS X Port JIRA " and refer you to the email sent to this list in Dec. 2011 that .. "... we will freeze the Mac OS X Port JIRA instance on java.net and continue the bug tracking by regular JDK means (i.e., Bugster)." http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-December/001775.html So it should have been made read-only shortly after that. -phil. From alexandr.scherbatiy at oracle.com Thu Oct 18 04:31:55 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 18 Oct 2012 15:31:55 +0400 Subject: [8] Review request for 7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again Message-ID: <507FE8AB.2090403@oracle.com> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175707 webrev: http://cr.openjdk.java.net/~alexsch/7175707/webrev.00 The nativeGetNSWindowDisplayID_AppKitThread can be invoked both from the AppKitThread and not from the AppKitThread. The fix invokes the GetNSWindowDisplayID_AppKitThread method on the AppKitThread in case if we are no on the AppKitThread. Thanks, Alexandr. From alexandr.scherbatiy at oracle.com Thu Oct 18 05:57:40 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 18 Oct 2012 16:57:40 +0400 Subject: [8] Review request for 7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again In-Reply-To: <507FEE8D.9020807@oracle.com> References: <507FE8AB.2090403@oracle.com> <507FEE8D.9020807@oracle.com> Message-ID: <507FFCC4.6040901@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7175707/webrev.01/ The GetNSWindowDisplayID_AppKitThread method is renamed to getNSWindowDisplayID_AppKitThread. Thanks, Alexandr. On 10/18/2012 3:57 PM, Sergey Bylokhov wrote: > Fix looks fine. > Only one minor issue: getNSWindowDisplayID is better than > GetNSWindowDisplayID? > > 18.10.2012 15:31, Alexander Scherbatiy wrote: >> >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175707 >> webrev: http://cr.openjdk.java.net/~alexsch/7175707/webrev.00 >> >> The nativeGetNSWindowDisplayID_AppKitThread can be invoked both from >> the AppKitThread and not from the AppKitThread. >> The fix invokes the GetNSWindowDisplayID_AppKitThread method on the >> AppKitThread in case if we are no on the AppKitThread. >> >> Thanks, >> Alexandr. >> > > From anthony.petrov at oracle.com Thu Oct 18 06:04:17 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 18 Oct 2012 17:04:17 +0400 Subject: [8] Review request for 7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again In-Reply-To: <507FFCC4.6040901@oracle.com> References: <507FE8AB.2090403@oracle.com> <507FEE8D.9020807@oracle.com> <507FFCC4.6040901@oracle.com> Message-ID: <507FFE51.8020003@oracle.com> Looks fine to me. -- best regards, Anthony On 10/18/2012 4:57 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7175707/webrev.01/ > > The GetNSWindowDisplayID_AppKitThread method is renamed to > getNSWindowDisplayID_AppKitThread. > > Thanks, > Alexandr. > > On 10/18/2012 3:57 PM, Sergey Bylokhov wrote: >> Fix looks fine. >> Only one minor issue: getNSWindowDisplayID is better than >> GetNSWindowDisplayID? >> >> 18.10.2012 15:31, Alexander Scherbatiy wrote: >>> >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175707 >>> webrev: http://cr.openjdk.java.net/~alexsch/7175707/webrev.00 >>> >>> The nativeGetNSWindowDisplayID_AppKitThread can be invoked both from >>> the AppKitThread and not from the AppKitThread. >>> The fix invokes the GetNSWindowDisplayID_AppKitThread method on the >>> AppKitThread in case if we are no on the AppKitThread. >>> >>> Thanks, >>> Alexandr. >>> >> >> > From Sergey.Bylokhov at oracle.com Thu Oct 18 06:11:00 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 18 Oct 2012 17:11:00 +0400 Subject: [8] Review request for 7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again In-Reply-To: <507FFCC4.6040901@oracle.com> References: <507FE8AB.2090403@oracle.com> <507FEE8D.9020807@oracle.com> <507FFCC4.6040901@oracle.com> Message-ID: <507FFFE4.1010304@oracle.com> Hi, Alexander. Looks good. 18.10.2012 16:57, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7175707/webrev.01/ > > The GetNSWindowDisplayID_AppKitThread method is renamed to > getNSWindowDisplayID_AppKitThread. > > Thanks, > Alexandr. > > On 10/18/2012 3:57 PM, Sergey Bylokhov wrote: >> Fix looks fine. >> Only one minor issue: getNSWindowDisplayID is better than >> GetNSWindowDisplayID? >> >> 18.10.2012 15:31, Alexander Scherbatiy wrote: >>> >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175707 >>> webrev: http://cr.openjdk.java.net/~alexsch/7175707/webrev.00 >>> >>> The nativeGetNSWindowDisplayID_AppKitThread can be invoked both from >>> the AppKitThread and not from the AppKitThread. >>> The fix invokes the GetNSWindowDisplayID_AppKitThread method on the >>> AppKitThread in case if we are no on the AppKitThread. >>> >>> Thanks, >>> Alexandr. >>> >> >> > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Oct 18 07:37:39 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 18 Oct 2012 18:37:39 +0400 Subject: [7u12] Review request for 7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again Message-ID: <50801433.7080208@oracle.com> This is a direct backport of the fix from the JDK 8 to JDK 7u12 bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175707 webrev: http://cr.openjdk.java.net/~alexsch/7175707/webrev.01 The nativeGetNSWindowDisplayID_AppKitThread can be invoked both from the AppKitThread and not from the AppKitThread. The fix invokes the getNSWindowDisplayID_AppKitThread method on the AppKitThread in case if we are no on the AppKitThread. The GetNSWindowDisplayID_AppKitThread method is renamed to getNSWindowDisplayID_AppKitThread. Thanks, Alexandr. From anthony.petrov at oracle.com Thu Oct 18 07:41:03 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 18 Oct 2012 18:41:03 +0400 Subject: [7u12] Review request for 7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again In-Reply-To: <50801433.7080208@oracle.com> References: <50801433.7080208@oracle.com> Message-ID: <508014FF.8050409@oracle.com> Still looks fine. -- best regards, Anthony On 10/18/2012 6:37 PM, Alexander Scherbatiy wrote: > > This is a direct backport of the fix from the JDK 8 to JDK 7u12 > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175707 > webrev: http://cr.openjdk.java.net/~alexsch/7175707/webrev.01 > > The nativeGetNSWindowDisplayID_AppKitThread can be invoked both from the > AppKitThread and not from the AppKitThread. > The fix invokes the getNSWindowDisplayID_AppKitThread method on the > AppKitThread in case if we are no on the AppKitThread. > > The GetNSWindowDisplayID_AppKitThread method is renamed to > getNSWindowDisplayID_AppKitThread. > > Thanks, > Alexandr. > From Sergey.Bylokhov at oracle.com Thu Oct 18 07:42:12 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 18 Oct 2012 18:42:12 +0400 Subject: [7u12] Review request for 7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again In-Reply-To: <50801433.7080208@oracle.com> References: <50801433.7080208@oracle.com> Message-ID: <50801544.7070402@oracle.com> Fix looks good. 18.10.2012 18:37, Alexander Scherbatiy wrote: > > This is a direct backport of the fix from the JDK 8 to JDK 7u12 > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7175707 > webrev: http://cr.openjdk.java.net/~alexsch/7175707/webrev.01 > > The nativeGetNSWindowDisplayID_AppKitThread can be invoked both from > the AppKitThread and not from the AppKitThread. > The fix invokes the getNSWindowDisplayID_AppKitThread method on the > AppKitThread in case if we are no on the AppKitThread. > > The GetNSWindowDisplayID_AppKitThread method is renamed to > getNSWindowDisplayID_AppKitThread. > > Thanks, > Alexandr. > -- Best regards, Sergey. From paul_t100 at fastmail.fm Fri Oct 19 04:50:38 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Fri, 19 Oct 2012 12:50:38 +0100 Subject: File.exists() does not work on mac for non-English characters on Java 7 on Mac In-Reply-To: References: <9CF0158F-57C9-4772-840D-721BDCB393EA@sidelinesports.com> <50746049.1080203@oracle.com> <1D9514D101F84ED3A7B00952B931D1CB@hagi> <507537A2.9070103@oracle.com> <8A3A944F-4DF2-490C-BD01-4AAAD3F19083@sudo.ch> <50755FD0.1040608@oracle.com> <5076B717.4070008@oracle.com> Message-ID: <50813E8E.9090701@fastmail.fm> On 16/10/2012 16:33, David Kocher wrote: > On 11.10.2012, at 14:09, Alan Bateman wrote: > >> On 11/10/2012 13:06, ?orvaldur Bl?ndal wrote: >>> @Alan I registered 2356502 on bugs.sun.com that has a link to the JIRA-case. >> David Kocher reports that the issue that he was seeing is resolved in jdk8 (recent builds). Have you tried jdk8? >> >> -Alan > > The question remains when this will be backported to JDK 7. > > -- David I think I'm seeing the same problem I have a file containing within its name the following char ? file.exists() fails for this file I'm using with "1.7.0_10-ea", is this going to be fixed soon in Java 7 , or is there a workaround I can apply to my bundled application to resolve this ? Paul From jcpalmer at rochester.rr.com Fri Oct 19 16:01:32 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Fri, 19 Oct 2012 19:01:32 -0400 Subject: Inability to download JAWS apps after 7u9 Message-ID: I reported this to the forum on some else's thread, but I am sure more people read this. Can anyone reproduce this? Run a previously downloaded JWS app after upgrading to 7u9. Mine still worked. Later, I updated the jar of one app on the server, and now that one no longer runs, but others still do. That can also be simulated by just running one you do not have. Here is sample app from the summer I dug up and brought back to life. It does not do much, but that is not the point. http://www.whatifsquared.com/retina-scraper.jnlp I cleared the cache leaving the one that still worked intact. A download occurs when run from safari, but then the process abruptly ends. Subsequent runs from cache viewer do not do the download again, but same result. Oddly, in the cache viewer, it shows the apps with the date column blank, except for the one still working. Again, can anyone duplicate the result using the sample app? I verified the sample just worked from Windows. FYI, I have not yet run the thing from Apple that is causing problems with java 6 apps. I also restarted the machine. Thanks Jeff Palmer From nam.t.nguyen at oracle.com Sun Oct 21 18:13:09 2012 From: nam.t.nguyen at oracle.com (Nam Nguyen) Date: Sun, 21 Oct 2012 18:13:09 -0700 (PDT) Subject: Inability to download JAWS apps after 7u9 Message-ID: I ran 7u9 javaws http://www.whatifsquared.com/retina-scraper.jnlp fine, fresh or from cache. Maybe you could turn on all tracing to help debug. See: http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/plugin.html#gcexdfmacosx-port-dev From heinz at javaspecialists.eu Sun Oct 21 23:42:30 2012 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Mon, 22 Oct 2012 08:42:30 +0200 Subject: WatchService In-Reply-To: <507FFE51.8020003@oracle.com> References: <507FE8AB.2090403@oracle.com> <507FEE8D.9020807@oracle.com> <507FFCC4.6040901@oracle.com> <507FFE51.8020003@oracle.com> Message-ID: <5084EAD6.3010800@javaspecialists.eu> Hi all, are there any plans to implement a native WatchService implementation for the Mac OS X file system? I just hope that the Mac OS X version of OpenJDK will eventually have the system specific extensions built in. For example, here is a file watcher class: import java.io.*; import java.nio.file.*; public class FileWatcher { public static void main(String[] args) throws IOException, InterruptedException { WatchService watcher = FileSystems.getDefault().newWatchService(); Path opt = FileSystems.getDefault().getPath("."); WatchKey key = opt.register(watcher, StandardWatchEventKinds.ENTRY_CREATE, StandardWatchEventKinds.ENTRY_DELETE, StandardWatchEventKinds.ENTRY_MODIFY); while (true) { key = watcher.take(); for (WatchEvent ev : key.pollEvents()) { System.out.println(ev.context()); System.out.println(ev.count()); } key.reset(); } } } Works brilliantly on Windows and Linux, but on Mac, it creates an unnamed thread that polls the directory every 10 seconds! "Thread-0" daemon prio=5 tid=0x00007ff7728cb000 nid=0x5203 waiting on condition [0x000000016532d000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000001449c3e50> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 75 595 262 Skype: kabutz From heinz at javaspecialists.eu Sun Oct 21 23:45:02 2012 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Mon, 22 Oct 2012 08:45:02 +0200 Subject: 32-bit JVM In-Reply-To: <5084EAD6.3010800@javaspecialists.eu> References: <507FE8AB.2090403@oracle.com> <507FEE8D.9020807@oracle.com> <507FFCC4.6040901@oracle.com> <507FFE51.8020003@oracle.com> <5084EAD6.3010800@javaspecialists.eu> Message-ID: <5084EB6E.4080309@javaspecialists.eu> A few months ago, we had a discussion about providing a JDK 7 for the Mac that can also operate in 32-bit mode. Someone enabled it and it then got disabled again, because it apparently broke something. Is there any chance to enable it again? Being able to operate in 32-bit and also -client mode is quite important in order to be able to test concurrency code using different JVMs. I still have the JDK that we built with this enabled and it works fine, but ideally I would like this to be supported by the latest JDK 1.7. Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 75 595 262 Skype: kabutz From henri.gomez at gmail.com Mon Oct 22 01:01:50 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 22 Oct 2012 10:01:50 +0200 Subject: 32-bit JVM In-Reply-To: <5084EB6E.4080309@javaspecialists.eu> References: <507FE8AB.2090403@oracle.com> <507FEE8D.9020807@oracle.com> <507FFCC4.6040901@oracle.com> <507FFE51.8020003@oracle.com> <5084EAD6.3010800@javaspecialists.eu> <5084EB6E.4080309@javaspecialists.eu> Message-ID: There will be no 32bits version of OpenJDK for OSX. It was discussed many time on this mailing list. I provided patches to restore universal build (32/64bits) and raised problems I encountered while using such 32bits non official JVM but nobody was interested to investigate. Java 7 and more on OSX will be 64bits only. 2012/10/22 Dr Heinz M. Kabutz : > A few months ago, we had a discussion about providing a JDK 7 for the Mac > that can also operate in 32-bit mode. Someone enabled it and it then got > disabled again, because it apparently broke something. > > Is there any chance to enable it again? Being able to operate in 32-bit and > also -client mode is quite important in order to be able to test concurrency > code using different JVMs. I still have the JDK that we built with this > enabled and it works fine, but ideally I would like this to be supported by > the latest JDK 1.7. > > Regards > > Heinz > -- > Dr Heinz M. Kabutz (PhD CompSci) > Author of "The Java(tm) Specialists' Newsletter" > Sun Java Champion > IEEE Certified Software Development Professional > http://www.javaspecialists.eu > Tel: +30 69 75 595 262 > Skype: kabutz > From Alan.Bateman at oracle.com Mon Oct 22 01:12:05 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Oct 2012 09:12:05 +0100 Subject: WatchService In-Reply-To: <5084EAD6.3010800@javaspecialists.eu> References: <507FE8AB.2090403@oracle.com> <507FEE8D.9020807@oracle.com> <507FFCC4.6040901@oracle.com> <507FFE51.8020003@oracle.com> <5084EAD6.3010800@javaspecialists.eu> Message-ID: <5084FFD5.6060904@oracle.com> On 22/10/2012 07:42, Dr Heinz M. Kabutz wrote: > Hi all, > > are there any plans to implement a native WatchService implementation > for the Mac OS X file system? Eventually, until then the file system provider on Mac will fallback to using a simple polling implementation, which is why you are seeing in the thread dump. Michael Hall has been experimenting with an implementation, see: http://mail.openjdk.java.net/pipermail/nio-dev/2012-July/001791.html I don't know if he's got it to the point yet where it is passing the tests. -Alan. From martijnverburg at gmail.com Mon Oct 22 03:14:37 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 22 Oct 2012 11:14:37 +0100 Subject: 32-bit JVM In-Reply-To: References: <507FE8AB.2090403@oracle.com> <507FEE8D.9020807@oracle.com> <507FFCC4.6040901@oracle.com> <507FFE51.8020003@oracle.com> <5084EAD6.3010800@javaspecialists.eu> <5084EB6E.4080309@javaspecialists.eu> Message-ID: Hi all, I think it's a case that more people in the community need to be willing to help support the 32-bit Mac OS X builds for the long haul. Henri is obviously supportive :-) - Heinz, I'm not sure you'd have the time to commit to this as well? There probably needs to be a small group of folks for that port to be well-maintained. The sad reality is that 32-bit Mac is dying out, perhaps there are specific mailing lists/communities that you can reach out to? Cheers, Martijn On 22 October 2012 09:01, Henri Gomez wrote: > There will be no 32bits version of OpenJDK for OSX. > It was discussed many time on this mailing list. > > I provided patches to restore universal build (32/64bits) and raised > problems I encountered while using such 32bits non official JVM but > nobody was interested to investigate. > > Java 7 and more on OSX will be 64bits only. > > 2012/10/22 Dr Heinz M. Kabutz : >> A few months ago, we had a discussion about providing a JDK 7 for the Mac >> that can also operate in 32-bit mode. Someone enabled it and it then got >> disabled again, because it apparently broke something. >> >> Is there any chance to enable it again? Being able to operate in 32-bit and >> also -client mode is quite important in order to be able to test concurrency >> code using different JVMs. I still have the JDK that we built with this >> enabled and it works fine, but ideally I would like this to be supported by >> the latest JDK 1.7. >> >> Regards >> >> Heinz >> -- >> Dr Heinz M. Kabutz (PhD CompSci) >> Author of "The Java(tm) Specialists' Newsletter" >> Sun Java Champion >> IEEE Certified Software Development Professional >> http://www.javaspecialists.eu >> Tel: +30 69 75 595 262 >> Skype: kabutz >> From henri.gomez at gmail.com Mon Oct 22 04:34:20 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 22 Oct 2012 13:34:20 +0200 Subject: 32-bit JVM In-Reply-To: References: <507FE8AB.2090403@oracle.com> <507FEE8D.9020807@oracle.com> <507FFCC4.6040901@oracle.com> <507FFE51.8020003@oracle.com> <5084EAD6.3010800@javaspecialists.eu> <5084EB6E.4080309@javaspecialists.eu> Message-ID: > Hi all, > > I think it's a case that more people in the community need to be > willing to help support the 32-bit Mac OS X builds for the long haul. > Henri is obviously supportive :-) - Heinz, I'm not sure you'd have the > time to commit to this as well? There probably needs to be a small > group of folks for that port to be well-maintained. > > The sad reality is that 32-bit Mac is dying out, perhaps there are > specific mailing lists/communities that you can reach out to? I provided patches months ago to bring back universal builds (and so 32 and 64 bits mode) but nobody care about them. I also sent core and reports of failure when using OpenJDK 7 with universal patches against some apps like Jenkins, no more interest neither. 32 bits Mac JVM is dying because there is no interest for it. All others platforms will have 32 and 64 bits JVM, Linux, Windows, Solaris, but not OSX, it's sad but "c'est la vie". If users/admins/customers need 32bits JVM for minimal memory footprint or just because they just don't need 64bits addressing/pointers, there is plenty of OS and Java VM implementations around where 32bits support is still available and officially maintained. From krueger at lesspain.de Mon Oct 22 06:32:10 2012 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Mon, 22 Oct 2012 15:32:10 +0200 Subject: Resize-Behaviour/Performance Message-ID: Hi, I know this has been asked before (see for example http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003629.html) but my question is, if someone has already filed a bug report at bugs.sun.com (and please don't tell me to click through all the results that come up when searching for "resize" until there is a bug tracker where one can filter by platform and status) and if someone is anyone already working on achieving a result that is comparable to Apple's Java6, where resizing doesn't feel significantly worse than that of native apps? Thanks in advance, Robert From jesmith at kaon.com Mon Oct 22 08:28:20 2012 From: jesmith at kaon.com (Joshua Smith) Date: Mon, 22 Oct 2012 11:28:20 -0400 Subject: 32-bit JVM In-Reply-To: References: <507FE8AB.2090403@oracle.com> <507FEE8D.9020807@oracle.com> <507FFCC4.6040901@oracle.com> <507FFE51.8020003@oracle.com> <5084EAD6.3010800@javaspecialists.eu> <5084EB6E.4080309@javaspecialists.eu> Message-ID: It's worth pointing out that the lack of 32-bit JVM means that Google Chrome on Mac can no longer run Java applets. This is not some "nice to have" in a lot of people's view. It is a really huge, freaking deal. On Oct 22, 2012, at 7:34 AM, Henri Gomez wrote: >> Hi all, >> >> I think it's a case that more people in the community need to be >> willing to help support the 32-bit Mac OS X builds for the long haul. >> Henri is obviously supportive :-) - Heinz, I'm not sure you'd have the >> time to commit to this as well? There probably needs to be a small >> group of folks for that port to be well-maintained. >> >> The sad reality is that 32-bit Mac is dying out, perhaps there are >> specific mailing lists/communities that you can reach out to? > > I provided patches months ago to bring back universal builds (and so > 32 and 64 bits mode) but nobody care about them. > I also sent core and reports of failure when using OpenJDK 7 with > universal patches against some apps like Jenkins, no more interest > neither. > > 32 bits Mac JVM is dying because there is no interest for it. > All others platforms will have 32 and 64 bits JVM, Linux, Windows, > Solaris, but not OSX, it's sad but "c'est la vie". > > If users/admins/customers need 32bits JVM for minimal memory footprint > or just because they just don't need 64bits addressing/pointers, there > is plenty of OS and Java VM implementations around where 32bits > support is still available and officially maintained. From Sergey.Bylokhov at oracle.com Mon Oct 22 10:17:56 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 22 Oct 2012 21:17:56 +0400 Subject: Resize-Behaviour/Performance In-Reply-To: References: Message-ID: <50857FC4.5040904@oracle.com> Hi, Robert. Two bugs exists for this issue: 7198229 : [macosx] Painting during resizing of the frame should be more smooth http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229 7129082 : [macosx] UI performance http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129082 Both targeted to jdk 8 for now. 22.10.2012 17:32, Robert Kr?ger wrote: > Hi, > > I know this has been asked before (see for example > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-March/003629.html) > but my question is, if someone has already filed a bug report at > bugs.sun.com (and please don't tell me to click through all the > results that come up when searching for "resize" until there is a bug > tracker where one can filter by platform and status) and if someone is > anyone already working on achieving a result that is comparable to > Apple's Java6, where resizing doesn't feel significantly worse than > that of native apps? > > Thanks in advance, > > Robert -- Best regards, Sergey. From stephen.bannasch at deanbrook.org Mon Oct 22 11:26:05 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Mon, 22 Oct 2012 11:26:05 -0700 Subject: 32-bit JVM In-Reply-To: References: <507FE8AB.2090403@oracle.com> <507FEE8D.9020807@oracle.com> <507FFCC4.6040901@oracle.com> <507FFE51.8020003@oracle.com> <5084EAD6.3010800@javaspecialists.eu> <5084EB6E.4080309@javaspecialists.eu> Message-ID: At 11:14 AM +0100 10/22/12, Martijn Verburg wrote: >Hi all, > >I think it's a case that more people in the community need to be >willing to help support the 32-bit Mac OS X builds for the long haul. >Henri is obviously supportive :-) - Heinz, I'm not sure you'd have the >time to commit to this as well? There probably needs to be a small >group of folks for that port to be well-maintained. > >The sad reality is that 32-bit Mac is dying out, perhaps there are >specific mailing lists/communities that you can reach out to? The main reason I want the 32-bit options is to support existing native libraries that are 32-bit only and can't be easily adapted to work as 64-bit libraries. We have both Java Web Start applications and invisible Java applets that support access to probeware interfaces from companies like Pasco, Vernier, etc. Our target is K-12 Math, Science, and engineering education. Our code is open-source but the drivers we work with are often not open-source. Almost none of these features work anymore. FYI: http://lab.concord.org/ http://lab.concord.org/experiments/goio-sensor-grapher/index.html From krueger at lesspain.de Mon Oct 22 11:46:39 2012 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Mon, 22 Oct 2012 20:46:39 +0200 Subject: Access to native directory chooser Message-ID: Hi, we are currently using the following workaround to get a native directory chooser in our app: try { System.setProperty("apple.awt.fileDialogForDirectories", "true"); fileDialog.setVisible(true); } finally { System.setProperty("apple.awt.fileDialogForDirectories", "false"); } Is there anything other than JNI possible with JDK7? Thanks in advance, Robert From Sergey.Bylokhov at oracle.com Mon Oct 22 12:13:36 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 22 Oct 2012 23:13:36 +0400 Subject: Access to native directory chooser In-Reply-To: References: Message-ID: <50859AE0.4060906@oracle.com> Hi, Robert. This functionality was added to jdk and will be available in jdk 7u12 and 8 7161437 : [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 22.10.2012 22:46, Robert Kr?ger wrote: > Hi, > > we are currently using the following workaround to get a native > directory chooser in our app: > > try { > System.setProperty("apple.awt.fileDialogForDirectories", "true"); > fileDialog.setVisible(true); > } finally { > System.setProperty("apple.awt.fileDialogForDirectories", "false"); > } > > Is there anything other than JNI possible with JDK7? > > Thanks in advance, > > Robert -- Best regards, Sergey. From krueger at lesspain.de Mon Oct 22 12:39:16 2012 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Mon, 22 Oct 2012 21:39:16 +0200 Subject: Font rendering differences Message-ID: Hi, even on a non-retina display differences are significant between JDK6 and JDK7 (see screenshots of the same app started with each JDK). What is the reason for the difference? Can this be influenced somehow? It might not be too obvious for this tiny example but the entire app looks a bit like "withered" using JDK7. Thanks, Robert From Fabrizio.Giudici at tidalwave.it Mon Oct 22 12:46:59 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Mon, 22 Oct 2012 21:46:59 +0200 Subject: Access to native directory chooser In-Reply-To: <50859AE0.4060906@oracle.com> References: <50859AE0.4060906@oracle.com> Message-ID: On Mon, 22 Oct 2012 21:13:36 +0200, Sergey Bylokhov wrote: > Hi, Robert. > This functionality was added to jdk and will be available in jdk 7u12 > and 8 > > 7161437 : [macosx] awt.FileDialog doesn't respond appropriately for mac > when selecting folders > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 > > 22.10.2012 22:46, Robert Kr?ger wrote: >> Hi, >> >> we are currently using the following workaround to get a native >> directory chooser in our app: >> >> try { >> System.setProperty("apple.awt.fileDialogForDirectories", >> "true"); >> fileDialog.setVisible(true); >> } finally { >> System.setProperty("apple.awt.fileDialogForDirectories", >> "false"); >> } >> >> Is there anything other than JNI possible with JDK7? >> >> Thanks in advance, >> >> Robert Probably there's something I'm not understanding, but I've been running a native Mac OS X filechooser since JDK 7u4 using Quaqua with this code: private void runMacOSX (final @Nonnull Component parent) { final JFileChooser fileChooser = createFileChooser(); JSheet.showSaveSheet(fileChooser, parent, new SheetListener() { @Override public void optionSelected (final @Nonnull SheetEvent event) { if (event.getOption() == APPROVE_OPTION) { onFileSelected(fileChooser.getSelectedFile().toPath()); } } }); } @Nonnull private JFileChooser createFileChooser() { final JFileChooser fileChooser = new JFileChooser(); fileChooser.setDialogType(OPEN_DIALOG); fileChooser.setFileSelectionMode(type); return fileChooser; } I rather have problems with the Sheet rendering, which is not natively rendered due to a bug: http://java.net/jira/browse/QUAQUA-160 -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From mik3hall at gmail.com Mon Oct 22 13:27:10 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 22 Oct 2012 15:27:10 -0500 Subject: WatchService In-Reply-To: <5084FFD5.6060904@oracle.com> References: <507FE8AB.2090403@oracle.com> <507FEE8D.9020807@oracle.com> <507FFCC4.6040901@oracle.com> <507FFE51.8020003@oracle.com> <5084EAD6.3010800@javaspecialists.eu> <5084FFD5.6060904@oracle.com> Message-ID: <9CBDAF8F-20C4-48A0-9619-940D13B800ED@gmail.com> On Oct 22, 2012, at 3:12 AM, Alan Bateman wrote: > On 22/10/2012 07:42, Dr Heinz M. Kabutz wrote: >> Hi all, >> >> are there any plans to implement a native WatchService implementation for the Mac OS X file system? > Eventually, until then the file system provider on Mac will fallback to using a simple polling implementation, which is why you are seeing in the thread dump. > > Michael Hall has been experimenting with an implementation, see: > > http://mail.openjdk.java.net/pipermail/nio-dev/2012-July/001791.html > > I don't know if he's got it to the point yet where it is passing the tests I did a kqueue based implementation that passed the Basic tests. It didn't pass the 'lots of events' I think it was stress test exercising the overflow condition - at all. At some point I want to look at the existing implementations to see roughly how that should be handled. I also plan, again at some point, on trying a fsevents based implementation. I have read this could be a better choice for OS X especially if a large number of files are involved. Not begun. I haven't currently been doing anything with this. The trz project below in my mail signature if of any interest. Feedback welcome. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From mik3hall at gmail.com Mon Oct 22 13:30:22 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 22 Oct 2012 15:30:22 -0500 Subject: Access to native directory chooser In-Reply-To: References: <50859AE0.4060906@oracle.com> Message-ID: On Oct 22, 2012, at 2:46 PM, Fabrizio Giudici wrote: > Probably there's something I'm not understanding, but I've been running a native Mac OS X filechooser since JDK 7u4 using Quaqua with this code: Is Werner supporting Quaqua for Java 7 openjdk? I didn't see where his site indicated that he did the last time I looked. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From Fabrizio.Giudici at tidalwave.it Mon Oct 22 13:56:39 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Mon, 22 Oct 2012 22:56:39 +0200 Subject: Access to native directory chooser In-Reply-To: References: <50859AE0.4060906@oracle.com> Message-ID: On Mon, 22 Oct 2012 22:30:22 +0200, Michael Hall wrote: > On Oct 22, 2012, at 2:46 PM, Fabrizio Giudici wrote: > >> Probably there's something I'm not understanding, but I've been running >> a native Mac OS X filechooser since JDK 7u4 using Quaqua with this code: > > > Is Werner supporting Quaqua for Java 7 openjdk? I didn't see where his > site indicated that he did the last time I looked. The problem is more general: I'm not seeing updates after Version 8.0 2011-10-02 which is one year ago. Idem for the latest commit, as far as I can see. Still, apart from the problem I've mentioned, it's working fine. Of course, it's important to know whether the project is still maintained. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From philip.race at oracle.com Mon Oct 22 14:46:58 2012 From: philip.race at oracle.com (Phil Race) Date: Mon, 22 Oct 2012 14:46:58 -0700 Subject: Font rendering differences In-Reply-To: References: Message-ID: <5085BED2.1050206@oracle.com> Can you be (very) specific about what you see ? I don't know if you attempted to attach screen shots but some lists may not allow them. What I think are the major differences follow :- - Logical fonts may use a different underlying physical font. This is mostly to be "updated" to the more current fonts - LCD sub-pixel rendering isn't working - its grey scale only - The glyphs may appear a little darker/thicker in 7. I don't have a definitive answer here. I suspect that being rendered via OpenGL rather than software may be some part of the answer. So the glyph data we start from may be the same, but the final rendering step of blending the image to the surface is different. -phil. On 10/22/2012 12:39 PM, Robert Kr?ger wrote: > Hi, > > even on a non-retina display differences are significant between JDK6 > and JDK7 (see screenshots of the same app started with each JDK). What > is the reason for the difference? Can this be influenced somehow? It > might not be too obvious for this tiny example but the entire app > looks a bit like "withered" using JDK7. > > Thanks, > > Robert From steve at weblite.ca Mon Oct 22 16:19:31 2012 From: steve at weblite.ca (Steve Hannah) Date: Mon, 22 Oct 2012 16:19:31 -0700 Subject: Access to native directory chooser In-Reply-To: References: <50859AE0.4060906@oracle.com> Message-ID: Afaik quaqua is not actually a native dialog. It just adopts a native looking skin. This means that it is incompatible with the app store sandbox. Steve On Monday, October 22, 2012, Fabrizio Giudici wrote: > On Mon, 22 Oct 2012 21:13:36 +0200, Sergey Bylokhov < > Sergey.Bylokhov at oracle.com> wrote: > > Hi, Robert. >> This functionality was added to jdk and will be available in jdk 7u12 and >> 8 >> >> 7161437 : [macosx] awt.FileDialog doesn't respond appropriately for mac >> when selecting folders >> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7161437 >> >> 22.10.2012 22:46, Robert Kr?ger wrote: >> >>> Hi, >>> >>> we are currently using the following workaround to get a native >>> directory chooser in our app: >>> >>> try { >>> System.setProperty("apple.awt.**fileDialogForDirectories", >>> "true"); >>> fileDialog.setVisible(true); >>> } finally { >>> System.setProperty("apple.awt.**fileDialogForDirectories", >>> "false"); >>> } >>> >>> Is there anything other than JNI possible with JDK7? >>> >>> Thanks in advance, >>> >>> Robert >>> >> > Probably there's something I'm not understanding, but I've been running a > native Mac OS X filechooser since JDK 7u4 using Quaqua with this code: > > private void runMacOSX (final @Nonnull Component parent) > { > final JFileChooser fileChooser = createFileChooser(); > > JSheet.showSaveSheet(**fileChooser, parent, new SheetListener() > { > @Override > public void optionSelected (final @Nonnull SheetEvent event) > { > if (event.getOption() == APPROVE_OPTION) > { > onFileSelected(fileChooser.** > getSelectedFile().toPath()); > } > } > }); > } > > @Nonnull > private JFileChooser createFileChooser() > { > final JFileChooser fileChooser = new JFileChooser(); > fileChooser.setDialogType(**OPEN_DIALOG); > fileChooser.**setFileSelectionMode(type); > return fileChooser; > } > > > I rather have problems with the Sheet rendering, which is not natively > rendered due to a bug: > > http://java.net/jira/browse/**QUAQUA-160 > > > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/**blog - > fabrizio.giudici at tidalwave.it > -- Steve Hannah Web Lite Solutions Corp. From mik3hall at gmail.com Mon Oct 22 16:26:17 2012 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 22 Oct 2012 18:26:17 -0500 Subject: Access to native directory chooser In-Reply-To: References: <50859AE0.4060906@oracle.com> Message-ID: <8C021864-37B6-4A8B-9A5F-6B69FC929DBC@gmail.com> On Oct 22, 2012, at 6:19 PM, Steve Hannah wrote: > Afaik quaqua is not actually a native dialog. It just adopts a native > looking skin. This means that it is incompatible with the app store > sandbox. > Steve I think it involved different things for native. At one point I think it used Cocoa Java for the large preview icons. I also sort of remember that the filechooser code involved a native jnii lib, maybe once Cocoa Java was no longer supported? But, I think you are correct in that the dialog isn't completely native, it is java supplemented with native one way or another. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From Fabrizio.Giudici at tidalwave.it Tue Oct 23 01:36:33 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Tue, 23 Oct 2012 10:36:33 +0200 Subject: Access to native directory chooser In-Reply-To: <8C021864-37B6-4A8B-9A5F-6B69FC929DBC@gmail.com> References: <50859AE0.4060906@oracle.com> <8C021864-37B6-4A8B-9A5F-6B69FC929DBC@gmail.com> Message-ID: On Tue, 23 Oct 2012 01:26:17 +0200, Michael Hall wrote: > On Oct 22, 2012, at 6:19 PM, Steve Hannah wrote: > >> Afaik quaqua is not actually a native dialog. It just adopts a native >> looking skin. This means that it is incompatible with the app store >> sandbox. >> Steve > > I think it involved different things for native. At one point I think it > used Cocoa Java for the large preview icons. > I also sort of remember that the filechooser code involved a native jnii > lib, maybe once Cocoa Java was no longer supported? > But, I think you are correct in that the dialog isn't completely native, > it is java supplemented with native one way or another. It can use some natives, in fact it has a JNI library. For what concerns the app store, I don't know. The thing that comes to my mind is this: now that JDK 7 is open source also for Mac OS X, we should have the relevant parts of Quaqua integrated into it. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From Sergey.Bylokhov at oracle.com Tue Oct 23 04:41:14 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 23 Oct 2012 15:41:14 +0400 Subject: [8] Request for review: 7198229 [macosx] Painting during resizing of the frame should be more smooth Message-ID: <5086825A.2050104@oracle.com> Hi Everyone, Please review the fix. This is an attempt to make our resizing better. I try to eliminate all unnecessary repaint actions. 1 "Layer backed view" was changed to "Layer hosting view" - unnecessary call from drawRect() was eliminated. Now we post Paint event in the resize callback when necessary. 2 CALayer options were changed, so now it don't force setNeedsDisplay. 3 canDrawInCGLContext() was added to CGLLayer.m to eliminate unnecessary call to drawInCGLContext() when our 2d texture is not ready. 4 CPlatformWindow.deliverMoveResizeEvent() make an attempt to expose LWWindowPeer synchronously. (LWCToolkit.invokeAndWait is used) After the fix we call Layer.setNeedsDisplay only in the Java2D Queue Flusher threads. It means that we have no possibility to accelerate resizing even more from awt side. I'll make addition research of this question in the following CR. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129082 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001213 Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229 Webrev can be found at: http://cr.openjdk.java.net/~serb/7198229/webrev.00 -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Oct 23 05:15:39 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 23 Oct 2012 16:15:39 +0400 Subject: [8] Request for review: 7198229 [macosx] Painting during resizing of the frame should be more smooth In-Reply-To: <5086825A.2050104@oracle.com> References: <5086825A.2050104@oracle.com> Message-ID: <50868A6B.1040104@oracle.com> Hi Sergey, src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java > 902 //TODO validateSurface already called from notifyReshape > 903 if (!oldB.getSize().equals(nativeBounds.getSize()) ) { > 904 flushBuffers(); > 905 } > 906 validateSurface(); I think the comment at line 902 must be moved closer to the line 906 where it actually belongs. src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java > 503 public synchronized void run() { Why does this method have to be synchronized? Do you expect the Runnable.run() to be called many times from different threads? I'm not an expert in CA layers, but I think changing from a layer backed view to a layer hosting view is a big change. What tests did you run to verify there's no regressions with rendering? -- best regards, Anthony On 10/23/2012 3:41 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > This is an attempt to make our resizing better. I try to eliminate all > unnecessary repaint actions. > 1 "Layer backed view" was changed to "Layer hosting view" - unnecessary > call from drawRect() was eliminated. Now we post Paint event in the > resize callback when necessary. > 2 CALayer options were changed, so now it don't force setNeedsDisplay. > 3 canDrawInCGLContext() was added to CGLLayer.m to eliminate unnecessary > call to drawInCGLContext() when our 2d texture is not ready. > 4 CPlatformWindow.deliverMoveResizeEvent() make an attempt to expose > LWWindowPeer synchronously. (LWCToolkit.invokeAndWait is used) > > After the fix we call Layer.setNeedsDisplay only in the Java2D Queue > Flusher threads. It means that we have no possibility to accelerate > resizing even more from awt side. > I'll make addition research of this question in the following CR. > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129082 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001213 > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7198229/webrev.00 > From Sergey.Bylokhov at oracle.com Tue Oct 23 05:32:06 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 23 Oct 2012 16:32:06 +0400 Subject: [8] Request for review: 7198229 [macosx] Painting during resizing of the frame should be more smooth In-Reply-To: <50868A6B.1040104@oracle.com> References: <5086825A.2050104@oracle.com> <50868A6B.1040104@oracle.com> Message-ID: <50868E46.7030706@oracle.com> 23.10.2012 16:15, Anthony Petrov wrote: > Hi Sergey, > > src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >> 902 //TODO validateSurface already called from notifyReshape >> 903 if (!oldB.getSize().equals(nativeBounds.getSize()) ) { >> 904 flushBuffers(); >> 905 } >> 906 validateSurface(); > > I think the comment at line 902 must be moved closer to the line 906 > where it actually belongs. ok, changed. > > > src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java >> 503 public synchronized void run() { > > Why does this method have to be synchronized? Do you expect the > Runnable.run() to be called many times from different threads? I get this pattern from CDropTargetContextPeer.flushEvents(). This code can be safely removed later. > > I'm not an expert in CA layers, but I think changing from a layer > backed view to a layer hosting view is a big change. What tests did > you run to verify there's no regressions with rendering? At least awt jck/regression tests passed. But sure some regressions could be introduced. > > -- > best regards, > Anthony > > On 10/23/2012 3:41 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Please review the fix. >> This is an attempt to make our resizing better. I try to eliminate >> all unnecessary repaint actions. >> 1 "Layer backed view" was changed to "Layer hosting view" - >> unnecessary call from drawRect() was eliminated. Now we post Paint >> event in the resize callback when necessary. >> 2 CALayer options were changed, so now it don't force setNeedsDisplay. >> 3 canDrawInCGLContext() was added to CGLLayer.m to eliminate >> unnecessary call to drawInCGLContext() when our 2d texture is not ready. >> 4 CPlatformWindow.deliverMoveResizeEvent() make an attempt to expose >> LWWindowPeer synchronously. (LWCToolkit.invokeAndWait is used) >> >> After the fix we call Layer.setNeedsDisplay only in the Java2D Queue >> Flusher threads. It means that we have no possibility to accelerate >> resizing even more from awt side. >> I'll make addition research of this question in the following CR. >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129082 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001213 >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7198229/webrev.00 >> -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Oct 23 05:34:51 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 23 Oct 2012 16:34:51 +0400 Subject: [8] Request for review: 7198229 [macosx] Painting during resizing of the frame should be more smooth In-Reply-To: <50868E46.7030706@oracle.com> References: <5086825A.2050104@oracle.com> <50868A6B.1040104@oracle.com> <50868E46.7030706@oracle.com> Message-ID: <50868EEB.7080905@oracle.com> On 10/23/2012 4:32 PM, Sergey Bylokhov wrote: >> src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java >>> 503 public synchronized void run() { >> >> Why does this method have to be synchronized? Do you expect the >> Runnable.run() to be called many times from different threads? > I get this pattern from CDropTargetContextPeer.flushEvents(). This code > can be safely removed later. Unless there's a clear reason for this method to be synchronized, I suggest to remove this keyword from the method signature. >> I'm not an expert in CA layers, but I think changing from a layer >> backed view to a layer hosting view is a big change. What tests did >> you run to verify there's no regressions with rendering? > At least awt jck/regression tests passed. But sure some regressions > could be introduced. Thanks. The fix looks safe then. -- best regards, Anthony >> >> -- >> best regards, >> Anthony >> >> On 10/23/2012 3:41 PM, Sergey Bylokhov wrote: >>> Hi Everyone, >>> Please review the fix. >>> This is an attempt to make our resizing better. I try to eliminate >>> all unnecessary repaint actions. >>> 1 "Layer backed view" was changed to "Layer hosting view" - >>> unnecessary call from drawRect() was eliminated. Now we post Paint >>> event in the resize callback when necessary. >>> 2 CALayer options were changed, so now it don't force setNeedsDisplay. >>> 3 canDrawInCGLContext() was added to CGLLayer.m to eliminate >>> unnecessary call to drawInCGLContext() when our 2d texture is not ready. >>> 4 CPlatformWindow.deliverMoveResizeEvent() make an attempt to expose >>> LWWindowPeer synchronously. (LWCToolkit.invokeAndWait is used) >>> >>> After the fix we call Layer.setNeedsDisplay only in the Java2D Queue >>> Flusher threads. It means that we have no possibility to accelerate >>> resizing even more from awt side. >>> I'll make addition research of this question in the following CR. >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129082 >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001213 >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7198229/webrev.00 >>> > > From Sergey.Bylokhov at oracle.com Tue Oct 23 05:45:20 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 23 Oct 2012 16:45:20 +0400 Subject: [8] Request for review: 7198229 [macosx] Painting during resizing of the frame should be more smooth In-Reply-To: <50868EEB.7080905@oracle.com> References: <5086825A.2050104@oracle.com> <50868A6B.1040104@oracle.com> <50868E46.7030706@oracle.com> <50868EEB.7080905@oracle.com> Message-ID: <50869160.2030102@oracle.com> New version of the fix: http://cr.openjdk.java.net/~serb/7198229/webrev.01/ 23.10.2012 16:34, Anthony Petrov wrote: > On 10/23/2012 4:32 PM, Sergey Bylokhov wrote: >>> src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java >>>> 503 public synchronized void run() { >>> >>> Why does this method have to be synchronized? Do you expect the >>> Runnable.run() to be called many times from different threads? >> I get this pattern from CDropTargetContextPeer.flushEvents(). This >> code can be safely removed later. > > Unless there's a clear reason for this method to be synchronized, I > suggest to remove this keyword from the method signature. > > >>> I'm not an expert in CA layers, but I think changing from a layer >>> backed view to a layer hosting view is a big change. What tests did >>> you run to verify there's no regressions with rendering? >> At least awt jck/regression tests passed. But sure some regressions >> could be introduced. > > Thanks. The fix looks safe then. > > -- > best regards, > Anthony > >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/23/2012 3:41 PM, Sergey Bylokhov wrote: >>>> Hi Everyone, >>>> Please review the fix. >>>> This is an attempt to make our resizing better. I try to eliminate >>>> all unnecessary repaint actions. >>>> 1 "Layer backed view" was changed to "Layer hosting view" - >>>> unnecessary call from drawRect() was eliminated. Now we post Paint >>>> event in the resize callback when necessary. >>>> 2 CALayer options were changed, so now it don't force setNeedsDisplay. >>>> 3 canDrawInCGLContext() was added to CGLLayer.m to eliminate >>>> unnecessary call to drawInCGLContext() when our 2d texture is not >>>> ready. >>>> 4 CPlatformWindow.deliverMoveResizeEvent() make an attempt to >>>> expose LWWindowPeer synchronously. (LWCToolkit.invokeAndWait is used) >>>> >>>> After the fix we call Layer.setNeedsDisplay only in the Java2D >>>> Queue Flusher threads. It means that we have no possibility to >>>> accelerate resizing even more from awt side. >>>> I'll make addition research of this question in the following CR. >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129082 >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001213 >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7198229/webrev.00 >>>> >> >> -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Oct 23 07:09:35 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 23 Oct 2012 18:09:35 +0400 Subject: [8] Request for review: 7198229 [macosx] Painting during resizing of the frame should be more smooth In-Reply-To: <50869160.2030102@oracle.com> References: <5086825A.2050104@oracle.com> <50868A6B.1040104@oracle.com> <50868E46.7030706@oracle.com> <50868EEB.7080905@oracle.com> <50869160.2030102@oracle.com> Message-ID: <5086A51F.4090702@oracle.com> Looks fine. Thanks. -- best regards, Anthony On 10/23/2012 4:45 PM, Sergey Bylokhov wrote: > New version of the fix: > http://cr.openjdk.java.net/~serb/7198229/webrev.01/ > > 23.10.2012 16:34, Anthony Petrov wrote: >> On 10/23/2012 4:32 PM, Sergey Bylokhov wrote: >>>> src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java >>>>> 503 public synchronized void run() { >>>> >>>> Why does this method have to be synchronized? Do you expect the >>>> Runnable.run() to be called many times from different threads? >>> I get this pattern from CDropTargetContextPeer.flushEvents(). This >>> code can be safely removed later. >> >> Unless there's a clear reason for this method to be synchronized, I >> suggest to remove this keyword from the method signature. >> >> >>>> I'm not an expert in CA layers, but I think changing from a layer >>>> backed view to a layer hosting view is a big change. What tests did >>>> you run to verify there's no regressions with rendering? >>> At least awt jck/regression tests passed. But sure some regressions >>> could be introduced. >> >> Thanks. The fix looks safe then. >> >> -- >> best regards, >> Anthony >> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/23/2012 3:41 PM, Sergey Bylokhov wrote: >>>>> Hi Everyone, >>>>> Please review the fix. >>>>> This is an attempt to make our resizing better. I try to eliminate >>>>> all unnecessary repaint actions. >>>>> 1 "Layer backed view" was changed to "Layer hosting view" - >>>>> unnecessary call from drawRect() was eliminated. Now we post Paint >>>>> event in the resize callback when necessary. >>>>> 2 CALayer options were changed, so now it don't force setNeedsDisplay. >>>>> 3 canDrawInCGLContext() was added to CGLLayer.m to eliminate >>>>> unnecessary call to drawInCGLContext() when our 2d texture is not >>>>> ready. >>>>> 4 CPlatformWindow.deliverMoveResizeEvent() make an attempt to >>>>> expose LWWindowPeer synchronously. (LWCToolkit.invokeAndWait is used) >>>>> >>>>> After the fix we call Layer.setNeedsDisplay only in the Java2D >>>>> Queue Flusher threads. It means that we have no possibility to >>>>> accelerate resizing even more from awt side. >>>>> I'll make addition research of this question in the following CR. >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129082 >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001213 >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/7198229/webrev.00 >>>>> >>> >>> > > From Sergey.Bylokhov at oracle.com Tue Oct 23 07:51:27 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 23 Oct 2012 18:51:27 +0400 Subject: [8] Request for review: 7198229 [macosx] Painting during resizing of the frame should be more smooth In-Reply-To: <5086825A.2050104@oracle.com> References: <5086825A.2050104@oracle.com> Message-ID: <5086AEEF.9010605@oracle.com> cc Scott. As plugin may be affected. 23.10.2012 15:41, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > This is an attempt to make our resizing better. I try to eliminate all > unnecessary repaint actions. > 1 "Layer backed view" was changed to "Layer hosting view" - > unnecessary call from drawRect() was eliminated. Now we post Paint > event in the resize callback when necessary. > 2 CALayer options were changed, so now it don't force setNeedsDisplay. > 3 canDrawInCGLContext() was added to CGLLayer.m to eliminate > unnecessary call to drawInCGLContext() when our 2d texture is not ready. > 4 CPlatformWindow.deliverMoveResizeEvent() make an attempt to expose > LWWindowPeer synchronously. (LWCToolkit.invokeAndWait is used) > > After the fix we call Layer.setNeedsDisplay only in the Java2D Queue > Flusher threads. It means that we have no possibility to accelerate > resizing even more from awt side. > I'll make addition research of this question in the following CR. > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129082 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001213 > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7198229/webrev.00 > -- Best regards, Sergey. From scott.kovatch at oracle.com Wed Oct 24 10:33:06 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Wed, 24 Oct 2012 10:33:06 -0700 Subject: [8] Request for review: 7198229 [macosx] Painting during resizing of the frame should be more smooth In-Reply-To: <50869160.2030102@oracle.com> References: <5086825A.2050104@oracle.com> <50868A6B.1040104@oracle.com> <50868E46.7030706@oracle.com> <50868EEB.7080905@oracle.com> <50869160.2030102@oracle.com> Message-ID: <6836A0E3-5B26-4868-A524-D2FAD01437C3@oracle.com> This all looks good to me. It looks like we may be able to remove the workaround in the plugin where we have to update the size of the CALayer on a window resize. I knew something was wrong in the AWT but wasn't sure what. -- Scott On Oct 23, 2012, at 5:45 AM, Sergey Bylokhov wrote: > New version of the fix: > http://cr.openjdk.java.net/~serb/7198229/webrev.01/ > > 23.10.2012 16:34, Anthony Petrov wrote: >> On 10/23/2012 4:32 PM, Sergey Bylokhov wrote: >>>> src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java >>>>> 503 public synchronized void run() { >>>> >>>> Why does this method have to be synchronized? Do you expect the Runnable.run() to be called many times from different threads? >>> I get this pattern from CDropTargetContextPeer.flushEvents(). This code can be safely removed later. >> >> Unless there's a clear reason for this method to be synchronized, I suggest to remove this keyword from the method signature. >> >> >>>> I'm not an expert in CA layers, but I think changing from a layer backed view to a layer hosting view is a big change. What tests did you run to verify there's no regressions with rendering? >>> At least awt jck/regression tests passed. But sure some regressions could be introduced. >> >> Thanks. The fix looks safe then. >> >> -- >> best regards, >> Anthony >> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/23/2012 3:41 PM, Sergey Bylokhov wrote: >>>>> Hi Everyone, >>>>> Please review the fix. >>>>> This is an attempt to make our resizing better. I try to eliminate all unnecessary repaint actions. >>>>> 1 "Layer backed view" was changed to "Layer hosting view" - unnecessary call from drawRect() was eliminated. Now we post Paint event in the resize callback when necessary. >>>>> 2 CALayer options were changed, so now it don't force setNeedsDisplay. >>>>> 3 canDrawInCGLContext() was added to CGLLayer.m to eliminate unnecessary call to drawInCGLContext() when our 2d texture is not ready. >>>>> 4 CPlatformWindow.deliverMoveResizeEvent() make an attempt to expose LWWindowPeer synchronously. (LWCToolkit.invokeAndWait is used) >>>>> >>>>> After the fix we call Layer.setNeedsDisplay only in the Java2D Queue Flusher threads. It means that we have no possibility to accelerate resizing even more from awt side. >>>>> I'll make addition research of this question in the following CR. >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129082 >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001213 >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229 >>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/7198229/webrev.00 >>>>> >>> >>> > > > -- > Best regards, Sergey. > From jcpalmer at rochester.rr.com Wed Oct 24 14:52:00 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Wed, 24 Oct 2012 17:52:00 -0400 Subject: 7u9 jnlp very touchy with vm args Message-ID: <604AE758-56E5-4A0F-8E7D-C9498A1E14C4@rochester.rr.com> I have isolated my problem, & I think the reason might help explain some other messages on the other list. I have reviewed the allowable vm args in JNLPs as published: http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/syntax.html#resources I was not fully compliant, as I was referencing the argument, -XX:+UseConcMarkSweepGC. This is a working JNLP snippet from the previous release (7u8 I think): Take out the unsupported argument in both places, and it now works. 7u9 does tolerate the GC arg on Windows still. This is clearly not a bug. I think a little better could be done on providing feed though. The program just ENDS. No warning, failure message, traces, nothing. This makes it hard to find. This one took a day. I was concerned my Lion partition had a bunch of ea stuff which I had tinkered with & was not stock enough anyway, so the time to blow it away & rebuilding it was still worth it. Finally, after I re-installed, I just went to the Oracle site and installed the JRE. In Safari, specifying a jnlp, downloads & starts it. If you click on the desktop icon for subsequent runs you get message box from Software Update: "To open "BLAH,BLAH, BLAH" you need a Java SE 6 runtime. Would you like to install one now?" No, I do not need this. This message did NOT come up because I have the 2 j2se tags. I tried when there was only 1. If I actually followed through and did that, it would not even use it. (guess I have to though, starting though cache viewer is a pain). The test is wrong. It should be testing for the Oracle plugin installed. From igor.nekrestyanov at oracle.com Wed Oct 24 15:09:26 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Wed, 24 Oct 2012 15:09:26 -0700 Subject: 7u9 jnlp very touchy with vm args In-Reply-To: <604AE758-56E5-4A0F-8E7D-C9498A1E14C4@rochester.rr.com> References: <604AE758-56E5-4A0F-8E7D-C9498A1E14C4@rochester.rr.com> Message-ID: <50886716.1080008@oracle.com> I think the reason of this behavior (with unsupported option) is that if you try to pass unsupported arg to java launcher then jvm will simply exit with error. javaws or plugin spawns new JVM and it does not really know why that other process exits (or crash). I totally agree it is not developer friendly though. Please file your suggestions/ideas as bugs/JIRA issues. This is first step to make them fixed. Your second problem sounds like some incompatibility between Apple helper tools and Oracle JRE. Perhaps Scott or someone from install team can comment on this, -igor On 10/24/12 2:52 PM, Jeff Palmer wrote: > I have isolated my problem,& I think the reason might help explain some other messages on the other list. I have reviewed the allowable vm args in JNLPs as published: > > http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/syntax.html#resources > > I was not fully compliant, as I was referencing the argument, -XX:+UseConcMarkSweepGC. > > This is a working JNLP snippet from the previous release (7u8 I think): > > version="1.7+" > java-vm-args="-Xmx200m XX:+UseConcMarkSweepGC" > /> > > > > > version="1.6+" > java-vm-args="-Xmx200m XX:+UseConcMarkSweepGC -Dapple.awt.graphics.UseQuartz=true" > /> > > > Take out the unsupported argument in both places, and it now works. 7u9 does tolerate the GC arg on Windows still. > > This is clearly not a bug. I think a little better could be done on providing feed though. The program just ENDS. No warning, failure message, traces, nothing. This makes it hard to find. > > This one took a day. I was concerned my Lion partition had a bunch of ea stuff which I had tinkered with& was not stock enough anyway, so the time to blow it away& rebuilding it was still worth it. > > Finally, after I re-installed, I just went to the Oracle site and installed the JRE. In Safari, specifying a jnlp, downloads& starts it. If you click on the desktop icon for subsequent runs you get message box from Software Update: > "To open "BLAH,BLAH, BLAH" you need a Java SE 6 runtime. Would you like to install one now?" > > No, I do not need this. This message did NOT come up because I have the 2 j2se tags. I tried when there was only 1. > > If I actually followed through and did that, it would not even use it. (guess I have to though, starting though cache viewer is a pain). The test is wrong. It should be testing for the Oracle plugin installed. > > > > From swpalmer at gmail.com Wed Oct 24 15:48:39 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 24 Oct 2012 18:48:39 -0400 Subject: 7u9 jnlp very touchy with vm args In-Reply-To: <604AE758-56E5-4A0F-8E7D-C9498A1E14C4@rochester.rr.com> References: <604AE758-56E5-4A0F-8E7D-C9498A1E14C4@rochester.rr.com> Message-ID: You are missing a leading minus sign in the XML snippets you provided. Typo? (I have no clue if that would make a difference as far as the acceptance of the args) Scott On 2012-10-24, at 5:52 PM, Jeff Palmer wrote: > I have isolated my problem, & I think the reason might help explain some other messages on the other list. I have reviewed the allowable vm args in JNLPs as published: > > http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/syntax.html#resources > > I was not fully compliant, as I was referencing the argument, -XX:+UseConcMarkSweepGC. > > This is a working JNLP snippet from the previous release (7u8 I think): > > version="1.7+" > java-vm-args="-Xmx200m XX:+UseConcMarkSweepGC" > /> > > > > > version="1.6+" > java-vm-args="-Xmx200m XX:+UseConcMarkSweepGC -Dapple.awt.graphics.UseQuartz=true" > /> > > > Take out the unsupported argument in both places, and it now works. 7u9 does tolerate the GC arg on Windows still. > > This is clearly not a bug. I think a little better could be done on providing feed though. The program just ENDS. No warning, failure message, traces, nothing. This makes it hard to find. > > This one took a day. I was concerned my Lion partition had a bunch of ea stuff which I had tinkered with & was not stock enough anyway, so the time to blow it away & rebuilding it was still worth it. > > Finally, after I re-installed, I just went to the Oracle site and installed the JRE. In Safari, specifying a jnlp, downloads & starts it. If you click on the desktop icon for subsequent runs you get message box from Software Update: > "To open "BLAH,BLAH, BLAH" you need a Java SE 6 runtime. Would you like to install one now?" > > No, I do not need this. This message did NOT come up because I have the 2 j2se tags. I tried when there was only 1. > > If I actually followed through and did that, it would not even use it. (guess I have to though, starting though cache viewer is a pain). The test is wrong. It should be testing for the Oracle plugin installed. > > > > From jesmith at kaon.com Thu Oct 25 10:28:15 2012 From: jesmith at kaon.com (Joshua Smith) Date: Thu, 25 Oct 2012 13:28:15 -0400 Subject: Two Issues with JRE 7 Applets Message-ID: (I posted this over on the Apple list, but haven't gotten any response yet.) 1. When I type [option]-2, I'm seeing then number 2, not the ? symbol. If I use the "Show Character Viewer" doohickey, I don't get anything at all. Using the option key to make accented characters does work, just not stuff like ? and ?. 2. I cannot copy/paste from AWT dialogs. These are both regressions from Apple's JRE 6. Are there workarounds to either of these? Is there a bug database someplace that I can search to see if these are know issues? (There was a lot of back-and-forth recently about bug databases, and I'm left not knowing which way is up on that front.) -Joshua From swingler at apple.com Thu Oct 25 10:30:28 2012 From: swingler at apple.com (Mike Swingler) Date: Thu, 25 Oct 2012 10:30:28 -0700 Subject: Two Issues with JRE 7 Applets In-Reply-To: References: Message-ID: <9ADA6B6F-46C1-48C2-8420-1655BAF3739E@apple.com> On Oct 25, 2012, at 10:28 AM, Joshua Smith wrote: > (I posted this over on the Apple list, but haven't gotten any response yet.) > > 1. When I type [option]-2, I'm seeing then number 2, not the ? symbol. If I use the "Show Character Viewer" doohickey, I don't get anything at all. Using the option key to make accented characters does work, just not stuff like ? and ?. > > 2. I cannot copy/paste from AWT dialogs. > > These are both regressions from Apple's JRE 6. > > Are there workarounds to either of these? > > Is there a bug database someplace that I can search to see if these are know issues? (There was a lot of back-and-forth recently about bug databases, and I'm left not knowing which way is up on that front.) is the current/best one to use right now. Regards, Mike Swingler Apple Inc. From jesmith at kaon.com Thu Oct 25 10:47:33 2012 From: jesmith at kaon.com (Joshua Smith) Date: Thu, 25 Oct 2012 13:47:33 -0400 Subject: Two Issues with JRE 7 Applets In-Reply-To: <9ADA6B6F-46C1-48C2-8420-1655BAF3739E@apple.com> References: <9ADA6B6F-46C1-48C2-8420-1655BAF3739E@apple.com> Message-ID: I couldn't find either of these reported there. I found a trivial applet on the web that can be used to reproduce the problem: http://www.willamette.edu/~gorr/classes/cs231/lectures/chapter5/ Just scroll down to the applet and try using Option-2 in it. You'll get a 2 instead of a ?. Then try to copy/paste in it -- doesn't work. Both of these work correctly in Apple's JDK 6. Can someone at Oracle put these into the real bug tracking system? -Joshua On Oct 25, 2012, at 1:30 PM, Mike Swingler wrote: > On Oct 25, 2012, at 10:28 AM, Joshua Smith wrote: > >> (I posted this over on the Apple list, but haven't gotten any response yet.) >> >> 1. When I type [option]-2, I'm seeing then number 2, not the ? symbol. If I use the "Show Character Viewer" doohickey, I don't get anything at all. Using the option key to make accented characters does work, just not stuff like ? and ?. >> >> 2. I cannot copy/paste from AWT dialogs. >> >> These are both regressions from Apple's JRE 6. >> >> Are there workarounds to either of these? >> >> Is there a bug database someplace that I can search to see if these are know issues? (There was a lot of back-and-forth recently about bug databases, and I'm left not knowing which way is up on that front.) > > is the current/best one to use right now. > > Regards, > Mike Swingler > Apple Inc. > From Sergey.Bylokhov at oracle.com Thu Oct 25 11:12:22 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 25 Oct 2012 22:12:22 +0400 Subject: Two Issues with JRE 7 Applets In-Reply-To: References: <9ADA6B6F-46C1-48C2-8420-1655BAF3739E@apple.com> Message-ID: <50898106.3020900@oracle.com> Hi, Joshua. You should use this one: http://bugs.sun.com/bugdatabase/ Thanks. 25.10.2012 21:47, Joshua Smith wrote: > I couldn't find either of these reported there. > > I found a trivial applet on the web that can be used to reproduce the problem: > > http://www.willamette.edu/~gorr/classes/cs231/lectures/chapter5/ > > Just scroll down to the applet and try using Option-2 in it. You'll get a 2 instead of a ?. Then try to copy/paste in it -- doesn't work. > > Both of these work correctly in Apple's JDK 6. > > Can someone at Oracle put these into the real bug tracking system? > > -Joshua > > On Oct 25, 2012, at 1:30 PM, Mike Swingler wrote: > >> On Oct 25, 2012, at 10:28 AM, Joshua Smith wrote: >> >>> (I posted this over on the Apple list, but haven't gotten any response yet.) >>> >>> 1. When I type [option]-2, I'm seeing then number 2, not the ? symbol. If I use the "Show Character Viewer" doohickey, I don't get anything at all. Using the option key to make accented characters does work, just not stuff like ? and ?. >>> >>> 2. I cannot copy/paste from AWT dialogs. >>> >>> These are both regressions from Apple's JRE 6. >>> >>> Are there workarounds to either of these? >>> >>> Is there a bug database someplace that I can search to see if these are know issues? (There was a lot of back-and-forth recently about bug databases, and I'm left not knowing which way is up on that front.) >> is the current/best one to use right now. >> >> Regards, >> Mike Swingler >> Apple Inc. >> -- Best regards, Sergey. From jesmith at kaon.com Thu Oct 25 12:14:26 2012 From: jesmith at kaon.com (Joshua Smith) Date: Thu, 25 Oct 2012 15:14:26 -0400 Subject: Two Issues with JRE 7 Applets In-Reply-To: <50898106.3020900@oracle.com> References: <9ADA6B6F-46C1-48C2-8420-1655BAF3739E@apple.com> <50898106.3020900@oracle.com> Message-ID: <085A078D-897E-4098-8417-B5D961B6BE8B@kaon.com> Done. Oddly, it doesn't tell me the bug number after I submit it, and new bugs do not appear in search results, so I can't tell you what they are. I also posted both bugs to stackoverflow, hoping that someone thinks of a work-around. These are both major production problems for my company. (We copy and paste a lot, and our customers ?, ?, and ? everything! :) -Joshua On Oct 25, 2012, at 2:12 PM, Sergey Bylokhov wrote: > Hi, Joshua. > You should use this one: > http://bugs.sun.com/bugdatabase/ > > Thanks. > > 25.10.2012 21:47, Joshua Smith wrote: >> I couldn't find either of these reported there. >> >> I found a trivial applet on the web that can be used to reproduce the problem: >> >> http://www.willamette.edu/~gorr/classes/cs231/lectures/chapter5/ >> >> Just scroll down to the applet and try using Option-2 in it. You'll get a 2 instead of a ?. Then try to copy/paste in it -- doesn't work. >> >> Both of these work correctly in Apple's JDK 6. >> >> Can someone at Oracle put these into the real bug tracking system? >> >> -Joshua >> >> On Oct 25, 2012, at 1:30 PM, Mike Swingler wrote: >> >>> On Oct 25, 2012, at 10:28 AM, Joshua Smith wrote: >>> >>>> (I posted this over on the Apple list, but haven't gotten any response yet.) >>>> >>>> 1. When I type [option]-2, I'm seeing then number 2, not the ? symbol. If I use the "Show Character Viewer" doohickey, I don't get anything at all. Using the option key to make accented characters does work, just not stuff like ? and ?. >>>> >>>> 2. I cannot copy/paste from AWT dialogs. >>>> >>>> These are both regressions from Apple's JRE 6. >>>> >>>> Are there workarounds to either of these? >>>> >>>> Is there a bug database someplace that I can search to see if these are know issues? (There was a lot of back-and-forth recently about bug databases, and I'm left not knowing which way is up on that front.) >>> is the current/best one to use right now. >>> >>> Regards, >>> Mike Swingler >>> Apple Inc. >>> > > > -- > Best regards, Sergey. > From jcpalmer at rochester.rr.com Thu Oct 25 12:32:21 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Thu, 25 Oct 2012 15:32:21 -0400 Subject: macosx-port-dev Digest, Vol 22, Issue 32 In-Reply-To: References: Message-ID: I did put something in for an enhancement. Below is the confirmation message, which restates it. Yes, that was a typo. I do not develop on Mac, but do mail from it. JNLP's look processed in cache, freehanded it in original message. most of confirmation msg (the source JNLP shows a blanks): release: 7 hardware: x86 OSversion: macosx priority: 4 Synopsis: Invalid vm args cause immediate termination Description: A DESCRIPTION OF THE REQUEST : If java-vm-args attribute of contains invalid options, then the forked off vm process simply terminates, leaving no trail to suggest what the problem might be. JUSTIFICATION : While there should be no expectation of good things happening when invalid options are specified, the lack of feedback makes understanding what is wrong a function of the developers skill, stubbornness, & desperation (+luck). The reason is: How are they to even to know it is an args problem? Did the VM even start? Briefly the Name of the program changes to what it should be, but what does that mean? EXPECTED VERSUS ACTUAL BEHAVIOR : EXPECTED - The best option is to valid all args against the documented list of supported args prior to forking off. If there is an arg specified which is not listed, and the attribute no-arg-warn="true" is not found, then: Bring up a dialog similar to the one if the mandatory version attribute is missing saying: VM "Blah" argument is not universally supported. Do you wish to proceed?" Since the no-arg-warn must be added to suppress the warning, things can be caught very quickly. Force developer to add the no-arg-warn, EVEN if it is being specified inside a resources with an os="Blah OS". Not sure about -d args. They seem to cause windows to take twice as long to start program, but never seen a failure. My JNLP's are always signed though. ACTUAL - see Description ---------- BEGIN SOURCE ---------- Add -XX:+UseConcMarkSweepGC into any JNLP. It will work on Windows, and fail on Mac for 7u9. Operated, or at least ignored on both for 7u8. ---------- END SOURCE ---------- CUSTOMER SUBMITTED WORKAROUND : psychiatric therapy On Oct 25, 2012, at 3:00 PM, macosx-port-dev-request at openjdk.java.net wrote: > From: Igor Nekrestyanov > Subject: Re: 7u9 jnlp very touchy with vm args > Date: October 24, 2012 6:09:26 PM EDT > To: Jeff Palmer > Cc: macosx-port-dev at openjdk.java.net > > > I think the reason of this behavior (with unsupported option) is that if you try to pass unsupported arg to java launcher then jvm will simply exit with error. > javaws or plugin spawns new JVM and it does not really know why that other process exits (or crash). > > I totally agree it is not developer friendly though. Please file your suggestions/ideas as bugs/JIRA issues. > This is first step to make them fixed. > > Your second problem sounds like some incompatibility between Apple helper tools and Oracle JRE. > Perhaps Scott or someone from install team can comment on this, > > -igor > > On 10/24/12 2:52 PM, Jeff Palmer wrote: >> I have isolated my problem,& I think the reason might help explain some other messages on the other list. I have reviewed the allowable vm args in JNLPs as published: >> >> http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/syntax.html#resources >> >> I was not fully compliant, as I was referencing the argument, -XX:+UseConcMarkSweepGC. >> >> This is a working JNLP snippet from the previous release (7u8 I think): >> >> > version="1.7+" >> java-vm-args="-Xmx200m XX:+UseConcMarkSweepGC" >> /> >> >> >> >> >> > version="1.6+" >> java-vm-args="-Xmx200m XX:+UseConcMarkSweepGC -Dapple.awt.graphics.UseQuartz=true" >> /> >> >> >> Take out the unsupported argument in both places, and it now works. 7u9 does tolerate the GC arg on Windows still. >> >> This is clearly not a bug. I think a little better could be done on providing feed though. The program just ENDS. No warning, failure message, traces, nothing. This makes it hard to find. >> >> This one took a day. I was concerned my Lion partition had a bunch of ea stuff which I had tinkered with& was not stock enough anyway, so the time to blow it away& rebuilding it was still worth it. >> >> Finally, after I re-installed, I just went to the Oracle site and installed the JRE. In Safari, specifying a jnlp, downloads& starts it. If you click on the desktop icon for subsequent runs you get message box from Software Update: >> "To open "BLAH,BLAH, BLAH" you need a Java SE 6 runtime. Would you like to install one now?" >> >> No, I do not need this. This message did NOT come up because I have the 2 j2se tags. I tried when there was only 1. >> >> If I actually followed through and did that, it would not even use it. (guess I have to though, starting though cache viewer is a pain). The test is wrong. It should be testing for the Oracle plugin installed. > From jcpalmer at rochester.rr.com Thu Oct 25 13:50:59 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Thu, 25 Oct 2012 16:50:59 -0400 Subject: 7u9 jnlp very touchy with vm args In-Reply-To: References: Message-ID: Well, I got around to agreeing to installing the Java SE 6 supposedly required to run a webstart 7 app from an icon. Was thinking it was going to be some bizarre situation of then having to reinstall Java 7. Wrong, worse. Now the Icon click just terminates after changing the menu briefly. No Traces, logs, or console entries. Can still run from cache viewer (create icon button disabled though) & from Safari. I am kind of underwhelmed. This looks more like dis-intergration than integration. I think anyone assuming things are going to work for customers with brand new machines might be wrong, unless the some exact unknown procedure is followed. After my Lion rebuild, I just went to the Oracle verify page, http://www.java.com/en/download/installed.jsp . Clicked the "Verify Java Version" button, and after I got tired of waiting to be told I did not have it, clicked on a nearby "download" link. If someone was using that Java Script launcher script for the html button, that is probably where the customers will end up too. I dumped the java script method due to many issues with different browsers on Windows. I put out a link to the verifier, and link directly to the JNLP. If this was a PDF, you link it & add a link to get Acrobat. Almost the same here. I do not have time to really deal with this right now. I will open a bug, but there will not be anything which is not here. Thanks, Jeff On Oct 25, 2012, at 3:00 PM, macosx-port-dev-request at openjdk.java.net wrote: > From: Igor Nekrestyanov > Subject: Re: 7u9 jnlp very touchy with vm args > Date: October 24, 2012 6:09:26 PM EDT > To: Jeff Palmer > Cc: macosx-port-dev at openjdk.java.net > > > I think the reason of this behavior (with unsupported option) is that if you try to pass unsupported arg to java launcher then jvm will simply exit with error. > javaws or plugin spawns new JVM and it does not really know why that other process exits (or crash). > > I totally agree it is not developer friendly though. Please file your suggestions/ideas as bugs/JIRA issues. > This is first step to make them fixed. > > Your second problem sounds like some incompatibility between Apple helper tools and Oracle JRE. > Perhaps Scott or someone from install team can comment on this, > > -igor > > On 10/24/12 2:52 PM, Jeff Palmer wrote: >> I have isolated my problem,& I think the reason might help explain some other messages on the other list. I have reviewed the allowable vm args in JNLPs as published: >> >> http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/syntax.html#resources >> >> I was not fully compliant, as I was referencing the argument, -XX:+UseConcMarkSweepGC. >> >> This is a working JNLP snippet from the previous release (7u8 I think): >> >> > version="1.7+" >> java-vm-args="-Xmx200m XX:+UseConcMarkSweepGC" >> /> >> >> >> >> >> > version="1.6+" >> java-vm-args="-Xmx200m XX:+UseConcMarkSweepGC -Dapple.awt.graphics.UseQuartz=true" >> /> >> >> >> Take out the unsupported argument in both places, and it now works. 7u9 does tolerate the GC arg on Windows still. >> >> This is clearly not a bug. I think a little better could be done on providing feed though. The program just ENDS. No warning, failure message, traces, nothing. This makes it hard to find. >> >> This one took a day. I was concerned my Lion partition had a bunch of ea stuff which I had tinkered with& was not stock enough anyway, so the time to blow it away& rebuilding it was still worth it. >> >> Finally, after I re-installed, I just went to the Oracle site and installed the JRE. In Safari, specifying a jnlp, downloads& starts it. If you click on the desktop icon for subsequent runs you get message box from Software Update: >> "To open "BLAH,BLAH, BLAH" you need a Java SE 6 runtime. Would you like to install one now?" >> >> No, I do not need this. This message did NOT come up because I have the 2 j2se tags. I tried when there was only 1. >> >> If I actually followed through and did that, it would not even use it. (guess I have to though, starting though cache viewer is a pain). The test is wrong. It should be testing for the Oracle plugin installed. > From jcpalmer at rochester.rr.com Fri Oct 26 09:09:43 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Fri, 26 Oct 2012 12:09:43 -0400 Subject: Is there a 24 hr production release warning DL? Message-ID: Was looking around on Java.net for some email distribution list, which sent out production release notifications BEFORE they actually occur. Actually, I could not even find a reference to any email lists. I do not remember any more how I added myself to this list. On the assumption that it does not exist, this is what might make things run smoother: 1) Production release message are sent 24 hrs prior to going live, or when known if earlier. This is coupled with some way to get the final release through alternate channels. A link pointing to the location would save time. 2) No one can generally send to this list This is not a place for two way communications. If you spot a problem, submit a bug, and/or use the lists like this or forums. 3) ea's should also be announced when they happen. When possible, there should also be release candidate ea with tight restriction rules on what can cause any change before the production release. Unless your job is actually making Java, who could retest all their products once a week against the latest ea on multiple platforms? Some of this information is probably gleanable today, but there has got to be an easier way. Would anyone else subscribe? Finally, on a Mac specific note: why is there no way to un-install the JRE under program control? I do not think you need to be able to run more than one JRE at a time, but say you load an ea & did your tests. How do you get it out? On Windows, I can just uninstall it (minus the regedit pointers), then reload the production one. On a side note I will NEVER EVER use the JRE control panel's facility to update my system again, Windows or Mac. If you download the media separately and keep it, then you have it if you missed something. It is gone from the website, AFAIK. Can just loading an older JRE always work as a substitute for uninstall? Thanks, Jeff From jcpalmer at rochester.rr.com Fri Oct 26 11:16:01 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Fri, 26 Oct 2012 14:16:01 -0400 Subject: Is there a 24 hr production release warning DL? In-Reply-To: References: Message-ID: Well did eventually find the list of lists , http://mail.openjdk.java.net/mailman/listinfo . The "announce" list might work, being tightly moderated. There was a message in October, but the 7u9 ea's or release not it. Anything wrong with using that one? On Oct 26, 2012, at 12:09 PM, Jeff Palmer wrote: > Was looking around on Java.net for some email distribution list, which sent out production release notifications BEFORE they actually occur. Actually, I could not even find a reference to any email lists. I do not remember any more how I added myself to this list. > > On the assumption that it does not exist, this is what might make things run smoother: > 1) Production release message are sent 24 hrs prior to going live, or when known if earlier. This is coupled with some way to get the final release through alternate channels. A link pointing to the location would save time. > 2) No one can generally send to this list This is not a place for two way communications. If you spot a problem, submit a bug, and/or use the lists like this or forums. > 3) ea's should also be announced when they happen. When possible, there should also be release candidate ea with tight restriction rules on what can cause any change before the production release. Unless your job is actually making Java, who could retest all their products once a week against the latest ea on multiple platforms? > > Some of this information is probably gleanable today, but there has got to be an easier way. Would anyone else subscribe? > > Finally, on a Mac specific note: why is there no way to un-install the JRE under program control? I do not think you need to be able to run more than one JRE at a time, but say you load an ea & did your tests. How do you get it out? On Windows, I can just uninstall it (minus the regedit pointers), then reload the production one. On a side note I will NEVER EVER use the JRE control panel's facility to update my system again, Windows or Mac. If you download the media separately and keep it, then you have it if you missed something. It is gone from the website, AFAIK. Can just loading an older JRE always work as a substitute for uninstall? > > Thanks, > > Jeff From Fabrizio.Giudici at tidalwave.it Fri Oct 26 11:32:20 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Fri, 26 Oct 2012 20:32:20 +0200 Subject: Is there a 24 hr production release warning DL? In-Reply-To: References: Message-ID: On Fri, 26 Oct 2012 20:16:01 +0200, Jeff Palmer wrote: > Well did eventually find the list of lists , > http://mail.openjdk.java.net/mailman/listinfo . The "announce" list > might work, being tightly moderated. There was a message in October, > but the 7u9 ea's or release not it. Anything wrong with using that one? I'm taking the opportunity of Jeff's email to say that I'm a bit puzzled about that. At the moment I'm focused about Mac OSX ports because I'm embedding the JRE with some apps and whenever I release a new version of the app I'd like to embed the latest JRE; and frankly whenever I go to http://code.google.com/p/openjdk-osx-build/ I can't tell which is actually the latest stable stuff to download. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From jcpalmer at rochester.rr.com Fri Oct 26 11:59:28 2012 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Fri, 26 Oct 2012 14:59:28 -0400 Subject: Is there a 24 hr production release warning DL? In-Reply-To: References: Message-ID: The place to get the JRE from is http://www.java.com/en/download/manual.jsp#mac . There is only current, hence never update thru control panel, and save your media from here. Are you are really trying to embed a JRE facsimile (minus plugin/webstart), by ripping out the compiler & other developer stuff of a JDK? That is from an Oracle page, though I do not have it right now. Jeff On Oct 26, 2012, at 2:32 PM, Fabrizio Giudici wrote: > On Fri, 26 Oct 2012 20:16:01 +0200, Jeff Palmer wrote: > >> Well did eventually find the list of lists , http://mail.openjdk.java.net/mailman/listinfo . The "announce" list might work, being tightly moderated. There was a message in October, but the 7u9 ea's or release not it. Anything wrong with using that one? > > I'm taking the opportunity of Jeff's email to say that I'm a bit puzzled about that. At the moment I'm focused about Mac OSX ports because I'm embedding the JRE with some apps and whenever I release a new version of the app I'd like to embed the latest JRE; and frankly whenever I go to http://code.google.com/p/openjdk-osx-build/ I can't tell which is actually the latest stable stuff to download. > > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From Fabrizio.Giudici at tidalwave.it Fri Oct 26 12:12:25 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Fri, 26 Oct 2012 21:12:25 +0200 Subject: Is there a 24 hr production release warning DL? In-Reply-To: References: Message-ID: On Fri, 26 Oct 2012 20:59:28 +0200, Jeff Palmer wrote: > The place to get the JRE from is > http://www.java.com/en/download/manual.jsp#mac . There is only current, > hence never update thru control panel, and save your media from here. This is Oracle JRE, I was referring to the open source build, which I prefer to use. > > Are you are really trying to embed a JRE facsimile (minus > plugin/webstart), by ripping out the compiler & other developer stuff of > a JDK? That is from an Oracle page, though I do not have it right now. I'm not trying, I'm just doing what the official appbundler tool does (http://java.net/projects/appbundler/). I don't know why, but it does require the full JDK and then takes the JRE from it. If at Oracle/Apple designed it in this way, I presume there's a reason. In any case, the problem is not just with the JDK or JRE, is with both. The latest time I looked at the google code page, for instance, I could see a 7u10. I suppose it's an early access. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From mik3hall at gmail.com Fri Oct 26 14:44:00 2012 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 26 Oct 2012 16:44:00 -0500 Subject: Is there a 24 hr production release warning DL? In-Reply-To: References: Message-ID: <1BFD583D-FE45-425C-BEC1-2F48A28691CE@gmail.com> On Oct 26, 2012, at 1:32 PM, Fabrizio Giudici wrote: > On Fri, 26 Oct 2012 20:16:01 +0200, Jeff Palmer wrote: > >> Well did eventually find the list of lists , http://mail.openjdk.java.net/mailman/listinfo . The "announce" list might work, being tightly moderated. There was a message in October, but the 7u9 ea's or release not it. Anything wrong with using that one? > > I'm taking the opportunity of Jeff's email to say that I'm a bit puzzled about that. At the moment I'm focused about Mac OSX ports because I'm embedding the JRE with some apps and whenever I release a new version of the app I'd like to embed the latest JRE; and frankly whenever I go to http://code.google.com/p/openjdk-osx-build/ I can't tell which is actually the latest stable stuff to download. Looking at that page again, http://code.google.com/p/openjdk-osx-build/ , it isn't appear it's going to be continued. Thanks for the effort Henri, I used your builds a couple times. Especially useful when I was still on a 32 bit machine and the mainstream project pulled the plug. Michael Hall trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter From Fabrizio.Giudici at tidalwave.it Fri Oct 26 15:04:46 2012 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Sat, 27 Oct 2012 00:04:46 +0200 Subject: Is there a 24 hr production release warning DL? In-Reply-To: <1BFD583D-FE45-425C-BEC1-2F48A28691CE@gmail.com> References: <1BFD583D-FE45-425C-BEC1-2F48A28691CE@gmail.com> Message-ID: On Fri, 26 Oct 2012 23:44:00 +0200, Michael Hall wrote: > Looking at that page again, http://code.google.com/p/openjdk-osx-build/ > , it isn't appear it's going to be continued. Hell! :-( -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From dalibor.topic at oracle.com Mon Oct 29 10:11:04 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 29 Oct 2012 18:11:04 +0100 Subject: Is there a 24 hr production release warning DL? In-Reply-To: References: Message-ID: <508EB8A8.3050901@oracle.com> You can download Oracle JDK 7 update developer preview builds here: http://jdk7.java.net/download.html They happen typically every week or few depending on where in a 7 update release cycle the release is. Latest is 7u10 Build b13, from October 24th. You can also find the next three dates for Oracle Java SE Critical Patch Updates here: http://www.oracle.com/technetwork/topics/security/alerts-086861.html -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 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 dalibor.topic at oracle.com Mon Oct 29 10:17:37 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 29 Oct 2012 18:17:37 +0100 Subject: Is there a 24 hr production release warning DL? In-Reply-To: References: Message-ID: <508EBA31.8020500@oracle.com> On 10/26/12 8:16 PM, Jeff Palmer wrote: > Well did eventually find the list of lists , http://mail.openjdk.java.net/mailman/listinfo . The "announce" list might work, being tightly moderated. There was a message in October, but the 7u9 ea's or release not it. Anything wrong with using that one? That list is for general, OpenJDK-wide announcements. Weekly builds of a specific project don't fit that bill. The list you're looking for is jdk7u-dev, which has announcements on schedules, etc. under subjects starting with [7u communication]. No EA build announcements, though, since we don't actually provide builds in OpenJDK, but you can follow along with the commit messages to see when a particular build's sources have been tagged, and attempt to build it yourself, if you like. Here's an example tag commit message: http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-September/004332.html -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 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 niagarasoft20-macosxportdev at yahoo.com Tue Oct 30 18:26:59 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Tue, 30 Oct 2012 18:26:59 -0700 (PDT) Subject: Build fails on vanilla Mountain Lion install In-Reply-To: <508EB8A8.3050901@oracle.com> References: <508EB8A8.3050901@oracle.com> Message-ID: <1351646819.22341.YahooMailNeo@web121805.mail.ne1.yahoo.com> Hello,? I'm trying to build the macport openJDK sources as described on this page: https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port I've followed the instructions described on the page but get stuck with a few errors regarding X11. I did install the XQuartz package and that got me a little further along however still getting errors as follows below. What am I missing? Mike -------------------------------------------------------------------------------------------------- In file included from ../../../src/share/native/sun/awt/../java2d/pipe/Region.h:34, ? ? ? ? ? ? ? ? ?from ../../../src/share/native/sun/awt/../java2d/pipe/Region.c:30: ../../../src/solaris/native/sun/awt/utility/rect.h:31:22: error: X11/Xlib.h: No such file or directory In file included from ../../../src/share/native/sun/awt/../java2d/pipe/Region.h:34, ? ? ? ? ? ? ? ? ?from ../../../src/share/native/sun/awt/../java2d/pipe/Region.c:30: ../../../src/solaris/native/sun/awt/utility/rect.h:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'RECT_T' ../../../src/solaris/native/sun/awt/utility/rect.h:51: error: expected declaration specifiers or '...' before 'RECT_T' In file included from ../../../src/share/native/sun/awt/../java2d/pipe/Region.c:30: ../../../src/share/native/sun/awt/../java2d/pipe/Region.h:211: error: expected declaration specifiers or '...' before 'RECT_T' ../../../src/share/native/sun/awt/../java2d/pipe/Region.c:243: error: expected declaration specifiers or '...' before 'RECT_T' ../../../src/share/native/sun/awt/../java2d/pipe/Region.c: In function 'RegionToYXBandedRectangles': ../../../src/share/native/sun/awt/../java2d/pipe/Region.c:254: error: 'pRect' undeclared (first use in this function) ../../../src/share/native/sun/awt/../java2d/pipe/Region.c:254: error: (Each undeclared identifier is reported only once ../../../src/share/native/sun/awt/../java2d/pipe/Region.c:254: error: for each function it appears in.) ../../../src/share/native/sun/awt/../java2d/pipe/Region.c:263: warning: comparison between signed and unsigned ../../../src/share/native/sun/awt/../java2d/pipe/Region.c:264: error: 'RECT_T' undeclared (first use in this function) ../../../src/share/native/sun/awt/../java2d/pipe/Region.c:264: error: expected expression before ')' token make[5]: *** [/Users/mnigrin/jdk7u-dev/build/macosx-x86_64/tmp/sun/sun.awt/awt/obj64/Region.o] Error 1 make[5]: *** Waiting for unfinished jobs.... In file included from ../../../src/solaris/native/sun/awt/color.h:28, ? ? ? ? ? ? ? ? ?from ../../../src/solaris/native/sun/awt/img_util_md.h:26, ? ? ? ? ? ? ? ? ?from ../../../src/share/native/sun/awt/image/BufImgSurfaceData.c:31: ../../../src/solaris/native/sun/awt/awt.h:38:27: error: X11/Intrinsic.h: No such file or directory In file included from ../../../src/solaris/native/sun/awt/color.h:28, ? ? ? ? ? ? ? ? ?from ../../../src/solaris/native/sun/awt/img_util_md.h:26, ? ? ? ? ? ? ? ? ?from ../../../src/share/native/sun/awt/image/BufImgSurfaceData.c:31: ../../../src/solaris/native/sun/awt/awt.h:162: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token ../../../src/solaris/native/sun/awt/awt.h:163: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'awt_ModLockIsShiftLock' In file included from ../../../src/solaris/native/sun/awt/img_util_md.h:26, ? ? ? ? ? ? ? ? ?from ../../../src/share/native/sun/awt/image/BufImgSurfaceData.c:31: ../../../src/solaris/native/sun/awt/color.h:34: error: expected specifier-qualifier-list before 'XPixmapFormatValues' In file included from ../../../src/share/native/sun/awt/image/BufImgSurfaceData.c:31: ../../../src/solaris/native/sun/awt/img_util_md.h:32: error: expected specifier-qualifier-list before 'XID' make[5]: *** [/Users/mnigrin/jdk7u-dev/build/macosx-x86_64/tmp/sun/sun.awt/awt/obj64/BufImgSurfaceData.o] Error 1 make[4]: *** [library_parallel_compile] Error 2 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [jdk-build] Error 2 make: *** [build_product_image] Error 2 From Sergey.Bylokhov at oracle.com Tue Oct 30 19:07:21 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 31 Oct 2012 06:07:21 +0400 Subject: Build fails on vanilla Mountain Lion install In-Reply-To: <1351646819.22341.YahooMailNeo@web121805.mail.ne1.yahoo.com> References: <508EB8A8.3050901@oracle.com> <1351646819.22341.YahooMailNeo@web121805.mail.ne1.yahoo.com> Message-ID: <509087D9.2000309@oracle.com> Hello. This steps works for me: http://mail.openjdk.java.net/pipermail/build-dev/2012-July/006506.html 31.10.2012 5:26, niagarasoft20-macosxportdev at yahoo.com wrote: > I've followed the instructions described on the page but get stuck with a few errors regarding X11. I did install the XQuartz package and that got me a little further along however still getting errors as follows below. What am I missing? -- Best regards, Sergey. From niagarasoft20-macosxportdev at yahoo.com Tue Oct 30 20:21:21 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Tue, 30 Oct 2012 20:21:21 -0700 (PDT) Subject: Build fails on vanilla Mountain Lion install In-Reply-To: <509087D9.2000309@oracle.com> References: <508EB8A8.3050901@oracle.com> <1351646819.22341.YahooMailNeo@web121805.mail.ne1.yahoo.com> <509087D9.2000309@oracle.com> Message-ID: <1351653681.14528.YahooMailNeo@web121805.mail.ne1.yahoo.com> Thanks that worked! >________________________________ > From: Sergey Bylokhov >To: "niagarasoft20-macosxportdev at yahoo.com" >Cc: "macosx-port-dev at openjdk.java.net" >Sent: Tuesday, October 30, 2012 10:07 PM >Subject: Re: Build fails on vanilla Mountain Lion install > >Hello. >This steps works for me: >http://mail.openjdk.java.net/pipermail/build-dev/2012-July/006506.html > >31.10.2012 5:26, niagarasoft20-macosxportdev at yahoo.com wrote: >> I've followed the instructions described on the page but get stuck with a few errors regarding X11. I did install the XQuartz package and that got me a little further along however still getting errors as follows below. What am I missing? > > >-- Best regards, Sergey. > > > > From leonid.romanov at oracle.com Wed Oct 31 15:43:12 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 1 Nov 2012 02:43:12 +0400 Subject: [8] Review request for 7124310: [macosx] "opposite" seems always null in focus events Message-ID: <962A66A3-1C8F-4649-98C1-82EE55D73DBE@oracle.com> Hi, Please review a fix for 7124310: [macosx] "opposite" seems always null in focus events. It's not a real bug, but something that hasn't been implemented yet: Cocoa focus notifications don't have information about "opposite" window, so we have to track it ourselves. Webrev: http://cr.openjdk.java.net/~leonidr/7124310/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124310 Thanks, Leonid.