There are plenty classes extending CFRetainedResource, TryIcon for
example. Will disposing them cause the same issue inside the native app?
On 7/31/2015 4:37 PM, Sergey Bylokhov wrote:
Yes, it is possible if this simple native application emulate
initialization of these libraries.
On 31.07.15 16:07, Semyon Sadetsky wrote:
Is it possible to reproduce the scenario using simple native
application which embeds the Java VM?
On 7/31/2015 3:37 PM, Sergey Bylokhov wrote:
On 31.07.15 10:30, Semyon Sadetsky wrote:
JMC-4034 is not an OpenJDK project. Souldn't this test be copied to
the client-libs test base?
JDK-8132469 description contains manual steps executed using
SwingSet2, right?
All sqe tests is not a part of openjdk project. These particular
tests cannot be copied to our ws because they are depend from the
external java libraries, which require some manual configuration.
--Semyon
On 7/30/2015 5:55 PM, Sergey Bylokhov wrote:
Hi, Semyon.
There are two tests which failed, see JMC-4034( jmc_plugintest/swt
case) and JDK-8132469(swingnode/fx case).
On 30.07.15 9:49, Semyon Sadetsky wrote:
Hi Sergey,
You've marked the bug as noreg-sqe. I could not find the existing
test that crashes during the bug scenario. Could add this info?
--Semyon
On 7/29/2015 6:51 PM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk9.
In the fix 8068886[1] the new native resources deallocation code
assumes that we have a full control over the Cocoa
NSApplication. This is incorrect in case of embedding, when
NSApplication is controlled by swt or fx libraries. In the fix I
add an additional check that the necessary selector exists in
the current NSApp.
[1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b26427c5b3fe
Bug: https://bugs.openjdk.java.net/browse/JDK-8132382
Webrev can be found at:
http://cr.openjdk.java.net/~serb/8132382/webrev.02
--
Best regards, Sergey.
--
Best regards, Sergey.
--
Best regards, Sergey.
