Edward Thomson

It's been a long time since I updated my blog, in part because I'm lazy, but mostly because we were busy putting the finishing touches on Teamprise Client Suite 3.0. We're very proud of our 3.0 release, it's got a lot of great new features, and we think you'll be very happy with it.

If you're in the greater Chicagoland area next week, I've been invited to the Chicago VSTS User Group to give a tour of the new version of Teamprise. If you're interested in how Team System can play nice with Java developers, I suggest you stop by and check it out:

The meeting begins at 5:30 PM at the Microsoft Chicago (Loop) Offices:
77 W Wacker Dr, Suite 2300

Please RSVP if you're going to attend.

Even if you can't make it next week, be sure to check out the Chicago VSTS User Group, or another user group near you. It's a great resource if you're a VSTS or Team Foundation Server user!

Gluing C and Java together isn't particularly difficult - JNI is a well-designed bridge to the world of native code. Simple tasks are straightforward, and more complex ones are still possible. Surprisingly, it's quite easy to debug as well.

When working on native code, I tend to make all my code work in C first - debug it, write some native test cases, and ensure that everything works. Then I write a little JNI glue to make it accessible from Java. This has worked surprisingly well, and given few surprises. But what happens when something goes wrong?

For example: I was writing some ugly Win32 code to do some various things that can only be done in C. Despite my aversion to programming in Windows, I whipped up some native code to access what I needed. I wrote some test cases to confirm that everything worked, and I was pretty happy with myself, until I realized that all the work I had done was on ANSI C strings (ie, null-terminated char arrays.)

Regardless, I tied it up to my Java with some JNI code just to watch it fail when I passed in Unicode strings.

I'm not particularly well-versed in the intricacies of Unicode, and even less so Win32 programming with its WCHARs and PSEC_WCHARs and nasty habit of #define'ing function names to those that end in W. So I wasn't real sure of exactly what I needed to change to make my native code Unicode friendly. It sure would be nice if I could debug this in VisualStudio.

Attaching to a running process in gdb is easy - and it's easy to provide debugging symbols for that process. VisualStudio is a little less straightforward, but just as easy.

First, make sure that your DLL is emitting debugging symbols. Ensure that you're passing these flags to the compiler and linker:

CFLAGS: -Od -DDEBUG -D_DEBUG -Zi
LFLAGS: -DEBUG

Build your native DLL and ensure that a .PDB file was created - this is the debugging information for your library. Run your java application.

Open VisualStudio and setup your symbols. Go to Tools -> Options, and open the Debugging -> Symbols pane. Add a new PDB location which points to the PDB file that was created from your build.

Now you can attach to your java process by going Tools -> Attach to Process.

Finally, you can load the source (ensure that this is the source you built from, in the same directory as your PDB file) and set breakpoints, etc.

My coworker, Martin Woodward has been very pleased with himself lately about his world's smallest TFS proxy. Never one to back down from a challenge, I present the smaller than the world's smallest TFS proxy. It's running on a Mac Mini, which Martin assures me is (just slightly) smaller than his proxy.

Inevitably, someone else like me with an overblown competitive streak will come along and build a still smaller TFS proxy. Being as I'm a jerk, I've decided to hit a point that nobody else will match: this is the first TFS proxy server to run on a Mac.

When I say "run on a Mac", I don't mean that I've got a VM running Windows and Microsoft's TFS proxy server. That's too easy -- we've got a pint-sized TFS proxy actually running in MacOS X, thanks to Teamprise's new Java SDK for Team Foundation Server.

Fortunately, writing against the Teamprise SDK is easy. I didn't keep strict track, but I think that writing this little proxy server took about 10 hours, which probably broke down like:

• 4 hours: figuring out the Jetty servlet framework (for hosting the proxy)
• 2 hours: figuring out the hsqldb database framework (for caching)
• 1 hour: lost to cigarette breaks
• 2 hours: various other slacking
• 1 hour: getting the files out of Team Foundation Server through our SDK

As you can see, our new SDK will let you very quickly one-up your coworkers. Isn't that really what software's all about?

If you're at TechEd, and want to see the (new) world's smallest TFS proxy, or the world's first TFS proxy on a Mac, swing by and say hi. Teamprise is at booth 1333.

Teamprise is pleased to be exhibiting at the JavaOne conference next week, Tuesday 5/8 - Thursday 5/10. If you're attending JavaOne and you're interested in Team Foundation Server, you should stop by our booth to see Teamprise in action.

But you don't need to be registered for JavaOne to visit us! I have a limited number of exhibit-only passes to JavaOne.

If you're in the Bay Area this week and you're interested integrating Team Foundation Server's version control and work item tracking into Eclipse, or you're interested in accessing Team System from cross-platform clients, come check us out at the Moscone Center.

Just send me an email and we can get the passes to you!

I've previously mentioned that SWT-based Java apps need some work to run on Intel Macs. This is still true if you're building against Eclipse 3.1.

Fortunately, it's dead simple - all you need to do is download the Universal Eclipse 3.1.2 (available as an attachment to Bug 98889) and copy some of its files into your app.

First, you need the JAR containing the architecture-specific SWT jnilib. Assuming Eclipse is unpacked into /Applications/Eclipse, and you're in your app's .app folder:

If you're building an RCP-based app, you should update the Eclipse launcher, too -- otherwise Rosetta will drag along and you'll have a several second delay when starting your app. Thanks to the simplicity of the launcher - which determines class loading based on the name it's called by - you can just copy the Univeral Eclipse launcher onto your app's launcher. Assuming you're in your .app folder, and your app is called MyRCPApp:

There it is -- zip this up and you've got a Universal app. (Or better yet, update your 3.1.2 delta pack so your build process does this automatically) and you've got a Universal build.

(Sorry if this seems elementary or obvious -- I was feeling bad about not having updated my blog recently, and I thought an easy entry would kickstart me into writing more!)