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()?
Asked
Active
Viewed 1,483 times
6
4 Answers
6
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".
Vit Khudenko
- 28,288
- 10
- 63
- 91
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, ...
user207421
- 305,947
- 44
- 307
- 483
-
And calling it as the last instruction after having cleaned up, would be considered correct? (I usually do, it saves me from iterating over the screens in stack one by one). – Mister Smith Nov 29 '11 at 10:06
1
From my understanding it is incorrect to kill off your container by invoking System.exit(). The proper way to do so is to create a destroy() method of some sort which allows for cleaning your threads and closing any resources you have opened.
To put things in layman's terms System.exit() may leave behind lingering data/session-information.
Dennis
- 3,962
- 7
- 26
- 44
0
From what I remember of BB development, System.exit() just closes the app without destructing the objects you've created, leaving them to the garbage collector. Hence, the app will not effectively be removed from memory. Closing screens one by one will actually deallocate them.
I might be a bit off on the details, but there's enough info about best practices on the net :)
favoretti
- 29,299
- 4
- 48
- 61
-
1Untrue. The application is removed from memory. All memory is released to the operating system when a process exits. All system resources are released to the operating system as well, including fds, windows, sockets, ... Last time I used an operating system on which that wasn't true was about 1994. – user207421 Nov 29 '11 at 01:57
-
1Well, you are right when you're talking about OS, you're not right when you're talking about JVM. – favoretti Nov 29 '11 at 07:19
-
@favoretti The topic under discussion is a JVM that has exited via `System.exit()`. That's what my comment addresses. Your answer remains incorrect. – user207421 Nov 29 '11 at 09:04
-
In a BB app `System.exit()` does not terminate JVM, only the app is terminated. There is the only JVM per BB device. All apps are running within the only JVM. – Vit Khudenko Nov 29 '11 at 20:40
-
That was my idea as well. Although it's been a while since I did BB programming, and EJP was so aggressively-reassured, I just shut up :) – favoretti Nov 29 '11 at 21:54
-
@favoretti: Well, I created a test app and it turns out the static handles in a new app session are always null after the previous app session has been terminated by `System.exit(0)`. I added the UPDATE section to my answer. – Vit Khudenko Nov 30 '11 at 13:57
-
@Arhimed: hmm, if they are nulled it doesn't mean they are destoyed, right? they merely have number of references = 0, so next GC run should pick em up from the heap. Or am I completely out of my mind now? – favoretti Nov 30 '11 at 14:55
-
@favoretti: I thought about this too, maybe handles are nullified, but the objects themself are still alive awaiting a GC call. However since in BB API `Object` does not have `finalize()` it is impossible to write a code to test this. – Vit Khudenko Nov 30 '11 at 15:27
-
@Arhimed, well I don't have a BB suite here, and in general I'm a long-time Mac user now, so if you don't mind twiddling some more - basically very simple test, boot an emulator, let it run for 5-10 mins, fetch the amount of free ram, then start the app, allocate some crap it it, substantially visible, kill the app via System.exit(), run another small app that only will report amount of used memory, wait for a few more minutes until GC run kicks in, see if the amount of freed memory equals or nearly equals allocated by the app :P – favoretti Nov 30 '11 at 15:40
-