Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #35437 > unrolled thread

How do I terminate a JVM properly?

Back to article view | Back to comp.lang.java.programmer

Contents

  How do I terminate a JVM properly? Eric Douglas <e.d.programmer@gmail.com> - 2016-08-24 08:14 -0700
    Re: How do I terminate a JVM properly? Eric Douglas <e.d.programmer@gmail.com> - 2016-08-24 14:00 -0700
      Re: How do I terminate a JVM properly? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-24 17:39 -0400
        Re: How do I terminate a JVM properly? Eric Douglas <e.d.programmer@gmail.com> - 2016-08-25 05:24 -0700
          Re: How do I terminate a JVM properly? Nigel Wade <nmw@local.domain> - 2016-08-25 13:52 +0100
            Re: How do I terminate a JVM properly? Eric Douglas <e.d.programmer@gmail.com> - 2016-08-25 06:05 -0700
              Re: How do I terminate a JVM properly? Nigel Wade <nmw@local.domain> - 2016-08-25 15:04 +0100
                Re: How do I terminate a JVM properly? Eric Douglas <e.d.programmer@gmail.com> - 2016-08-25 08:20 -0700
              Re: How do I terminate a JVM properly? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-25 15:55 -0400
                Re: How do I terminate a JVM properly? Eric Douglas <e.d.programmer@gmail.com> - 2016-08-25 13:35 -0700
                  Re: How do I terminate a JVM properly? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-25 16:58 -0400
                  Re: How do I terminate a JVM properly? Arne Vajhøj <arne@vajhoej.dk> - 2016-08-28 13:29 -0400
                    Re: How do I terminate a JVM properly? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-28 13:53 -0400
                      Re: How do I terminate a JVM properly? Arne Vajhøj <arne@vajhoej.dk> - 2016-08-28 14:14 -0400
          Re: How do I terminate a JVM properly? Eric Douglas <e.d.programmer@gmail.com> - 2016-08-25 05:52 -0700
      Re: How do I terminate a JVM properly? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-24 18:19 -0400
      Re: How do I terminate a JVM properly? Lew <lewbloch@gmail.com> - 2016-08-24 16:12 -0700
      Re: How do I terminate a JVM properly? Roedy Green <inquiry@mindprod.com> - 2016-08-30 16:34 -0700

#35437 — How do I terminate a JVM properly?

I don't want to call System.exit().
After I dispose the last GUI object the JVM should terminate itself.
I can't see anything in the code that is not properly closed.
I run this in webstart and my client console stays open.
I press 'v' to get the thread dump and it shows me this, but I'm not sure what it's telling me.

Dump thread stack ...
----------------------------------------------------
2016-08-24 11:07:56
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode):

"TimerQueue" #61 daemon prio=5 os_prio=0 tid=0x000000001cbee800 nid=0x1c34 waiting on condition [0x00000000222ae000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000000d5c70d38> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(Unknown Source)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source)
	at java.util.concurrent.DelayQueue.take(Unknown Source)
	at javax.swing.TimerQueue.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

"AWT-EventQueue-2" #58 prio=6 os_prio=0 tid=0x000000001cbf2000 nid=0x1498 waiting on condition [0x00000000224af000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x0000000081402520> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(Unknown Source)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source)
	at java.awt.EventQueue.getNextEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

"D3D Screen Updater" #45 daemon prio=7 os_prio=1 tid=0x000000001cbf0800 nid=0x1db8 in Object.wait() [0x00000000205ff000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at sun.java2d.d3d.D3DScreenUpdateManager.run(Unknown Source)
	- locked <0x00000000811aa4d8> (a java.lang.Object)
	at java.lang.Thread.run(Unknown Source)

"CacheCleanUpThread" #28 daemon prio=5 os_prio=0 tid=0x000000001cbed800 nid=0xc20 in Object.wait() [0x000000001f2ff000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x0000000081229540> (a com.sun.deploy.cache.CleanupThread)
	at java.lang.Object.wait(Unknown Source)
	at com.sun.deploy.cache.CleanupThread.run(Unknown Source)
	- locked <0x0000000081229540> (a com.sun.deploy.cache.CleanupThread)

"CacheMemoryCleanUpThread" #25 daemon prio=5 os_prio=0 tid=0x000000001cbef000 nid=0xd40 in Object.wait() [0x000000001f1ff000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.ref.ReferenceQueue.remove(Unknown Source)
	- locked <0x00000000811e6958> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(Unknown Source)
	at com.sun.deploy.cache.MemoryCache$LoadedResourceCleanupThread.run(Unknown Source)

"MemoryCache-DelayedCleanup" #26 daemon prio=5 os_prio=0 tid=0x000000001cb24000 nid=0x1b48 in Object.wait() [0x000000001f0fe000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x000000008128f658> (a java.util.TaskQueue)
	at java.util.TimerThread.mainLoop(Unknown Source)
	- locked <0x000000008128f658> (a java.util.TaskQueue)
	at java.util.TimerThread.run(Unknown Source)

"TimerQueue" #23 daemon prio=5 os_prio=0 tid=0x000000001ca98000 nid=0x1110 waiting on condition [0x000000001edfe000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000000812904d0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(Unknown Source)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source)
	at java.util.concurrent.DelayQueue.take(Unknown Source)
	at javax.swing.TimerQueue.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

"ConsoleTraceListener" #22 daemon prio=5 os_prio=0 tid=0x000000001ca78800 nid=0x1274 in Object.wait() [0x000000001ecff000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at com.sun.deploy.uitoolkit.ui.ConsoleTraceListener$ConsoleWriterThread.run(Unknown Source)
	- locked <0x0000000081290820> (a com.sun.deploy.uitoolkit.ui.ConsoleTraceListener$BoundedStringBuffer)

"AWT-EventQueue-1" #21 prio=6 os_prio=0 tid=0x000000001c95c000 nid=0x1cf8 waiting on condition [0x000000001d98c000]
   java.lang.Thread.State: RUNNABLE
	at com.sun.deploy.uitoolkit.ui.ConsoleHelper.dumpAllStacksImpl(Native Method)
	at com.sun.deploy.uitoolkit.ui.ConsoleHelper.dumpAllStacks(Unknown Source)
	at com.sun.deploy.uitoolkit.impl.awt.ui.SwingConsoleWindow$3.actionPerformed(Unknown Source)
	at javax.swing.JComponent$ActionStandin.actionPerformed(Unknown Source)
	at javax.swing.SwingUtilities.notifyAction(Unknown Source)
	at javax.swing.JComponent.processKeyBinding(Unknown Source)
	at javax.swing.KeyboardManager.fireBinding(Unknown Source)
	at javax.swing.KeyboardManager.fireKeyboardAction(Unknown Source)
	at javax.swing.JComponent.processKeyBindingsForAllComponents(Unknown Source)
	at javax.swing.JComponent.processKeyBindings(Unknown Source)
	at javax.swing.JComponent.processKeyEvent(Unknown Source)
	at java.awt.Component.processEvent(Unknown Source)
	at java.awt.Container.processEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source)
	at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Window.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.awt.EventQueue.access$500(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue$4.run(Unknown Source)
	at java.awt.EventQueue$4.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

"DestroyJavaVM" #20 prio=5 os_prio=0 tid=0x0000000002c16000 nid=0x1e70 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Javaws Secure Thread" #18 daemon prio=5 os_prio=0 tid=0x000000001c953000 nid=0x1c68 in Object.wait() [0x000000001d58f000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Unknown Source)
	at com.sun.javaws.ui.JavawsSysRun$SecureThread.run(Unknown Source)
	- locked <0x00000000812918f8> (a java.lang.Object)

"AWT-EventQueue-0" #17 prio=6 os_prio=0 tid=0x000000001c94f000 nid=0xcdc waiting on condition [0x000000001d38e000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x0000000081239670> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(Unknown Source)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source)
	at java.awt.EventQueue.getNextEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

"AWT-Windows" #15 daemon prio=6 os_prio=0 tid=0x000000001c941800 nid=0x1874 runnable [0x0000000000e8f000]
   java.lang.Thread.State: RUNNABLE
	at sun.awt.windows.WToolkit.eventLoop(Native Method)
	at sun.awt.windows.WToolkit.run(Unknown Source)

"AWT-Shutdown" #14 prio=5 os_prio=0 tid=0x000000001c93f800 nid=0x1bbc in Object.wait() [0x000000001d28f000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Unknown Source)
	at sun.awt.AWTAutoShutdown.run(Unknown Source)
	- locked <0x0000000081207680> (a java.lang.Object)
	at java.lang.Thread.run(Unknown Source)

"Java2D Disposer" #13 daemon prio=10 os_prio=2 tid=0x000000001c93f000 nid=0x1ec8 in Object.wait() [0x000000001d18e000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.ref.ReferenceQueue.remove(Unknown Source)
	- locked <0x00000000811222d8> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(Unknown Source)
	at sun.java2d.Disposer.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

"traceMsgQueueThread" #11 daemon prio=5 os_prio=0 tid=0x000000001b3e0000 nid=0x1a80 runnable [0x000000001c87e000]
   java.lang.Thread.State: RUNNABLE
	at java.io.WinNTFileSystem.getLength(Native Method)
	at java.io.File.length(Unknown Source)
	at com.sun.deploy.trace.FileTraceListener.print(Unknown Source)
	at com.sun.deploy.trace.Trace.firePrintlnEvent(Unknown Source)
	at com.sun.deploy.trace.Trace.access$200(Unknown Source)
	at com.sun.deploy.trace.Trace$TraceMsgQueueChecker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x000000001b38a000 nid=0xb4c runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #9 daemon prio=9 os_prio=2 tid=0x000000001b2eb800 nid=0x1e5c runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #8 daemon prio=9 os_prio=2 tid=0x000000001b2e8000 nid=0x1ce0 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #7 daemon prio=9 os_prio=2 tid=0x000000001b2e7800 nid=0x1cac waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x000000001b2d9800 nid=0x1ed4 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x000000001b2d8800 nid=0x17d0 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x000000001b2d5800 nid=0x1f48 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x0000000018218000 nid=0x1904 in Object.wait() [0x000000001b89e000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.ref.ReferenceQueue.remove(Unknown Source)
	- locked <0x00000000810ce3f0> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(Unknown Source)
	at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x000000001b2c0800 nid=0x11cc in Object.wait() [0x000000001b79f000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Unknown Source)
	at java.lang.ref.Reference.tryHandlePending(Unknown Source)
	- locked <0x00000000813f1e58> (a java.lang.ref.Reference$Lock)
	at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)

"VM Thread" os_prio=2 tid=0x0000000018208000 nid=0xd8 runnable 

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000002c2c000 nid=0x17e0 runnable 

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000002c2d800 nid=0x7f0 runnable 

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x0000000002c2f000 nid=0x1280 runnable 

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000002c30800 nid=0x1f68 runnable 

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x0000000002c33000 nid=0x1ee4 runnable 

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x0000000002c34000 nid=0x1df8 runnable 

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x0000000002c38000 nid=0x1e60 runnable 

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000000002c39000 nid=0x1e50 runnable 

"VM Periodic Task Thread" os_prio=2 tid=0x000000001b3db000 nid=0x1c1c waiting on condition 

0 tid=0x0000000002c38000 nid=0x1e60 runnable 

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000000002c39000 nid=0x1e50 runnable 

"VM Periodic Task Thread" os_prio=2 tid=0x000000001b3db000 nid=0x1c1c waiting on condition 


----------------------------------------------------
Done.

[toc] | [next] | [standalone]

#35440

On Wednesday, August 24, 2016 at 11:14:32 AM UTC-4, Eric Douglas wrote:
> I don't want to call System.exit().
> After I dispose the last GUI object the JVM should terminate itself.
> I can't see anything in the code that is not properly closed.
> I run this in webstart and my client console stays open.
> I press 'v' to get the thread dump and it shows me this, but I'm not sure what it's telling me.

Appears to be a bug in the JRE?  I tried the simplest program, with all GUI windows disposed, JVM still did not close itself.  Only workaround I can see is checking in the window close event if any displayable windows exist, if not then call System.exit.

[toc] | [prev] | [next] | [standalone]

#35441

On 8/24/2016 5:00 PM, Eric Douglas wrote:
> On Wednesday, August 24, 2016 at 11:14:32 AM UTC-4, Eric Douglas wrote:
>> I don't want to call System.exit().
>> After I dispose the last GUI object the JVM should terminate itself.
>> I can't see anything in the code that is not properly closed.
>> I run this in webstart and my client console stays open.
>> I press 'v' to get the thread dump and it shows me this, but I'm not sure what it's telling me.
>
> Appears to be a bug in the JRE?  I tried the simplest program, [...]

     Code?

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35451

On Wednesday, August 24, 2016 at 5:40:23 PM UTC-4, Eric Sosman wrote:
> > Appears to be a bug in the JRE?  I tried the simplest program, [...]
> 
>      Code?

I mean as simple as simple can be.  There's a JNLP pointing to a test server set up on IIS.

<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="6.0+" codebase="http://myserver.mydomain.com/MyWebRoot/" href="Public/Test.jnlp">
<security>
     <all-permissions/> 
</security> 
<resources>
     <j2se version="1.8+" initial-heap-size="128m"/>
     <jar href="Public/Test.jar"/>
</resources>
<application-desc main-class="com.javatest.SimpleTest">
</application-desc>
</jnlp>

and that jar packaged in that one class.
package com.javatest;

import java.awt.EventQueue;

import javax.swing.JDialog;

public class SimpleTest {
     public SimpleTest() {
          EventQueue.invokeLater(new Runnable() {

               @Override
               public void run() {
                    showGui();
               }
          });
     }
     
     public static void main(String[] args) {
          new SimpleTest();
     }
     
     private void showGui() {
          final JDialog frame = new JDialog();
          frame.setTitle("Testing");
          frame.setVisible(true);
     }

}

The JVM does terminate itself if I set Java in the Control Panel to hide the console, but if that console is visible it stays open deadlocked until I hit the Close button.  In our regular application I can run with the console window visible and it disappears when the program ends, but we're starting from a third party jar so I can only guess they're calling System.exit().  I assume this is why no one cares that the JVM doesn't terminate, because end users normally hide the console window.  I'm used to that window disappearing on it's own so when I wrote a standalone program and it didn't disappear I assume I missed something or it's a bug.

[toc] | [prev] | [next] | [standalone]

#35452

On 25/08/16 13:24, Eric Douglas wrote:
> On Wednesday, August 24, 2016 at 5:40:23 PM UTC-4, Eric Sosman wrote:
>>> Appears to be a bug in the JRE?  I tried the simplest program, [...]
>>
>>      Code?
>
> I mean as simple as simple can be.  There's a JNLP pointing to a test server set up on IIS.

In your original post you stated that:
"After I dispose the last GUI object the JVM should terminate itself."

Indeed it should. But where exactly, in the code below, do you dispose of the GUI objects you've created?
(FYI, close != dispose).

The EDT will not exit as long as there are displayable components left which the JVM is managing.
(displayable != visible).


>
> <?xml version="1.0" encoding="utf-8"?>
> <jnlp spec="6.0+" codebase="http://myserver.mydomain.com/MyWebRoot/" href="Public/Test.jnlp">
> <security>
>      <all-permissions/>
> </security>
> <resources>
>      <j2se version="1.8+" initial-heap-size="128m"/>
>      <jar href="Public/Test.jar"/>
> </resources>
> <application-desc main-class="com.javatest.SimpleTest">
> </application-desc>
> </jnlp>
>
> and that jar packaged in that one class.
> package com.javatest;
>
> import java.awt.EventQueue;
>
> import javax.swing.JDialog;
>
> public class SimpleTest {
>      public SimpleTest() {
>           EventQueue.invokeLater(new Runnable() {
>
>                @Override
>                public void run() {
>                     showGui();
>                }
>           });
>      }
>
>      public static void main(String[] args) {
>           new SimpleTest();
>      }
>
>      private void showGui() {
>           final JDialog frame = new JDialog();
>           frame.setTitle("Testing");
>           frame.setVisible(true);
>      }
>
> }
>
> The JVM does terminate itself if I set Java in the Control Panel to hide the console, but if that console is visible it stays open deadlocked until I hit the Close button.  In our regular application I can run with the console window visible and it disappears when the program ends, but we're starting from a third party jar so I can only guess they're calling System.exit().  I assume this is why no one cares that the JVM doesn't terminate, because end users normally hide the console window.  I'm used to that window disappearing on it's own so when I wrote a standalone program and it didn't disappear I assume I missed something or it's a bug.
>

[toc] | [prev] | [next] | [standalone]

#35454

On Thursday, August 25, 2016 at 8:52:12 AM UTC-4, Nigel Wade wrote:
> In your original post you stated that:
> "After I dispose the last GUI object the JVM should terminate itself."
> 
> Indeed it should. But where exactly, in the code below, do you dispose of the GUI objects you've created?
> (FYI, close != dispose).
> 
> The EDT will not exit as long as there are displayable components left which the JVM is managing.
> (displayable != visible).
> 

It appears to destroy the window when you click the X.  DISPOSE_ON_CLOSE is not the default?  Let's try adding that.
I normally set windows to DO_NOTHING_ON_CLOSE with a WindowListener looking for the close event to do some cleanup before calling dispose().  I left that out of the simple test thinking it shouldn't be necessary.
I do remember testing yesterday that the window was showing isDisplayable() = true before calling dispose().

So, if console is visible (as a developer mine normally is, I put debug messages in there), the JVM stays active apparently on a deadlock until you manually close the console with it's Close button.  With an explicit call to dispose the JVM does terminate if console is not visible. (our normal application API does automatically close that console window, must be calling System.exit)

     private void showGui() {
          final JDialog frame = new JDialog();
          frame.addWindowListener(new WindowAdapter() {

               @Override
               public void windowClosing(final WindowEvent e) {
                    ((Window) e.getSource()).dispose();
               }
          });

          frame.setTitle("Testing");
          frame.setVisible(true);
     }

[toc] | [prev] | [next] | [standalone]

#35455

On 25/08/16 14:05, Eric Douglas wrote:
> On Thursday, August 25, 2016 at 8:52:12 AM UTC-4, Nigel Wade wrote:
>> In your original post you stated that:
>> "After I dispose the last GUI object the JVM should terminate itself."
>>
>> Indeed it should. But where exactly, in the code below, do you dispose of the GUI objects you've created?
>> (FYI, close != dispose).
>>
>> The EDT will not exit as long as there are displayable components left which the JVM is managing.
>> (displayable != visible).
>>
>
> It appears to destroy the window when you click the X.

It closes the window. Nothing else.

> DISPOSE_ON_CLOSE is not the default?  Let's try adding that.

No, it's not the default.

> I normally set windows to DO_NOTHING_ON_CLOSE with a WindowListener looking for the close event to do some cleanup before calling dispose().  I left that out of the simple test thinking it shouldn't be necessary.
> I do remember testing yesterday that the window was showing isDisplayable() = true before calling dispose().
>
> So, if console is visible (as a developer mine normally is, I put debug messages in there), the JVM stays active apparently on a deadlock until you manually close the console with it's Close button.  With an explicit call to dispose the JVM does terminate if console is not visible. (our normal application API does automatically close that console window, must be calling System.exit)

Is the JVM still running, or just the console? I don't use Windows much, so wouldn't know what the Windows Java console window does.
If you want to know if your application is exiting cleanly run it from the command line and see if it exits.

[toc] | [prev] | [next] | [standalone]

#35456

On Thursday, August 25, 2016 at 10:04:40 AM UTC-4, Nigel Wade wrote:
> Is the JVM still running, or just the console? I don't use Windows much, so wouldn't know what the Windows Java console window does.
> If you want to know if your application is exiting cleanly run it from the command line and see if it exits.

Yes the console is part of the JVM.  If you select Show Console from the Advanced tab of the Java in Control Panel you get a plain white window on the client where System.out messages show.  As long as this is visible, Task Manager shows JVM.

With no console visible if you display a Swing window and close it using the default option which only hides it, the JVM stays in task manager under Background processes, with the window disposed the JVM does terminate.

Apparently you cannot terminate a JVM with a visible console without calling System.exit, otherwise user must push the close button in the console to terminate.

[toc] | [prev] | [next] | [standalone]

#35460

On 8/25/2016 9:05 AM, Eric Douglas wrote:
> On Thursday, August 25, 2016 at 8:52:12 AM UTC-4, Nigel Wade wrote:
>> In your original post you stated that:
>> "After I dispose the last GUI object the JVM should terminate itself."
>>
>> Indeed it should. But where exactly, in the code below, do you dispose of the GUI objects you've created?
>> (FYI, close != dispose).
>>
>> The EDT will not exit as long as there are displayable components left which the JVM is managing.
>> (displayable != visible).
>
> It appears to destroy the window when you click the X.  DISPOSE_ON_CLOSE is not the default?
> [...]

     Nigel's nailed it.  Quoth the Javadoc for JDialog: "The value is
set to HIDE_ON_CLOSE by default."  (You've got to hunt a bit for it:
The text is not in the "up front" material for the class, the way it
is for JFrame, but down in the setDefaultCloseOperation() description.)

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35461

On Thursday, August 25, 2016 at 3:55:57 PM UTC-4, Eric Sosman wrote:
>      Nigel's nailed it.  Quoth the Javadoc for JDialog: "The value is
> set to HIDE_ON_CLOSE by default."  (You've got to hunt a bit for it:
> The text is not in the "up front" material for the class, the way it
> is for JFrame, but down in the setDefaultCloseOperation() description.)

Right...JFrame does tell you it does a hide on close by default right in the top block of the Javadoc while the JDialog is only documented under that method, I just had guessed for the simple sample the default would be to dispose (because who assumes you want to reuse a window after you close it?).

In my app I never use JFrame because JDialog can do everything a JFrame can do but gives you more control, specifically in making windows modal so user can't access a window if an event from that window generates a new window, also giving you control over window decorations like a user should be able to minimize a window but not maximize it (or for a popup window to remove all decorations).  I don't normally care about the default close operation because I always override to do nothing on close, so a window listener can add a popup "Are you sure you want to close?" prompt and do some cleanup.

The confusing part is a JVM never terminates without calling System.exit() if the user has the Java Console visible, unless they click the Close button on that console.  Though everything else is properly disposed, that console holds it open.  In our application (running on a closed source API) that console does close itself, so they must just be exiting.  To write a multi-window standalone app that closes that console I would have to check if there are any displayable windows in my window closing listeners (after disposing current window) then call the exit.

[toc] | [prev] | [next] | [standalone]

#35462

On 8/25/2016 4:35 PM, Eric Douglas wrote:
> On Thursday, August 25, 2016 at 3:55:57 PM UTC-4, Eric Sosman wrote:
>>      Nigel's nailed it.  Quoth the Javadoc for JDialog: "The value is
>> set to HIDE_ON_CLOSE by default."  (You've got to hunt a bit for it:
>> The text is not in the "up front" material for the class, the way it
>> is for JFrame, but down in the setDefaultCloseOperation() description.)
>
> Right...JFrame does tell you it does a hide on close by default right in the top block of the Javadoc while the JDialog is only documented under that method, I just had guessed for the simple sample the default would be to dispose (because who assumes you want to reuse a window after you close it?).

     I can't recall re-using a closed JFrame, but I re-use JDialogs more
often than not.  They're for notifications (often via JOptionPane, but
sometimes customized), or more frequently for data entry -- and why
re-construct the whole data entry form again, just because the user
has finished describing one item and moves on to the next?

     YMMV, naturally.

> [...]
> The confusing part is a JVM never terminates without calling System.exit() if the user has the Java Console visible, unless they click the Close button on that console.  Though everything else is properly disposed, that console holds it open. [...]

     I seldom use a console window, but this behavior makes sense.  The
user may want to read the application's last-gasp console message before
it disappears:

	The application has encountered a fatal error. Please contact
	Technical support immediately and provide these syndrome codes:

	    0x00EB9C4408 0x0000ED64 0x231

	                             > vanish <

	                  > "Hey, where'd those codes go?" <

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35491

On 8/26/2016 11:55 AM, Stefan Ram wrote:
>   When Swing was still around,

It still is.

Arne

[toc] | [prev] | [next] | [standalone]

#35493

On 8/28/2016 1:29 PM, Arne Vajhøj wrote:
> On 8/26/2016 11:55 AM, Stefan Ram wrote:
>>   When Swing was still around,
>
> It still is.

     In fact, Swing is part of Java SE while JavaFX is not.

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35494

On 8/28/2016 1:53 PM, Eric Sosman wrote:
> On 8/28/2016 1:29 PM, Arne Vajhøj wrote:
>> On 8/26/2016 11:55 AM, Stefan Ram wrote:
>>>   When Swing was still around,
>>
>> It still is.
>
>     In fact, Swing is part of Java SE while JavaFX is not.

And it will be there for a long time.

Relative fast pace:

Java 9 - JavaFX added to Java SE
Java 10 - Swing Deprecated
Java 11 or 12 - Swing removed

Slow pace will start be deprecating AWT !! :-)

Arne

[toc] | [prev] | [next] | [standalone]

#35453

On Thursday, August 25, 2016 at 8:25:01 AM UTC-4, Eric Douglas wrote:
>

or at least that simple test appeared to close the JVM with the console set to hidden.  I just checked Task Manager and Java Web Launcher shows under Background processes once for each time I run that test.

[toc] | [prev] | [next] | [standalone]

#35443

On 8/24/2016 5:50 PM, Stefan Ram wrote:
> Eric Douglas <e.d.programmer@gmail.com> writes:
>> Appears to be a bug in the JRE?  I tried the simplest
>> program, with all GUI windows disposed, JVM still did not
>> close itself.
>
>   Works here.
>
> public final class Main extends javafx.application.Application
>[...]

     Note that the stack traces shown in the original message have no
mentions of anything in a javafx package.  They do, however, show
various javax.swing packages -- and classes, including JComponent
and SwingUtilities.  My guess is that he's using Swing, and that
examples based on JavaFX may be less than completely relevant.

     ... but it'd be nice not to need to guess, so I hope he'll show
us the source of his "simplest program."

-- 
esosman@comcast-dot-net.invalid
The Tooth Fairy has gone high-tech, now pays in Bitecoin.

[toc] | [prev] | [next] | [standalone]

#35444

Eric Douglas wrote:
> Appears to be a bug in the JRE? 

Sure. That happens. All the time. Because, you know, after twenty years it's so unstable.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#35500

On Wed, 24 Aug 2016 14:00:21 -0700 (PDT), Eric Douglas
<e.d.programmer@gmail.com> wrote:

>Appears to be a bug in the JRE?  I tried the simplest program,
 with all GUI windows disposed, JVM still did not close itself.  Only
workaround I can see is checking in the window close event if any
displayable windows exist, if not then call System.exit.
When you think you are done:

call this to find out what threads are still  running:

 /**
     * call just before System.exit( 0 ) to find out if there was more
than one thread.
     */
    public static void trackLastThread()
        {
        final int activeCount = Thread.activeCount();
        if ( activeCount <= 1 )
            {
            return;
            }
        final Thread[] ta = new Thread[ activeCount ];
        Thread.enumerate( ta );
        // list just the user threads, not the daemons
        int userCount = 0;
        for ( Thread t : ta )
            {
            if ( !t.isDaemon() )
                {
                userCount++;
                }
            }
        if ( userCount <= 1 )
            {
            return;
            }
        for ( Thread t : ta )
            {
            if ( !t.isDaemon() )
                {
                out.println( "U S E R   T H R E A D" );
                out.println( t.toString() + " : " + t.getState() );
                final StackTraceElement[] s = t.getStackTrace();
                for ( StackTraceElement e : s )
                    {
                    out.println( e.toString() );
                    }
                out.println();
                }
            }
        }// /method

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web