A Concurrent Affair

I got myself into a bit of a problem when I tried to set the automatic end-of-line style property for our text files in Subversion. I wanted to use “native”, because that should automatically convert all line endings to LF (“\n”) on Unix and Mac, and to CR LF (“\r\n”) on Windows.

This seemed to work, but unfortunately the language level tests started breaking. It was pretty clear that this had to be a line ending issue. I couldn’t figure out why, though, and I went back and forth and changed the eol-style, ran dos2unix or unix2dos, and because the failures were only appearing after an update or checkout on another system, all of this went into the repository. All in all, it took me from revision 5144 to revision 5163 to get this right. This is shameful.

In retrospect, I should have done this in a branch, but svn was behaving very strangely, and I was worried that I might get it to work in the branch, but then something would go wrong when copying the files back into the trunk. I think there were two things that confused me:

1. On Windows (or perhaps on Cygwin), Subversion seems to be line-ending insensitive. I can take a file that had Unix line endings, run unix2dos on it, the file had changed, but Subversion would not list it as modified.
2. On Cygwin, Subversion’s “native” line ending is not the Windows default of CR LF, but LF, just like on Unix systems. That meant that the files with the “expected” outcome still contained LF line endings, but the files we were generating contained CR LF line endings. This is not well documented.

I was close to forcing LF line endings everywhere, but then decided to stick with “native”. If someone actually has a non-Cygwin Windows Subversion client, this may work, and I had to make the unit tests line ending-insensitive anyway.

There was another issue that gave me a hard time for an hour or so: The unit tests use some class files and make sure that they are newer than the source files. I had touched the source files when I changed the line endings, but the class files had not been recompiled. This caused the a couple of unit tests to fail with a nondescript error message. I had to trace the execution of the test to get to the following line to understand the problem:

if (sourceFile.lastModified() > classModTime) {

As a hack, I just Unix-touch the class files to give them a more recent time stamp. I tried to recompile the class files, but that wasn’t possible:

1. Some of the class files (B.class, Doh.class, TestWeirdStuff.class) don’t have any associated source (it’s missing).
2. Wow.dj0 contains the public keyword, which is not permitted in the elementary level.
3. The classes Tom.dj1 and Jerry.dj1 contain a cyclic inheritance graph, so they cannot be compiled, yet their class files exist.

I kept the class files. I didn’t want to re-engineer or understand the unit tests more than I had to. Considering that I had another sudden failure with the unit tests a few weeks ago, I don’t think they are well engineered.

As a side note: I love bash. I don’t know if it’s actually helping or hurting me (kind of like LaTeX), but writing something like this is cool every time:

find . -type f -not -path "\*.svn\*"|xargs -n 1 -I {} -i bash -c 'if [ "`svn propget svn:eol-style {}`" == "LF" ]; then echo {}; fi'| xargs -n 1 dos2unix

Or perhaps a Unix guru out there has a better way to run dos2unix on all files that have been marked with the “LF” end-of-line style property in Subversion?

I just fixed two bugs in DrJava that had to do with boxed floating-point comparisons of NaN and -0.0.

Both bugs had the same cause, a difference between the behavior of primitive == and the equals method in Double and Float.

According to IEEE 754, any NaN isn’t equal to anything, not even itself. Therefore, Double.NaN==Double.NaN should evaluate to false. On the other hand, positive and negative zero are the same (even though they have different encodings), so 0.0==-0.0 should evaluate to true. This is the case for the primitive types double and float, but not for the boxed types Double and Float.

This may be surprising, but the boxed types had additional contracts to fulfill regarding the behavior of equals and hashCode in hash tables. It was decided that it was more important to successfully look up floating-point values in hash tables, so new Double(Double.NaN).equals(new Double(Double.NaN)) returns true, and new Double(0.0).equals(new Double(-0.0)) returns false. Try it.

In Dynamic Java, the interpreter in DrJava, we internally used boxed types when comparing primitives, just because that way, we could write the equals method more easily. Now I created special cases for floating-point numbers that unboxes the values and eschews the equals method.

A few days ago, I noticed that double-clicking on a *.java file in Windows Explorer caused an AssertionError in DrJava. This wasn’t a huge issue, because it only shows with assertions enabled (i.e. -ea in the JVM Arguments for the Main JVM).

It’s still something I wanted to fix, because under some circumstances, opening a file this way could violate the convention of accessing certain Swing data structures only in the event thread and cause problems down the road. So, after being done with our Mint paper and taking the weekend off, I made the simple change of moving code into an invokeLater.

But when testing it, I discovered that Finder integration on the Mac wasn’t working anymore. It turned out this was also an effect of having assertions enabled with the -ea argument: When a file is opened from the Finder, the ApplicationListener.handleOpenFile method is called, but when we have Main JVM arguments like -ea, we need to restart DrJava, and the second instance doesn’t get another call to handleOpenFile anymore, so we need to change the file from that method into a command line parameter.

Whether this works or not depends on when the call to handleOpenFile arrives: Does it arrive before or after the restart? This is a race condition.

Unfortunately, fixing this properly is difficult. It seems like it is guaranteed that handleOpenFile will be called eventually if the file was opened from the Finder, but we don’t know when. How long do we wait before we decide to not wait any longer and restart? It would have been nice to get a handleOpenFileComplete call after all events (there can be multiple) have been processed. That method should be called as well if no calls to handleOpenFile are generated. But that’s not how Mac OS X does it.

I restart now whenever DrJava gets ready, and then uses the DrJava remote control to open files that arrive too late. Of course, that only works if remote control is enabled and if the new instance of DrJava can is actually running a remote control server.

Some big ifs, but I think this is the best I can do now without a lot of re-engineering.