Bug 1111 - Java3D does not dispose correctly after use
Summary: Java3D does not dispose correctly after use
Status: RESOLVED FIXED
Alias: None
Product: Java3D
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: pc_x86_64 windows
: --- major
Assignee: Phil Jordan
URL:
Depends on:
Blocks:
 
Reported: 2014-12-16 07:36 CET by iryan
Modified: 2016-11-01 08:27 CET (History)
2 users (show)

See Also:
Type: FEATURE
SCM Refs:
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description iryan 2014-12-16 07:36:41 CET
When using Java3D (version 1.6) without drawing anything onto the screen or setting anything to visible (for example to render an image into a file), the application will not exit. There simply seems to be no way to close Java3D without System.exiting the whole program.

Already tried to call finish on J3DThread (see  https://stackoverflow.com/questions/16470930/is-there-a-way-to-terminate-a-java-application-that-uses-java3d-without-calling ), which does not cause any errors - but also doesn't fix the problem, unfortunately. 

The problem can be reproduced simply with the old Java3D offscreen_canvas3D example (using the 1.6 libs and dependencies), by simply removing the call the JFrame.setVisible(true). The application starts, opens some windows (Java3D, I assume) for a short moment and then... does nothing but also doesn't exit.

The thread dump can be found here: http://pastebin.com/AK0gNs7D

The question would be, how to dipose the Java3D components manually to get back to the state the application was in before anything Java3D related was started.
Comment 1 Julien Gouesse 2014-12-16 10:34:08 CET
The problem is that the provided thread dump shows no thread created by Java3D except main-SharedResourceRunner, which comes from JOGL. Please try to dispose the Java3D canvas too.
Comment 2 iryan 2014-12-22 08:13:24 CET
I tried setVisible(false), disable (deprecated) on the Canvas3D (since it has no dispose() method), but that doesn't change anything. There seem to be some potentially helpful sounding static methods, but as they aren't public...
Comment 3 Harvey Harrison 2014-12-22 08:26:35 CET
Looking at that thread dump, the only non-daemon threads left are the AWT EventQueue threads, meaning there is some AWT component that hasn't been disposed....maybe fire up jvisualVM and look for leftover AWT windows?

Harvey
Comment 4 Phil Jordan 2016-10-18 07:34:55 CEST
https://java.net/projects/java3d/pages/Java3DApplicationDev
Has a section on this subject, that might be worth looking at
Comment 5 Phil Jordan 2016-11-01 08:27:30 CET
Resolved in 1.7.0

All Java3D threads set to daemon

Note there is a strong possibility that this could have side effects particularly in headless environments.

However a daemon nature is more correct and will allow applications to exit gracefully and when expected.

In testing normal swing operations can cause non-exiting.
E.g. 
JFrame f = new JFrame();
f.pack();

will not exit unless 
f.dispose(); 
is called. This is unrelated to Java3D.