Yes, jdk7u-dev@ is the right place to request an approval. I believe we
can port it right away given that 1) the fix is very simple and hence
low-risk; and 2) the 7u-dev repos will soon close for stabilization
before the 7u40 release.
Please follow this template for your request:
http://openjdk.java.net/projects/jdk7u/approval-template.html
You can find links to the mailing list messages at
http://mail.openjdk.java.net/pipermail/awt-dev/
(to link to a review thread for this fix).
Also, you may indicate me as a person who's actually going to push this
fix for you.
--
best regards,
Anthony
On 05/30/2013 11:04 PM, James Tomson wrote:
Fantastic - thanks Anthony et al. for following up.
I'm not quite sure of the procedure to nominate this patch for inclusion
in the jdk7u sources as well - would it be helpful for me to bring this
up on the jdk7u-dev list?
Cheers,
James
On Thu, May 30, 2013 at 10:14 AM, Anthony Petrov
<[email protected] <mailto:[email protected]>> wrote:
Hi James,
Thank you very much for the contribution! Your fix is now pushed to
the repository:
http://hg.openjdk.java.net/__jdk8/awt/jdk/rev/768fcc36182a
<http://hg.openjdk.java.net/jdk8/awt/jdk/rev/768fcc36182a>
--
best regards,
Anthony
On 05/29/13 01:30, James Tomson wrote:
Running the Leaks instrument while triggering multiple openURIs (and
openFile, and printFile events) and neither the descriptors or the
queued blocks are flagged as leaked. I've only had a chance to
run the
profile against a patched jdk7u, not a patched jdk8.
Cheers,
James
On Mon, May 27, 2013 at 1:23 PM, Mike Swingler
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
This looks reasonable to me. Did you test the fix using the
"leaks"
to determine that the descriptors or the block itself were not
over-retained?
Regards,
Mike Swingler
Apple Inc.
On May 27, 2013, at 6:53 AM, Anthony Petrov
<[email protected]
<mailto:[email protected]>
<mailto:anthony.petrov@oracle.__com
<mailto:[email protected]>>> wrote:
> Thanks for testing, James. I'm fine with the fix then.
>
> Note that we need at least one more review from a
reviewer on
this mailing list before we can push your fix to the
repository.
>
> Anyone?
>
> --
> best regards,
> Anthony
>
> On 05/24/13 22:39, James Tomson wrote:
>> Hi Anthony,
>>
>> Thanks for taking a look. To answer your questions, the
>> application:openFiles and application:printFiles
methods should
not need
>> similar special treatment - the passed instances should
be getting
>> implicitly retained and released by the block from my
understanding, and
>> can be queued for later processing without a problem.
Testing
locally
>> with those handlers, the OpenFilesEvent and PrintFilesEvent
events on
>> the java-side are delivered without issue when the app is
launched from
>> an open file or print file event from the Finder.
>>
>> The issue with the passed NSAppleEventDescriptors is
that while the
>> objects are properly retained and released by the
block, the
Apple Event
>> Handling system seems to be marking the instance's
internal state as
>> otherwise invalid/expired even though the instance
itself is still
>> retained. I'm unable to find any specific documentation or
discussion
>> about the lifecycle of these event descriptor objects
though.
>>
>> -James
>>
>>
>> On Fri, May 24, 2013 at 12:13 PM, Anthony Petrov
>> <[email protected]
<mailto:[email protected]>
<mailto:anthony.petrov@oracle.__com
<mailto:[email protected]>>
<mailto:anthony.petrov@oracle.__com
<mailto:[email protected]>
<mailto:anthony.petrov@oracle.__com
<mailto:[email protected]>>>> wrote:
>>
>> Hi James,
>>
>> I like your patch.
>>
>> Do you know if other handlers are affected by a
similar issue? In
>> particular, the application:openFiles and
application:printFiles
>> also take references to NSObjects as their
arguments. Could you
>> please test if these handlers are affected or not?
>>
>> --
>> best regards,
>> Anthony
>>
>>
>> On 05/23/2013 10:56 PM, James Tomson wrote:
>>
>> Hi - this issue was originally discussed on the
jdk7u-dev
list here:
>>
http://mail.openjdk.java.net/____pipermail/jdk7u-dev/2013-May/____006446.html
<http://mail.openjdk.java.net/__pipermail/jdk7u-dev/2013-May/__006446.html>
>>
<http://mail.openjdk.java.net/__pipermail/jdk7u-dev/2013-May/__006446.html
<http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-May/006446.html>>
>>
>> Additionally a report should be available soon
in the bug
>> database as
>> (JDK-8015302)
>>
http://bugs.sun.com/____bugdatabase/view_bug.do?bug_____id=8015302
<http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=8015302>
>>
<http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=8015302
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015302>>
>>
>> To summarize, a bundled mac application which
registers
custom url
>> schemes via the CFBundleURLSchemes entry in its
Info.plist, and
>> listens
>> for uri events using
>>
com.apple.eawt.Application.____setOpenURIHandler, will
>> not receive the URI used to launch the application.
>>
>> Once the application is running however,
subsequent openURI
>> events will
>> be delivered without issue. The problem only
manifests
with the
>> URI is
>> used to launch the App initially.
>>
>> When the app is opened via URI, the following
appears in the
>> system log:
>>
>> ----------
>> JavaAppLauncher[74278]: -[NSAppleEventDescriptor
>> paramDescriptorForKeyword:] called on invalid
NSAppleEventDescriptor
>> ----------
>>
>> It appears that since the
QueueingApplicationDelegate is only
>> keeping
>> references to those descriptor 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 (same for both jdk8 and jdk7u
sources) seems to
>> resolve the issue:
>>
>> ----
>> diff --git
>>
a/src/macosx/native/sun/____osxapp/____QueuingApplicationDelegate.m
>>
b/src/macosx/native/sun/____osxapp/____QueuingApplicationDelegate.m
>> ---
a/src/macosx/native/sun/____osxapp/____QueuingApplicationDelegate.m
>> +++
b/src/macosx/native/sun/____osxapp/____QueuingApplicationDelegate.m
>> @@ -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]];
>> }
>> -----
>>
>> Please let me know if there is additional
information
that I can
>> provide
>> - thanks!
>>
>> -James
>>
>>
