DrJava and the Tablets

I implemented an algorithm suggested by Peter Centgraf today that attempts to detect if DrJava did not close properly the last time it ran. This is still related to bug [ 1550220 ].

On startup, DrJava creates a lock file in the temporary directory (containing the user name in the file name so different users can be distinguished); if the file already existed, then there might have been a crash. DrJava now attempts to acquire a FileLock for that file; if that fails, then another instance of DrJava is currently running.

If the file existed and no other instance is running, the user is presented with a Yes/No dialog box with the text “DrJava’s lock file was not deleted the last time DrJava ran, which may have been due to
DrJava failing to exit properly. If you remember DrJava hanging after you tried to close it we suggest you enable the ‘Forcefully Quit DrJava’ option. Would you like to enable that option?”, and if the user chooses “Yes”, the option is enabled.

On closing DrJava, the lock is relesed and the file deleted by the process that originally created it. This is done in a shutdown hook to make it happen “as late as possible”, i.e. after the call to System.exit. Recall that there is no problem running code until System.exit is called, after which DrJava hangs, so calling the code to release the lock and close the file before System.exit is utterly pointless.

Peter looked at my implementation and still found a few problems:

If the user launches DrJava too soon after killing the hung instance, the lock might not be freed before the check runs. I think the user may have to dismiss the “Send error report” dialog before re-launching.

I’m not sure I can do anything about that. That seems to be Windows.

${java.io.tmpdir} is in the user profile on Windows XP, so this will not be local for a roaming profiles setup.

I don’t know of a platform-independent way to find a local temporary directory, though.

The dialog box presented to the user is singularly unhelpful, since it doesn’t describe the consequences of the choice or provide a reasonable alternative. Since the worst thing that can happen is that a few temp files won’t be cleaned up, I think it would be safe to silently enable “Forcefully quit” if it is needed. Windows users suffer from runaway temp files anyway, so DrJava won’t be making a significant impact.

The truth is: I just have no idea what using Runtime.halt instead of System.exit can do, so I would only suggest it to those users that are likely to suffer from exactly this problem. If you have to kill DrJava at any other time, the lock file will also still be there, but in that case, enabling “forcefully quit” would not be the right choice.

We’ll see what the others think of these issues.

When I had that implemented, I used the lock file for an experiment of mine to implement feature request [ 1518709 ]: I wrote the file name of the “MasterRemote” stub into the lock file. That way, a second instance of DrJava can connect to an existing instance. I implemented a -connect command line switch that tells DrJava to open the files specified on the command line in the instance of DrJava that created the lock file.


java -jar drjava-lockfile3.jar
java -jar drjava-lockfile3.jar -connect Test.java

This opens one copy of DrJava, then tells DrJava to open Test.java in the first instance. Only one copy of DrJava will be open at the end.

Unfortunately, because of the strange way file locking is done by the OS, this does not work on Windows: The second instance of DrJava cannot read the lock file. This was just an experiment. If we want to do this across all platforms, we probably have to use the RMI registry.


About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in DrJava. Bookmark the permalink.

Leave a Reply