We’re working on three branches of DrJava and on the trunk right now. I don’t think we’ve seen this much parallel development in a while.
In the trunk, for the last three days I’ve been working on a strange bug that Dung found on the Mac:
The menu for the Project does not seem to work right: sometime it just disables itself and does allow the user to select anything, and the run project main class menu item does not seem to work.
One of the ways this was reproducible was:
1. Have project open (with a main class set).
2. Project Properties.
4. BUG: Project menu items now all disabled.
5. Can be reset by pressing Compile Project button.
This only seems to happen on Mac OS X 10.6, definitely not on my 10.4, and not on Windows or Linux. I finally discovered late this afternoon that a call to
JMenuBar.setEnabled seems to be the culprit. This post on the Apple mailing list describes the same symptoms and seems to suggest that the calls maybe appear outside the event thread, and that causes the problems. I have to wait until we can test this on Dung’s OS X 10.6.
On the way, I have fixed a number of smaller bugs that had to do with the project main class and project build directory. Before I realized that
JMenuBar.setEnabled seems to be the problem, I also started to rewrite the way we enable menu items, which can get relatively complex: “Clean Build Directory”, for example, may only be enabled if a project is open, a build directory is set, and JUnit isn’t running (which isn’t really an accurate description; it should be any task that ties up that directory for a while: compiling, JUnit, etc.).
I have set up a listener framework for these events. The code greatly simplifies our code, but it is also a fairly major change without external benefits, now that I have diagnosed the problem Dung was having. I don’t want to commit the changes to the trunk until after our next stable release; therefore, the code went into the drjava-guiAvailListener branch.
The folks from the Habanero research group have also begun integrating the Habanero Java compiler into DrJava. That’s in the drjava-hj branch, because we definitely don’t want this in the trunk before the next stable. I haven’t really kept up with how well this has been going. The last thing I heard was that they could compile, but they had problems running programs.
Because of these problems, and because it should really be easier to integrate research compilers into DrJava, I have begun to refactor the entire compiler interface. The idea is that I don’t want to have to modify the main DrJava code to add more search paths for JDKs and compilers anymore. It should really just work by using the custom bundle feature on a jar containing a JDK descriptor and compiler adapter.
I’m using the NextGen compiler as a test of how easy it is to integrate additional compilers. So far I can compile, but I haven’t tried the runtime side of it yet. All of this, again, should definitely not go into the trunk before we release the stable; therefore, this code is in the drjava-compilers branch.
All of this will require major merging, of course. I think the order will probably be drjava-guiAvailListener first, drjava-hj next, and drjava-compilers last, depending on how quickly the Habanero group can get their compiler integrated.
When can this begin? After we have released the next stable. I’m still waiting for a few changes to the language levels. But if they aren’t coming soon, I don’t think we can wait, considering how many DrJava users we have, but how few of them use language levels.