Planet SCM

Jeffrey Fredrick just announced that CruiseControl 2.7.2 is now available for download: http://tinyurl.com/2zm9mz.

There are lots of bug fixes, lots of changes to the Dashboard and some new plug-ins, but the bit that is of most interest to me was (from the release notes)

TeamFoundationServer source control
----------------------
* Fix compatibility with Microsoft Visual Studio Team Foundation Server 2008 (CC-735). Submitted by Martin Woodward.

This was to work around an issue that came up when using CruiseControl (java version) to talk to a TFS2008 server (TFS2005 worked fine and still does).  If you are attempting to use CruiseControl with TFS 2008 then you should go with CruiseControl 2.7.2.  For that matter - if you are using CruiseControl.NET with TFS then you should also take a look at the latest release of the integration to TFS - as that contains the same fix allowing you to happily talk to a 2008 version of Team Foundation Server (also using the TFS 2008 client API's).

Anyway, congratulations to the CruiseControl team on the 2.7.2 release!

The blogosphere today is buzzing with news of the other launch happening today, but there is one a bit closer to my own heart - Eclipse 3.3 (Europa) has been released.  I'm downloading it right now.

I've been running Eclipse 3.3 since Milestone 3 at the start of the year, and as the releases have been coming out it has been getting better and better.  Interestingly, the download site today has broken down Eclipse into separate versions geared towards downloading the parts that different audiences are interested in - bringing the straight "Eclipse IDE for Java Developers" down to 78MB.  The version I need "Eclipse for RCP/Plug-in Developers" is a more substantial 153MB.

My immediate needs in Eclipse 3.3 was support for the Windows Vista native UI widgets (including things like the Vista tree control).  The version of SWT that was shipping at the time of Vista launch had a weird bug which caused the JVM to crash randomly, but was fixed early in the 3.3 codebase.  SWT in the 3.3 release has also got a version which renders using WPF rather than Win32.  I'm still not really sure what the reasoning behind a WPF version, but it is funny to compile Teamprise Explorer against this version of WPF and then zoom in using the magnification tool in Vista and everything is all smooth as it is vector based.  Performance sucks with the WPF version - but still.  With Teamprise Explorer compiled against the 3.3 Win32 SWT libraries, performance is super with the application looking more native on Vista than ones written using .NET 3.0.

Other the next few weeks I'm also going to try looking into some of the additional Europa projects.  The whole organization of the Eclipse Open Source project is very interesting to watch.  Today sees the simultaneous launch of 21 separate open source projects - many of which have dependencies on other projects.  The complexity is very interesting and yet (from the outside at least) seems to work impressively well.  Eclipse has been very good at doing releases every year, with substantial improvements as well as incremental changes.

As I write, I am 89% done downloading.  I'll let you know how I get on.  If anyone is queuing for the other launch, be sure to let me know how that goes.

So, the day after I get made a Microsoft MVP I do two posts about Java - go figure.  Anyway, today I had one of those moments where you thought you understood something and then realize you didn't and probably a lot of your code that you've written over the past 10 years doesn't work as well as you thought...  All this with the humble String.compareTo method.

Take the following strings:-

• charlotte
• Chloé
• Raoul
• Real
• Réal
• Rico

In .NET, if you want to perform a standard case insensitive, dictionary based comparison between two strings then you can use the String.Compare method.  This does a culture based, case insensitive comparison.

In Java, if you were to do use the Comparable interface which makes use of the standard String.compareTo method to sort a list, you would end up with:-

• Chloé
• Raoul
• Real
• Rico
• Réal
• charlotte

That is because compareTo looks at the unicode value of the character and sorts on that - which for those of us that tend to live in the ASCII range tends to work ok (only that lowercase letters come after the uppercase ones) - however if you have a language that uses one of the many other characters it doesn't work so well.  If you had a language where M comes before A in the alphabet you are totally screwed.

This is were you should be using the java.text.Collator class in Java.  The Collator class does locale sensitive string comparisons - i.e. allowing you to do a dictionary base sort of a set of strings.

Dope.  One of those classes I should have been using for a while...  I thought I was just being dumb, but then a couple of other people I mentioned this to were not aware of the issue so I thought it worth a blog post.

One of the things that Java IDE's have always had over Visual Studio is the ability to target older versions of the VM from the latest and greatest versions of the tools.  For example, I develop in Eclipse 3.2 day to day, but I target Eclipse 3.0 on Java 1.4 for compilations and to debug against.  That way I get errors in Eclipse 3.2 if I try to use a method that isn't in the Eclipse 3.0 object model.  Very useful.  That said - I had a problem recently because my IDE was telling me that I couldn't use the "assert" keyword which was introduced in Java 1.4 (which we require for Teamprise).

The problem was in Windows, Preferences, Java, Compiler.  Source compatibility was set to Java 1.3 and .class file compatibility set to Java 1.2 - I corrected these preferences to make them allow Java 1.4 source and class files and now the assert keyword works just fine.

Teamprise currently requires a Java JRE with DES encryption available in the JVM for the magic of NTLM authentication to work correctly.  Unfortunately, the GCJ that ships by default with Ubuntu and other Debian based distributions does not have one.  The easiest way around this is to install a JRE from one of the other vendors (such as Sun, IBM or BEA) – all of which are free (as in beer).

Since Sun has recently modified it’s licensing agreement for Java it has recently become a lot easier to install a the Sun JRE onto your Debian based installation.  Today I happened to stumble upon the excellent documentation in the Ubuntu wiki detailing how to install the Sun JRE and make it your default:-

https://help.ubuntu.com/community/Java

The command I never knew existed until now was:-

sudo update-alternatives --config java

That saved me a lot of time hacking around manually (I never can get the parameters to create a symlink the correct way round first time…)

Thanks to Ben for passing this on. You can now do a straight forward “apt-get install sun-java5–jre” and have it install on Debian and Ubuntu.  Due to the old licensing restrictions you used to have to package up the installation yourself and was a real pain.  Our Teamprise client needs the Sun JRE because it contains the various encryption bits necessary for NTLM authentication to work – hopefully this will make life easier for our customers running Debian based distributions such as the growingly popular Ubuntu.  See Simon Phipp’s weblog for more details.  Gentoo will have it soon too and any other GNU/Linux or OpenSolaris distributions are welcome to join in the fun.

Correction:  As Shaw points out in the comments, we don’t *need* the Sun JRE, we just need the encryption bits.  The JRE from IBM and JRockit from BEA also contain the relevant bits.  It’s just that GCJ as installed by default on Debian does not have them.