Now I’ll take a break, then I’ll proof-read it again. Then I’ll take a break, and then I’ll proof-read it again. And then I’ll take a break, and then I’ll proof-read it yet again… ;)
And after that, all I have left to do for this weekend is review some open source projects, integrate Mint into DrJava, and write a bit more on the Mint Blog.
But tomorrow I’ll hit the Houston Museum of Science. It’s Museum District Day!
DrJava hit 850,000 downloads today. We should be on track for the big one million by the time I graduate (knock on wood, both for DrJava and for graduating).
I’m writing a paper about ConcJUnit, this time with an educational focus, and as usual, writing helps me in systematically covering the problem space. I shouldn’t spend a whole lot of time blogging now, because the paper submission deadline is approaching fast, but I want to make a more-than-just-mental note anyway.
ConcJUnit can emit “lucky” warnings if all child threads terminated before a test ended, but this was not enforced with a join. Daemon threads are exempt from this requirement, because they should shut down by themselves in a real program.
Now, what happens if I refactor my program and change something like this
public void someOperation() {
// ...
fail();
}
public void testFoo() {
new Thread() {
public void run() { someOperation(); }
}.start();
}
which will correctly warn me that the new thread wasn’t joined, into something like this:
public void testFoo() {
EventQueue.invokeLater(new Runnable() {
public void run() { someOperation(); }
});
}
This code puts the task on the event queue, but because the event thread is a daemon thread, ConcJUnit does not warn that the operation may not have had time to fail yet.
Perhaps I can enqueue a “token” event at the end of a test and wait for it to be processed?
Soon it will be possible to compile and run Mint programs in
DrJava. I just haven’t had time to finish this. In the meantime, here is a program that you can analyze. It is another program that calculates the power x^n.
import edu.rice.cs.mint.runtime.Code;
public class Power_For {
public static void main(String[] args) {
final double x = 2;
int n = 17;
Code
for(int i=0; i<n; ++i) {
c = <| `c * x |>;
}
System.out.println(c.run());
}
}
This time it uses a for loop. I don’t know if you have seen for loops, but the part
for(int i=0; i<17; ++i) { /* something here */ }
sets a variable i to 0, and repeats the part /* something here \*/ as long as i<n. Each time the loop is done with /* something here */, it will execute ++i, which will increase i by 1. So eventually i will be 17, and since n is 17, i is not < n anymore, and the loop exits.
We have a Code<Double> c that starts out with the code for 1.0:
Code<Double> c = <| 1.0 |>;
Then we have the aforementioned for loop. The code that gets executed
over and over in the loop body is
c = <| `c * x |>;
We are creating a new code value, and inside the code value, we’re splicing in c (initially 1.0) and multiplying it with x. Then we assign the new code value back to c. That means after the first
iteration of the loop, c will be the following:
<| 1.0 * x |>
After the second iteration, c will be
<| 1.0 * x * x |>
And so on. After the 17th iteration, it will contain the code
<| 1.0 * x * x * x * x * x * x * x * x * x * x * x * x * x
* x * x * x * x |>
When we run c with c.run() and print out the value, we will get 131072.0, which is 2 to the power of 17, as expected.
You can download the complete source code for the example here:
Power_For.java: Multi-stage Power function using a for Loop(Re-posted from The Java Mint Blog)
Here are some quick instructions on how to download and install Java Mint.
Windows
C:\Program Files.
C:\Program Files\JavaMint directory. If you don’t see an “Extract All…” option in your context menu, you may need to download a program such as WinZip or WinRar first.
MINT_HOMEC:\Program Files\JavaMint
Path variable in the “System variables” box, select it and click “Edit”.
;%MINT_HOME%\langtools\binNow you can compile programs using mintc and run them using mint. Open a Command Prompt by clicking on the “Start” button, selecting “Run” and entering cmd and pressing “OK” (or search for the “Command Prompt” program in your Start Menu).
mintc Power.java
mint Power
There are samples in the C:\Program Files\JavaMint\langtools\mintTest directory.
(Re-posted from The Java Mint Blog)
Here are some quick instructions on how to download and install Java Mint.
MacOS
/usr/local/soylatte, i.e. the Java compiler should be /usr/local/soylatte/bin/javac.
/Users/mgricken/Desktop.
/usr/local directory:cd /usr/local
sudo unzip /Users/mgricken/Desktop/JavaMint-r13871-binaries.zip
MINT_HOME and PATH environment variables:export MINT_HOME=/usr/local/JavaMintexport PATH=$PATH:$MINT_HOME/langtools/bin.bash_profile or .bashrc file and put the two lines from step 6 line at the end of the file.Now you can compile programs using mintc and run them using mint.
mintc Power.java
mint Power
There are samples in the /usr/local/JavaMint/langtools/mintTest directory. You cannot compile them there, however, because the directory is read-only unless you are the root user. So unzip the Java Mint implementation zip file somewhere else, e.g. in your Documents directory.
The easiest way to experiment with Mint is to download DrJava with Mint. Here are more instructions on how to run DrJava with Mint.
Note: If you are using SoyLatte as your Java 6, please start DrJava with Mint from inside an X11 terminal window.
(Re-posted from The Java Mint Blog)
So I’ve been back from Calgary for nearly a week now, but I haven’t had time to write. The last week, and the conference, were pretty intense.
On Wednesday, August 26 I got up bright and early. I had already packed, so instead I could work on integrating ConcJUnit support into DrJava. I really did work until the last minute: Even at IAH Terminal A I was still making changes. I just figured the demo of ConcJUnit wasn’t very exciting from a visual perspective, so using it inside DrJava might make it a bit better. I think this was the right idea.
My flight had a short layover in Salt Lake City, Utah. The mountains seemed great from the air. Maybe some day I can spend some more time there. It did look rather dry there though; in fact, even the airport was lacking water fountains, and I couldn’t refill my water bottle for the flight to Calgary. I got to Calgary around 10 PM (11 PM CDT). I had just used carry-on luggage (although the airplanes were so small that I couldn’t in fact carry it with me), so getting my stuff didn’t take long.
The immigration examination was pretty thorough: The officer asked me what I was doing in Calgary (“I’ll speak at a conference.”), what conference it was (“PPPJ at the University of Calgary.”), and what kind of a conference it was (“It’s a computer science conference.”). She then asked what my status in the US was (“I’m an F1 international student.”) and “what I was taking”. I didn’t understand that question. I guess she was asking what classes I was taking. I finally responded with “I’m a computer scientist.” Customs, on the other hand, was very easy. I took a taxi to the hotel and then had some late-night McDonald’s. I hate getting fast food, but I didn’t want to search for restaurants that were still open at 11 PM.
On both Thursday and Friday I got up at 6:30, used the coffee maker in my room and got dressed, then headed down for the complimentary breakfast, which was pretty good. On Friday, though, it was swamped with Austrian tourists. I pretended not to understand them. Then, around 8:45, I headed to the conference venue. I got back around 9 PM on both days and then continued to work at home.
The conference was pretty small — it seemed like nearly everyone that was there was also presenting. The highlights for me were definitely Michael Ernst‘s tutorial on pluggable type-checking, Borys Bradel‘s presentation on trace-based parallelization of recursive Java programs, and the work by Danilo Ansaloni et al, particularly MAJOR.
Danilo’s MAJOR presentation was just before mine, and it was really an impressive demonstration of aspect-oriented programming for instrumenting programs. He shocked me by saying, as an aside, that in their aspect-oriented version of ReCrash they can also detect uncaught exceptions in all threads. They do this by applying an advice at a join point at the end of the Thread.run() method.
This seems a lot cooler than how I’m doing it, and I have to admit that I was stunned and that my presentation suffered. My approach, ConcJUnit, however, is simpler and uses standard Java, so it does have its merits.
The conference was enjoyable. I met some very smart, interesting and genuinely nice people. In addition to Borys, Danilo and Michael, I want to mention Ben Stephenson, the General Chair of the conference; Ondrej Lhotak, the keynote speaker; and Dave Hughes, chair of the CS department at Brock University and user of DrJava.
I did feel pretty tired afterward, though, and except for dinner downtown on Friday night, I didn’t have any time to go sightseeing. Consequently, the only pictures I took are from inside my nice hotel room and of a rather gigantic rabbit on the campus of the University of Calgary:
On Saturday morning, I got up at 4:30 and had coffee, then shared a taxi to the airport with David Hughes. The flight back via Minneapolis, Minn. was uneventful, and again I got a decent amount of work done. There was no free wireless network at either of the airports (at least none that I could get to work), so in Minneapolis I used tethering on my Palm Treo to submit my changes to Perforce and Subversion.
I thank my advisor and co-author Corky Cartwright for letting me attend this conference; the School of Engineering for partially supporting me; and the conference organizers and reviewers for their hard work.
Now I’m back, and I’ve spent the last few days improving the ConcJUnit integration in DrJava. As of yesterday, it is now possible to select a JUnit or ConcJUnit jar file and use it instead of the built-in JUnit. If ConcJUnit is used, the Java runtime library can also be processed at the touch of a button.
ConcJUnit: Unit Testing for Concurrent Programs
Where: The 7th International Conference on the Principles and Practice of Programming in Java (PPPJ 2009)
When: August 28, 2009
In test-driven development, tests are written for each program unit before the code is written, ensuring that the code has a comprehensive unit testing harness. Unfortunately, unit testing is much less effective for concurrent programs than for conventional sequential programs, partly because extant unit testing frameworks provide little help in addressing the challenges of testing concurrent code. In this paper, we present ConcJUnit, an extension of the popular unit testing framework JUnit that simplifies the task of writing tests for concurrent programs by handling uncaught exceptions and failed assertions in all threads, and by detecting child threads that were not forced to terminate before the main thread ends.
In our COMP 600 graduate seminar, I gave a practice talk for my upcoming presentation at PPPJ 2009.
I got some valuable feedback about the presentation and the slides, mainly that the blue background for the source code made it hard to read. Thanks for your help.
ConcJUnit: Unit Testing for Concurrent Programs
Where: Rice University Computer Science Department, COMP 600 Graduate Seminar
When: August 24, 2009
In test-driven development, tests are written for each program unit before the code is written, ensuring that the code has a comprehensive unit testing harness. Unfortunately, unit testing is much less effective for concurrent programs than for conventional sequential programs, partly because extant unit testing frameworks provide little help in addressing the challenges of testing concurrent code. In this paper, we present ConcJUnit, an extension of the popular unit testing framework JUnit that simplifies the task of writing tests for concurrent programs by handling uncaught exceptions and failed assertions in all threads, and by detecting child threads that were not forced to terminate before the main thread ends.
I found a video tutorial by Chris Thiel that uses DrJava to prepare students for the APCS curriculum.
I particularly liked that he used several of the features I introduced to DrJava, like the auto-import dialog in the Interactions Pane and the “Open Javadoc” feature.
We have made a new stable version available: drjava-stable-20090821-r5004. You can download it from SourceForge or from the DrJava homepage.
Available for download at http://drjava.org .
DrJava is a lightweight programming environment for Java designed to foster test-driven software development. It includes an intelligent program editor, an interactions pane for evaluating program text, a source level debugger, and a unit testing tool.
In addition to bug fixes, this stable release includes a number of new features introduced after the last stable release:
These features include default imports for the Interactions Pane, inner classes as main class for projects, Javadocs and auto-completion for JUnit, Javadocs and auto-completion for user-defined libraries (“Additional Javadoc URLs”).
An applet viewer is included, and classes that extend Applet can be run using the “Run Document as Applet” menu item (under “Tools”) or using the “applet MyClass” command in the Interactions Pane.
The debugger has been improved and now includes an automatic trace feature to step through the code at a user-determined interval, array element watches in the debugger, and the ability to debug language level files without seeing the Java code that they get translated to. The debugger also retains the imports that have been made before the last step was taken or a breakpoint was hit.
DrJava can now also associate source, project and add-on files with DrJava so that they can be opened by double-clicking on them in the Windows Explorer or MacOS Finder (.java, .drjava, and .djapp files).
The source browser was improved: Browse forward and backward like in a web browser!
Since there still is an incompatibility between Sun’s Swing GUI library and the the Compiz window manager on Linux, we now check for the presence of Compiz and display a warning.
Notable is the ability to close the System.in stream in the Interactions Pane and an automatic update feature that downloads new versions of DrJava automatically.
The most important bug fixes include changes to the language level converter, compatibility with network paths, a debugger deadlock, and color preferences.
Note: The default project file extension now is .drjava, not .xml anymore.
Note: Java 1.4 compatibility has been dropped with this release. To use DrJava, you will need Java 5 or newer.
New features since the last stable release:
Bug fixes since the last stable release:
I’m working on integrating ConcJUnit into DrJava (for after the upcoming stable release of DrJava and for my presentations at Rice and PPPJ), and I ran into an interesting issue.
I had a thread that I knew was outliving the test, so it should be flagged with a “no join” warning. However, inside DrJava it wasn’t. The reason was that the thread was a daemon thread, even though I hadn’t set it to be a daemon. I looked at the Java API source code and the Javadoc and found the following statement (emphasis mine):
When code running in some thread creates a new Thread object, the new
thread has its priority initially set equal to the priority of the
creating thread, and is a daemon thread if and only if the creating
thread is a daemon.
It seems like the thread in which the Interactions Pane runs is a daemon thread, and therefore by default all threads created in it are daemons. I am now wondering if we should change this and whether there are any reasons why we couldn’t. The notion of ignoring daemon threads otherwise seems sound for ConcJUnit, so I’d rather not lose it.
Update
I dealt with this internally in ConcJUnit for now, by setting the test thread to always be a non-daemon. It seems like RMI threads are always daemons. If we want to change the behavior and let threads created in the Interactions Pane be non-daemon threads by default (which is the behavior in stand-alone applications), then we probably have to create a helper thread, force it to be a non-daemon, run the interaction in it, and wait for it to complete.
It seems like we have some incompatibilities with the OpenJDK implementation of Java, both in DrJava as well as in ConcJUnit. I don’t have the exact details on the DrJava problem, but Corky mentioned that there were display problems.
For ConcJUnit, it seems like the instrumented rt.jar file that I create somehow is invalid and the JVM cannot be initialized:
Error occurred during initialization of VM java/lang/ClassNotFoundException: error in opening JAR file /home/mgricken/drjava/drjava-concjunit/rt.concjunit.jar
And another quick upgrade to WordPress 2.8.4 due to a vulnerability in the previous version.
I think I actually experienced attempts to exploit this problem: During the last two days, I received numerous unrequested password reset notifications for the administrator accounts on my blogs.
The PPPJ 2009 program has been posted. I don’t know why I even waited for this: It seems like my session is always the very last one on the very last day.
Come hear me talk about unit testing concurrent programs in Calgary on Friday, August 28, 2009 from 3:30 to 5 PM.
We made an updated implementation of Mint, our multi-stage extension of Java, available. The technical report Multi-stage Programming for Mainstream Languages (TR09-02) has also been updated.
I finally also added a section for Mint and multi-stage programming to my homepage.
Does Randall Munroe know me? Because this xkcd webcomic seems to be about me.
Well, not anymore, now that I have posted this.
I just managed to do a WordPress auto-upgrade for the first time in a while. When it didn’t work this time, I searched the WordPress support forums and found out that the .htaccess file had to be fixed for users of 1&1.
This blog is now running on WordPress 2.8.3. The Markdown plugin stopped working in a very strange way, so I updated to a different Markdown plugin. Then I had to change the “next/previous page” links, but now everything seems to work.
If you notice any errors on this blog, please let me know.
We have made a new beta version available: drjava-beta-20090803-r4975. You can download it from SourceForge or from the DrJava homepage.
Available for download at http://drjava.org .
DrJava is a lightweight programming environment for Java designed to foster test-driven software development. It includes an intelligent program editor, an interactions pane for evaluating program text, a source level debugger, and a unit testing tool.
In addition to bug fixes in anticipation of the next stable release, this second beta release includes a number of new features introduced after the last beta release:
These features include the ability to associate source, project and add-on files with DrJava so that they can be opened by double-clicking on them in the Windows Explorer or MacOS Finder (.java, .drjava, and .djapp files).
The source browser was improved: Browse forward and backward like in a web browser!
Since there still is an incompatibility between Sun’s Swing GUI library and the the Compiz window manager on Linux, we now check for the presence of Compiz and display a warning.
Note: The default project file extension now is .drjava, not .xml anymore.
Note: Java 1.4 compatibility has been dropped with this release. To use DrJava, you will need Java 5 or newer.
New features:
Bug fixes: