QVCS-Enterprise 2.0.2 beta now available

I just posted the bits for the 2.0.2 beta.

It's not yet feature complete, but it's got the big feature for the 2.0 series of releases: support for IDE integration.

The documentation has been updated some, though I still have some work to do there. The cool change with the way the docs are provided is that the docs are now embedded within the server .jar file. The downside of this change is that users can't easily edit the web site that the server provides. The advantage of this approach is the guarantee that the link to the associated client .zip file is accurate.

There are several things that remain to be completed for the IDE integration. For example: addition of support for command options for the various actions that you can perform within the IDE. Suppose you want to apply a label to a file when you check it in -- that functionality isn't yet completely there.

If using IDE integration, the biggest thing to be wary of (that comes to mind): the transport is not secure. This means that if you want any kind of security, you'll need to connect via a VPN, or similar mechanism. You also need to use the client application to define the external visual compare utility that will be used within the IDE for visual compares.

Aside from the additions to IDE functionality, the rest of the work going into the production release of 2.0 will focus on usability improvements. I've got a pretty long list of TO-DO's in this area (not all of them will get done before the release) -- if you've got a suggestion that you'd like to see implemented in 2.0, now's a good time to let me know.

Java puzzler

There is a bug in QVCS-Enterprise 1.2.11 (and earlier releases) that only just came to light. You can get a little background from this forum thread.

The bug only shows up if you run your QVCS-Enterprise server on a Linux platform. The puzzler was to figure out why things were behaving differently on Linux than on Windows. I set up my Linux box as a server for remote debugging and spent some time tracking down the problem. As it turns out, the problem was caused by slightly different behavior on Linux.

The offending (a.k.a buggy) line of code looks like:

int descriptionLength = 1 + description.length());

where description is just an instance of a String object.

The bug-free (a.k.a fixed) line of code looks like:

int descriptionLength = 1 + description.getBytes().length;

This implies that on Linux at least description.length() != description.getBytes().length.

This is a surprising result, at least to me. I had thought that the length of a String would be the same as the length of a String's byte[]. As the above code shows, and the Linux JVM confirms, this is not universally true. It's probably documented somewhere, and it probably has something to do with different internal String representations on the respective platforms. In any case, it's the kind of subtle bug that demonstrates the Java mantra of "write once, test everywhere".

This is okay. In my experience in using Java across platforms, almost always, deploying on a different platform helps expose bugs in your own code instead of exposing bugs in the JVM.

I'll be publishing a fix for this bug later this week. If you need the fix immediately, a patch is available.

Back from a Canada vacation

We just finished up a vacation to Canada. Our primary destinations were Montreal and Quebec city. We had a good time in both.

Montreal is a big city -- 1.5 million or so. They have a good subway system, and the old city where we stayed is very walkable. While I remember only a little of my high school French, it was little needed: it was easy enough to figure things out, and the folks at restaurants and hotels all spoke good English and were friendly and helpful.

In Montreal, we stayed in a loft apartment that was part of a hotel, in the old part of the city. We were within easy walking distance of the St. Lawrence river, City Hall, the Metro, and countless numbers of restaurants and shops. We left our car at the hotel the whole 4 days we were in town -- preferring to walk and/or use the Metro as the way to get around.

While in Montreal, we caught the first of a series of fireworks displays (Montreal hosts this annual international competition) -- the one we saw was put on by the Swiss. We had purchased good seats, figuring it would be unlikely that we'd ever be back to see the fireworks again. Most impressive. The show lasted a little over 30 minutes, and was finely choreographed to synchronize with each song that they played over the sound system. The weather was pleasantly cool, and the fireworks were worth seeing again.

In Quebec city, we also stayed in the old part of the city. Everything was within easy walking distance: There was a convenience store two doors up the street; the river was only blocks away, and the shopping tourist section was also just a short walk. On St. Louis street, (less than a block from our apartment), there were endless restaurants, many with outdoor seating. I'm not Catholic, so I don't know how many saints there are. It's a good thing there are lots, though, since most of the streets in old Quebec are named after some saint or other.

The old part of Quebec seems a little cleaner than the part of Montreal where we stayed. Both were generally cleaner than most American cities. The streets felt safe. In Quebec, there were lots of student tour groups trooping through the old part of the city... apparently on 'educational' field trips -- you know the kind they schedule at the end of the school year so that teachers can pretend to teach the restless students, and the restless students can pretend to learn.

I had feared that we might need more knowlege of French in Quebec city. The fear was unfounded. English is a second language, but widely spoken, and everyone was very friendly and helpful.

We'll have to make the trip again -- maybe in the Fall some year.

Open Source Java

Eric Sink had a recent article where he spills some bits on Java, and Sun's recent tentative steps to take Java Open Source. The article generated a number of comments, many along the lines of how slow Java is, and what a lousy language it is, etc.

By most measures, Java has been an incredible success. It was so successful that Microsoft tried (and failed) to gain greater control of it. There is no doubt that it could be even more successful, but that observation applies to almost everything.

I work with both Java and C++ on a daily basis. Both languages are good. If I had to choose between Java and C++ strictly for productivity, I would choose Java 90 percent of the time: Java is a simpler language, has built-in garbage collection, and has a much better built-in collection of libraries than C++. Java performance these days is quite good. There are a number of free Java development tools that rival Microsoft's Visual Studio (NetBeans and Eclipse come to mind) that are written in Java.

(Readers should not infer from this that Quma will be abandoning the C++ based QVCS and QVCS-Pro products!!).

What I don't get about Eric's post is his pose of omniscience. He admits that he doesn't use Java, and then goes on to condemn Sun's business decisions related to that product. Sun made a decision seven years ago that they would not Open Source Java. The world has changed in the past seven years, and they have now reconsidered that decision.

Would Java have been a greater success had it been Open Sourced seven years ago? Will Java now be more or less successful as a result of the move to Open Source?

I don't know the answer to either question... and neither does Eric.