Kieran France Kieran France is a programmer for IDRSolutions in charge of there internal test suite. In his spare time he enjoys tinkering with gadgets and code.

Only hit the button marked “System.exit” in an emergency!

1 min read

Recently I have been working on the removal of any System.exit I can find within our library. This was prompted for two main reasons. We are building a library to be used by other and thread issues may can go unseen due to the System.exit call.

When you are putting a library into your own application, if it uses System.exit call within the library it will also leave the application it is built into as all threads being used by the application are closed if you want it or not.

This is the same reason thread issue may slip through. System.exit abruptly forces all related threads to close. This means some thread may not actually have a way to close and has become to rely on the System.exit to close it. The problem hits when we need to exit a library but leave the application it is within open. Those threads relying on System.exit have not closed.

Whilst working on the removal I have came up with 3 good reasons why removal or refraining from using System.exit unless you must absolutely drop out of every which should be reserved for catching on the most critical errors.


1. System.exit closes the current application, if the library is added another application and a System.exit is called it will not only close our library code but also the other application. By removing the System.exit we can close and remove the objects used by jPedal leaving the other application to continue.

2. In removing the System.exit calls our internal handling of threads is improving as the System.exit would close all threads. By not using System.exit we can ensure all threads are removed, disposed and garbage collection can all function as intended instead of abruptly ending threads.

3. Related to the first reason, in making these changes we make the library easier to integrate into different types of third party applications, such as those planning to open and close multiple viewer instances before the application should exit.

So what should you do instead?

There are many things that should be done to ensure the application will close. The most important ones I have come across are as follow.

  • Ensure your program reaches the end of the main thread when the application should close. If you open additional threads the application will remain open until the thread ends.
  • If you open additional threads ensure they are closed and disposed when the application should end.
  • If you don’t want a thread to keep the application open, make them daemon threads.
  • If using a JFrame ensure the default close operation is set to JFrame.DISPOSE_ON_CLOSE or JFrame.EXIT_ON_CLOSE
  • Ensure any object created that contain threads are disposed of correctly when your exit routines are called.

I hope I have managed to convince you to stop using System.exit. If after reading this you begin thinking of System.exit as the big red emergency button and not the power switch I have successfully achieved my goal.

View PDF files in a web application →

Parse PDF files as HTML →

Display PDF Forms in a web browser →

View PDF Documents in Java Applications →

Rasterize PDF Documents to image →

Read/Write images (including HEIC, JPG and WEBP) →

Convert Image files to PDF Documents →

Kieran France Kieran France is a programmer for IDRSolutions in charge of there internal test suite. In his spare time he enjoys tinkering with gadgets and code.

Leave a Reply

Your email address will not be published. Required fields are marked *

IDRsolutions Ltd 2022. All rights reserved.