<AWT Dev> Best workaround for OSX Window leak? (JDK-8029147)

[Sergey Bylokhov]

Hi, Andy.
You code lack of Frame.dispose(), so the frames are shown forever. You 
can update the test by these lines:
	frm.setVisible(true);
+        try {
+            Thread.sleep(1000);
+        } catch (InterruptedException e) {
+            e.printStackTrace();
+        }
+        frm.dispose();

And it will pass after some period of time on jdk8u112, and fails on 
jdk8u101. Can you please double check?

On 20.09.16 15:43, Andy Lee wrote:
> Here is my test code that demonstrates the
> leak: http://bonuslord.github.io/misc/FrameLeakDemo.java
>
> In JDK 8 the output indicates 3 frames remaining even after closing all
> of the JFrames.
> In JDK 9 the output usually reports 1 frame remaining after closing all
> of the frames, although sometimes all 3 JFrames get properly GC'd and
> the output reports 0.
>
> On Mon, Sep 19, 2016 at 4:08 PM, Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>     On 19.09.16 23:02, Andy Lee wrote:
>
>         In JDK 9 the problem seems to be partially fixed; only the most
>         recently
>         closed JFrame leaks (ie, a temporary leak).  I was unable to get
>         Visual
>         VM to connect to the Java 9 process so I'm not exactly sure what was
>         preventing the last JFrame from being GC'd.
>
>
>     Can you place the code which uses JFrame somewhere? It seems that
>     some of the related bugs were not backported, like:
>     https://bugs.openjdk.java.net/browse/JDK-8156116
>     <https://bugs.openjdk.java.net/browse/JDK-8156116>
>
>     I will check which one.
>
>
>         The Java 9 behavior would be sufficient to solve most of our major
>         issues, but it will be quite some time before it becomes feasible to
>         move our application to Java 9 so it doesn't really help us.
>
>         On Mon, Sep 19, 2016 at 2:51 PM, Sergey Bylokhov
>         <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>         <mailto:Sergey.Bylokhov at oracle.com
>         <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>
>             On 19.09.16 19:13, Andy Lee wrote:
>
>                 Yes, I just tried my test case on JDK 8u112 and I can still
>                 reproduce
>                 the JFrame leak.
>
>
>             And what about the latest jdk9?
>             https://jdk9.java.net/download
>
>
>                 On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov
>                 <Sergey.Bylokhov at oracle.com
>         <mailto:Sergey.Bylokhov at oracle.com>
>         <mailto:Sergey.Bylokhov at oracle.com
>         <mailto:Sergey.Bylokhov at oracle.com>>
>                 <mailto:Sergey.Bylokhov at oracle.com
>         <mailto:Sergey.Bylokhov at oracle.com>
>
>                 <mailto:Sergey.Bylokhov at oracle.com
>         <mailto:Sergey.Bylokhov at oracle.com>>>> wrote:
>
>                     Hi, Andy.
>                     I suggest to check the latest jdk9 and jdk8. Do you
>         able to
>                     reproduce this bug on jdk8u112?
>
>
>                     On 19.09.16 17:19, Andy Lee wrote:
>
>                         Not sure if this is the best place to ask, but I'm
>                 looking for
>                         good way
>                         to prevent the JFrame/JDialog memory leaks caused
>                         by
>         https://bugs.openjdk.java.net/browse/JDK-8029147
>         <https://bugs.openjdk.java.net/browse/JDK-8029147>
>                 <https://bugs.openjdk.java.net/browse/JDK-8029147
>         <https://bugs.openjdk.java.net/browse/JDK-8029147>>
>
>         <https://bugs.openjdk.java.net/browse/JDK-8029147
>         <https://bugs.openjdk.java.net/browse/JDK-8029147>
>                 <https://bugs.openjdk.java.net/browse/JDK-8029147
>         <https://bugs.openjdk.java.net/browse/JDK-8029147>>>
>
>                         The best solution I've found so far is to use
>         reflection
>                 to dig
>                         in and
>                         null out the 'target' fields on the
>         LWComponentPeer and
>                         CPlatformWindow
>                         after disposing.  This at least allows the
>         JDialog/JFrame
>                         instance to be
>                         GC'd (along with any heavier objects they may
>                 reference), but isn't
>                         optimal since ultimately the LWComponentPeer and
>                 CPlatformWindow
>                         instances still end up leaking.  Another problem
>         with this
>                         approach is
>                         that we have hundreds of uses of
>         JFrames/JDialogs across our
>                         codebase
>                         and this workaround would require each one of
>         them to be
>                         modified to add
>                         this special cleanup logic; I'd like to avoid
>         that if at all
>                         possible~
>
>                         Any suggestions?
>
>                         ~Andy Lee
>
>
>
>                     --
>                     Best regards, Sergey.
>
>
>
>
>             --
>             Best regards, Sergey.
>
>
>
>
>     --
>     Best regards, Sergey.
>
>


-- 
Best regards, Sergey.