From alexandr.scherbatiy at oracle.com Fri Feb 1 07:37:43 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 01 Feb 2013 19:37:43 +0400 Subject: NSOpenGLLayer animation issue under VNC Message-ID: <510BE147.7020706@oracle.com> Hello Mike, There is the issue 8005668 security control panel got greyed out when access Mac machine remotely using VNC http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005668 After a little investigation we have found that an animation does not work for the NSOpenGLLayer if a user uses VNC connection and the MAC OS X does not have connected monitors. Here are steps to reproduce which use only Cocoa application: - Connect to an Mac OS X with VNC - Detach all monitors from the Mac OS X (I used a Mac mini) - Run the code below The animation does not work The output shows that the drawInCGLContext method has been invoked only once or twice: ------------------------------------------------------------------ 2013-02-01 19:21:27.488 OpenGLLayerSample[1731:707] invalid drawable 2013-02-01 19:21:27.489 OpenGLLayerSample[1731:707] drawInCGLContext 2013-02-01 19:21:27.513 OpenGLLayerSample[1731:707] drawInCGLContext ------------------------------------------------------------------ Connection a monitor to the Mac OS X makes the animation work. It seems that it can have a relation to the issue 8005668 so the first time there is nothing to draw and next time nothing is drawn on a Java app. Is it a known issue and could it have a workaround? Thanks, Alexandr. ------------------------------------------------------------------ NSRect rect = NSMakeRect (200, 200, 300, 300); unsigned int styleMask = NSTitledWindowMask | NSMiniaturizableWindowMask; NSWindow *myWindow = [NSWindow alloc]; myWindow = [myWindow initWithContentRect: rect styleMask: styleMask backing: NSBackingStoreBuffered defer: NO]; NSView *view = [[NSView alloc] initWithFrame:rect]; view.layer = [CALayer layer]; view.wantsLayer = YES; CALayer *newLayer = [CALayer layer]; newLayer.backgroundColor = CGColorGetConstantColor(kCGColorBlack); newLayer.position = CGPointMake(150,150); newLayer.frame = NSMakeRect(100,100,100,100); [view.layer addSublayer:newLayer]; // do some custom GL drawing RotatingSquareGLLayer *caGLLayer = [RotatingSquareGLLayer layer]; caGLLayer.asynchronous = YES; //[caGLLayer drawsAsynchronously: YES]; caGLLayer.position = CGPointMake(150,150); caGLLayer.frame = NSMakeRect(100,100,100,100); caGLLayer.asynchronous = YES; [view.layer addSublayer:caGLLayer]; [myWindow setContentView: view]; [myWindow setTitle: @"Main Window"]; [myWindow makeKeyAndOrderFront: nil]; @interface RotatingSquareGLLayer : NSOpenGLLayer { } @end #import #import #import @implementation RotatingSquareGLLayer // override to draw custom GL content -(void)drawInCGLContext:(CGLContextObj)glContext pixelFormat:(CGLPixelFormatObj)pixelFormat forLayerTime:(CFTimeInterval)timeInterval displayTime:(const CVTimeStamp *)timeStamp { NSLog(@"drawInCGLContext"); //* // set the current context CGLSetCurrentContext(glContext); // draw a single red quad spinning around based on the current time GLfloat rotate = timeInterval * 60.0; // 60 degrees per second glClear(GL_COLOR_BUFFER_BIT); glMatrixMode(GL_MODELVIEW); glPushMatrix(); glRotatef(rotate, 0.0, 0.0, 1.0); glBegin(GL_QUADS); glColor3f(1.0, 0.0, 0.0); glVertex2f(-0.5, -0.5); glVertex2f(-0.5, 0.5); glVertex2f( 0.5, 0.5); glVertex2f( 0.5, -0.5); glEnd(); glPopMatrix(); //*/ // call super to finalize the drawing - by default all it does is call glFlush() [super drawInCGLContext:glContext pixelFormat:pixelFormat forLayerTime:timeInterval displayTime:timeStamp]; } @end ------------------------------------------------------------------ From alexandr.scherbatiy at oracle.com Fri Feb 1 07:48:50 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 01 Feb 2013 19:48:50 +0400 Subject: [8] Review request for 8007146 [macosx] Setting a display mode crashes JDK under VNC In-Reply-To: <510A84B3.3080500@oracle.com> References: <510A759A.6020303@oracle.com> <510A7805.1090707@oracle.com> <510A7F8B.50700@oracle.com> <510A84B3.3080500@oracle.com> Message-ID: <510BE3E2.2060800@oracle.com> Hi Anthony, The CGCompleteDisplayConfiguration documenation says that: ------------------------------------------- configRef: The display configuration with the desired changes. On return, this configuration is no longer valid. ------------------------------------------- https://developer.apple.com/library/mac/#documentation/graphicsimaging/reference/Quartz_Services_Ref/Reference/reference.html Should the configRef be manually released after the CGCompleteDisplayConfiguration method invocation? Releasing the configRef crashes the system in case if the CGCompleteDisplayConfiguration does not return successful result. Thanks, Alexandr. On 1/31/2013 6:50 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Thanks for info. Fix looks good to me. But I am not sure about > CFRelease removing, because "On return, this configuration is no > longer valid." is not clear. > > 31.01.2013 18:28, Alexander Scherbatiy wrote: >> On 1/31/2013 5:56 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> Could we check DM in setDisplayMode() against modes from >>> CGraphicsDevice.getDisplayModes() on java lvl? >> 1. We need to filter display modes which have width = 1 and >> height = 1 in the list returned by the CGDisplayCopyAllDisplayModes >> function. >> The code below reproduces the problem in pure Cocoa application: >> >> ------------------------------------------ >> - (void) test { >> int MAX_DISPLAYS = 100; >> CGDirectDisplayID displays[MAX_DISPLAYS]; >> uint32_t numDisplays; >> uint32_t i; >> CGGetActiveDisplayList(MAX_DISPLAYS, displays, &numDisplays); >> for(i=0; i> { >> CGDisplayModeRef mode; >> CFIndex index, count; >> CFArrayRef modeList; >> modeList=CGDisplayCopyAllDisplayModes(displays[i], NULL); >> count=CFArrayGetCount(modeList); >> NSLog(@"\n\nmode --"); >> for(index=0;index> { >> mode=(CGDisplayModeRef)CFArrayGetValueAtIndex(modeList, index); >> long h=0, w=0; >> h=CGDisplayModeGetHeight(mode); >> w=CGDisplayModeGetWidth(mode); >> uint32_t flags=CGDisplayModeGetIOFlags(mode); >> NSLog(@"flags: %d", flags); >> NSLog(@"w, h: %ld, %ld", w, h); >> } >> CFRelease(modeList); >> } >> >> } >> ------------------------------------------------ >> mode -- >> 2013-01-31 18:29:35.220 MyWindowTest[78789:707] flags: 7 >> 2013-01-31 18:29:35.221 MyWindowTest[78789:707] w, h: 1, 1 >> 2013-01-31 18:29:35.221 MyWindowTest[78789:707] flags: 7 >> 2013-01-31 18:29:35.222 MyWindowTest[78789:707] w, h: 1, 1 >> 2013-01-31 18:29:35.222 MyWindowTest[78789:707] flags: 7 >> 2013-01-31 18:29:35.223 MyWindowTest[78789:707] w, h: 1, 1 >> 2013-01-31 18:29:35.223 MyWindowTest[78789:707] flags: 7 >> 2013-01-31 18:29:35.223 MyWindowTest[78789:707] w, h: 1, 1 >> 2013-01-31 18:29:35.224 MyWindowTest[78789:707] flags: 7 >> 2013-01-31 18:29:35.224 MyWindowTest[78789:707] w, h: 1, 1 >> --------------------------------------------------------------------------- >> >> >> >> 2. The getBestModeForParameters method allows to set only those >> display methods which have the same width, height, and bit depth with >> the existed display modes. >> It seems that there is no need to check the display modes one more >> time on java level. >> >> Thanks, >> Alexandr. >> >> >> >>> >>> 31.01.2013 17:46, Alexander Scherbatiy wrote: >>>> >>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007146 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8007146/webrev.00 >>>> >>>> The issue is reproduced when a program is running under a VNC and >>>> all monitors are disconnected from the Mac OS X system. >>>> The CGDisplayCopyAllDisplayModes returns display modes with width >>>> and height equal to 1. >>>> CGCompleteDisplayConfiguration returns error when the invalid >>>> display mode is set and JDK crashes after releasing the display >>>> configuration. >>>> According to the CGCompleteDisplayConfiguration doc: "On return, >>>> this configuration is no longer valid." >>>> >>>> The fix filters the invalid display modes and does not release the >>>> display configuration. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >>> >> > > From anthony.petrov at oracle.com Fri Feb 1 07:59:02 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 01 Feb 2013 19:59:02 +0400 Subject: [8] Review request for 8007146 [macosx] Setting a display mode crashes JDK under VNC In-Reply-To: <510BE3E2.2060800@oracle.com> References: <510A759A.6020303@oracle.com> <510A7805.1090707@oracle.com> <510A7F8B.50700@oracle.com> <510A84B3.3080500@oracle.com> <510BE3E2.2060800@oracle.com> Message-ID: <510BE646.3060900@oracle.com> Hi Alexander, Given the remark about invalidity of the config on return of this function, I'd think a call to CFRelease is unneeded. E.g. see http://forum.openframeworks.cc/index.php?topic=5175.0 - they don't CFRelease() anything. -- best regards, Anthony On 2/1/2013 19:48, Alexander Scherbatiy wrote: > > Hi Anthony, > > The CGCompleteDisplayConfiguration documenation says that: > ------------------------------------------- > configRef: The display configuration with the desired changes. On > return, this configuration is no longer valid. > ------------------------------------------- > > https://developer.apple.com/library/mac/#documentation/graphicsimaging/reference/Quartz_Services_Ref/Reference/reference.html > > > Should the configRef be manually released after the > CGCompleteDisplayConfiguration method invocation? > Releasing the configRef crashes the system in case if the > CGCompleteDisplayConfiguration does not return successful result. > > Thanks, > Alexandr. > > > On 1/31/2013 6:50 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Thanks for info. Fix looks good to me. But I am not sure about >> CFRelease removing, because "On return, this configuration is no >> longer valid." is not clear. >> >> 31.01.2013 18:28, Alexander Scherbatiy wrote: >>> On 1/31/2013 5:56 PM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> Could we check DM in setDisplayMode() against modes from >>>> CGraphicsDevice.getDisplayModes() on java lvl? >>> 1. We need to filter display modes which have width = 1 and >>> height = 1 in the list returned by the CGDisplayCopyAllDisplayModes >>> function. >>> The code below reproduces the problem in pure Cocoa application: >>> >>> ------------------------------------------ >>> - (void) test { >>> int MAX_DISPLAYS = 100; >>> CGDirectDisplayID displays[MAX_DISPLAYS]; >>> uint32_t numDisplays; >>> uint32_t i; >>> CGGetActiveDisplayList(MAX_DISPLAYS, displays, &numDisplays); >>> for(i=0; i>> { >>> CGDisplayModeRef mode; >>> CFIndex index, count; >>> CFArrayRef modeList; >>> modeList=CGDisplayCopyAllDisplayModes(displays[i], NULL); >>> count=CFArrayGetCount(modeList); >>> NSLog(@"\n\nmode --"); >>> for(index=0;index>> { >>> mode=(CGDisplayModeRef)CFArrayGetValueAtIndex(modeList, index); >>> long h=0, w=0; >>> h=CGDisplayModeGetHeight(mode); >>> w=CGDisplayModeGetWidth(mode); >>> uint32_t flags=CGDisplayModeGetIOFlags(mode); >>> NSLog(@"flags: %d", flags); >>> NSLog(@"w, h: %ld, %ld", w, h); >>> } >>> CFRelease(modeList); >>> } >>> >>> } >>> ------------------------------------------------ >>> mode -- >>> 2013-01-31 18:29:35.220 MyWindowTest[78789:707] flags: 7 >>> 2013-01-31 18:29:35.221 MyWindowTest[78789:707] w, h: 1, 1 >>> 2013-01-31 18:29:35.221 MyWindowTest[78789:707] flags: 7 >>> 2013-01-31 18:29:35.222 MyWindowTest[78789:707] w, h: 1, 1 >>> 2013-01-31 18:29:35.222 MyWindowTest[78789:707] flags: 7 >>> 2013-01-31 18:29:35.223 MyWindowTest[78789:707] w, h: 1, 1 >>> 2013-01-31 18:29:35.223 MyWindowTest[78789:707] flags: 7 >>> 2013-01-31 18:29:35.223 MyWindowTest[78789:707] w, h: 1, 1 >>> 2013-01-31 18:29:35.224 MyWindowTest[78789:707] flags: 7 >>> 2013-01-31 18:29:35.224 MyWindowTest[78789:707] w, h: 1, 1 >>> --------------------------------------------------------------------------- >>> >>> >>> >>> 2. The getBestModeForParameters method allows to set only those >>> display methods which have the same width, height, and bit depth with >>> the existed display modes. >>> It seems that there is no need to check the display modes one more >>> time on java level. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> >>>> >>>> 31.01.2013 17:46, Alexander Scherbatiy wrote: >>>>> >>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007146 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8007146/webrev.00 >>>>> >>>>> The issue is reproduced when a program is running under a VNC and >>>>> all monitors are disconnected from the Mac OS X system. >>>>> The CGDisplayCopyAllDisplayModes returns display modes with width >>>>> and height equal to 1. >>>>> CGCompleteDisplayConfiguration returns error when the invalid >>>>> display mode is set and JDK crashes after releasing the display >>>>> configuration. >>>>> According to the CGCompleteDisplayConfiguration doc: "On return, >>>>> this configuration is no longer valid." >>>>> >>>>> The fix filters the invalid display modes and does not release the >>>>> display configuration. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>>> >>> >> >> > From jose.cornado at gmail.com Fri Feb 1 12:01:41 2013 From: jose.cornado at gmail.com (=?ISO-8859-1?Q?Jos=E9_Cornado?=) Date: Fri, 1 Feb 2013 13:01:41 -0700 Subject: Wildcard Generics/Inheritance Question Message-ID: Hello! Why an interface that extends another interface returns null when getSuperclass() is called? -- Jos? Cornado -- home: http://www.efekctive.com blog: http://blogging.efekctive.com ---------------------- Everything has been said before, but since nobody listens we have to keep going back and beginning all over again. Andre Gide From jose.cornado at gmail.com Fri Feb 1 12:03:22 2013 From: jose.cornado at gmail.com (=?ISO-8859-1?Q?Jos=E9_Cornado?=) Date: Fri, 1 Feb 2013 13:03:22 -0700 Subject: Wildcard Generics/Inheritance Question In-Reply-To: References: Message-ID: Never getInterfaces() does the trick. thanks anyway On Fri, Feb 1, 2013 at 1:01 PM, Jos? Cornado wrote: > Hello! > > Why an interface that extends another interface returns null when > getSuperclass() is called? > > -- > Jos? Cornado > > -- > > home: http://www.efekctive.com > blog: http://blogging.efekctive.com > ---------------------- > > Everything has been said before, but since nobody listens we have to keep > going back and beginning all over again. > > Andre Gide > -- Jos? Cornado -- home: http://www.efekctive.com blog: http://blogging.efekctive.com ---------------------- Everything has been said before, but since nobody listens we have to keep going back and beginning all over again. Andre Gide From paul_t100 at fastmail.fm Sun Feb 3 08:20:01 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sun, 03 Feb 2013 16:20:01 +0000 Subject: EventThread crashing with 1.7.0_12-ea-b08 In-Reply-To: References: Message-ID: <510E8E31.4040501@fastmail.fm> Using the latest early access version of Java macbook:jaikoz paul$ java -version java version "1.7.0_12-ea" Java(TM) SE Runtime Environment (build 1.7.0_12-ea-b08) Java HotSpot(TM) 64-Bit Server VM (build 24.0-b28, mixed mode) My application crashed on the Event Thread: ................................ ............................... Thread 24 Crashed:: Java: AWT-EventQueue-0 0 libsystem_kernel.dylib 0x00007fff9208a212 __pthread_kill + 10 1 libsystem_c.dylib 0x00007fff937cfaf4 pthread_kill + 90 2 libsystem_c.dylib 0x00007fff93813dce abort + 143 3 libjvm.dylib 0x0000000103f8ddfd os::abort(bool) + 25 4 libjvm.dylib 0x0000000104092506 VMError::report_and_die() + 2316 5 libjvm.dylib 0x0000000103f8f68f JVM_handle_bsd_signal + 1073 6 libsystem_c.dylib 0x00007fff937bc8ea _sigtramp + 26 7 libsystem_c.dylib 0x00007fff937e9e66 szone_free + 1922 8 com.apple.CoreFoundation 0x00007fff8f40ddd3 CFRelease + 1571 9 com.apple.CoreFoundation 0x00007fff8f439434 __CFBasicHashReplaceValue + 180 10 com.apple.CoreFoundation 0x00007fff8f411fbd CFDictionarySetValue + 189 11 libosxui.dylib 0x000000015e198728 Java_apple_laf_JRSUIControl_paintChangesImage + 154 12 ??? 0x0000000104897cd8 0 + 4371086552 13 ??? 0x000000010488b1d4 0 + 4371034580 14 ??? 0x0000000104a14d70 0 + 4372647280 ...................... ...................... Thread 24 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x0000000000000006 rcx: 0x000000016251daf8 rdx: 0x0000000000000000 rdi: 0x000000000000c603 rsi: 0x0000000000000006 rbp: 0x000000016251db20 rsp: 0x000000016251daf8 r8: 0x00007fff7b92e278 r9: 0x000000016251dad0 r10: 0x0000000020000000 r11: 0x0000000000000206 r12: 0x0000000104378f60 r13: 0x00000001039b1000 r14: 0x0000000162520000 r15: 0x0000000103f916de rip: 0x00007fff9208a212 rfl: 0x0000000000000206 cr2: 0x00007fff7b927fe8 Logical CPU: 0 I have the full output but have just posted the pertitent part here, is this a known bug, can anybody parse this ? The crash conditons cannot be reproduced, it seems to crash at random From swpalmer at gmail.com Sun Feb 3 08:42:12 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 3 Feb 2013 11:42:12 -0500 Subject: EventThread crashing with 1.7.0_12-ea-b08 In-Reply-To: <510E8E31.4040501@fastmail.fm> References: <510E8E31.4040501@fastmail.fm> Message-ID: I have seen similar crashes on the event thread (reported to Oracle's bug database just yesterday). Here's the relevant part of mine from 1.7.0_13: Crashed Thread: 21 Java: AWT-EventQueue-0 Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008 VM Regions Near 0x8: --> __TEXT 00000001037a4000-00000001037b5000 [ 68K] r-x/rwx SM=COW /Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home/bin/java Application Specific Information: *** error for object 0x7fa5be280a08: pointer being freed was not allocated Thread 21 Crashed:: Java: AWT-EventQueue-0 0 libsystem_kernel.dylib 0x00007fff903e6212 __pthread_kill + 10 1 libsystem_c.dylib 0x00007fff913d2af4 pthread_kill + 90 2 libsystem_c.dylib 0x00007fff91416dce abort + 143 3 libsystem_c.dylib 0x00007fff913ea959 free + 392 4 libdcpr.dylib 0x00000001599b3183 dcPool_endCycle + 219 5 libdcpr.dylib 0x00000001599b431b dcPathStore_reset + 136 6 libdcpr.dylib 0x00000001599bade5 reset + 52 7 libdcpr.dylib 0x00000001599b4bf5 Java_sun_dc_pr_PathFiller_reset + 59 8 ??? 0x00000001049f2a26 0 + 4372507174 9 ??? 0x0000000104a01b6c 0 + 4372568940 Regards, Scott On 2013-02-03, at 11:20 AM, Paul Taylor wrote: > Using the latest early access version of Java > > macbook:jaikoz paul$ java -version > java version "1.7.0_12-ea" > Java(TM) SE Runtime Environment (build 1.7.0_12-ea-b08) > Java HotSpot(TM) 64-Bit Server VM (build 24.0-b28, mixed mode) > > > My application crashed on the Event Thread: > > ................................ > > ............................... > Thread 24 Crashed:: Java: AWT-EventQueue-0 > 0 libsystem_kernel.dylib 0x00007fff9208a212 __pthread_kill + 10 > 1 libsystem_c.dylib 0x00007fff937cfaf4 pthread_kill + 90 > 2 libsystem_c.dylib 0x00007fff93813dce abort + 143 > 3 libjvm.dylib 0x0000000103f8ddfd os::abort(bool) + 25 > 4 libjvm.dylib 0x0000000104092506 VMError::report_and_die() + 2316 > 5 libjvm.dylib 0x0000000103f8f68f JVM_handle_bsd_signal + 1073 > 6 libsystem_c.dylib 0x00007fff937bc8ea _sigtramp + 26 > 7 libsystem_c.dylib 0x00007fff937e9e66 szone_free + 1922 > 8 com.apple.CoreFoundation 0x00007fff8f40ddd3 CFRelease + 1571 > 9 com.apple.CoreFoundation 0x00007fff8f439434 __CFBasicHashReplaceValue + 180 > 10 com.apple.CoreFoundation 0x00007fff8f411fbd CFDictionarySetValue + 189 > 11 libosxui.dylib 0x000000015e198728 Java_apple_laf_JRSUIControl_paintChangesImage + 154 > 12 ??? 0x0000000104897cd8 0 + 4371086552 > 13 ??? 0x000000010488b1d4 0 + 4371034580 > 14 ??? 0x0000000104a14d70 0 + 4372647280 > > ...................... > ...................... > > Thread 24 crashed with X86 Thread State (64-bit): > rax: 0x0000000000000000 rbx: 0x0000000000000006 rcx: 0x000000016251daf8 rdx: 0x0000000000000000 > rdi: 0x000000000000c603 rsi: 0x0000000000000006 rbp: 0x000000016251db20 rsp: 0x000000016251daf8 > r8: 0x00007fff7b92e278 r9: 0x000000016251dad0 r10: 0x0000000020000000 r11: 0x0000000000000206 > r12: 0x0000000104378f60 r13: 0x00000001039b1000 r14: 0x0000000162520000 r15: 0x0000000103f916de > rip: 0x00007fff9208a212 rfl: 0x0000000000000206 cr2: 0x00007fff7b927fe8 > Logical CPU: 0 > > I have the full output but have just posted the pertitent part here, is this a known bug, can anybody parse this ? > > The crash conditons cannot be reproduced, it seems to crash at random > From leonid.romanov at oracle.com Sun Feb 3 17:46:42 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 4 Feb 2013 05:46:42 +0400 Subject: EventThread crashing with 1.7.0_12-ea-b08 In-Reply-To: References: <510E8E31.4040501@fastmail.fm> Message-ID: Scott, Could you tell please what ID number has been assigned to your report? On Feb 3, 2013, at 8:42 PM, Scott Palmer wrote: > I have seen similar crashes on the event thread (reported to Oracle's bug database just yesterday). > Here's the relevant part of mine from 1.7.0_13: > > Crashed Thread: 21 Java: AWT-EventQueue-0 > > Exception Type: EXC_BAD_ACCESS (SIGABRT) > Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008 > > VM Regions Near 0x8: > --> > __TEXT 00000001037a4000-00000001037b5000 [ 68K] r-x/rwx SM=COW /Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home/bin/java > > Application Specific Information: > *** error for object 0x7fa5be280a08: pointer being freed was not allocated > > > Thread 21 Crashed:: Java: AWT-EventQueue-0 > 0 libsystem_kernel.dylib 0x00007fff903e6212 __pthread_kill + 10 > 1 libsystem_c.dylib 0x00007fff913d2af4 pthread_kill + 90 > 2 libsystem_c.dylib 0x00007fff91416dce abort + 143 > 3 libsystem_c.dylib 0x00007fff913ea959 free + 392 > 4 libdcpr.dylib 0x00000001599b3183 dcPool_endCycle + 219 > 5 libdcpr.dylib 0x00000001599b431b dcPathStore_reset + 136 > 6 libdcpr.dylib 0x00000001599bade5 reset + 52 > 7 libdcpr.dylib 0x00000001599b4bf5 Java_sun_dc_pr_PathFiller_reset + 59 > 8 ??? 0x00000001049f2a26 0 + 4372507174 > 9 ??? 0x0000000104a01b6c 0 + 4372568940 > > Regards, > > Scott > > On 2013-02-03, at 11:20 AM, Paul Taylor wrote: > >> Using the latest early access version of Java >> >> macbook:jaikoz paul$ java -version >> java version "1.7.0_12-ea" >> Java(TM) SE Runtime Environment (build 1.7.0_12-ea-b08) >> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b28, mixed mode) >> >> >> My application crashed on the Event Thread: >> >> ................................ >> >> ............................... >> Thread 24 Crashed:: Java: AWT-EventQueue-0 >> 0 libsystem_kernel.dylib 0x00007fff9208a212 __pthread_kill + 10 >> 1 libsystem_c.dylib 0x00007fff937cfaf4 pthread_kill + 90 >> 2 libsystem_c.dylib 0x00007fff93813dce abort + 143 >> 3 libjvm.dylib 0x0000000103f8ddfd os::abort(bool) + 25 >> 4 libjvm.dylib 0x0000000104092506 VMError::report_and_die() + 2316 >> 5 libjvm.dylib 0x0000000103f8f68f JVM_handle_bsd_signal + 1073 >> 6 libsystem_c.dylib 0x00007fff937bc8ea _sigtramp + 26 >> 7 libsystem_c.dylib 0x00007fff937e9e66 szone_free + 1922 >> 8 com.apple.CoreFoundation 0x00007fff8f40ddd3 CFRelease + 1571 >> 9 com.apple.CoreFoundation 0x00007fff8f439434 __CFBasicHashReplaceValue + 180 >> 10 com.apple.CoreFoundation 0x00007fff8f411fbd CFDictionarySetValue + 189 >> 11 libosxui.dylib 0x000000015e198728 Java_apple_laf_JRSUIControl_paintChangesImage + 154 >> 12 ??? 0x0000000104897cd8 0 + 4371086552 >> 13 ??? 0x000000010488b1d4 0 + 4371034580 >> 14 ??? 0x0000000104a14d70 0 + 4372647280 >> >> ...................... >> ...................... >> >> Thread 24 crashed with X86 Thread State (64-bit): >> rax: 0x0000000000000000 rbx: 0x0000000000000006 rcx: 0x000000016251daf8 rdx: 0x0000000000000000 >> rdi: 0x000000000000c603 rsi: 0x0000000000000006 rbp: 0x000000016251db20 rsp: 0x000000016251daf8 >> r8: 0x00007fff7b92e278 r9: 0x000000016251dad0 r10: 0x0000000020000000 r11: 0x0000000000000206 >> r12: 0x0000000104378f60 r13: 0x00000001039b1000 r14: 0x0000000162520000 r15: 0x0000000103f916de >> rip: 0x00007fff9208a212 rfl: 0x0000000000000206 cr2: 0x00007fff7b927fe8 >> Logical CPU: 0 >> >> I have the full output but have just posted the pertitent part here, is this a known bug, can anybody parse this ? >> >> The crash conditons cannot be reproduced, it seems to crash at random >> > From swpalmer at gmail.com Sun Feb 3 17:48:59 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 3 Feb 2013 20:48:59 -0500 Subject: EventThread crashing with 1.7.0_12-ea-b08 In-Reply-To: References: <510E8E31.4040501@fastmail.fm> Message-ID: "Your report has been assigned an internal review ID of 2437209." Cheers, Scott On 2013-02-03, at 8:46 PM, Leonid Romanov wrote: > Scott, > Could you tell please what ID number has been assigned to your report? > > On Feb 3, 2013, at 8:42 PM, Scott Palmer wrote: > >> I have seen similar crashes on the event thread (reported to Oracle's bug database just yesterday). >> Here's the relevant part of mine from 1.7.0_13: >> >> Crashed Thread: 21 Java: AWT-EventQueue-0 >> >> Exception Type: EXC_BAD_ACCESS (SIGABRT) >> Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008 >> >> VM Regions Near 0x8: >> --> >> __TEXT 00000001037a4000-00000001037b5000 [ 68K] r-x/rwx SM=COW /Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home/bin/java >> >> Application Specific Information: >> *** error for object 0x7fa5be280a08: pointer being freed was not allocated >> >> >> Thread 21 Crashed:: Java: AWT-EventQueue-0 >> 0 libsystem_kernel.dylib 0x00007fff903e6212 __pthread_kill + 10 >> 1 libsystem_c.dylib 0x00007fff913d2af4 pthread_kill + 90 >> 2 libsystem_c.dylib 0x00007fff91416dce abort + 143 >> 3 libsystem_c.dylib 0x00007fff913ea959 free + 392 >> 4 libdcpr.dylib 0x00000001599b3183 dcPool_endCycle + 219 >> 5 libdcpr.dylib 0x00000001599b431b dcPathStore_reset + 136 >> 6 libdcpr.dylib 0x00000001599bade5 reset + 52 >> 7 libdcpr.dylib 0x00000001599b4bf5 Java_sun_dc_pr_PathFiller_reset + 59 >> 8 ??? 0x00000001049f2a26 0 + 4372507174 >> 9 ??? 0x0000000104a01b6c 0 + 4372568940 >> >> Regards, >> >> Scott >> >> On 2013-02-03, at 11:20 AM, Paul Taylor wrote: >> >>> Using the latest early access version of Java >>> >>> macbook:jaikoz paul$ java -version >>> java version "1.7.0_12-ea" >>> Java(TM) SE Runtime Environment (build 1.7.0_12-ea-b08) >>> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b28, mixed mode) >>> >>> >>> My application crashed on the Event Thread: >>> >>> ................................ >>> >>> ............................... >>> Thread 24 Crashed:: Java: AWT-EventQueue-0 >>> 0 libsystem_kernel.dylib 0x00007fff9208a212 __pthread_kill + 10 >>> 1 libsystem_c.dylib 0x00007fff937cfaf4 pthread_kill + 90 >>> 2 libsystem_c.dylib 0x00007fff93813dce abort + 143 >>> 3 libjvm.dylib 0x0000000103f8ddfd os::abort(bool) + 25 >>> 4 libjvm.dylib 0x0000000104092506 VMError::report_and_die() + 2316 >>> 5 libjvm.dylib 0x0000000103f8f68f JVM_handle_bsd_signal + 1073 >>> 6 libsystem_c.dylib 0x00007fff937bc8ea _sigtramp + 26 >>> 7 libsystem_c.dylib 0x00007fff937e9e66 szone_free + 1922 >>> 8 com.apple.CoreFoundation 0x00007fff8f40ddd3 CFRelease + 1571 >>> 9 com.apple.CoreFoundation 0x00007fff8f439434 __CFBasicHashReplaceValue + 180 >>> 10 com.apple.CoreFoundation 0x00007fff8f411fbd CFDictionarySetValue + 189 >>> 11 libosxui.dylib 0x000000015e198728 Java_apple_laf_JRSUIControl_paintChangesImage + 154 >>> 12 ??? 0x0000000104897cd8 0 + 4371086552 >>> 13 ??? 0x000000010488b1d4 0 + 4371034580 >>> 14 ??? 0x0000000104a14d70 0 + 4372647280 >>> >>> ...................... >>> ...................... >>> >>> Thread 24 crashed with X86 Thread State (64-bit): >>> rax: 0x0000000000000000 rbx: 0x0000000000000006 rcx: 0x000000016251daf8 rdx: 0x0000000000000000 >>> rdi: 0x000000000000c603 rsi: 0x0000000000000006 rbp: 0x000000016251db20 rsp: 0x000000016251daf8 >>> r8: 0x00007fff7b92e278 r9: 0x000000016251dad0 r10: 0x0000000020000000 r11: 0x0000000000000206 >>> r12: 0x0000000104378f60 r13: 0x00000001039b1000 r14: 0x0000000162520000 r15: 0x0000000103f916de >>> rip: 0x00007fff9208a212 rfl: 0x0000000000000206 cr2: 0x00007fff7b927fe8 >>> Logical CPU: 0 >>> >>> I have the full output but have just posted the pertitent part here, is this a known bug, can anybody parse this ? >>> >>> The crash conditons cannot be reproduced, it seems to crash at random >>> >> > From leonid.romanov at oracle.com Mon Feb 4 13:16:57 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 5 Feb 2013 01:16:57 +0400 Subject: Status of Application.setDefaultMenuBar In-Reply-To: References: <522D32ED-0F0A-42CC-95FF-755972E9BF00@me.com> <50BF200C.3050204@oracle.com> <8B6006C8-903A-4080-B6EC-6249C3F6B2F4@me.com> Message-ID: Hi, Just FYI. Here is the link to your bug, so you know that it hasn't been lost: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007267 On Jan 30, 2013, at 6:51 AM, Bruce Johnson wrote: > Is there any news on this (that is, is anyone actually working on implementing the default menubar)? I never saw an actual bug generated for my report. Not having a default screen menubar is a real blocker for a decent Mac application. > > Bruce > > On Dec 5, 2012, at 1:16 PM, Bruce Johnson wrote: > >> I've filed a bug. The internal review code is: 2396618 >> >> cheers, >> >> Bruce >> >> On Dec 5, 2012, at 5:21 AM, Anthony Petrov wrote: >> >>> Hi Bruce, >>> >>> So, did you file a bug at bugs.sun.com about this issue yet? If not, you should do so. There's really nothing wrong with filing a bug even if it exists already - it will just be closed as a duplicate. >>> >>> A general rule: when in doubt - file a bug. >>> >>> PS. The JIRA instance you're referring to is no longer used to track JDK issues on the Mac. It might happen that the bug was filed after the migration had been completed, and thus it didn't make it to the real bug database. This is our fault that the JIRA project hasn't been made read-only after the migration. Sorry about that. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 12/4/2012 10:09 PM, Bruce Johnson wrote: >>>> I can't readily release my application for Java 1.7 on the Mac without support for Application.setDefaultMenuBar. This seems pretty important for anyone that wants their application to look like a native Mac application and the lack of it is a big step backwards relative to Java 1.6. >>>> Is there any hope that this will be supported in the "near future"? Or do we need to go back to the crazy old days of creating an identical, hidden, menubar for every window? >>>> Also, does anyone know if there is an actual bug filed for the lack of setDefaultMenuBar. I can't find anything in bugs.sun.com, though there was an item in the old Jira system: http://java.net/jira/browse/MACOSX_PORT-775. I thought all those bugs had been migrated to bugs.sun.com. >>>> Thanks for any info, >>>> Bruce >> > From maillists at lunddal.dk Tue Feb 5 03:33:25 2013 From: maillists at lunddal.dk (Jan Lunddal Larsen) Date: Tue, 5 Feb 2013 12:33:25 +0100 Subject: Deny file-read-data Message-ID: <9CF6D1B4-3EB9-4641-9120-C76CAC65B0E1@lunddal.dk> Hi, We have a Java Web Start app in our company, and printing is handled by making PDFs and opening them in the user's default app (usually Preview). But running the Web Start app in Java 7, the app can't open the PDFs if Preview isn't running. The following error appear in the system.log: Feb 5 12:31:25 lunddal.bruun-rasmussen.dk Preview[55965]: No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting Feb 5 12:31:25 lunddal com.apple.launchd.peruser.501[167] ([0x0-0xda24a17].com.apple.Preview[55965]): Exited with code: 1 Feb 5 12:31:25 lunddal kernel[0]: Sandbox: sandboxd(55966) deny mach-lookup com.apple.coresymbolicationd Feb 5 12:31:25 lunddal.bruun-rasmussen.dk sandboxd[55966] ([55965]): Preview(55965) deny file-read-data /Users/lunddal/Library/Application Support/Oracle/Java/Deployment/cache/6.0/bundles Feb 5 12:31:26 lunddal.bruun-rasmussen.dk WindowServer[51371]: kCGErrorIllegalArgument: _CGXRemoveWindowFromWindowMovementGroup: Window not in group The app uses 'open path/to/file' to open the PDFs. Best regards Jan Lunddal Larsen System Administrator & IT Support Manager Bruun Rasmussen Auctioneers Sundkrogsgade 30 ? DK-2100 Copenhagen Tel: +45 8818 1082 www.bruun-rasmussen.dk From maillists at lunddal.dk Tue Feb 5 04:49:25 2013 From: maillists at lunddal.dk (Jan Lunddal Larsen) Date: Tue, 5 Feb 2013 13:49:25 +0100 Subject: Deny file-read-data In-Reply-To: <9CF6D1B4-3EB9-4641-9120-C76CAC65B0E1@lunddal.dk> References: <9CF6D1B4-3EB9-4641-9120-C76CAC65B0E1@lunddal.dk> Message-ID: Hi again, It's just typical. We've fixed it just minutes after sending this e-mail :-) It seems to have been a bug in an earlier Java7 version, that's fixed in 7u13 (or perhaps earlier). By deleting the stub the Web Start app saves in ~/Library/Application Support/Oracle/Java/Deployment/cache/6.0/bundles, the new one it makes at the next launch can open Preview just fine. Best regards Jan Lunddal Larsen System Administrator & IT Support Manager Bruun Rasmussen Auctioneers Sundkrogsgade 30 ? DK-2100 Copenhagen Tel: +45 8818 1082 www.bruun-rasmussen.dk On 05/02/2013, at 12.33, Jan Lunddal Larsen wrote: > Hi, > > We have a Java Web Start app in our company, and printing is handled by making PDFs and opening them in the user's default app (usually Preview). > > But running the Web Start app in Java 7, the app can't open the PDFs if Preview isn't running. The following error appear in the system.log: > > Feb 5 12:31:25 lunddal.bruun-rasmussen.dk Preview[55965]: No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting > Feb 5 12:31:25 lunddal com.apple.launchd.peruser.501[167] ([0x0-0xda24a17].com.apple.Preview[55965]): Exited with code: 1 > Feb 5 12:31:25 lunddal kernel[0]: Sandbox: sandboxd(55966) deny mach-lookup com.apple.coresymbolicationd > Feb 5 12:31:25 lunddal.bruun-rasmussen.dk sandboxd[55966] ([55965]): Preview(55965) deny file-read-data /Users/lunddal/Library/Application Support/Oracle/Java/Deployment/cache/6.0/bundles > Feb 5 12:31:26 lunddal.bruun-rasmussen.dk WindowServer[51371]: kCGErrorIllegalArgument: _CGXRemoveWindowFromWindowMovementGroup: Window not in group > > The app uses 'open path/to/file' to open the PDFs. > > Best regards > > Jan Lunddal Larsen > System Administrator & IT Support Manager > > Bruun Rasmussen Auctioneers > Sundkrogsgade 30 ? DK-2100 Copenhagen > > Tel: +45 8818 1082 > www.bruun-rasmussen.dk From ajgregory at gmail.com Wed Feb 6 09:28:21 2013 From: ajgregory at gmail.com (AJ Gregory) Date: Wed, 6 Feb 2013 09:28:21 -0800 Subject: Java 7 and Application.setOpenURIHandler Message-ID: I have an app bundled with Java 7 (1.7.0_13) which registers a custom URL scheme using CFBundleURLSchemes in it's Info.plist and uses the Application.setOpenURIHandler to register a listener. When I click on a link that has the custom URL scheme in the browser it launches the app OK but doesn't call the handler and the following dump is in the console. I just submitted a bug on this as well. Thanks, -Aj 2/6/13 8:46:21.473 AM JavaAppLauncher[842]: ( 0 CoreFoundation 0x00007fff898200a6 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x00007fff840043f0 objc_exception_throw + 43 2 CoreFoundation 0x00007fff8981fe7c +[NSException raise:format:] + 204 3 Foundation 0x00007fff8c29f763 -[NSAppleEventDescriptor paramDescriptorForKeyword:] + 71 4 liblwawt.dylib 0x0000000168fb2b77 -[ApplicationDelegate _handleOpenURLEvent:withReplyEvent:] + 137 5 libosxapp.dylib 0x00000001690588b1 __-[QueuingApplicationDelegate _handleOpenURLEvent:withReplyEvent:]_block_invoke_1 + 135 6 libosxapp.dylib 0x00000001690597bf -[QueuingApplicationDelegate processQueuedEventsWithTargetDelegate:] + 134 7 libosxapp.dylib 0x0000000169057857 OSXAPP_SetApplicationDelegate + 153 8 liblwawt.dylib 0x0000000168fb1899 __+[AWTStarter start:swtMode:swtModeForWebStart:]_block_invoke_1 + 111 9 Foundation 0x00007fff8c2cf677 __NSThreadPerformPerform + 225 10 CoreFoundation 0x00007fff8979f101 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 11 CoreFoundation 0x00007fff8979ea25 __CFRunLoopDoSources0 + 245 12 CoreFoundation 0x00007fff897c1dc5 __CFRunLoopRun + 789 13 CoreFoundation 0x00007fff897c16b2 CFRunLoopRunSpecific + 290 14 HIToolbox 0x00007fff872880a4 RunCurrentEventLoopInMode + 209 15 HIToolbox 0x00007fff87287d84 ReceiveNextEventCommon + 166 16 HIToolbox 0x00007fff87287cd3 BlockUntilNextEventMatchingListInMode + 62 17 AppKit 0x00007fff8e331613 _DPSNextEvent + 685 18 AppKit 0x00007fff8e330ed2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 19 libosxapp.dylib 0x0000000169057b56 -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 20 AppKit 0x00007fff8e328283 -[NSApplication run] + 517 21 libosxapp.dylib 0x00000001690579b9 +[NSApplicationAWT runAWTLoopWithApp:] + 156 22 liblwawt.dylib 0x0000000168fb181a -[AWTStarter starter:] + 1591 23 Foundation 0x00007fff8c2cf677 __NSThreadPerformPerform + 225 24 CoreFoundation 0x00007fff8979f101 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 25 CoreFoundation 0x00007fff8979ea25 __CFRunLoopDoSources0 + 245 26 CoreFoundation 0x00007fff897c1dc5 __CFRunLoopRun + 789 27 CoreFoundation 0x00007fff897c16b2 CFRunLoopRunSpecific + 290 28 libjli.dylib 0x00000001001cb88d CreateExecutionEnvironment + 871 29 libjli.dylib 0x00000001001c603c JLI_Launch + 1952 30 JavaAppLauncher 0x00000001000629cb launch + 5035 31 JavaAppLauncher 0x00000001000614f6 main + 102 32 JavaAppLauncher 0x0000000100061484 start + 52 33 ??? 0x0000000000000002 0x0 + 2 ) From swingler at apple.com Wed Feb 6 09:29:37 2013 From: swingler at apple.com (Mike Swingler) Date: Wed, 06 Feb 2013 09:29:37 -0800 Subject: NSOpenGLLayer animation issue under VNC In-Reply-To: <510BE147.7020706@oracle.com> References: <510BE147.7020706@oracle.com> Message-ID: <1FD63AD4-3470-4017-9B94-CB2FAC19A2B6@apple.com> On Feb 1, 2013, at 7:37 AM, Alexander Scherbatiy wrote: > > Hello Mike, > > There is the issue 8005668 security control panel got greyed out when access Mac machine remotely using VNC > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005668 > > After a little investigation we have found that an animation does not work for the NSOpenGLLayer if a user uses VNC connection > and the MAC OS X does not have connected monitors. > > Here are steps to reproduce which use only Cocoa application: > - Connect to an Mac OS X with VNC > - Detach all monitors from the Mac OS X (I used a Mac mini) > - Run the code below > The animation does not work > > The output shows that the drawInCGLContext method has been invoked only once or twice: > ------------------------------------------------------------------ > 2013-02-01 19:21:27.488 OpenGLLayerSample[1731:707] invalid drawable > 2013-02-01 19:21:27.489 OpenGLLayerSample[1731:707] drawInCGLContext > 2013-02-01 19:21:27.513 OpenGLLayerSample[1731:707] drawInCGLContext > ------------------------------------------------------------------ > > Connection a monitor to the Mac OS X makes the animation work. > > It seems that it can have a relation to the issue 8005668 so the first time there is nothing to draw and next time nothing is drawn on a Java app. > Is it a known issue and could it have a workaround? This does appear to be a bug in the OS - you should see some an animation when you are screen-shared into the machine. Please file a bug at , and let me know what the bug ID is so I can ensure that it gets to the correct team. Thanks, Mike Swingler Apple Inc. From alexandr.scherbatiy at oracle.com Thu Feb 7 05:49:33 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 07 Feb 2013 17:49:33 +0400 Subject: NSOpenGLLayer animation issue under VNC In-Reply-To: <1FD63AD4-3470-4017-9B94-CB2FAC19A2B6@apple.com> References: <510BE147.7020706@oracle.com> <1FD63AD4-3470-4017-9B94-CB2FAC19A2B6@apple.com> Message-ID: <5113B0ED.6040105@oracle.com> Hello Mike, I have created the issue on http://bugreporter.apple.com with the bug ID 13170906 . Thanks, Alexandr. On 2/6/2013 9:29 PM, Mike Swingler wrote: > On Feb 1, 2013, at 7:37 AM, Alexander Scherbatiy wrote: > >> Hello Mike, >> >> There is the issue 8005668 security control panel got greyed out when access Mac machine remotely using VNC >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005668 >> >> After a little investigation we have found that an animation does not work for the NSOpenGLLayer if a user uses VNC connection >> and the MAC OS X does not have connected monitors. >> >> Here are steps to reproduce which use only Cocoa application: >> - Connect to an Mac OS X with VNC >> - Detach all monitors from the Mac OS X (I used a Mac mini) >> - Run the code below >> The animation does not work >> >> The output shows that the drawInCGLContext method has been invoked only once or twice: >> ------------------------------------------------------------------ >> 2013-02-01 19:21:27.488 OpenGLLayerSample[1731:707] invalid drawable >> 2013-02-01 19:21:27.489 OpenGLLayerSample[1731:707] drawInCGLContext >> 2013-02-01 19:21:27.513 OpenGLLayerSample[1731:707] drawInCGLContext >> ------------------------------------------------------------------ >> >> Connection a monitor to the Mac OS X makes the animation work. >> >> It seems that it can have a relation to the issue 8005668 so the first time there is nothing to draw and next time nothing is drawn on a Java app. >> Is it a known issue and could it have a workaround? > This does appear to be a bug in the OS - you should see some an animation when you are screen-shared into the machine. Please file a bug at, and let me know what the bug ID is so I can ensure that it gets to the correct team. > > Thanks, > Mike Swingler > Apple Inc. > From alexandr.scherbatiy at oracle.com Thu Feb 7 06:27:41 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 07 Feb 2013 18:27:41 +0400 Subject: [8] Review request for 8007146 [macosx] Setting a display mode crashes JDK under VNC In-Reply-To: <510BE646.3060900@oracle.com> References: <510A759A.6020303@oracle.com> <510A7805.1090707@oracle.com> <510A7F8B.50700@oracle.com> <510A84B3.3080500@oracle.com> <510BE3E2.2060800@oracle.com> <510BE646.3060900@oracle.com> Message-ID: <5113B9DD.3060308@oracle.com> Hello Mike, There is one more issue that has been discovered on Mac OS under VNC if all monitors are disconnected. The CGDisplayCopyAllDisplayModes returns display modes with width and height equal to 1. Should I create an apple issue on it? One more question that is not clear for us from the documentation: ------------------------------------------- configRef: The display configuration with the desired changes. On return, this configuration is no longer valid. ------------------------------------------- https://developer.apple.com/library/mac/#documentation/graphicsimaging/reference/Quartz_Services_Ref/Reference/reference.html Should the configRef be manually released after the CGCompleteDisplayConfiguration method invocation? Thanks, Alexandr. On 2/1/2013 7:59 PM, Anthony Petrov wrote: > Hi Alexander, > > Given the remark about invalidity of the config on return of this > function, I'd think a call to CFRelease is unneeded. > > E.g. see http://forum.openframeworks.cc/index.php?topic=5175.0 - they > don't CFRelease() anything. > > -- > best regards, > Anthony > > On 2/1/2013 19:48, Alexander Scherbatiy wrote: >> >> Hi Anthony, >> >> The CGCompleteDisplayConfiguration documenation says that: >> ------------------------------------------- >> configRef: The display configuration with the desired changes. On >> return, this configuration is no longer valid. >> ------------------------------------------- >> >> https://developer.apple.com/library/mac/#documentation/graphicsimaging/reference/Quartz_Services_Ref/Reference/reference.html >> >> >> Should the configRef be manually released after the >> CGCompleteDisplayConfiguration method invocation? >> Releasing the configRef crashes the system in case if the >> CGCompleteDisplayConfiguration does not return successful result. >> >> Thanks, >> Alexandr. >> >> >> On 1/31/2013 6:50 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> Thanks for info. Fix looks good to me. But I am not sure about >>> CFRelease removing, because "On return, this configuration is no >>> longer valid." is not clear. >>> >>> 31.01.2013 18:28, Alexander Scherbatiy wrote: >>>> On 1/31/2013 5:56 PM, Sergey Bylokhov wrote: >>>>> Hi, Alexander. >>>>> Could we check DM in setDisplayMode() against modes from >>>>> CGraphicsDevice.getDisplayModes() on java lvl? >>>> 1. We need to filter display modes which have width = 1 and >>>> height = 1 in the list returned by the CGDisplayCopyAllDisplayModes >>>> function. >>>> The code below reproduces the problem in pure Cocoa application: >>>> >>>> ------------------------------------------ >>>> - (void) test { >>>> int MAX_DISPLAYS = 100; >>>> CGDirectDisplayID displays[MAX_DISPLAYS]; >>>> uint32_t numDisplays; >>>> uint32_t i; >>>> CGGetActiveDisplayList(MAX_DISPLAYS, displays, &numDisplays); >>>> for(i=0; i>>> { >>>> CGDisplayModeRef mode; >>>> CFIndex index, count; >>>> CFArrayRef modeList; >>>> modeList=CGDisplayCopyAllDisplayModes(displays[i], NULL); >>>> count=CFArrayGetCount(modeList); >>>> NSLog(@"\n\nmode --"); >>>> for(index=0;index>>> { >>>> mode=(CGDisplayModeRef)CFArrayGetValueAtIndex(modeList, index); >>>> long h=0, w=0; >>>> h=CGDisplayModeGetHeight(mode); >>>> w=CGDisplayModeGetWidth(mode); >>>> uint32_t flags=CGDisplayModeGetIOFlags(mode); >>>> NSLog(@"flags: %d", flags); >>>> NSLog(@"w, h: %ld, %ld", w, h); >>>> } >>>> CFRelease(modeList); >>>> } >>>> >>>> } >>>> ------------------------------------------------ >>>> mode -- >>>> 2013-01-31 18:29:35.220 MyWindowTest[78789:707] flags: 7 >>>> 2013-01-31 18:29:35.221 MyWindowTest[78789:707] w, h: 1, 1 >>>> 2013-01-31 18:29:35.221 MyWindowTest[78789:707] flags: 7 >>>> 2013-01-31 18:29:35.222 MyWindowTest[78789:707] w, h: 1, 1 >>>> 2013-01-31 18:29:35.222 MyWindowTest[78789:707] flags: 7 >>>> 2013-01-31 18:29:35.223 MyWindowTest[78789:707] w, h: 1, 1 >>>> 2013-01-31 18:29:35.223 MyWindowTest[78789:707] flags: 7 >>>> 2013-01-31 18:29:35.223 MyWindowTest[78789:707] w, h: 1, 1 >>>> 2013-01-31 18:29:35.224 MyWindowTest[78789:707] flags: 7 >>>> 2013-01-31 18:29:35.224 MyWindowTest[78789:707] w, h: 1, 1 >>>> --------------------------------------------------------------------------- >>>> >>>> >>>> >>>> 2. The getBestModeForParameters method allows to set only those >>>> display methods which have the same width, height, and bit depth >>>> with the existed display modes. >>>> It seems that there is no need to check the display modes one >>>> more time on java level. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> >>>>> >>>>> 31.01.2013 17:46, Alexander Scherbatiy wrote: >>>>>> >>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007146 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8007146/webrev.00 >>>>>> >>>>>> The issue is reproduced when a program is running under a VNC and >>>>>> all monitors are disconnected from the Mac OS X system. >>>>>> The CGDisplayCopyAllDisplayModes returns display modes with width >>>>>> and height equal to 1. >>>>>> CGCompleteDisplayConfiguration returns error when the invalid >>>>>> display mode is set and JDK crashes after releasing the display >>>>>> configuration. >>>>>> According to the CGCompleteDisplayConfiguration doc: "On return, >>>>>> this configuration is no longer valid." >>>>>> >>>>>> The fix filters the invalid display modes and does not release >>>>>> the display configuration. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>> >>>>> >>>> >>> >>> >> From philip.race at oracle.com Fri Feb 8 14:10:12 2013 From: philip.race at oracle.com (Phil Race) Date: Fri, 08 Feb 2013 14:10:12 -0800 Subject: Please review a fix for 8007748: MacOSX build error : cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is deprecated; use sel_getName instead Message-ID: <511577C4.6080603@oracle.com> People building with the latest xcode seem to be hitting the error in the subject line. I think the error message is misleading about the solution and I propose the fix below. Does it look OK ? I'm not really sure where to send this for review but I think the porting alias is likely to have more people who would know what is right than any of the other lists. Here's a pointer to the full bug http://bugs.sun.com/view_bug.do?bug_id=8007748 diff --git a/src/macosx/native/jobjc/src/core/native/SEL.m b/src/macosx/native/jobjc/src/core/native/SEL.m --- a/src/macosx/native/jobjc/src/core/native/SEL.m +++ b/src/macosx/native/jobjc/src/core/native/SEL.m @@ -34,7 +34,7 @@ const char *selNameAsChars = (*env)->GetStringUTFChars(env, selName, JNI_FALSE); const SEL sel = sel_registerName(selNameAsChars); (*env)->ReleaseStringUTFChars(env, selName, selNameAsChars); - return ptr_to_jlong(sel); + return ptr_to_jlong((void*)sel); } JNIEXPORT jstring JNICALL Java_com_apple_jobjc_SEL_getSelectorName From timo.tommila at me.com Sun Feb 10 06:04:29 2013 From: timo.tommila at me.com (Timo Tommila) Date: Sun, 10 Feb 2013 16:04:29 +0200 Subject: Printing problem on Mountain Lion with java7 Message-ID: <66ED375C-3BAC-4879-8862-9E4A41F1C2B7@me.com> Hi, Printing on Mountain Lion with java7 is not working correctly! If I try to change font family, font size or to use bold effect etc, I always get the same 'unknown' font, the font size is fixed and the bold effect is not applied. The code works correctly on XP with java7 on the same MacBook Pro (with help of VMWare) and of course the code works also on windows PC. Is this a known bug? I am using following setup: java version "1.7.0_13" Java(TM) SE Runtime Environment (build 1.7.0_13-b20) Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) MacOSX 10.8.2 Timo ps. You will find the test code below: _________________________________________________________________ package printingtest; import java.awt.*; import java.awt.print.*; import javax.print.*; import javax.print.attribute.*; import javax.print.attribute.standard.*; public class PrintingTest implements Printable { public PrintingTest() { PrintRequestAttributeSet aset = new HashPrintRequestAttributeSet(); aset.add(new JobName("Test printing job", null)); PrinterJob pj = PrinterJob.getPrinterJob(); pj.setPrintable(this); PrintService[] services = PrinterJob.lookupPrintServices(); if (services.length > 0) { try { pj.setPrintService(services[0]); pj.pageDialog(aset); if (pj.printDialog(aset)) pj.print(aset); } catch (PrinterException pe) {} } } Font titleFont = new Font("Times", Font.BOLD, 24); Font textFont = new Font("monospaced", Font.PLAIN, 12); Font signatureFont = new Font("Serif", Font.PLAIN, 7); public int print(Graphics g, PageFormat pf, int pageIndex) { if (pageIndex == 0) { Graphics2D g2d = (Graphics2D) g; g2d.translate(pf.getImageableX(), pf.getImageableY()); g2d.setFont(titleFont); g2d.drawString("Title string in Times(24,bold)", 150, 260); g2d.setFont(textFont); g2d.drawString("Text string in monospaced(12)", 150, 280); g2d.setFont(signatureFont); g2d.drawString("Signature string in Serif(7)", 150, 300); return Printable.PAGE_EXISTS; } else return Printable.NO_SUCH_PAGE; } public static void main(String arg[]) { PrintingTest sp = new PrintingTest(); } } From anthony.petrov at oracle.com Mon Feb 11 06:01:49 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 11 Feb 2013 18:01:49 +0400 Subject: Please review a fix for 8007748: MacOSX build error : cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is deprecated; use sel_getName instead In-Reply-To: <511577C4.6080603@oracle.com> References: <511577C4.6080603@oracle.com> Message-ID: <5118F9CD.2080906@oracle.com> The code can run into a problem if Apple change the underlying type of SEL to something completely different (and larger) than a void* pointer. However, I think this is unlikely to happen. The evaluation sounds reasonable to me, so consider the fix reviewed. -- best regards, Anthony On 02/09/13 02:10, Phil Race wrote: > People building with the latest xcode seem to be hitting the error in > the subject line. > I think the error message is misleading about the solution and I propose > the fix below. > Does it look OK ? > I'm not really sure where to send this for review but I think the porting > alias is likely to have more people who would know what is right than > any of the other lists. > > Here's a pointer to the full bug > http://bugs.sun.com/view_bug.do?bug_id=8007748 > > diff --git a/src/macosx/native/jobjc/src/core/native/SEL.m > b/src/macosx/native/jobjc/src/core/native/SEL.m > --- a/src/macosx/native/jobjc/src/core/native/SEL.m > +++ b/src/macosx/native/jobjc/src/core/native/SEL.m > @@ -34,7 +34,7 @@ > const char *selNameAsChars = (*env)->GetStringUTFChars(env, selName, > JNI_FALSE); > const SEL sel = sel_registerName(selNameAsChars); > (*env)->ReleaseStringUTFChars(env, selName, selNameAsChars); > - return ptr_to_jlong(sel); > + return ptr_to_jlong((void*)sel); > } > > JNIEXPORT jstring JNICALL Java_com_apple_jobjc_SEL_getSelectorName From david.dehaven at oracle.com Wed Feb 13 09:32:29 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 13 Feb 2013 09:32:29 -0800 Subject: Please review a fix for 8007748: MacOSX build error : cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is deprecated; use sel_getName instead In-Reply-To: <5118F9CD.2080906@oracle.com> References: <511577C4.6080603@oracle.com> <5118F9CD.2080906@oracle.com> Message-ID: <38A7ACA0-788E-4122-9477-864665814D8E@oracle.com> SEL is defined thusly: typedef struct objc_selector *SEL; I would have a hard time believing Apple could change that without breaking everything that's currently written in Objective-C. The opaque parts could change, which is likely why the warning is showing up, or maybe they're just enforcing better coding practices. -DrD- > The code can run into a problem if Apple change the underlying type of SEL to something completely different (and larger) than a void* pointer. However, I think this is unlikely to happen. > > The evaluation sounds reasonable to me, so consider the fix reviewed. > > -- > best regards, > Anthony > > On 02/09/13 02:10, Phil Race wrote: >> People building with the latest xcode seem to be hitting the error in >> the subject line. >> I think the error message is misleading about the solution and I propose >> the fix below. >> Does it look OK ? >> I'm not really sure where to send this for review but I think the porting >> alias is likely to have more people who would know what is right than >> any of the other lists. >> >> Here's a pointer to the full bug >> http://bugs.sun.com/view_bug.do?bug_id=8007748 >> >> diff --git a/src/macosx/native/jobjc/src/core/native/SEL.m >> b/src/macosx/native/jobjc/src/core/native/SEL.m >> --- a/src/macosx/native/jobjc/src/core/native/SEL.m >> +++ b/src/macosx/native/jobjc/src/core/native/SEL.m >> @@ -34,7 +34,7 @@ >> const char *selNameAsChars = (*env)->GetStringUTFChars(env, selName, >> JNI_FALSE); >> const SEL sel = sel_registerName(selNameAsChars); >> (*env)->ReleaseStringUTFChars(env, selName, selNameAsChars); >> - return ptr_to_jlong(sel); >> + return ptr_to_jlong((void*)sel); >> } >> >> JNIEXPORT jstring JNICALL Java_com_apple_jobjc_SEL_getSelectorName From steve.x.northover at oracle.com Wed Feb 13 12:23:18 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 13 Feb 2013 15:23:18 -0500 Subject: SWT with Java 7 on Mac In-Reply-To: <51026B8D.9020905@oracle.com> References: <51026B8D.9020905@oracle.com> Message-ID: <511BF636.8090800@oracle.com> Nicholas, Did you file a bug at Eclipse.org for: - Oracle Bug #2366830 (no link cause doesn't show up in bug database) SWT app using AWT does not receive Dock's Quit event Steve On 25/01/2013 6:25 AM, Anthony Petrov wrote: > Hi Nicholas, > > Since the issues arise when using SWT, I suggest to start with filing > a bug against SWT. If engineers working on the SWT issue diagnose the > problem and conclude that this is a JDK bug, they will file a > corresponding bug report against JDK then. > > -- > best regards, > Anthony > > On 1/24/2013 17:05, Nicholas Rahn wrote: >> Hi. I've submitted a number of bugs relating to using SWT with Java7 >> on the >> Mac (see below) and am looking for advice on finding the right path to >> getting them fixed. >> >> The general problem, as I see it, is that it's not really clear if the >> issues are in SWT or in Java 7, and thus which development group to >> ask for >> advice on fixing them. None of the issues are present when using the >> Apple-provided Java6, so it seems possible that things need to be >> resolved >> in Java 7. On the other hand, because the issues arise when using SWT, >> perhaps the problems actually need to be addressed there, to >> compensate for >> changes in Java 7. >> >> Here's the list of bug. >> >> - Oracle Bug #2366830 (no link cause doesn't show up in bug >> database) SWT >> app using AWT does not receive Dock's Quit event >> >> - https://bugs.eclipse.org/bugs/show_bug.cgi?id=389486 App freeze when >> going fullscreen using Java 7 on Mac >> >> - https://bugs.eclipse.org/bugs/show_bug.cgi?id=388886 Table/tree >> rubber >> banding does not work with Java 7 on Mac >> >> >> The first one (submitted to Oracle) is a show-stopper for bundling >> Java 7 >> with an app, imho. >> >> So my questions is, what's the best way to attack these bugs? From >> the SWT >> side or from the Java 7 side? >> >> Thanks for any help and advice. >> Nick From nick at transparentech.com Wed Feb 13 12:28:20 2013 From: nick at transparentech.com (Nicholas Rahn) Date: Wed, 13 Feb 2013 21:28:20 +0100 Subject: SWT with Java 7 on Mac In-Reply-To: <511BF636.8090800@oracle.com> References: <51026B8D.9020905@oracle.com> <511BF636.8090800@oracle.com> Message-ID: Yes, I did. Here's the link: https://bugs.eclipse.org/bugs/show_bug.cgi?id=399091 Sorry about not posting this before. Nick On Wed, Feb 13, 2013 at 9:23 PM, wrote: > Nicholas, > > Did you file a bug at Eclipse.org for: > > > - Oracle Bug #2366830 (no link cause doesn't show up in bug database) SWT > app using AWT does not receive Dock's Quit event > > Steve > > > On 25/01/2013 6:25 AM, Anthony Petrov wrote: > >> Hi Nicholas, >> >> Since the issues arise when using SWT, I suggest to start with filing a >> bug against SWT. If engineers working on the SWT issue diagnose the problem >> and conclude that this is a JDK bug, they will file a corresponding bug >> report against JDK then. >> >> -- >> best regards, >> Anthony >> >> On 1/24/2013 17:05, Nicholas Rahn wrote: >> >>> Hi. I've submitted a number of bugs relating to using SWT with Java7 on >>> the >>> Mac (see below) and am looking for advice on finding the right path to >>> getting them fixed. >>> >>> The general problem, as I see it, is that it's not really clear if the >>> issues are in SWT or in Java 7, and thus which development group to ask >>> for >>> advice on fixing them. None of the issues are present when using the >>> Apple-provided Java6, so it seems possible that things need to be >>> resolved >>> in Java 7. On the other hand, because the issues arise when using SWT, >>> perhaps the problems actually need to be addressed there, to compensate >>> for >>> changes in Java 7. >>> >>> Here's the list of bug. >>> >>> - Oracle Bug #2366830 (no link cause doesn't show up in bug database) >>> SWT >>> app using AWT does not receive Dock's Quit event >>> >>> - https://bugs.eclipse.org/bugs/**show_bug.cgi?id=389486 App freeze when >>> going fullscreen using Java 7 on Mac >>> >>> - https://bugs.eclipse.org/bugs/**show_bug.cgi?id=388886 Table/tree rubber >>> banding does not work with Java 7 on Mac >>> >>> >>> The first one (submitted to Oracle) is a show-stopper for bundling Java 7 >>> with an app, imho. >>> >>> So my questions is, what's the best way to attack these bugs? From the >>> SWT >>> side or from the Java 7 side? >>> >>> Thanks for any help and advice. >>> Nick >>> >> From hadrabap at gmail.com Thu Feb 14 04:24:52 2013 From: hadrabap at gmail.com (Petr Hadraba) Date: Thu, 14 Feb 2013 13:24:52 +0100 Subject: Build Issues on OS X Message-ID: Dear guys, sorry to bother you, but I would like to get a bit more involved into the JDK world. I decided to start with JDK7-dev repository. But I'm unable to compile JObjC native component. I've followed Your instructions; I've set up all the necessary tools and theirs respective versions. The sanity check completes successfully. My configuration: - OS X 10.7.5 - Xcode 4.6 incl. CLI tools I tried both JDK7u13 and JDK6u37 as bootstrap JDK with the same result. It seems I have misconfigured something. Could you please point me somewhere where I can get more information about this issue? Thanks in advance and sorry if this is something stupid. Sincerely Yours, PETR [exec] === BUILD NATIVE TARGET build-core-native OF PROJECT JObjC WITH CONFIGURATION Debug === [exec] Check dependencies [exec] [exec] CompileC /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.o src/core/native/SEL.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler [exec] cd /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc [exec] setenv LANG en_US.US-ASCII [exec] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch i386 -fmessage-length=0 -fobjc-gc -Wno-trigraphs -fpascal-strings -Os -Werror -Werror-implicit-function-declaration -Wno-missing-field-initializers -Wmissing-prototypes -Wreturn-type -Wno-implicit-atomic-properties -Wno-receiver-is-weak -Wformat -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-empty-body -Wuninitialized -Wunknown-pragmas -Wshadow -Wfour-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion -Wsign-compare -Wshorten-64-to-32 -Wpointer-sign -Wnewline-eof -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -Wno-deprecated-implementations -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/JObjC.hmap -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/include -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/src/jni_headers/core -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.build/src/jni_headers/core -I/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources/i386 -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -Wformat -Wformat-security -Wcast-align -Wwrite-strings -Wuninitialized -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wpointer-arith -Wall -F/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug -F/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks -MMD -MT dependencies -MF /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.d --serialize-diagnostics /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.dia -c /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/SEL.m -o /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.o [exec] /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/SEL.m:37:12: error: cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is deprecated; use sel_getName instead [-Werror,-Wcast-of-sel-type] [exec] return ptr_to_jlong(sel); [exec] ^~~~~~~~~~~~~~~~~ [exec] /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Headers/JNFJNI.h:42:44: note: expanded from macro 'ptr_to_jlong' [exec] #define ptr_to_jlong(a) ((jlong)(uintptr_t)(a)) [exec] ^~~ [exec] 1 error generated. [exec] [exec] CompileC /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/FFIType.o src/core/native/FFIType.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler [exec] cd /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc [exec] setenv LANG en_US.US-ASCII [exec] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch x86_64 -fmessage-length=0 -fobjc-gc -Wno-trigraphs -fpascal-strings -Os -Werror -Werror-implicit-function-declaration -Wno-missing-field-initializers -Wmissing-prototypes -Wreturn-type -Wno-implicit-atomic-properties -Wno-receiver-is-weak -Wformat -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-empty-body -Wuninitialized -Wunknown-pragmas -Wshadow -Wfour-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion -Wsign-compare -Wshorten-64-to-32 -Wpointer-sign -Wnewline-eof -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -Wno-deprecated-implementations -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/JObjC.hmap -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/include -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/src/jni_headers/core -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.build/src/jni_headers/core -I/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources/x86_64 -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -Wformat -Wformat-security -Wcast-align -Wwrite-strings -Wuninitialized -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wpointer-arith -Wall -F/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug -F/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks -MMD -MT dependencies -MF /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/FFIType.d --serialize-diagnostics /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/FFIType.dia -c /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/FFIType.m -o /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/FFIType.o [exec] [exec] CompileC /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.o src/core/native/SEL.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler [exec] cd /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc [exec] setenv LANG en_US.US-ASCII [exec] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch x86_64 -fmessage-length=0 -fobjc-gc -Wno-trigraphs -fpascal-strings -Os -Werror -Werror-implicit-function-declaration -Wno-missing-field-initializers -Wmissing-prototypes -Wreturn-type -Wno-implicit-atomic-properties -Wno-receiver-is-weak -Wformat -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-empty-body -Wuninitialized -Wunknown-pragmas -Wshadow -Wfour-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion -Wsign-compare -Wshorten-64-to-32 -Wpointer-sign -Wnewline-eof -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -Wno-deprecated-implementations -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/JObjC.hmap -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/include -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/src/jni_headers/core -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.build/src/jni_headers/core -I/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources/x86_64 -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -Wformat -Wformat-security -Wcast-align -Wwrite-strings -Wuninitialized -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wpointer-arith -Wall -F/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug -F/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks -MMD -MT dependencies -MF /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.d --serialize-diagnostics /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.dia -c /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/SEL.m -o /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.o [exec] /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/SEL.m:37:12: error: cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is deprecated; use sel_getName instead [-Werror,-Wcast-of-sel-type] [exec] return ptr_to_jlong(sel); [exec] ^~~~~~~~~~~~~~~~~ [exec] /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Headers/JNFJNI.h:42:44: note: expanded from macro 'ptr_to_jlong' [exec] #define ptr_to_jlong(a) ((jlong)(uintptr_t)(a)) [exec] ^~~ [exec] 1 error generated. [exec] [exec] [exec] ** BUILD FAILED ** [exec] [exec] [exec] The following build commands failed: [exec] CompileC /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.o src/core/native/SEL.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler [exec] CompileC /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.o src/core/native/SEL.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler [exec] (2 failures) BUILD FAILED /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/build.xml:158: exec returned: 65 at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:646) at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:672) at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:498) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:392) at org.apache.tools.ant.Target.performTasks(Target.java:413) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:811) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Total time: 7 seconds make[4]: *** [/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.build/JObjC.jar] Error 1 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [jdk-build] Error 2 make: *** [build_product_image] Error 2 From anthony.petrov at oracle.com Thu Feb 14 04:31:11 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 14 Feb 2013 16:31:11 +0400 Subject: Build Issues on OS X In-Reply-To: References: Message-ID: <511CD90F.2000809@oracle.com> Hi Petr, This is a known issue and a fix is being reviewed on this mailing list at the moment: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-February/005359.html You can take the patch, apply it to your workspace, and give it a try, or wait until the fix is pushed to the repository. -- best regards, Anthony On 02/14/13 16:24, Petr Hadraba wrote: > Dear guys, > > sorry to bother you, but I would like to get a bit more involved into the JDK world. I decided to start with JDK7-dev repository. But I'm unable to compile JObjC native component. > > I've followed Your instructions; I've set up all the necessary tools and theirs respective versions. The sanity check completes successfully. > > My configuration: > - OS X 10.7.5 > - Xcode 4.6 incl. CLI tools > > I tried both JDK7u13 and JDK6u37 as bootstrap JDK with the same result. It seems I have misconfigured something. > > Could you please point me somewhere where I can get more information about this issue? > > Thanks in advance and sorry if this is something stupid. > > Sincerely Yours, > > PETR > > > [exec] === BUILD NATIVE TARGET build-core-native OF PROJECT JObjC WITH CONFIGURATION Debug === > [exec] Check dependencies > [exec] > [exec] CompileC /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.o src/core/native/SEL.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler > [exec] cd /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc > [exec] setenv LANG en_US.US-ASCII > [exec] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch i386 -fmessage-length=0 -fobjc-gc -Wno-trigraphs -fpascal-strings -Os -Werror -Werror-implicit-function-declaration -Wno-missing-field-initializers -Wmissing-prototypes -Wreturn-type -Wno-implicit-atomic-properties -Wno-receiver-is-weak -Wformat -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-empty-body -Wuninitialized -Wunknown-pragmas -Wshadow -Wfour-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion -Wsign-compare -Wshorten-64-to-32 -Wpointer-sign -Wnewline-eof -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -Wno-deprecated-implementations -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/JObjC.h map -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/include -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/src/jni_headers/core -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.build/src/jni_headers/core -I/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources/i386 -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -Wformat -Wformat-security -Wcast-align -Wwrite-strings -Wuninitialized -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wpointer-arith -Wall -F/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug -F/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks -MMD -MT dependencies -MF /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.d --serialize-diagnostics /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.dia -c /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/SEL.m -o /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.o > [exec] /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/SEL.m:37:12: error: cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is deprecated; use sel_getName instead [-Werror,-Wcast-of-sel-type] > [exec] return ptr_to_jlong(sel); > [exec] ^~~~~~~~~~~~~~~~~ > [exec] /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Headers/JNFJNI.h:42:44: note: expanded from macro 'ptr_to_jlong' > [exec] #define ptr_to_jlong(a) ((jlong)(uintptr_t)(a)) > [exec] ^~~ > [exec] 1 error generated. > [exec] > [exec] CompileC /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/FFIType.o src/core/native/FFIType.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler > [exec] cd /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc > [exec] setenv LANG en_US.US-ASCII > [exec] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch x86_64 -fmessage-length=0 -fobjc-gc -Wno-trigraphs -fpascal-strings -Os -Werror -Werror-implicit-function-declaration -Wno-missing-field-initializers -Wmissing-prototypes -Wreturn-type -Wno-implicit-atomic-properties -Wno-receiver-is-weak -Wformat -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-empty-body -Wuninitialized -Wunknown-pragmas -Wshadow -Wfour-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion -Wsign-compare -Wshorten-64-to-32 -Wpointer-sign -Wnewline-eof -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -Wno-deprecated-implementations -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/JObjC .hmap -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/include -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/src/jni_headers/core -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.build/src/jni_headers/core -I/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources/x86_64 -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -Wformat -Wformat-security -Wcast-align -Wwrite-strings -Wuninitialized -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wpointer-arith -Wall -F/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug -F/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks -MMD -MT dependencies -MF /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/FFIType.d --serialize-diagnostics /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_6 4/FFIType.dia -c /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/FFIType.m -o /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/FFIType.o > [exec] > [exec] CompileC /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.o src/core/native/SEL.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler > [exec] cd /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc > [exec] setenv LANG en_US.US-ASCII > [exec] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch x86_64 -fmessage-length=0 -fobjc-gc -Wno-trigraphs -fpascal-strings -Os -Werror -Werror-implicit-function-declaration -Wno-missing-field-initializers -Wmissing-prototypes -Wreturn-type -Wno-implicit-atomic-properties -Wno-receiver-is-weak -Wformat -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-empty-body -Wuninitialized -Wunknown-pragmas -Wshadow -Wfour-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion -Wsign-compare -Wshorten-64-to-32 -Wpointer-sign -Wnewline-eof -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -Wno-deprecated-implementations -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/JObjC .hmap -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/include -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/src/jni_headers/core -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.build/src/jni_headers/core -I/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources/x86_64 -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -Wformat -Wformat-security -Wcast-align -Wwrite-strings -Wuninitialized -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wpointer-arith -Wall -F/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug -F/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks -MMD -MT dependencies -MF /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.d --serialize-diagnostics /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SE L.dia -c /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/SEL.m -o /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.o > [exec] /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/SEL.m:37:12: error: cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is deprecated; use sel_getName instead [-Werror,-Wcast-of-sel-type] > [exec] return ptr_to_jlong(sel); > [exec] ^~~~~~~~~~~~~~~~~ > [exec] /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Headers/JNFJNI.h:42:44: note: expanded from macro 'ptr_to_jlong' > [exec] #define ptr_to_jlong(a) ((jlong)(uintptr_t)(a)) > [exec] ^~~ > [exec] 1 error generated. > [exec] > [exec] > [exec] ** BUILD FAILED ** > [exec] > [exec] > [exec] The following build commands failed: > [exec] CompileC /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.o src/core/native/SEL.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler > [exec] CompileC /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.o src/core/native/SEL.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler > [exec] (2 failures) > > BUILD FAILED > /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/build.xml:158: exec returned: 65 > at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:646) > at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:672) > at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:498) > at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:392) > at org.apache.tools.ant.Target.performTasks(Target.java:413) > at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) > at org.apache.tools.ant.Project.executeTarget(Project.java:1368) > at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > at org.apache.tools.ant.Project.executeTargets(Project.java:1251) > at org.apache.tools.ant.Main.runBuild(Main.java:811) > at org.apache.tools.ant.Main.startAnt(Main.java:217) > at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) > at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) > > Total time: 7 seconds > make[4]: *** [/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.build/JObjC.jar] Error 1 > make[3]: *** [all] Error 1 > make[2]: *** [all] Error 1 > make[1]: *** [jdk-build] Error 2 > make: *** [build_product_image] Error 2 > From philip.race at oracle.com Thu Feb 14 09:16:14 2013 From: philip.race at oracle.com (Phil Race) Date: Thu, 14 Feb 2013 09:16:14 -0800 Subject: Build Issues on OS X In-Reply-To: <511CD90F.2000809@oracle.com> References: <511CD90F.2000809@oracle.com> Message-ID: <511D1BDE.1040400@oracle.com> The fix should make it into JDK 8 master within about a week. I wasn't sure about the timing of a JDK7 backport as really a fix should "bake" in 8 for a couple of months, but if more people are running into this with JDK7 because of xcode updates, then on balance it seems I should accelerate that schedule. -phil. On 2/14/2013 4:31 AM, Anthony Petrov wrote: > Hi Petr, > > This is a known issue and a fix is being reviewed on this mailing list > at the moment: > > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-February/005359.html > > > You can take the patch, apply it to your workspace, and give it a try, > or wait until the fix is pushed to the repository. > > -- > best regards, > Anthony > > On 02/14/13 16:24, Petr Hadraba wrote: >> Dear guys, >> >> sorry to bother you, but I would like to get a bit more involved into >> the JDK world. I decided to start with JDK7-dev repository. But I'm >> unable to compile JObjC native component. >> >> I've followed Your instructions; I've set up all the necessary tools >> and theirs respective versions. The sanity check completes successfully. >> >> My configuration: >> - OS X 10.7.5 >> - Xcode 4.6 incl. CLI tools >> >> I tried both JDK7u13 and JDK6u37 as bootstrap JDK with the same >> result. It seems I have misconfigured something. >> >> Could you please point me somewhere where I can get more information >> about this issue? >> >> Thanks in advance and sorry if this is something stupid. >> >> Sincerely Yours, >> >> PETR >> >> >> [exec] === BUILD NATIVE TARGET build-core-native OF PROJECT >> JObjC WITH CONFIGURATION Debug === >> [exec] Check dependencies >> [exec] >> [exec] CompileC >> /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.o >> src/core/native/SEL.m normal i386 objective-c >> com.apple.compilers.llvm.clang.1_0.compiler >> [exec] cd /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc >> [exec] setenv LANG en_US.US-ASCII >> [exec] >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang >> -x objective-c -arch i386 -fmessage-length=0 -fobjc-gc -Wno-trigraphs >> -fpascal-strings -Os -Werror -Werror-implicit-function-declaration >> -Wno-missing-field-initializers -Wmissing-prototypes -Wreturn-type >> -Wno-implicit-atomic-properties -Wno-receiver-is-weak -Wformat >> -Wmissing-braces -Wparentheses -Wswitch -Wunused-function >> -Wno-unused-label -Wno-unused-parameter -Wunused-variable >> -Wunused-value -Wno-empty-body -Wuninitialized -Wunknown-pragmas >> -Wshadow -Wfour-char-constants -Wno-conversion >> -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion >> -Wsign-compare -Wshorten-64-to-32 -Wpointer-sign -Wnewline-eof >> -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector >> -Wno-deprecated-implementations -fasm-blocks -fstrict-aliasing >> -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion >> -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/JObjC.h > map > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/include > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/src/jni_headers/core > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.build/src/jni_headers/core > -I/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources/i386 > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources -Wmost > -Wno-four-char-constants -Wno-unknown-pragmas -Wformat > -Wformat-security -Wcast-align -Wwrite-strings -Wuninitialized > -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wpointer-arith -Wall > -F/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug > -F/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks > -MMD -MT dependencies -MF > /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.d > --serialize-diagnostics > /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.dia > -c > /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/SEL.m > -o > /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.o >> [exec] >> /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/SEL.m:37:12: >> error: cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is >> deprecated; use sel_getName instead [-Werror,-Wcast-of-sel-type] >> [exec] return ptr_to_jlong(sel); >> [exec] ^~~~~~~~~~~~~~~~~ >> [exec] >> /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Headers/JNFJNI.h:42:44: >> note: expanded from macro 'ptr_to_jlong' >> [exec] #define ptr_to_jlong(a) ((jlong)(uintptr_t)(a)) >> [exec] ^~~ >> [exec] 1 error generated. >> [exec] >> [exec] CompileC >> /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/FFIType.o >> src/core/native/FFIType.m normal x86_64 objective-c >> com.apple.compilers.llvm.clang.1_0.compiler >> [exec] cd /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc >> [exec] setenv LANG en_US.US-ASCII >> [exec] >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang >> -x objective-c -arch x86_64 -fmessage-length=0 -fobjc-gc >> -Wno-trigraphs -fpascal-strings -Os -Werror >> -Werror-implicit-function-declaration -Wno-missing-field-initializers >> -Wmissing-prototypes -Wreturn-type -Wno-implicit-atomic-properties >> -Wno-receiver-is-weak -Wformat -Wmissing-braces -Wparentheses >> -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter >> -Wunused-variable -Wunused-value -Wno-empty-body -Wuninitialized >> -Wunknown-pragmas -Wshadow -Wfour-char-constants -Wno-conversion >> -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion >> -Wsign-compare -Wshorten-64-to-32 -Wpointer-sign -Wnewline-eof >> -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector >> -Wno-deprecated-implementations -fasm-blocks -fstrict-aliasing >> -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion >> -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/JObjC > .hmap > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/include > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/src/jni_headers/core > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.build/src/jni_headers/core > -I/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources/x86_64 > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources -Wmost > -Wno-four-char-constants -Wno-unknown-pragmas -Wformat > -Wformat-security -Wcast-align -Wwrite-strings -Wuninitialized > -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wpointer-arith -Wall > -F/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug > -F/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks > -MMD -MT dependencies -MF > /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/FFIType.d > --serialize-diagnostics > /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_6 > 4/FFIType.dia -c > /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/FFIType.m > -o > /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/FFIType.o >> [exec] >> [exec] CompileC >> /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.o >> src/core/native/SEL.m normal x86_64 objective-c >> com.apple.compilers.llvm.clang.1_0.compiler >> [exec] cd /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc >> [exec] setenv LANG en_US.US-ASCII >> [exec] >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang >> -x objective-c -arch x86_64 -fmessage-length=0 -fobjc-gc >> -Wno-trigraphs -fpascal-strings -Os -Werror >> -Werror-implicit-function-declaration -Wno-missing-field-initializers >> -Wmissing-prototypes -Wreturn-type -Wno-implicit-atomic-properties >> -Wno-receiver-is-weak -Wformat -Wmissing-braces -Wparentheses >> -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter >> -Wunused-variable -Wunused-value -Wno-empty-body -Wuninitialized >> -Wunknown-pragmas -Wshadow -Wfour-char-constants -Wno-conversion >> -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion >> -Wsign-compare -Wshorten-64-to-32 -Wpointer-sign -Wnewline-eof >> -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector >> -Wno-deprecated-implementations -fasm-blocks -fstrict-aliasing >> -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion >> -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/JObjC > .hmap > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/include > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug/src/jni_headers/core > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.build/src/jni_headers/core > -I/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources/x86_64 > -I/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/DerivedSources -Wmost > -Wno-four-char-constants -Wno-unknown-pragmas -Wformat > -Wformat-security -Wcast-align -Wwrite-strings -Wuninitialized > -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wpointer-arith -Wall > -F/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Debug > -F/System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks > -MMD -MT dependencies -MF > /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.d > --serialize-diagnostics > /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SE > L.dia -c > /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/SEL.m > -o > /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.o >> [exec] >> /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/src/core/native/SEL.m:37:12: >> error: cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is >> deprecated; use sel_getName instead [-Werror,-Wcast-of-sel-type] >> [exec] return ptr_to_jlong(sel); >> [exec] ^~~~~~~~~~~~~~~~~ >> [exec] >> /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Headers/JNFJNI.h:42:44: >> note: expanded from macro 'ptr_to_jlong' >> [exec] #define ptr_to_jlong(a) ((jlong)(uintptr_t)(a)) >> [exec] ^~~ >> [exec] 1 error generated. >> [exec] >> [exec] >> [exec] ** BUILD FAILED ** >> [exec] >> [exec] >> [exec] The following build commands failed: >> [exec] CompileC >> /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/i386/SEL.o >> src/core/native/SEL.m normal i386 objective-c >> com.apple.compilers.llvm.clang.1_0.compiler >> [exec] CompileC >> /Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.dst/Objects-normal/x86_64/SEL.o >> src/core/native/SEL.m normal x86_64 objective-c >> com.apple.compilers.llvm.clang.1_0.compiler >> [exec] (2 failures) >> >> BUILD FAILED >> /Users/petr/tmp/jdk7/src/jdk/src/macosx/native/jobjc/build.xml:158: >> exec returned: 65 >> at >> org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:646) >> at org.apache.tools.ant.taskdefs.ExecTask.runExec(ExecTask.java:672) >> at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:498) >> at >> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) >> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at >> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >> at org.apache.tools.ant.Task.perform(Task.java:348) >> at org.apache.tools.ant.Target.execute(Target.java:392) >> at org.apache.tools.ant.Target.performTasks(Target.java:413) >> at >> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) >> at org.apache.tools.ant.Project.executeTarget(Project.java:1368) >> at >> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >> at org.apache.tools.ant.Project.executeTargets(Project.java:1251) >> at org.apache.tools.ant.Main.runBuild(Main.java:811) >> at org.apache.tools.ant.Main.startAnt(Main.java:217) >> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) >> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) >> >> Total time: 7 seconds >> make[4]: *** >> [/Users/petr/tmp/jdk7/src/build/macosx-x86_64/JObjC.build/JObjC.jar] >> Error 1 >> make[3]: *** [all] Error 1 >> make[2]: *** [all] Error 1 >> make[1]: *** [jdk-build] Error 2 >> make: *** [build_product_image] Error 2 >> From jcpalmer at rochester.rr.com Sat Feb 16 09:41:27 2013 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Sat, 16 Feb 2013 12:41:27 -0500 Subject: jdk7.java.net/download.html returns 502 Message-ID: <941C6A4C-E95A-43AD-90B7-3327B71CD7FA@rochester.rr.com> check this like 4 times a day for checksum change, got the proxy error 8:45 pm last night. Manually just checked. Took a really long time to come up. Just an FYI, some TLC might be required. From dalibor.topic at oracle.com Sat Feb 16 13:39:54 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Sat, 16 Feb 2013 22:39:54 +0100 Subject: jdk7.java.net/download.html returns 502 In-Reply-To: <941C6A4C-E95A-43AD-90B7-3327B71CD7FA@rochester.rr.com> References: <941C6A4C-E95A-43AD-90B7-3327B71CD7FA@rochester.rr.com> Message-ID: <511FFCAA.3090505@oracle.com> On 2/16/13 6:41 PM, Jeff Palmer wrote: > check this like 4 times a day for checksum change, got the proxy error 8:45 pm last night. > > Manually just checked. Took a really long time to come up. > > Just an FYI, some TLC might be required. > Works for me now: dalibor-topics-macbook:~ robilad$ wget jdk7.java.net/download.html --2013-02-16 22:38:31-- http://jdk7.java.net/download.html Resolving jdk7.java.net (jdk7.java.net)... 192.9.164.103 Connecting to jdk7.java.net (jdk7.java.net)|192.9.164.103|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 31134 (30K) [text/html] Saving to: ?download.html? 100%[=======================================================================================================================================================================>] 31,134 47.4KB/s in 0.6s 2013-02-16 22:38:33 (47.4 KB/s) - ?download.html? saved [31134/31134] cheers, dalibor topic -- 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 john_mulcahy at hotmail.com Sun Feb 17 05:48:22 2013 From: john_mulcahy at hotmail.com (John Mulcahy) Date: Sun, 17 Feb 2013 13:48:22 +0000 Subject: JavaSound in OS X port Message-ID: Apple's JRE had a pretty miserable JavaSound implementation, with no ports and bugs that meant no access to the inputs of Firewire-connected soundcards or the inputs of USB soundcards that supported more than 2 channels. One of the most annoying bugs was that audio data fed to lines that should be running at 48k (and said they were running at 48k) was replayed at 44.1k, so a 1 kHz sine wave data stream (for example) actually produced a 918.75 Hz tone. On 10.5 and 10.6 this could be fixed by installing the Mandolane M3DMixer. I saw a post that said Mandolane's code had been contributed to OpenJDK, so thought this sample rate bug would have been fixed in the JDK8, but I've had a report from a user running the latest OS X JDK8 1.8.0-ea build (downloaded yesterday) that the sample rate bug is still present. Did Mandolane's output mixer code not make it into JDK8? Best regards, John From dalibor.topic at oracle.com Mon Feb 18 03:15:25 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 18 Feb 2013 12:15:25 +0100 Subject: JavaSound in OS X port In-Reply-To: References: Message-ID: <51220D4D.9070504@oracle.com> On 2/17/13 2:48 PM, John Mulcahy wrote: > I saw a post that said Mandolane's code had been contributed to OpenJDK There was a thread on a potential contribution of some code in 2010 [0], but I don't think that the thread went any further then that. cheers, dalibor topic [0] http://openjdk.markmail.org/search/?q=mandolane&x=0&y=0 -- 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 sselvia at gmail.com Mon Feb 18 13:39:04 2013 From: sselvia at gmail.com (Scott Selvia) Date: Mon, 18 Feb 2013 16:39:04 -0500 Subject: Java UI apps won't display when using Mac Screen Sharing Message-ID: <95D2415F-175B-4A02-A490-61B3EBCF2118@gmail.com> When using the Mac Screen Sharing or a VNC client to view a Mac Mini desktop a launched JavaFX or Netbeans IDE won't display (refresh) the screen unless the window is forced to paint with a resize. I'm trying to run a JavaFX application on the server and I have to resize the stage in order to see the content. I reproduced the same issue with Netbeans IDE 7.1.2 running on the server. From leonid.romanov at oracle.com Mon Feb 18 17:22:50 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 19 Feb 2013 05:22:50 +0400 Subject: JNF performOnMainThreadWaiting thread safety Message-ID: <2A0743D8-959B-4F71-BB70-9C4582BB5928@oracle.com> Hi, I've got a question: is + (void)performOnMainThreadWaiting:(BOOL)waitUntilDone withBlock:(void (^)())block thread safe? Suppose two native threads are calling this method with waitUntilDone set to YES. Should we be OK in this case or some external locking is necessary to ensure that both threads won't call performOnMainThreadWaiting at the "same" time? Thanks, Leonid. From ajgregory at gmail.com Mon Feb 18 19:28:08 2013 From: ajgregory at gmail.com (AJ Gregory) Date: Mon, 18 Feb 2013 19:28:08 -0800 Subject: Java 7 and Application.setOpenURIHandler Message-ID: I have an app bundled with Java 7 (1.7.0_13) which registers a custom URL scheme using CFBundleURLSchemes in it's Info.plist and uses the Application.setOpenURIHandler to register a listener. When I click on a link that has the custom URL scheme in the browser it launches the app OK but doesn't call the handler and the following dump is in the console. I tried to submitted a bug as well but never got a bug number so not sure if it was created. Anybody else have experience with this? Thanks, -Aj 2/6/13 8:46:21.473 AM JavaAppLauncher[842]: ( 0 CoreFoundation 0x00007fff898200a6 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x00007fff840043f0 objc_exception_throw + 43 2 CoreFoundation 0x00007fff8981fe7c +[NSException raise:format:] + 204 3 Foundation 0x00007fff8c29f763 -[NSAppleEventDescriptor paramDescriptorForKeyword:] + 71 4 liblwawt.dylib 0x0000000168fb2b77 -[ApplicationDelegate _handleOpenURLEvent: withReplyEvent:] + 137 5 libosxapp.dylib 0x00000001690588b1 __-[QueuingApplicationDelegate _handleOpenURLEvent:withReplyEvent:]_block_invoke_1 + 135 6 libosxapp.dylib 0x00000001690597bf -[QueuingApplicationDelegate processQueuedEventsWithTargetDelegate:] + 134 7 libosxapp.dylib 0x0000000169057857 OSXAPP_SetApplicationDelegate + 153 8 liblwawt.dylib 0x0000000168fb1899 __+[AWTStarter start:swtMode:swtModeForWebStart:]_block_invoke_1 + 111 9 Foundation 0x00007fff8c2cf677 __NSThreadPerformPerform + 225 10 CoreFoundation 0x00007fff8979f101 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 11 CoreFoundation 0x00007fff8979ea25 __CFRunLoopDoSources0 + 245 12 CoreFoundation 0x00007fff897c1dc5 __CFRunLoopRun + 789 13 CoreFoundation 0x00007fff897c16b2 CFRunLoopRunSpecific + 290 14 HIToolbox 0x00007fff872880a4 RunCurrentEventLoopInMode + 209 15 HIToolbox 0x00007fff87287d84 ReceiveNextEventCommon + 166 16 HIToolbox 0x00007fff87287cd3 BlockUntilNextEventMatchingListInMode + 62 17 AppKit 0x00007fff8e331613 _DPSNextEvent + 685 18 AppKit 0x00007fff8e330ed2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 19 libosxapp.dylib 0x0000000169057b56 -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124 20 AppKit 0x00007fff8e328283 -[NSApplication run] + 517 21 libosxapp.dylib 0x00000001690579b9 +[NSApplicationAWT runAWTLoopWithApp:] + 156 22 liblwawt.dylib 0x0000000168fb181a -[AWTStarter starter:] + 1591 23 Foundation 0x00007fff8c2cf677 __NSThreadPerformPerform + 225 24 CoreFoundation 0x00007fff8979f101 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 25 CoreFoundation 0x00007fff8979ea25 __CFRunLoopDoSources0 + 245 26 CoreFoundation 0x00007fff897c1dc5 __CFRunLoopRun + 789 27 CoreFoundation 0x00007fff897c16b2 CFRunLoopRunSpecific + 290 28 libjli.dylib 0x00000001001cb88d CreateExecutionEnvironment + 871 29 libjli.dylib 0x00000001001c603c JLI_Launch + 1952 30 JavaAppLauncher 0x00000001000629cb launch + 5035 31 JavaAppLauncher 0x00000001000614f6 main + 102 32 JavaAppLauncher 0x0000000100061484 start + 52 33 ??? 0x0000000000000002 0x0 + 2 ) From anthony.petrov at oracle.com Tue Feb 19 01:48:04 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 19 Feb 2013 13:48:04 +0400 Subject: Java UI apps won't display when using Mac Screen Sharing In-Reply-To: <95D2415F-175B-4A02-A490-61B3EBCF2118@gmail.com> References: <95D2415F-175B-4A02-A490-61B3EBCF2118@gmail.com> Message-ID: <51234A54.3070505@oracle.com> I use VNC to connect to my Mac-mini a lot. Never seen this problem before. I'm using the TightVNC 2.6 client on MS Windows and connecting to a Mac running OS X 10.8. I also use TightVNC 1.3 client to connect from my Linux workstation to the same Mac, and it works fine there, too. What VNC client software do you use? Can you try TightVNC and see if it's still an issue? -- best regards, Anthony On 2/19/2013 1:39, Scott Selvia wrote: > When using the Mac Screen Sharing or a VNC client to view a Mac Mini desktop a launched JavaFX or Netbeans IDE won't display (refresh) the screen unless the window is forced to paint with a resize. I'm trying to run a JavaFX application on the server and I have to resize the stage in order to see the content. I reproduced the same issue with Netbeans IDE 7.1.2 running on the server. From alexandr.scherbatiy at oracle.com Tue Feb 19 02:45:37 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 19 Feb 2013 14:45:37 +0400 Subject: Java UI apps won't display when using Mac Screen Sharing In-Reply-To: <95D2415F-175B-4A02-A490-61B3EBCF2118@gmail.com> References: <95D2415F-175B-4A02-A490-61B3EBCF2118@gmail.com> Message-ID: <512357D1.3090509@oracle.com> Hi Scott, There is a known animation issue on Mac OS X. It is reproduced only if Mac OS X does not have connected monitors. To check that it is the same issue you could run the JAWTExample on JDK 6. The animation (rotated square) should not work: http://developer.apple.com/library/mac/#/legacy/mac/library/samplecode/JAWTExample/Introduction/Intro.html Or you could connect a monitor to the Mac OS X and check that Java applications start to work. Thanks, Alexandr. On 2/19/2013 1:39 AM, Scott Selvia wrote: > When using the Mac Screen Sharing or a VNC client to view a Mac Mini desktop a launched JavaFX or Netbeans IDE won't display (refresh) the screen unless the window is forced to paint with a resize. I'm trying to run a JavaFX application on the server and I have to resize the stage in order to see the content. I reproduced the same issue with Netbeans IDE 7.1.2 running on the server. From petr.pchelko at oracle.com Tue Feb 19 03:35:30 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 19 Feb 2013 15:35:30 +0400 Subject: JNF performOnMainThreadWaiting thread safety In-Reply-To: <2A0743D8-959B-4F71-BB70-9C4582BB5928@oracle.com> References: <2A0743D8-959B-4F71-BB70-9C4582BB5928@oracle.com> Message-ID: <9B9E56B8-30E8-4613-B04F-8CBA1B0A78FB@oracle.com> Hello, Leonid. The following is just my speculation, so it might be not true. The JNFRunLoop reference does not state if this method is thread-safe or not, however it should probably be implemented by NSObject performOnMainThreadWaiting method. And NSObject is thread-safe according to the documentation. So I think that it is much more likely to be thread-safe than not. However, only someone how've seen the implementation of the JNFRunLoop would be 100% sure. With best regards. Petr. On Feb 19, 2013, at 5:22 AM, Leonid Romanov wrote: > Hi, > I've got a question: is + (void)performOnMainThreadWaiting:(BOOL)waitUntilDone withBlock:(void (^)())block thread safe? Suppose two native threads are calling this method with waitUntilDone set to YES. Should we be OK in this case or some external locking is necessary to ensure that both threads won't call performOnMainThreadWaiting at the "same" time? > > Thanks, > Leonid. From swingler at apple.com Tue Feb 19 08:42:00 2013 From: swingler at apple.com (Mike Swingler) Date: Tue, 19 Feb 2013 08:42:00 -0800 Subject: JNF performOnMainThreadWaiting thread safety In-Reply-To: <2A0743D8-959B-4F71-BB70-9C4582BB5928@oracle.com> References: <2A0743D8-959B-4F71-BB70-9C4582BB5928@oracle.com> Message-ID: On Feb 18, 2013, at 5:22 PM, Leonid Romanov wrote: > Hi, > I've got a question: is + (void)performOnMainThreadWaiting:(BOOL)waitUntilDone withBlock:(void (^)())block thread safe? Suppose two native threads are calling this method with waitUntilDone set to YES. Should we be OK in this case or some external locking is necessary to ensure that both threads won't call performOnMainThreadWaiting at the "same" time? +[JNFRunLoop performOnMainThreadWaiting:withBlock:] is completely thread safe. That is somewhat the point - and yes, it is implemented in terms of -[NSObject performSelectorOnMainThread:withObject:waitUntilDone:modes:], to ensure that the block is run in the proper run loop modes. Regards, Mike Swingler Apple Inc. From swingler at apple.com Tue Feb 19 08:49:59 2013 From: swingler at apple.com (Mike Swingler) Date: Tue, 19 Feb 2013 08:49:59 -0800 Subject: Java UI apps won't display when using Mac Screen Sharing In-Reply-To: <512357D1.3090509@oracle.com> References: <95D2415F-175B-4A02-A490-61B3EBCF2118@gmail.com> <512357D1.3090509@oracle.com> Message-ID: This is a bug in OS X. Please file with your testcase at , and reference bug ID 13170906: "animation does not work in NSOpenGLLayer under VNC". Be sure to mention that the physical display is disconnected. Thanks, Mike Swingler Apple Inc. On Feb 19, 2013, at 2:45 AM, Alexander Scherbatiy wrote: > > Hi Scott, > > There is a known animation issue on Mac OS X. It is reproduced only if Mac OS X does not have connected monitors. > > To check that it is the same issue you could run the JAWTExample on JDK 6. The animation (rotated square) should not work: > http://developer.apple.com/library/mac/#/legacy/mac/library/samplecode/JAWTExample/Introduction/Intro.html > > Or you could connect a monitor to the Mac OS X and check that Java applications start to work. > > Thanks, > Alexandr. > > On 2/19/2013 1:39 AM, Scott Selvia wrote: >> When using the Mac Screen Sharing or a VNC client to view a Mac Mini desktop a launched JavaFX or Netbeans IDE won't display (refresh) the screen unless the window is forced to paint with a resize. I'm trying to run a JavaFX application on the server and I have to resize the stage in order to see the content. I reproduced the same issue with Netbeans IDE 7.1.2 running on the server. > From paul_t100 at fastmail.fm Tue Feb 19 09:00:56 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 19 Feb 2013 17:00:56 +0000 Subject: When is Java 7u14 going to be released ? Message-ID: <5123AFC8.5080201@fastmail.fm> Can we have an ETA for when Java 7u14 is going to be released, i.e the first Java OSX release that is suitable for production use i.e I assume 7u12 is going to get renamed now that 7u13 has been released, and also last build available on java.net was 7u12 Build b08 at the start of January.Its a bit fustrating that Mike Swinger was teling us to hurry up and move from Apple Java to Oracle Java back in September 2012, yet we are still waiting for a release with the Apple extensions in it, although the previews have worked pretty well for a while. Paul From david.dehaven at oracle.com Tue Feb 19 09:15:55 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 19 Feb 2013 09:15:55 -0800 Subject: JNF performOnMainThreadWaiting thread safety In-Reply-To: <9B9E56B8-30E8-4613-B04F-8CBA1B0A78FB@oracle.com> References: <2A0743D8-959B-4F71-BB70-9C4582BB5928@oracle.com> <9B9E56B8-30E8-4613-B04F-8CBA1B0A78FB@oracle.com> Message-ID: <0A4C0033-56A8-4052-83A7-41864EF5FECC@oracle.com> In my experience the "performOnMainThread" calls are all thread safe (that's their intended use?), I would expect the JNF message to be a wrapper for NSObjects performSelectorOnMainThread:withObject:waitUntilDone:. There's no guarantee of order (unless multiple calls are made in the same thread) or that the request will be processed in any timely manner, so the calling threads need to consider the implications of blocking until the request is handled and the main thread needs to be in running it's main runloop. -DrD- > Hello, Leonid. > > The following is just my speculation, so it might be not true. > > The JNFRunLoop reference does not state if this method is thread-safe or not, however it should probably be implemented by NSObject performOnMainThreadWaiting method. And NSObject is thread-safe according to the documentation. > > So I think that it is much more likely to be thread-safe than not. > However, only someone how've seen the implementation of the JNFRunLoop would be 100% sure. > > With best regards. Petr. > > > On Feb 19, 2013, at 5:22 AM, Leonid Romanov wrote: > >> Hi, >> I've got a question: is + (void)performOnMainThreadWaiting:(BOOL)waitUntilDone withBlock:(void (^)())block thread safe? Suppose two native threads are calling this method with waitUntilDone set to YES. Should we be OK in this case or some external locking is necessary to ensure that both threads won't call performOnMainThreadWaiting at the "same" time? >> >> Thanks, >> Leonid. > From leonid.romanov at oracle.com Tue Feb 19 18:26:58 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 20 Feb 2013 06:26:58 +0400 Subject: JNF performOnMainThreadWaiting thread safety In-Reply-To: <0A4C0033-56A8-4052-83A7-41864EF5FECC@oracle.com> References: <2A0743D8-959B-4F71-BB70-9C4582BB5928@oracle.com> <9B9E56B8-30E8-4613-B04F-8CBA1B0A78FB@oracle.com> <0A4C0033-56A8-4052-83A7-41864EF5FECC@oracle.com> Message-ID: <10BA3BE0-5B60-41FF-A393-CFD9DBCD0886@oracle.com> I see? I think I need to take a better look what is going on with my main thread. Thanks! On Feb 19, 2013, at 9:15 PM, David DeHaven wrote: > > In my experience the "performOnMainThread" calls are all thread safe (that's their intended use?), I would expect the JNF message to be a wrapper for NSObjects performSelectorOnMainThread:withObject:waitUntilDone:. There's no guarantee of order (unless multiple calls are made in the same thread) or that the request will be processed in any timely manner, so the calling threads need to consider the implications of blocking until the request is handled and the main thread needs to be in running it's main runloop. > > -DrD- > >> Hello, Leonid. >> >> The following is just my speculation, so it might be not true. >> >> The JNFRunLoop reference does not state if this method is thread-safe or not, however it should probably be implemented by NSObject performOnMainThreadWaiting method. And NSObject is thread-safe according to the documentation. >> >> So I think that it is much more likely to be thread-safe than not. >> However, only someone how've seen the implementation of the JNFRunLoop would be 100% sure. >> >> With best regards. Petr. >> >> >> On Feb 19, 2013, at 5:22 AM, Leonid Romanov wrote: >> >>> Hi, >>> I've got a question: is + (void)performOnMainThreadWaiting:(BOOL)waitUntilDone withBlock:(void (^)())block thread safe? Suppose two native threads are calling this method with waitUntilDone set to YES. Should we be OK in this case or some external locking is necessary to ensure that both threads won't call performOnMainThreadWaiting at the "same" time? >>> >>> Thanks, >>> Leonid. >> > From aniruddha.galgali at gmail.com Tue Feb 19 23:12:57 2013 From: aniruddha.galgali at gmail.com (Aniruddha Galgali) Date: Wed, 20 Feb 2013 12:42:57 +0530 Subject: Drag-and-drop on applet broken in Safari Message-ID: Hello Everyone, Drag-n-drop applets are not working in Safari. A workaround was mentioned at: http://lists.apple.com/archives/java-dev/2011/Jul/msg00083.html "you can detach the applet from the web page by holding down Cmd-Shift and dragging. The detached applet should respond correctly any DnD operations." However the workaround is not working in Safari 6.0.1 using Java SE 7 Update 13. I had posted the problem on java-dev and was suggested to post it here. http://lists.apple.com/archives/java-dev/2013/Feb/msg00041.html. Please help... Thanks, Aniruddha From joe.mcglynn at oracle.com Wed Feb 20 05:46:43 2013 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Wed, 20 Feb 2013 05:46:43 -0800 Subject: Drag-and-drop on applet broken in Safari In-Reply-To: References: Message-ID: <3AC7BACD-ACD0-4458-AA4D-2A1C17D9BC64@oracle.com> Please file a bug with steps to reproduce. On Feb 19, 2013, at 11:12 PM, Aniruddha Galgali wrote: > Hello Everyone, > > Drag-n-drop applets are not working in Safari. > A workaround was mentioned at: > http://lists.apple.com/archives/java-dev/2011/Jul/msg00083.html > "you can detach the applet from the web page by holding down Cmd-Shift and > dragging. The detached applet should respond correctly any DnD operations." > > However the workaround is not working in Safari 6.0.1 using Java SE 7 > Update 13. > I had posted the problem on java-dev and was suggested to post it here. > http://lists.apple.com/archives/java-dev/2013/Feb/msg00041.html. > > Please help... > > Thanks, > Aniruddha From emile.schwarz at yahoo.com Thu Feb 21 05:03:00 2013 From: emile.schwarz at yahoo.com (Emile Schwarz) Date: Thu, 21 Feb 2013 13:03:00 +0000 (GMT) Subject: macosx-port-dev Digest, Vol 26, Issue 19 In-Reply-To: References: Message-ID: <1361451780.43155.YahooMailNeo@web132503.mail.ird.yahoo.com> Hi, consider me as a java 7 newbie. I upgraded my OS X from Lion to Mountain Lion. Then I go to Oracle and downloaded the latest available version. Then I wanted to execute the application JDownloader who asked for (Apple 1.6 ?) java. Then, I fired the terminal, typed java -version and get: No Java runtime present, requesting install. And I promptl saw a new window that asked if I wanted to install java se 1.6. What do I do wrong ? TIA, Emile From Kustaa.Nyholm at planmeca.com Thu Feb 21 05:28:34 2013 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 Feb 2013 15:28:34 +0200 Subject: macosx-port-dev Digest, Vol 26, Issue 19 In-Reply-To: <1361451780.43155.YahooMailNeo@web132503.mail.ird.yahoo.com> Message-ID: On 21.2.2013 15.03, "Emile Schwarz" wrote: >Hi, > >consider me as a java 7 newbie. > >I upgraded my OS X from Lion to Mountain Lion. Then I go to Oracle and >downloaded the latest available version. > >Then I wanted to execute the application JDownloader who asked for (Apple >1.6 ?) java. > >Then, I fired the terminal, typed java -version and get: >No Java runtime present, requesting install. > >And I promptl saw a new window that asked if I wanted to install java se >1.6. > >What do I do wrong ? > >TIA, > >Emile > What are you trying to achieve? Java 7 as delivered by Oracle is for Java inside browsers, if you want to use it for running applications you need to invoke it explicitly in the command line (never tried, but I guess you can find the path to the JRE) or embed it with your application. If you use the command line tools or want to execute an application that does not embed JRE you need the Java 1.6 from Apple. I suppose JDownloader does not embed Java and it might be difficult to point it to Java 7 so you need to install Java 1.6 from Apple. At this point in time Java on Apple is moving away from having a system wide JRE (like it used to be) towards every application embedding their own version of JRE, but Oracle JRE is not ready for prime time yet so I suspect not many people use it and Apple is still sort of tolerating and supporting java 1.6 so that's what most application need, just my guess. On the otherhand it seems that for Browser java version 7 is mandatory, but does not work with Chrome I think... a bit of a hiatus atm. BTW Java 1.6==Java 6 and 1.7==7 br Kusti From yannick.jestin at enac.fr Thu Feb 21 07:27:24 2013 From: yannick.jestin at enac.fr (Yannick Jestin) Date: Thu, 21 Feb 2013 16:27:24 +0100 Subject: macosx-port-dev Digest, Vol 26, Issue 19 In-Reply-To: <1361451780.43155.YahooMailNeo@web132503.mail.ird.yahoo.com> References: <1361451780.43155.YahooMailNeo@web132503.mail.ird.yahoo.com> Message-ID: <94817C8B-7571-4F5F-8087-796B0D2581BC@enac.fr> > Then I wanted to execute the application JDownloader who asked for (Apple 1.6 ?) java. > > Then, I fired the terminal, typed java -version and get: > No Java runtime present, requesting install. > > And I promptl saw a new window that asked if I wanted to install java se 1.6. > > What do I do wrong ? This has been discussed a few times on this mailing list, and google(java7 command line macosx). The java preference panel seems to have disappeared on Mountain Lion. if the apple provided java6 is not present on Mountain Lion, the standard behavior is to trigger the download, even there is Oracle java7 on your computer. The java command line then points to $ which java /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Commands/java If you want to use java7, with or without downloading apple java6, you can execute $ export PATH=$(/usr/libexec/java_home)/bin:$PATH $ which java /Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home/bin/java If you want this setting to be permanent, you can adjust your ~/.bashrc accordingly -- Yannick Jestin From jrh at theptrgroup.com Thu Feb 21 08:10:44 2013 From: jrh at theptrgroup.com (Jamison Hope) Date: Thu, 21 Feb 2013 11:10:44 -0500 Subject: macosx-port-dev Digest, Vol 26, Issue 19 In-Reply-To: <94817C8B-7571-4F5F-8087-796B0D2581BC@enac.fr> References: <1361451780.43155.YahooMailNeo@web132503.mail.ird.yahoo.com> <94817C8B-7571-4F5F-8087-796B0D2581BC@enac.fr> Message-ID: <4ADB8FF5-19DE-42CB-9DCF-AD2C1B19B374@theptrgroup.com> On Feb 21, 2013, at 10:27 AM, Yannick Jestin wrote: >> Then I wanted to execute the application JDownloader who asked for (Apple 1.6 ?) java. >> >> Then, I fired the terminal, typed java -version and get: >> No Java runtime present, requesting install. >> >> And I promptl saw a new window that asked if I wanted to install java se 1.6. >> >> What do I do wrong ? > > This has been discussed a few times on this mailing list, and google(java7 command line macosx). The java preference panel seems to have disappeared on Mountain Lion. > > if the apple provided java6 is not present on Mountain Lion, the standard behavior is to trigger the download, even there is Oracle java7 on your computer. > > The java command line then points to > $ which java > /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Commands/java > > If you want to use java7, with or without downloading apple java6, you can execute > $ export PATH=$(/usr/libexec/java_home)/bin:$PATH > $ which java > /Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home/bin/java I don't think that's entirely accurate. I've never installed Apple Java 6 on my ML machine and /usr/bin/java finds the newest Oracle Java 7 in /Library/Java/JavaVirtualMachines/ just fine, no PATH changes required: $ /usr/bin/java -version java version "1.7.0_15" Java(TM) SE Runtime Environment (build 1.7.0_15-b03) Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) I don't recall having to do anything special the first time, either, but that was several months ago. OTOH, I do still see the occasional dialog asking me to install Java 6, I think that's triggered by applications that link against the deprecated JavaVM.framework or are otherwise incompatible with Java 7 (e.g. are 32-bit or have hard-coded dependencies on old paths). -- Jamison Hope The PTR Group www.theptrgroup.com From swingler at apple.com Thu Feb 21 09:49:25 2013 From: swingler at apple.com (Mike Swingler) Date: Thu, 21 Feb 2013 09:49:25 -0800 Subject: macosx-port-dev Digest, Vol 26, Issue 19 In-Reply-To: <4ADB8FF5-19DE-42CB-9DCF-AD2C1B19B374@theptrgroup.com> References: <1361451780.43155.YahooMailNeo@web132503.mail.ird.yahoo.com> <94817C8B-7571-4F5F-8087-796B0D2581BC@enac.fr> <4ADB8FF5-19DE-42CB-9DCF-AD2C1B19B374@theptrgroup.com> Message-ID: On Feb 21, 2013, at 8:10 AM, Jamison Hope wrote: > On Feb 21, 2013, at 10:27 AM, Yannick Jestin wrote: > >>> Then I wanted to execute the application JDownloader who asked for (Apple 1.6 ?) java. >>> >>> Then, I fired the terminal, typed java -version and get: >>> No Java runtime present, requesting install. >>> >>> And I promptl saw a new window that asked if I wanted to install java se 1.6. >>> >>> What do I do wrong ? >> >> This has been discussed a few times on this mailing list, and google(java7 command line macosx). The java preference panel seems to have disappeared on Mountain Lion. >> >> if the apple provided java6 is not present on Mountain Lion, the standard behavior is to trigger the download, even there is Oracle java7 on your computer. >> >> The java command line then points to >> $ which java >> /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Commands/java >> >> If you want to use java7, with or without downloading apple java6, you can execute >> $ export PATH=$(/usr/libexec/java_home)/bin:$PATH >> $ which java >> /Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home/bin/java > > I don't think that's entirely accurate. I've never installed Apple Java 6 on my ML machine and /usr/bin/java finds the newest Oracle Java 7 in /Library/Java/JavaVirtualMachines/ just fine, no PATH changes required: > > $ /usr/bin/java -version > java version "1.7.0_15" > Java(TM) SE Runtime Environment (build 1.7.0_15-b03) > Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) This exactly what should occur when you install an Oracle or OpenJDK in /Library/Java/JavaVirtualMachines from . Yannick likely only installed the Java applet plug-in from with it's own embedded JRE which is not visible to the command-line. > I don't recall having to do anything special the first time, either, but that was several months ago. > > > OTOH, I do still see the occasional dialog asking me to install Java 6, I think that's triggered by applications that link against the deprecated JavaVM.framework or are otherwise incompatible with Java 7 (e.g. are 32-bit or have hard-coded dependencies on old paths). This is correct. Apple is continuing to push developers to embed Java 7 and end users who need command-line tools to install an Oracle JDK. Unfortunately, for backwards compatibility, we will still have to offer Java SE 6 for applications which link against the JavaVM.framework and do not provide their own Java 7. We are planning to make Java SE 6 a manual download only, and completely remove the install-on-demand experience, even for legacy apps. Please, do seriously adopt Java 7, embed it in your application, and let Oracle know about any blocking issues. Regards, Mike Swingler Apple Inc. From Kustaa.Nyholm at planmeca.com Thu Feb 21 10:10:55 2013 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 21 Feb 2013 20:10:55 +0200 Subject: macosx-port-dev Digest, Vol 26, Issue 19 In-Reply-To: Message-ID: >Please, do seriously adopt Java 7, embed it in your application, >and let Oracle know about any blocking issues. Oracle is fully aware of the issues that are blocking me, so for me this is just wait and see when it is ready for prime time, until then I cope with whatever is available. Also, I have people who just won't upgrade to Lion or Mountain Lion so for them I'm going keep supporting not-embeded Java. Simple as that, no hard feelings and I see where the world is going but adapting Java 7 whole heartedly is not really not and option, at least not yet for me. br Kusti From kirk at kodewerk.com Thu Feb 21 10:41:24 2013 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 21 Feb 2013 19:41:24 +0100 Subject: macosx-port-dev Digest, Vol 26, Issue 19 In-Reply-To: References: Message-ID: <683A7538-DCD9-4C23-A573-E4CA8BEF2C21@kodewerk.com> Hi, I'm using mountain lion on one machine and there are enough significant problems with it that I've not upgraded any of my other machines. Regards, Kirk On 2013-02-21, at 7:10 PM, Kustaa Nyholm wrote: > >> Please, do seriously adopt Java 7, embed it in your application, >> and let Oracle know about any blocking issues. > > Oracle is fully aware of the issues that are blocking me, so for me > this is just wait and see when it is ready for prime time, until > then I cope with whatever is available. > > Also, I have people who just won't upgrade to Lion or Mountain Lion > so for them I'm going keep supporting not-embeded Java. > > Simple as that, no hard feelings and I see where the world is > going but adapting Java 7 whole heartedly is not really not > and option, at least not yet for me. > > br Kusti > From krueger at lesspain.de Fri Feb 22 03:19:15 2013 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Fri, 22 Feb 2013 12:19:15 +0100 Subject: macosx-port-dev Digest, Vol 26, Issue 19 In-Reply-To: References: <1361451780.43155.YahooMailNeo@web132503.mail.ird.yahoo.com> <94817C8B-7571-4F5F-8087-796B0D2581BC@enac.fr> <4ADB8FF5-19DE-42CB-9DCF-AD2C1B19B374@theptrgroup.com> Message-ID: Hello Mike, > > This is correct. Apple is continuing to push developers to embed Java 7 and end users who need command-line tools to install an Oracle JDK. > > Unfortunately, for backwards compatibility, we will still have to offer Java SE 6 for applications which link against the JavaVM.framework and do not provide their own Java 7. We are planning to make Java SE 6 a manual download only, and completely remove the install-on-demand experience, even for legacy apps. is there any chance that you inform developers about when this move is going to happen? because it will be quite a big thing for people like Kustaa and ourselves as we are basically in the same position he described (Oracle knows about issues but they are not fixed and if JDK6 becomes a manual download before Oracle gets these things fixed our product will suffer a serious competitive disadvantage as having to put instructions with required downloads into a product is really, really unusual for out target group. We so much _want_ to switch to Oracle's JRE as soon as we can and that totally depends on known issues to be fixed by Oracle and the only thing we can do is wait and while I find it totally legitimate of Apple to push people to using Oracle's JRE, the time seems too early to leave us without options (other than either having a bad installation experience or a bad product when it runs). This may change soon but as of today that is what I see would happen if you took away the install-on-demand behaviour of JDK6 tomorrow. Honestly, thanks for listening and your work to help us in this situation because you do a lot on this list in that regard and probably even more behind the scenes and we appreciate that, bigtime, Robert P.S.: I resent it to the list because the original reply accidentally only went to Mike. From emile.schwarz at yahoo.com Fri Feb 22 03:25:02 2013 From: emile.schwarz at yahoo.com (Emile Schwarz) Date: Fri, 22 Feb 2013 11:25:02 +0000 (GMT) Subject: Mt Lion Java on everyday usage In-Reply-To: References: Message-ID: <1361532302.20751.YahooMailNeo@web132501.mail.ird.yahoo.com> Hi all, first of all, please excuse my wrong doing (title) for my first porst (yesterday). I will rephrase my question: I am totally lost in the clouds. As a user point of view, and because troubles with Lion (and prior versions), I installed Mt Lion. I DO NOT WANT TO USE browser java. Now, I wanted to use JDownloader and I get a message telling me that I do not have Java installed and propose me to install Java 1.6. I will do that because I have to go ahead, but it seems strange to me to have to install Apple Java (the old one) when Oracle Java (the younger one) is already installed. Now, this afternoon, I will install NetBeans 7.3 and I hope I will not have troubles. For the record: can you tell me what is the actual java situation for end users and for developers. a.k.a. what each one have to install for their java use ? TIA, Emile From alexander.zuev at oracle.com Fri Feb 22 05:51:13 2013 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 22 Feb 2013 17:51:13 +0400 Subject: Mt Lion Java on everyday usage In-Reply-To: <1361532302.20751.YahooMailNeo@web132501.mail.ird.yahoo.com> References: <1361532302.20751.YahooMailNeo@web132501.mail.ird.yahoo.com> Message-ID: <512777D1.6030808@oracle.com> Emile, let's compose the step-by-step instruction here. 1. Go to the http://www.oracle.com/technetwork/java/javase/downloads/index.html 2. Look for the table named "Java Platform, Standard Edition" and inside click on the "Download" button under the word JDK (not JRE). This will lead you to the page with the list of all available downloads for the latest version of JDK (at the moment it's Java 7 update 15). 3. At the table "Java SE Development Kit 7u15" in the header check the radio button "Accept License Agreement" and then press on the link in the line that starts with the "Mac OS X x64", the .dmg file with the installer will start downloading. 4. Once the downloading process finished, open up the .dmg file and launch enclosed package installer. After installation process is finished you will have the Oracle Java7 installed. To check open up the console application and launch command: java -version Output should look somewhat like java version "1.7.0_15" Java(TM) SE Runtime Environment (build 1.7.0_15-b03) Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) After that install the JDownloader - it will work just fine (checked it myself - everything works smoothly). With best regards, Alex On 2/22/13 15:25, Emile Schwarz wrote: > Hi all, > > first of all, please excuse my wrong doing (title) for my first porst (yesterday). > > I will rephrase my question: I am totally lost in the clouds. > > As a user point of view, and because troubles with Lion (and prior versions), I installed Mt Lion. > > I DO NOT WANT TO USE browser java. > > Now, I wanted to use JDownloader and I get a message telling me that I do not have Java installed and propose me to install Java 1.6. > > I will do that because I have to go ahead, but it seems strange to me to have to install Apple Java (the old one) when Oracle Java (the younger one) is already installed. > > Now, this afternoon, I will install NetBeans 7.3 and I hope I will not have troubles. > > For the record: > can you tell me what is the actual java situation for end users and for developers. > > a.k.a. what each one have to install for their java use ? > > TIA, > > Emile From swingler at apple.com Fri Feb 22 08:06:24 2013 From: swingler at apple.com (Mike Swingler) Date: Fri, 22 Feb 2013 08:06:24 -0800 Subject: macosx-port-dev Digest, Vol 26, Issue 19 In-Reply-To: References: <1361451780.43155.YahooMailNeo@web132503.mail.ird.yahoo.com> <94817C8B-7571-4F5F-8087-796B0D2581BC@enac.fr> <4ADB8FF5-19DE-42CB-9DCF-AD2C1B19B374@theptrgroup.com> Message-ID: <4B4871ED-0AE4-4152-B941-D47E7E39ECA4@apple.com> On Feb 22, 2013, at 3:19 AM, Robert Kr?ger wrote: > Hello Mike, > >> This is correct. Apple is continuing to push developers to embed Java 7 and end users who need command-line tools to install an Oracle JDK. >> >> Unfortunately, for backwards compatibility, we will still have to offer Java SE 6 for applications which link against the JavaVM.framework and do not provide their own Java 7. We are planning to make Java SE 6 a manual download only, and completely remove the install-on-demand experience, even for legacy apps. > > is there any chance that you inform developers about when this move is > going to happen? I don't have any specific time frame that I can share, but you should expect the auto-download behavior to completely disappear before the end of this year. What is changing in in the near term is a policy shift for command-line tool invocations. We will soon present a dialog suggesting that the user install Oracle's JDK if there is no command-line Java available, instead of offering to auto-download Apple's Java SE 6. Anyone who has a Java SE 6 or Java 7 installed will continue to use the highest version installed by default. > because it will be quite a big thing for people like > Kustaa and ourselves as we are basically in the same position he > described (Oracle knows about issues but they are not fixed and if > JDK6 becomes a manual download before Oracle gets these things fixed > our product will suffer a serious competitive disadvantage as having > to put instructions with required downloads into a product is really, > really unusual for out target group. Right now your product goes through a non-optimal workflow, by asking end users to install Java SE 6, which has been EOL'd by Oracle and deprecated by Apple. The only difference will be the "auto" installation workflow will turn into a dialog which punts users to a web page (which should clearly explain that the thing they are installing is deprecated, but the only choice for these older applications). > We so much _want_ to switch to Oracle's JRE as soon as we can and that > totally depends on known issues to be fixed by Oracle and the only > thing we can do is wait and while I find it totally legitimate of > Apple to push people to using Oracle's JRE, the time seems too early > to leave us without options (other than either having a bad > installation experience or a bad product when it runs). This may > change soon but as of today that is what I see would happen if you > took away the install-on-demand behaviour of JDK6 tomorrow. We do understand that the time is not right now, but this is your heads-up that it is coming. We will not be making this change for bundled apps tomorrow. :-) I would also suggest trying to embed OpenJDK 8 in your app - that's where all the latest and greatest fixes are going after all. If, in your testing, it provides a superior experience, and the license is compatible with your product - it may be the best option for you in the immediate term, and it opens up distribution options for you. And best of all, no confusing additional downloads for your users. Even if there are still problems in OpenJDK 8, the turn around time for fixes will be a lot shorter than waiting for the next feature release cut of Java 7 from Oracle. Even better, if you come up with fixes issues you find in OpenJDK 8, you will be benefitting the entire Java ecosystem by contributing them. > Honestly, thanks for listening and your work to help us in this > situation because you do a lot on this list in that regard and > probably even more behind the scenes and we appreciate that, bigtime, > > Robert > > P.S.: I resent it to the list because the original reply accidentally > only went to Mike. Always happy to help, Mike Swingler Apple Inc. From krueger at lesspain.de Fri Feb 22 09:03:49 2013 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Fri, 22 Feb 2013 18:03:49 +0100 Subject: Status of retina fix in JDK8 Message-ID: Hi, I don't want to be a pain but I would like to ask what the status of http://bugs.sun.com/view_bug.do?bug_id=8000629 is, now that JDK8 M7 is more or less imminent. Will M7 contain a fix for this? Thanks, Robert From krueger at lesspain.de Fri Feb 22 09:07:59 2013 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Fri, 22 Feb 2013 18:07:59 +0100 Subject: macosx-port-dev Digest, Vol 26, Issue 19 In-Reply-To: <4B4871ED-0AE4-4152-B941-D47E7E39ECA4@apple.com> References: <1361451780.43155.YahooMailNeo@web132503.mail.ird.yahoo.com> <94817C8B-7571-4F5F-8087-796B0D2581BC@enac.fr> <4ADB8FF5-19DE-42CB-9DCF-AD2C1B19B374@theptrgroup.com> <4B4871ED-0AE4-4152-B941-D47E7E39ECA4@apple.com> Message-ID: On Fri, Feb 22, 2013 at 5:06 PM, Mike Swingler wrote: > What is changing in in the near term is a policy shift for command-line tool invocations. We will soon present a dialog suggesting that the user install Oracle's JDK if there is no command-line Java available, instead of offering to auto-download Apple's Java SE 6. Anyone who has a Java SE 6 or Java 7 installed will continue to use the highest version installed by default. OK. No problem for us. > > Right now your product goes through a non-optimal workflow, by asking end users to install Java SE 6, which has been EOL'd by Oracle and deprecated by Apple. The only difference will be the "auto" installation workflow will turn into a dialog which punts users to a web page (which should clearly explain that the thing they are installing is deprecated, but the only choice for these older applications). I still hope we can move to a bundled Open JDK by then > > We do understand that the time is not right now, but this is your heads-up that it is coming. We will not be making this change for bundled apps tomorrow. :-) > > I would also suggest trying to embed OpenJDK 8 in your app - that's where all the latest and greatest fixes are going after all. If, in your testing, it provides a superior experience, and the license is compatible with your product - it may be the best option for you in the immediate term, and it opens up distribution options for you. And best of all, no confusing additional downloads for your users. > That is exactly what are planning on, once http://bugs.sun.com/view_bug.do?bug_id=8000629 is fixed. We are hoping for the best. Thanks again, Robert From Sergey.Bylokhov at oracle.com Fri Feb 22 10:05:36 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 22 Feb 2013 22:05:36 +0400 Subject: [8] Request for review: 8008660 : Failure in 2D Queue Flusher thread on Mac Message-ID: <5127B370.4010203@oracle.com> Hello, Please review the fix for jdk 8. Fix will be ported to jdk7 as well. There is a few problems: 1 To eliminate the crash we should check that the system return correct CGLConfigInfofrom in CGLGraphicsConfig.getConfig(). (see http://bugs.sun.com/view_bug.do?bug_id=6755274) 2 Requested opengl attributes are too strict, so we cannot fail-back to the "software renderer". Next attrs were removed: NSOpenGLPFANoRecovery, -> if an accelerated renderer fails due to lack of resources, OpenGL automatically switches to another renderer. NSOpenGLPFAAccelerated, -> accelerated renderers are still preferred. NSOpenGLPFAFullScreen, -> we don't use this functionality. Also in this code we try to mix "CoreGraphics display id" and "Screen index". Currently we never use "screen index" so all related code was removed/renamed to be more obvious. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008660 Webrev can be found at: http://cr.openjdk.java.net/~serb/8008660/webrev.00 -- Best regards, Sergey. From swingler at apple.com Fri Feb 22 10:34:52 2013 From: swingler at apple.com (Mike Swingler) Date: Fri, 22 Feb 2013 10:34:52 -0800 Subject: [8] Request for review: 8008660 : Failure in 2D Queue Flusher thread on Mac In-Reply-To: <5127B370.4010203@oracle.com> References: <5127B370.4010203@oracle.com> Message-ID: <36824436-3E09-4540-8265-B0C5C53ACC55@apple.com> On Feb 22, 2013, at 10:05 AM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk 8. Fix will be ported to jdk7 as well. > There is a few problems: > 1 To eliminate the crash we should check that the system return correct CGLConfigInfofrom in CGLGraphicsConfig.getConfig(). (see http://bugs.sun.com/view_bug.do?bug_id=6755274) > 2 Requested opengl attributes are too strict, so we cannot fail-back to the "software renderer". > Next attrs were removed: > NSOpenGLPFANoRecovery, -> if an accelerated renderer fails due to lack of resources, OpenGL automatically switches to another renderer. > NSOpenGLPFAAccelerated, -> accelerated renderers are still preferred. > NSOpenGLPFAFullScreen, -> we don't use this functionality. > > Also in this code we try to mix "CoreGraphics display id" and "Screen index". Currently we never use "screen index" so all related code was removed/renamed to be more obvious. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008660 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8008660/webrev.00 This looks good. I like the simplification. Regards, Mike Swingler Apple Inc. From emile.schwarz at yahoo.com Sun Feb 24 04:24:38 2013 From: emile.schwarz at yahoo.com (Emile Schwarz) Date: Sun, 24 Feb 2013 12:24:38 +0000 (GMT) Subject: Mt Lion Java on everyday usage References: Message-ID: <1361708678.71714.YahooMailNeo@web132506.mail.ird.yahoo.com> Hi Alex, All, Thank you Alex for your kind step by step answer. Works fine, just like you wrote. Beside Thank you, nothing to say. BTW: yes one more thing to say: I wish everything is as easy to understand / install ! Emile PS: next step will be to isntall NetBeans 7.3. ________________________________ De?: "macosx-port-dev-request at openjdk.java.net" ??: macosx-port-dev at openjdk.java.net Envoy? le : Vendredi 22 f?vrier 2013 19h05 Objet?: macosx-port-dev Digest, Vol 26, Issue 21 Message: 2 Date: Fri, 22 Feb 2013 11:25:02 +0000 (GMT) From: Emile Schwarz Subject: Re: Mt Lion Java on everyday usage To: "macosx-port-dev at openjdk.java.net" ??? Message-ID: ??? <1361532302.20751.YahooMailNeo at web132501.mail.ird.yahoo.com> Content-Type: text/plain; charset=utf-8 Hi all, first of all, please excuse my wrong doing (title) for my first porst (yesterday). I will rephrase my question: I am totally lost in the clouds. As a user point of view, and because troubles with Lion (and prior versions), I installed Mt Lion. I DO NOT WANT TO USE browser java. Now, I wanted to use JDownloader and I get a message telling me that I do not have Java installed and propose me to install Java 1.6. I will do that because I have to go ahead, but it seems strange to me to have to install Apple Java (the old one) when Oracle Java (the younger one) is already installed. Now, this afternoon, I will install NetBeans 7.3 and I hope I will not have troubles. For the record: can you tell me what is the actual java situation for end users and for developers. a.k.a. what each one have to install for their java use ? TIA, Emile ------------------------------ Message: 3 Date: Fri, 22 Feb 2013 17:51:13 +0400 From: Alexander Zuev Subject: Re: Mt Lion Java on everyday usage To: Emile Schwarz Cc: "macosx-port-dev at openjdk.java.net" ??? Message-ID: <512777D1.6030808 at oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Emile, ? let's compose the step-by-step instruction here. 1. Go to the http://www.oracle.com/technetwork/java/javase/downloads/index.html 2. Look for the table named "Java Platform, Standard Edition" and inside click on the "Download" button under the word JDK (not JRE). This will lead you to the page with the list of all available downloads for the latest version of JDK (at the moment it's Java 7 update 15). 3. At the table "Java SE Development Kit 7u15" in the header check the radio button "Accept License Agreement" and then press on the link in the line that starts with the "Mac OS X x64", the .dmg file with the installer will start downloading. 4. Once the downloading process finished, open up the .dmg file and launch enclosed package installer. After installation process is finished you will have the Oracle Java7 installed. To check open up the console application and launch command: java -version Output should look somewhat like java version "1.7.0_15" Java(TM) SE Runtime Environment (build 1.7.0_15-b03) Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) After that install the JDownloader - it will work just fine (checked it myself - everything works smoothly). With best regards, Alex On 2/22/13 15:25, Emile Schwarz wrote: > Hi all, > > first of all, please excuse my wrong doing (title) for my first porst (yesterday). > > I will rephrase my question: I am totally lost in the clouds. > > As a user point of view, and because troubles with Lion (and prior versions), I installed Mt Lion. > > I DO NOT WANT TO USE browser java. > > Now, I wanted to use JDownloader and I get a message telling me that I do not have Java installed and propose me to install Java 1.6. > > I will do that because I have to go ahead, but it seems strange to me to have to install Apple Java (the old one) when Oracle Java (the younger one) is already installed. > > Now, this afternoon, I will install NetBeans 7.3 and I hope I will not have troubles. > > For the record: > can you tell me what is the actual java situation for end users and for developers. > > a.k.a. what each one have to install for their java use ? > > TIA, > > Emile From peter at myire.org Sun Feb 24 09:36:24 2013 From: peter at myire.org (Peter Franzen) Date: Sun, 24 Feb 2013 18:36:24 +0100 Subject: macosx-port-dev Digest, Vol 26, Issue 19 In-Reply-To: <683A7538-DCD9-4C23-A573-E4CA8BEF2C21@kodewerk.com> References: <683A7538-DCD9-4C23-A573-E4CA8BEF2C21@kodewerk.com> Message-ID: <125D8D63-9C74-4E72-9F4D-93A7D90E2FB6@myire.org> On 21 feb 2013, at 19:41, Kirk Pepperdine wrote: > Hi, > > I'm using mountain lion on one machine and there are enough significant problems with it that I've not upgraded any of my other machines. Are those problems related to Java or are they more general problems? I'm curious since I am about to upgrade to Mountain Lion on my main machine. /Peter From Sergey.Bylokhov at oracle.com Mon Feb 25 04:10:17 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Feb 2013 16:10:17 +0400 Subject: Status of retina fix in JDK8 In-Reply-To: References: Message-ID: <512B54A9.1@oracle.com> Hi, Robert. This change still in development, it isn't bound to any specific date. 22.02.2013 21:03, Robert Kr?ger wrote: > Hi, > > I don't want to be a pain but I would like to ask what the status of > http://bugs.sun.com/view_bug.do?bug_id=8000629 is, now that JDK8 M7 is > more or less imminent. Will M7 contain a fix for this? > > Thanks, > > Robert -- Best regards, Sergey. From Abhinay.Reddyreddy at mathworks.com Mon Feb 25 11:07:13 2013 From: Abhinay.Reddyreddy at mathworks.com (Abhinay Reddyreddy) Date: Mon, 25 Feb 2013 19:07:13 +0000 Subject: Is Printing broken in Java 7. Message-ID: <353D880645CCDC429732D7A445F7F5BF4617FE6C@exmb-00-ah.ad.mathworks.com> Hi, The following code works fine on my mac with Java 6 but it is broken with Java 7. import java.awt.*; import java.awt.print.PageFormat; import java.awt.print.Printable; import java.awt.print.PrinterException; import java.awt.print.PrinterJob; import javax.print.attribute.HashPrintRequestAttributeSet; import javax.print.attribute.PrintRequestAttributeSet; import javax.print.attribute.standard.DialogTypeSelection; //import sun.print.DialogTypeSelection; import javax.swing.*; public class TextAreaPrintingDemo extends javax.swing.JFrame { public TextAreaPrintingDemo() { } private static class TextPrintable implements Printable { @Override public int print(Graphics graphics, PageFormat pageFormat, int pageIndex) throws PrinterException { if(pageIndex > 1) { return NO_SUCH_PAGE; } else { Graphics2D g2d = (Graphics2D)graphics; g2d.setColor(Color.GREEN); g2d.translate(pageFormat.getImageableX(), pageFormat.getImageableY()); g2d.setFont(new Font("Monaco", Font.ITALIC, 13)); g2d.drawString("This text is being printed using JRE version: " + System.getProperty("java.version") , 30, 30); g2d.drawString("with java home: "+ System.getProperty("java.home") , 30, 70); return PAGE_EXISTS; } } } public static void main(String args[]) { SwingUtilities.invokeLater(new Runnable() { public void run() { PrinterJob job = PrinterJob.getPrinterJob(); PrintRequestAttributeSet pras = new HashPrintRequestAttributeSet(); pras.add(DialogTypeSelection.NATIVE); job.printDialog(pras); TextPrintable myPrintable = new TextPrintable(); job.setPrintable(myPrintable); try { job.print(pras); } catch(Exception e) { System.out.println("exception occured"); } } }); } } It looks like with Java 7, drawString function ignores font and color while rendering the text. I have attached the outputs for reference. Could anyone let me know if this is a known issue. If it is known, is there a bug reported and any suggested workaround ? Thanks, Abhinay. From philip.race at oracle.com Mon Feb 25 16:00:56 2013 From: philip.race at oracle.com (Phil Race) Date: Mon, 25 Feb 2013 16:00:56 -0800 Subject: Is Printing broken in Java 7. In-Reply-To: <353D880645CCDC429732D7A445F7F5BF4617FE6C@exmb-00-ah.ad.mathworks.com> References: <353D880645CCDC429732D7A445F7F5BF4617FE6C@exmb-00-ah.ad.mathworks.com> Message-ID: <512BFB38.60807@oracle.com> Both of these are OK in JDK 8 There was a bug wrt to setting font its fixed already but in a not yet shipping release. http://bugs.sun.com/view_bug.do?bug_id=7183516 It'll appear in a 7update. I think this probably covers the colour too fix but I don't immediately know that for sure. If you download a JDK 8 dev. build you do get both fixes. -phil. On 2/25/2013 11:07 AM, Abhinay Reddyreddy wrote: > Hi, > > The following code works fine on my mac with Java 6 but it is broken with Java 7. > > import java.awt.*; > import java.awt.print.PageFormat; > import java.awt.print.Printable; > import java.awt.print.PrinterException; > import java.awt.print.PrinterJob; > import javax.print.attribute.HashPrintRequestAttributeSet; > import javax.print.attribute.PrintRequestAttributeSet; > import javax.print.attribute.standard.DialogTypeSelection; > //import sun.print.DialogTypeSelection; > import javax.swing.*; > > public class TextAreaPrintingDemo extends javax.swing.JFrame { > > public TextAreaPrintingDemo() { > } > private static class TextPrintable implements Printable { > > @Override > public int print(Graphics graphics, PageFormat pageFormat, int pageIndex) throws PrinterException { > if(pageIndex > 1) { > return NO_SUCH_PAGE; > } else { > Graphics2D g2d = (Graphics2D)graphics; > g2d.setColor(Color.GREEN); > g2d.translate(pageFormat.getImageableX(), pageFormat.getImageableY()); > g2d.setFont(new Font("Monaco", Font.ITALIC, 13)); > g2d.drawString("This text is being printed using JRE version: " + System.getProperty("java.version") , 30, 30); > g2d.drawString("with java home: "+ System.getProperty("java.home") , 30, 70); > return PAGE_EXISTS; > } > } > } > > public static void main(String args[]) { > > SwingUtilities.invokeLater(new Runnable() { > public void run() { > > PrinterJob job = PrinterJob.getPrinterJob(); > PrintRequestAttributeSet pras = new HashPrintRequestAttributeSet(); > pras.add(DialogTypeSelection.NATIVE); > job.printDialog(pras); > TextPrintable myPrintable = new TextPrintable(); > job.setPrintable(myPrintable); > try { > job.print(pras); > } catch(Exception e) > { > System.out.println("exception occured"); > } > > } > }); > } > > } > > It looks like with Java 7, drawString function ignores font and color while rendering the text. I have attached the outputs for reference. > > Could anyone let me know if this is a known issue. If it is known, is there a bug reported and any suggested workaround ? > > > > > > Thanks, > Abhinay. From paul_t100 at fastmail.fm Tue Feb 26 01:43:49 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 26 Feb 2013 09:43:49 +0000 Subject: When is Java 7u14 going to be released ? In-Reply-To: <5123AFC8.5080201@fastmail.fm> References: <5123AFC8.5080201@fastmail.fm> Message-ID: <512C83D5.4050105@fastmail.fm> On 19/02/2013 17:00, Paul Taylor wrote: > Can we have an ETA for when Java 7u14 is going to be released, i.e the > first Java OSX release that is suitable for production use > > i.e I assume 7u12 is going to get renamed now that 7u13 has been > released, and also last build available on java.net was 7u12 Build b08 > at the start of January.Its a bit fustrating that Mike Swinger was > teling us to hurry up and move from Apple Java to Oracle Java back in > September 2012, yet we are still waiting for a release with the Apple > extensions in it, although the previews have worked pretty well for a > while. > > Paul > > Bump I don't expect an exact date, but cant someone give us a ballpark figure ? From Fabrizio.Giudici at tidalwave.it Tue Feb 26 01:56:06 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Tue, 26 Feb 2013 10:56:06 +0100 Subject: When is Java 7u14 going to be released ? In-Reply-To: <512C83D5.4050105@fastmail.fm> References: <5123AFC8.5080201@fastmail.fm> <512C83D5.4050105@fastmail.fm> Message-ID: On Tue, 26 Feb 2013 10:43:49 +0100, Paul Taylor wrote: > On 19/02/2013 17:00, Paul Taylor wrote: >> Can we have an ETA for when Java 7u14 is going to be released, i.e the >> first Java OSX release that is suitable for production use >> >> i.e I assume 7u12 is going to get renamed now that 7u13 has been >> released, and also last build available on java.net was 7u12 Build b08 >> at the start of January.Its a bit fustrating that Mike Swinger was >> teling us to hurry up and move from Apple Java to Oracle Java back in >> September 2012, yet we are still waiting for a release with the Apple >> extensions in it, although the previews have worked pretty well for a >> while. >> >> Paul >> >> > Bump > > I don't expect an exact date, but cant someone give us a ballpark figure There's something I'm not understanding, perhaps I've lost some messages in this thread. The subjectis 7u14, but I've already received the update to 7u15... Sorry if it's a trivial question. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From paul_t100 at fastmail.fm Tue Feb 26 02:01:34 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 26 Feb 2013 10:01:34 +0000 Subject: When is Java 7u14 going to be released ? In-Reply-To: References: <5123AFC8.5080201@fastmail.fm> <512C83D5.4050105@fastmail.fm> Message-ID: <512C87FE.8080200@fastmail.fm> On 26/02/2013 09:56, Fabrizio Giudici wrote: > On Tue, 26 Feb 2013 10:43:49 +0100, Paul Taylor > wrote: > >> On 19/02/2013 17:00, Paul Taylor wrote: >>> Can we have an ETA for when Java 7u14 is going to be released, i.e >>> the first Java OSX release that is suitable for production use >>> >>> i.e I assume 7u12 is going to get renamed now that 7u13 has been >>> released, and also last build available on java.net was 7u12 Build >>> b08 at the start of January.Its a bit fustrating that Mike Swinger >>> was teling us to hurry up and move from Apple Java to Oracle Java >>> back in September 2012, yet we are still waiting for a release with >>> the Apple extensions in it, although the previews have worked pretty >>> well for a while. >>> >>> Paul >>> >>> >> Bump >> >> I don't expect an exact date, but cant someone give us a ballpark figure > > There's something I'm not understanding, perhaps I've lost some > messages in this thread. The subjectis 7u14, but I've already received > the update to 7u15... Sorry if it's a trivial question. > > Ah, I think 7u15 was released later on the day I originally posted this. However I think it is just a security release and doesn't contain any of the mac improvements in the early access build whihc is what I want Paul From Fabrizio.Giudici at tidalwave.it Tue Feb 26 02:07:25 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Tue, 26 Feb 2013 11:07:25 +0100 Subject: When is Java 7u14 going to be released ? In-Reply-To: <512C87FE.8080200@fastmail.fm> References: <5123AFC8.5080201@fastmail.fm> <512C83D5.4050105@fastmail.fm> <512C87FE.8080200@fastmail.fm> Message-ID: On Tue, 26 Feb 2013 11:01:34 +0100, Paul Taylor wrote: > Ah, I think 7u15 was released later on the day I originally posted this. > However I think it is just a security release and doesn't contain any of > the mac improvements in the early access build whihc is what I want It's what I supposed. So the "first prodution-ready... " at this point is 7u16 (at least...), right? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From paul_t100 at fastmail.fm Tue Feb 26 02:21:40 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 26 Feb 2013 10:21:40 +0000 Subject: When is Java 7u14 going to be released ? In-Reply-To: References: <5123AFC8.5080201@fastmail.fm> <512C83D5.4050105@fastmail.fm> <512C87FE.8080200@fastmail.fm> Message-ID: <512C8CB4.5040800@fastmail.fm> On 26/02/2013 10:07, Fabrizio Giudici wrote: > On Tue, 26 Feb 2013 11:01:34 +0100, Paul Taylor > wrote: > >> Ah, I think 7u15 was released later on the day I originally posted this. >> However I think it is just a security release and doesn't contain any >> of the mac improvements in the early access build whihc is what I want > > It's what I supposed. So the "first prodution-ready... " at this point > is 7u16 (at least...), right? > I assume so From Sergey.Bylokhov at oracle.com Tue Feb 26 05:45:26 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Feb 2013 17:45:26 +0400 Subject: [8] Request for review: 8003169: [macosx] JVM crash after disconnecting from projector Message-ID: <512CBC76.3020300@oracle.com> Hello, Please review the fix for jdk 8. Fix will be ported to jdk7 as well. In the fix getScreenInsets() implementation was moved to the one native method. I assume that it doesn't lead to incorrect nsscreen in the middle of operations, if we run all appropriate operation in one step on appkit thread. CFRetain/CFRelease are unnecessary in this case. nativeGetDisplay** methods were changed to static, because in the native they implemented as a static. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003169 Webrev can be found at: http://cr.openjdk.java.net/~serb/8003169/webrev.00 -- Best regards, Sergey. From dalibor.topic at oracle.com Tue Feb 26 05:55:58 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 26 Feb 2013 14:55:58 +0100 Subject: When is Java 7u14 going to be released ? In-Reply-To: <512C8CB4.5040800@fastmail.fm> References: <5123AFC8.5080201@fastmail.fm> <512C83D5.4050105@fastmail.fm> <512C87FE.8080200@fastmail.fm> <512C8CB4.5040800@fastmail.fm> Message-ID: <512CBEEE.4040002@oracle.com> On 2/26/13 11:21 AM, Paul Taylor wrote: > On 26/02/2013 10:07, Fabrizio Giudici wrote: >> On Tue, 26 Feb 2013 11:01:34 +0100, Paul Taylor wrote: >> >>> Ah, I think 7u15 was released later on the day I originally posted this. >>> However I think it is just a security release and doesn't contain any of the mac improvements in the early access build whihc is what I want >> >> It's what I supposed. So the "first prodution-ready... " at this point is 7u16 (at least...), right? >> > I assume so See https://blogs.oracle.com/henrik/entry/migrating_from_java_se_6#comment-1361758646033 cheers, dalibor topic -- 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 anthony.petrov at oracle.com Tue Feb 26 06:28:52 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 26 Feb 2013 18:28:52 +0400 Subject: [8] Request for review: 8003169: [macosx] JVM crash after disconnecting from projector In-Reply-To: <512CBC76.3020300@oracle.com> References: <512CBC76.3020300@oracle.com> Message-ID: <512CC6A4.2050106@oracle.com> Hi Sergey, The fix looks good. However, is there a need to dispatch the nativeGetScreenInsets operation on the AppKit thread? Form a recent discussion on threading in FX we found out that NSScreen doesn't imply any threading restrictions on its usage, i.e. you can access NSScreen APIs from any thread. Would anything break if you comment out the performOnMainThreadWaiting call and execute the block directly on the current thread? -- best regards, Anthony On 2/26/2013 17:45, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk 8. Fix will be ported to jdk7 as well. > > In the fix getScreenInsets() implementation was moved to the one native > method. I assume that it doesn't lead to incorrect nsscreen in the > middle of operations, if we run all appropriate operation in one step on > appkit thread. CFRetain/CFRelease are unnecessary in this case. > nativeGetDisplay** methods were changed to static, because in the native > they implemented as a static. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003169 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8003169/webrev.00 > From Sergey.Bylokhov at oracle.com Tue Feb 26 07:38:19 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 26 Feb 2013 19:38:19 +0400 Subject: [8] Request for review: 8003169: [macosx] JVM crash after disconnecting from projector In-Reply-To: <512CC6A4.2050106@oracle.com> References: <512CBC76.3020300@oracle.com> <512CC6A4.2050106@oracle.com> Message-ID: <512CD6EB.5090504@oracle.com> Hi, Anthony. Even if this is possible I don't want to delete this code, otherwise I should synchronize operation of this method with the native callbacks(change of parameters of the display, etc) 26.02.2013 18:28, Anthony Petrov wrote: > Hi Sergey, > > The fix looks good. However, is there a need to dispatch the > nativeGetScreenInsets operation on the AppKit thread? Form a recent > discussion on threading in FX we found out that NSScreen doesn't imply > any threading restrictions on its usage, i.e. you can access NSScreen > APIs from any thread. Would anything break if you comment out the > performOnMainThreadWaiting call and execute the block directly on the > current thread? > > -- > best regards, > Anthony > > On 2/26/2013 17:45, Sergey Bylokhov wrote: >> Hello, >> Please review the fix for jdk 8. Fix will be ported to jdk7 as well. >> >> In the fix getScreenInsets() implementation was moved to the one >> native method. I assume that it doesn't lead to incorrect nsscreen in >> the middle of operations, if we run all appropriate operation in one >> step on appkit thread. CFRetain/CFRelease are unnecessary in this case. >> nativeGetDisplay** methods were changed to static, because in the >> native they implemented as a static. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003169 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8003169/webrev.00 >> -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Feb 26 07:45:37 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 26 Feb 2013 19:45:37 +0400 Subject: [8] Request for review: 8003169: [macosx] JVM crash after disconnecting from projector In-Reply-To: <512CD6EB.5090504@oracle.com> References: <512CBC76.3020300@oracle.com> <512CC6A4.2050106@oracle.com> <512CD6EB.5090504@oracle.com> Message-ID: <512CD8A1.40607@oracle.com> OK. -- best regards, Anthony On 2/26/2013 19:38, Sergey Bylokhov wrote: > Hi, Anthony. > Even if this is possible I don't want to delete this code, otherwise I > should synchronize operation of this method with the native > callbacks(change of parameters of the display, etc) > > 26.02.2013 18:28, Anthony Petrov wrote: >> Hi Sergey, >> >> The fix looks good. However, is there a need to dispatch the >> nativeGetScreenInsets operation on the AppKit thread? Form a recent >> discussion on threading in FX we found out that NSScreen doesn't imply >> any threading restrictions on its usage, i.e. you can access NSScreen >> APIs from any thread. Would anything break if you comment out the >> performOnMainThreadWaiting call and execute the block directly on the >> current thread? >> >> -- >> best regards, >> Anthony >> >> On 2/26/2013 17:45, Sergey Bylokhov wrote: >>> Hello, >>> Please review the fix for jdk 8. Fix will be ported to jdk7 as well. >>> >>> In the fix getScreenInsets() implementation was moved to the one >>> native method. I assume that it doesn't lead to incorrect nsscreen in >>> the middle of operations, if we run all appropriate operation in one >>> step on appkit thread. CFRetain/CFRelease are unnecessary in this case. >>> nativeGetDisplay** methods were changed to static, because in the >>> native they implemented as a static. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003169 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8003169/webrev.00 >>> > > From jcpalmer at rochester.rr.com Tue Feb 26 09:07:27 2013 From: jcpalmer at rochester.rr.com (Jeff Palmer) Date: Tue, 26 Feb 2013 12:07:27 -0500 Subject: When is Java 7u16 going to be released ? In-Reply-To: References: Message-ID: Though it is referenced at the time as 7u12, this is the planning doc I am going by: http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-December/005251.html Whether the info is still worth the disk space it occupies is unknown to me. Dalibor, Do not see any dates in the link, but have a question. If someone was planning to embed Java, could they do it from source and not have to wait for an official release? Not planning to do this, not even planning to embed prior to Java 8, but would like to know. Hope this gives some guidance. Jeff Palmer On Feb 26, 2013, at 9:29 AM, macosx-port-dev-request at openjdk.java.net wrote: > From: Dalibor Topic > Subject: Re: When is Java 7u14 going to be released ? > Date: February 26, 2013 8:55:58 AM EST > To: macosx-port-dev at openjdk.java.net > > > On 2/26/13 11:21 AM, Paul Taylor wrote: >> On 26/02/2013 10:07, Fabrizio Giudici wrote: >>> On Tue, 26 Feb 2013 11:01:34 +0100, Paul Taylor wrote: >>> >>>> Ah, I think 7u15 was released later on the day I originally posted this. >>>> However I think it is just a security release and doesn't contain any of the mac improvements in the early access build whihc is what I want >>> >>> It's what I supposed. So the "first prodution-ready... " at this point is 7u16 (at least...), right? >>> >> I assume so > > See https://blogs.oracle.com/henrik/entry/migrating_from_java_se_6#comment-1361758646033 > > cheers, > dalibor topic From dalibor.topic at oracle.com Tue Feb 26 11:04:47 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 26 Feb 2013 20:04:47 +0100 Subject: When is Java 7u16 going to be released ? In-Reply-To: References: Message-ID: <512D074F.7070705@oracle.com> On 2/26/13 6:07 PM, Jeff Palmer wrote: > If someone was planning to embed Java, could they do it from source and not have to wait for an official release? You can create your own builds of OpenJDK from the source code in the repositories. If you are planning to deploy a compatible Java implementation based on code derived from OpenJDK, I'd recommend that you take a look at the OCTLA, at http://openjdk.java.net/groups/conformance/JckAccess/index.html . cheers, dalibor topic -- 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 andrew.brygin at oracle.com Wed Feb 27 01:45:44 2013 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 27 Feb 2013 13:45:44 +0400 Subject: [8] Request for review: 8008660 : Failure in 2D Queue Flusher thread on Mac In-Reply-To: <5127B370.4010203@oracle.com> References: <5127B370.4010203@oracle.com> Message-ID: <512DD5C8.4060302@oracle.com> Hi Sergey, the fix looks fine to me. Thanks, Andrew On 2/22/2013 10:05 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk 8. Fix will be ported to jdk7 as well. > There is a few problems: > 1 To eliminate the crash we should check that the system return > correct CGLConfigInfofrom in CGLGraphicsConfig.getConfig(). (see > http://bugs.sun.com/view_bug.do?bug_id=6755274) > 2 Requested opengl attributes are too strict, so we cannot fail-back > to the "software renderer". > Next attrs were removed: > NSOpenGLPFANoRecovery, -> if an accelerated renderer fails due to lack > of resources, OpenGL automatically switches to another renderer. > NSOpenGLPFAAccelerated, -> accelerated renderers are still preferred. > NSOpenGLPFAFullScreen, -> we don't use this functionality. > > Also in this code we try to mix "CoreGraphics display id" and "Screen > index". Currently we never use "screen index" so all related code was > removed/renamed to be more obvious. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008660 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8008660/webrev.00 > From davmac at davmac.org Thu Feb 28 05:35:03 2013 From: davmac at davmac.org (Davin McCall) Date: Thu, 28 Feb 2013 13:35:03 +0000 Subject: Application/screen menu bar bug with JDK 7 Message-ID: <512F5D07.7060905@davmac.org> We have an application which uses the applicaiton-wide menu bar, by setting the apple.laf.useScreenMenu system property to true. We have discovered that disposing any JFrame which has a non-null menu bar causes the menus to disappear from the menu bar (until you switch to another application and back). The bug is present in JDK 7u15. I reported the bug (along with a self-contained example demonstrating the behavior) last week, using bugs.sun.com, but I haven't received any response yet. Is there somewhere else I should be reporting bugs? Thanks, Davin From leonid.romanov at oracle.com Thu Feb 28 07:45:48 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 28 Feb 2013 19:45:48 +0400 Subject: Application/screen menu bar bug with JDK 7 In-Reply-To: <512F5D07.7060905@davmac.org> References: <512F5D07.7060905@davmac.org> Message-ID: <653CB740-4C4A-4A5C-B3F3-FE02CADE92FA@oracle.com> Hi, This is a known bug and it has already been fixed. The fix will appear in the next non security release of JDK 7. Regards, Leonid. On 28.02.2013, at 17:35, Davin McCall wrote: > We have an application which uses the applicaiton-wide menu bar, by setting the apple.laf.useScreenMenu system property to true. We have discovered that disposing any JFrame which has a non-null menu bar causes the menus to disappear from the menu bar (until you switch to another application and back). The bug is present in JDK 7u15. > > I reported the bug (along with a self-contained example demonstrating the behavior) last week, using bugs.sun.com, but I haven't received any response yet. Is there somewhere else I should be reporting bugs? > > Thanks, > > Davin > From davmac at davmac.org Thu Feb 28 06:18:28 2013 From: davmac at davmac.org (Davin McCall) Date: Thu, 28 Feb 2013 14:18:28 +0000 Subject: Application/screen menu bar bug with JDK 7 In-Reply-To: <653CB740-4C4A-4A5C-B3F3-FE02CADE92FA@oracle.com> References: <512F5D07.7060905@davmac.org> <653CB740-4C4A-4A5C-B3F3-FE02CADE92FA@oracle.com> Message-ID: <512F6734.9020909@davmac.org> Thanks Leonid, that's good to know. I don't suppose you know of a bug database entry (URL) regarding this bug? regards Davin On 28/02/13 15:45, Leonid Romanov wrote: > Hi, > This is a known bug and it has already been fixed. The fix will appear in the next non security release of JDK 7. > > Regards, > Leonid. > > On 28.02.2013, at 17:35, Davin McCall wrote: > >> We have an application which uses the applicaiton-wide menu bar, by setting the apple.laf.useScreenMenu system property to true. We have discovered that disposing any JFrame which has a non-null menu bar causes the menus to disappear from the menu bar (until you switch to another application and back). The bug is present in JDK 7u15. >> >> I reported the bug (along with a self-contained example demonstrating the behavior) last week, using bugs.sun.com, but I haven't received any response yet. Is there somewhere else I should be reporting bugs? >> >> Thanks, >> >> Davin >> From leonid.romanov at oracle.com Thu Feb 28 08:08:06 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 28 Feb 2013 20:08:06 +0400 Subject: Application/screen menu bar bug with JDK 7 In-Reply-To: <512F6734.9020909@davmac.org> References: <512F5D07.7060905@davmac.org> <653CB740-4C4A-4A5C-B3F3-FE02CADE92FA@oracle.com> <512F6734.9020909@davmac.org> Message-ID: <4726A408-4106-4334-8267-EF2EF072B93D@oracle.com> This is the bug which has been fixed: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 Don't know the ID of the bug you've submitted, but it will be marked as a duplicate of the above bug anyway. Regards, Leonid. On 28.02.2013, at 18:18, Davin McCall wrote: > Thanks Leonid, that's good to know. > > I don't suppose you know of a bug database entry (URL) regarding this bug? > > regards > Davin > > On 28/02/13 15:45, Leonid Romanov wrote: >> Hi, >> This is a known bug and it has already been fixed. The fix will appear in the next non security release of JDK 7. >> >> Regards, >> Leonid. >> >> On 28.02.2013, at 17:35, Davin McCall wrote: >> >>> We have an application which uses the applicaiton-wide menu bar, by setting the apple.laf.useScreenMenu system property to true. We have discovered that disposing any JFrame which has a non-null menu bar causes the menus to disappear from the menu bar (until you switch to another application and back). The bug is present in JDK 7u15. >>> >>> I reported the bug (along with a self-contained example demonstrating the behavior) last week, using bugs.sun.com, but I haven't received any response yet. Is there somewhere else I should be reporting bugs? >>> >>> Thanks, >>> >>> Davin >>> > From davmac at davmac.org Thu Feb 28 06:29:56 2013 From: davmac at davmac.org (Davin McCall) Date: Thu, 28 Feb 2013 14:29:56 +0000 Subject: Application/screen menu bar bug with JDK 7 In-Reply-To: <4726A408-4106-4334-8267-EF2EF072B93D@oracle.com> References: <512F5D07.7060905@davmac.org> <653CB740-4C4A-4A5C-B3F3-FE02CADE92FA@oracle.com> <512F6734.9020909@davmac.org> <4726A408-4106-4334-8267-EF2EF072B93D@oracle.com> Message-ID: <512F69E4.4010203@davmac.org> On 28/02/13 16:08, Leonid Romanov wrote: > This is the bug which has been fixed: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007006 Thanks again, that's exactly what I wanted. Davin From alexandr.scherbatiy at oracle.com Thu Feb 28 07:57:19 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 28 Feb 2013 19:57:19 +0400 Subject: [8] Request for review: 8003169: [macosx] JVM crash after disconnecting from projector In-Reply-To: <512CBC76.3020300@oracle.com> References: <512CBC76.3020300@oracle.com> Message-ID: <512F7E5F.5030203@oracle.com> The fix looks good for me. Thanks, Alexandr. On 2/26/2013 5:45 PM, Sergey Bylokhov wrote: > Hello, > Please review the fix for jdk 8. Fix will be ported to jdk7 as well. > > In the fix getScreenInsets() implementation was moved to the one > native method. I assume that it doesn't lead to incorrect nsscreen in > the middle of operations, if we run all appropriate operation in one > step on appkit thread. CFRetain/CFRelease are unnecessary in this case. > nativeGetDisplay** methods were changed to static, because in the > native they implemented as a static. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003169 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8003169/webrev.00 >