Why Avoid System.exit()?

Question

I was reading in Anthony Rizk's book Beginning BlackBerry Development that although System.exit() method will exit an application, it is recommended to avoid this and properly clean up the application on exiting by closing all screens instead. My question is, why avoid System.exit()?

Answer 1

This is a really interesting question!

There is a difference in System.exit() behavior for Java SE API and BB Java API:

• In Java SE API: terminates the currently running Java Virtual Machine.
• In BB Java API: terminates the currently running Java application.

Also check what is said about this in the "Learn Blackberry Games Development" by Carol Hamer and Andrew Davison:

Caution: The BlackBerry platform doesn’t launch your application in a separate virtual machine, which means that you have to be very careful about cleanup. The remains of an earlier run (such as static variables and other data still in memory) can potentially affect later runs of the application. It also means that there’s a global namespace, so if two classes have the same name, errors can arise.

So, yes, there is the only JVM per BB device. And yes, in a BB app the System.exit() call just stops your app, leaving all your static data in RAM unless you do a preliminary cleanup.

So you should not avoid System.exit() - it is a legal/proper way to close a BB app, but just do any cleanup before this call.

UPDATE:

Ooops. I created a test app (using JDE 4.7.0 + Storm 9530 4.7.0 simulator) to test whether the static stuff really stays in RAM after System.exit() call. And it turns out that it DOES NOT stay there any longer. Next time I enter the app the static variables are nulls (as we would expect them to be in Java SE). So it is unclear for me what Carol Hamer and Andrew Davison mean saying "The remains of an earlier run (such as static variables and other data still in memory) can potentially affect later runs of the application".

Answer 2

It's because it may short-circuit your own orderly exit methods, e.g. flushing buffered output streams/writers, logging sessions out, deleting files, committing DBMS transactions, ...