Search code examples
javapdfbackgroundjframeicepdf

icepdfcore keeps JFrame opened in the background


I know my problem is a bit of weird, but I'm currently working on a java swing app that opens a pdf from a filechooser in another jframe using icepdfcore

This is my code :

private void jButton1ActionPerformed(java.awt.event.ActionEvent evt)
{
    JFilechooser filedialog=new JFileChooser();
    filedialog.showOpenDialog(frame);                                         
    File file=filedialog.getSelectedFile();
    SwingController controller = new SwingController();
    SwingViewBuilder factory = new SwingViewBuilder(controller);
    JPanel viewerComponentPanel = factory.buildViewerPanel();
    JFrame window = new JFrame("PDF Viewer");
    window.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
    window.getContentPane().add(viewerComponentPanel);
    window.setVisible(true);
    controller.openDocument(file.getAbsolutePath());
}

When I select the file it's correctly displayed using icepdfcore, but the problem is that when I close the main frame, it's not fully closed as I can see in netbeans that it's still running in the background, and the only way to force kill it is by clicking the red square

enter image description here

I added the onclosing event to the newframe but still the problem

window.addWindowListener(new java.awt.event.WindowAdapter()
{
    public void windowClosed(java.awt.event.WindowEvent evt)
    {
        controller.closeDocument();
        //controller.dispose();
        controller.exit();
    }
});

Somehow icepdfcore keeps the parent frame locked and so far I haven't figured out yet.

Any help would be appreciated.


Solution

  • I solved the issue by adding System.exit(0) to the windowClosed event of the JFrame

    This way, all program resources are destroyed, including the non daemon process running by icepdfcore

    window.addWindowListener(new java.awt.event.WindowAdapter()
    {
        public void windowClosed(java.awt.event.WindowEvent evt)
        {
            System.exit(0);
        }
    });
    

    However, I still cannot understand this unexpected behaviour, as I'm using version 4.3.3 and the bug had already been fixed in version 3.0