After finishing the change of the XML project file format in a series of all-nighters leading up to Thursday, April 3, with almost no sleep between Saturday and that Thursday, I unfortunately got sick again. It’s a shame: I get sick, I get better, I miss programming so much that I throw myself into endless hours of work, then I get sick again, probably from overdoing it and not eating properly. Before we made a new development release, drjava-20080411-1951-r4436 , I managed to make one commit with several small bugfixes for the new XML project file format on Windows machines, but that was it. I was so sick, I couldn’t make it from my bed to the fridge. I’m afraid I’m not healthy yet, I’m still just as sick, but I’ve lost so much weight that it’s become easier to transport my body…
Now I added a small thing that I wish had gone into the release on Friday: An automatic update checker for DrJava. By default, it runs every seven days on start-up of DrJava and checks if there is a newer stable or beta release. If there is, then a dialog is displayed with a “Download” button that takes the user to SourceForge.
The settings can also be changed so that it
- checks for stable releases only,
- checks for stable and beta releases,
- checks for all releases, including development releases, or
- doesn’t check automatically.
The number of days between automatic checks can also be changed (all in the “Miscellaneous” pane of the “Preferences”). The dialog can be manually invoked by using the “Check for New Version of DrJava” menu item in the “Help” menu.
It works by checking the LATEST_VERSION*.TXT files on drjava.org:
For that, of course, DrJava requires internet access, but DrJava fails gracefully if it cannot access the internet. I chose “check for stable and beta releases” as default. It would have been nice if all the users of the development release were automatically notified of the next beta release.
I’m pretty sure we have to make a new release soon, though, because the Mac application doesn’t work for me and at least one other person .
Corky and Dan figured out what the problem with the Mac application is: The DrJava file inside the application doesn’t have the execute permission set, because zip/unzip do not store permissions. We’ll revert to using gzip/gunzip, and then it should work again.