To Do for DrJava and the Thread Checker

Even though I’ve implemented the lock file scheme Peter suggested, because of limited feedback from tablet users and the inconvenience non-tablet users will experience, we’ve decided not to use it. The problem is that the dialog asking to enable “forcefully quit” would appear every time after DrJava has been killed, not only when it was related to the tablet problem, and I guess we don’t want to do that.

What I’m going to do instead is try to detect the Windows tablet PC operating system, and only if it has been detected and “forcefully quit” is disabled, show a similar dialog. These changes won’t go into the updated stable we are going to release soon. It’s not critical; I put the “forcefully quit” option in already, so we just need to highlight it in the release notes and on our website.

I’ve also noted that the thread checker is broken as of this morning. I made a bunch of small commits and must have broken something. I need to figure out what happened. (Update: It seems like I introduced the problem with changelist 596).

As to giving Swing model classes the ONLY\_AFTER\_REALIZED ability, one idea that I got during our group meeting today, besides somehow tagging models and views that belong together, is to check whether model code has been accessed by the event thread yet. I don’t know if this will work, but it’s possible that Swing doesn’t access the model until the view has been realized. In that case, the semantics of ONLY\_AFTER\_REALIZED for model classes would be that it’s ok for any thread to access it until the event thread accesses it; after that, it’s event thread-only. It’s a reasonable assumption, but I need to see if the Java API will let me do that.

Share

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 Concurrent Unit Testing, DrJava. Bookmark the permalink.

Leave a Reply