James, AJ,
I've moved the bug report into the JDK category. It should be appearing
with new ID shortly (JDK-8015302)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015302
I suggest you discuss the issue with the awt-dev mailing list first. (I
think this issue falls into that area). Ideally you could propose a
patch for JDK8 first and then backport to jdk7u. Details on how to
contribute can be found at : http://openjdk.java.net/contribute/
regards,
Sean.
On 22/05/2013 22:52, James Tomson wrote:
I've run into this issue as well with jdk7u_21, and just entered (another)
bug on the subject - 9003054.
Looking at the system log in Console.app when this occurs, there's a but
more info in the exception description:
----------
JavaAppLauncher[74278]: -[NSAppleEventDescriptor
paramDescriptorForKeyword:] called on invalid NSAppleEventDescriptor
----------
It appears that since the QueueingApplicationDelegate is only keeping
references to those event objects instead of making deep copies of them,
the event descriptor for the initial URI that launches the app is
invalidated by the time the app actually gets around to processing it.
The following patch seems to resolve the issue:
-----------
diff -r fd2743154fcf
src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m
--- a/src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Wed May
08 16:52:22 2013 -0700
+++ b/src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Wed May
22 12:41:08 2013 -0400
@@ -110,8 +110,14 @@
- (void)_handleOpenURLEvent:(NSAppleEventDescriptor *)openURLEvent
withReplyEvent:(NSAppleEventDescriptor *)replyEvent
{
+ // Make an explicit copy of the passed events as they may be
invalidated by the time they're processed
+ NSAppleEventDescriptor *openURLEventCopy = [openURLEvent copy];
+ NSAppleEventDescriptor *replyEventCopy = [replyEvent copy];
+
[self.queue addObject:[^(){
- [self.realDelegate _handleOpenURLEvent:openURLEvent
withReplyEvent:replyEvent];
+ [self.realDelegate _handleOpenURLEvent:openURLEventCopy
withReplyEvent:replyEventCopy];
+ [openURLEventCopy release];
+ [replyEventCopy release];
} copy]];
}
-----------
I'm not quite sure of the process required to get these patches considered,
but I've included the above diff in the bug report - hopefully it's of some
use and not completely off track :)
-James
I submitted a bug for this but it's been "not available" for a few weeks:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000081
Can anybody comment on this issue with the
Application.setOpenURIHandler and custom protocols?
Custom protocols really are useful especially now that applets are
dying a slow death with everybody disabling java in their browser...
Thanks,
-Aj
On Mon, Feb 18, 2013 at 7:28 PM, AJ Gregory <ajgregory at gmail.com> wrote:
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
)>
