Monday, March 17, 2008

Why I haven't changed my language!

There was a very interesting question posted on TheServerSide, "What would make you change languages?" and for me the answer is simple, Tool Support. I have used Groovy and it was kinda neat, but content assist didn't work very well. Possibly because of some bugs or maybe the language is just too dynamic to fully support this feature. I have used JavaScript and 3 of us spent a 1/2 hour tracking down a extra character (we tried to call a method Foo=(arg1, arg2)), bad place to put an equal sign.

Back in my undergraduate days, life was simple. All I needed was vi and a command line. I was happy and I figured if you needed a tool to do your job then you were never going to be a "real" software engineer. Seven years later (and the Eclipse influence) this has changed. What does looking up a method signature somewhere really do for me? What does spending my time tracking down a runtime error that really should have been caught at compile time accomplish?

Sure, a lot of new languages have shorter syntax for common operations, all intended to save me a few keystrokes. Let's count:

var person = new Person; (about 15 keystrokes)
Person person = new Person(); (about 10 keystrokes)

See, with proper tool support I would use content assist and type P(content-assist) p(content-assist) = (content-assist) P(content-assist);[enter].

And it is not just content assist. It is refactoring, search, navigation, debugging, analysis and collaboration. It seems that some languages are easier to write tools for than others. Java and Javascript are almost the same age; why isn't there top notch tooling for Javascript (something like the JDT)?

I'll continue to try out new languages, but without excellent tool support, I'm not changing languages anytime soon.

Anyways, to each their own!

Friday, March 14, 2008

An Updated Design

Today I decided to use the CSS from my website for my blog. The new design should integrate my blog and my website a little more tightly. The update wasn't too hard to complete, but the CSS isn't pretty. Blogger seems to use some custom server side scripts to handle style and some of them weren't compatible with my existing CSS page. As well, I could not find a way to upload images as part of my template, so I am linking back to my main site for those.

Anyways it's done, and hopefully over the next few days I will get a chance to clean-up some of the code and remove the unneeded tags.

Friday, March 07, 2008

Small GWT / OSGi Problem

I thought I would document a small problem I had today in case others ran into the same issue.

If anyone has been to my website you know it's not that exciting. A few links, a picture or two and links to my blog. What is exciting (for me at least), is how I built it. My website is actually an OSGi engine (Equinox) with a Jetty bundle to serve up the pages, a small EMF model in the back end (to hold some links), and GWT to tie it all together. To be clear, this is overkill!!! But I enjoyed setting it up and I learned a bunch!

Now the problem. Today I decided to see if I could modify things on my site (both client and server side) and update it using the OSGi update command. (With P2 on its way this seems like a cool thing to do). However, after I did the update *BOOM* GWT died.

It turns out that GWT does some server side security checks and they use the classloader attached to the current thread to do them. However, this doesn't play very well with OSGi. To fix this I added:

Thread.currentThread().setContextClassLoader( MyActivator.getDefault().getClass().getClassLoader() );

This way, the same class loader that loaded my activator will be used when GWT does its security checks.

I'm not sure if this is the best way to fix this, so if anyone else has suggestions I'll try them out and let you know how they work. Also, I found this bug after I sorted all this out :).