I spent this past weekend at the Gateway Java Symposium. This was my second time at the conference and overall I had a good time. After the show last year, I posted a review. This year I thought I�d do the same.

Since my review of the show last year, I�ve kept up with each of the presenters, reading their blogs regularly as well as a few of their books. Over the course of the year my opinion of some of these authors changed. Two of the speakers I looked forward to seeing again this year (James Davidson, and Ted Neward) didn�t speak at the conference this year.

Last year I spent the bulk of my review talking about the quality of the speakers (which was pretty high). This year I don�t have anything especially interesting to say about the speakers (they were all pretty good). Instead I would rather talk about the content a bit.

Last year there were a few topics that popped up in almost every discussion (dynamic languages were discussed a lot). Two major topics that seemed to pop up at every turn this year were AOP and the Spring framework. I had heard at least three presentations on AOP before the Symposium (we have two local JUGs here, so there is often overlap), so the buzz over AOP wasn�t new to me. I don�t expect to get to use AOP in a work environment for quite some time, so I�m trying not to get too excited about it.

Spring, however was completely new to me. It was presented as a lightweight replacement for J2EE. There wasn�t enough time to get a good handle on the Spring Framework�s implementation, but the concept is great. Although it wasn�t brought up at the show, the Spring Framework reminded me a bit of Microsoft�s solution with .Net (only the Spring is a bit more centralized still). As you need each new enterprise feature, you plug that feature in. There isn�t a single monolithic application server providing all services from a single place (you aren�t required to configure services you won�t ever use). Since I�m not working on a J2EE-scale project right now, I�m not in a huge rush to learn about alternatives (it would have been useful two years ago, however). I�ll probably just wait until June and read more about it from Bruce Tate�s new book.

There were some interesting sessions on testing web applications, using JSF (which IMHO, seems to barely leapfrog Struts, not even coming close to WebForms), CVS, Swing, SWT (the session was waaay too basic), coding practices (decoupling, TDD, etc), and at least 5 sessions just about persistence.

My biggest complaint about the session topics (and I may very well be alone here), is the lack of �fun� sessions. Last year my favorite sessions were on �Using Java on the Mac�, Objective-C, Ruby and Java vs. .Net. Quite a few of the speakers at the show took the time to stress diversity in learning, but for some reason the show�s topics were anything but diverse. I might be the odd man out here (I pay my own way to the show, and attend more for fun, than professional development), but I would have really liked a break from all the persistence sessions. A session on the Java Speech API, Batik, or JFreeChart between �Persistance with Hibernate� and �Hibernate vs. JDO� would have been nice. And although it would have been off topic, a session on Mozilla development or Mono would have been even better.

Overall I was happy with the Symposium. It was worth the price of admission (and worth my time). I do think it was a small step down from last year, and I�m on the fence about attending next year, but overall I recommend the experience. If you haven�t been to the �No Fluff, Just Stuff� show, then you really should give it a try.

The speaker at a local Java User Group meeting, mentioned his dislike for strong type safety, giving the usual reasons: high overhead in type safe languages, quick turn around with loosely typed languages, and the relatively small amount of errors caught by compile time checking. In a seemingly unrelated discussion, he mentioned his preference of code editors: Emacs. It occurred to me that I�ve never met someone who likes strongly typed languages AND uses a modern IDE. I believe the two preferences are closely related.

Those who use a text editor to write their code, have to compile their code AFTER they write it; only getting the benefit of compile time checking in small iterative batches. Even those who use inferior IDEs have to save their work and wait for the source to be parsed to see any compile time errors. Those using modern IDEs (such as IntelliJ IDEA) get to see their compile time errors as they type (it even offers to fix them for you with a keystroke).

Even with that aside, I believe compile time checking is only a minor benefit of strong typing. The greatest benefit is the added level of self-documentation provided by type checking. An object has only so many methods, and depending on its reference only a portion of those may be visible. With a good IDE, you have complete access to all the possible method calls for an object. You can quickly scan the list for method names that make sense, and even consult the method�s documentation without leaving your code. With only basic knowledge of an API, a programmer can immediately become productive.

I don�t believe anyone who uses Emacs could fully appreciate how much more productive these hints can make the average programmer. If you use VI to edit Java code, then you have to use an html browser to read the documentation, and type everything on your own. Since type safe languages have more ritual, the VI user gets all the downside of the type safe language and none of the advantage. Of course, from that point of view, switching to a loosely typed language is going to feel MUCH more productive.

I don�t have anything against loosely typed languages, or using VI as an editor. I happen to be learning Ruby and am enjoying it a lot (although I miss my IDE). I just don�t like hearing otherwise respectable people preaching about the huge productivity gap between strongly and loosely typed languages. I think it�s all in the tool.

UPDATE:

This last post was a bit sloppy, and a few people called me on it. I�d like to clarify some of it and take a couple things back.

First of all, I used the phrases �strongly typed� and �staticly typed� interchangeably. This isn�t correct. You can read more about this here.

I would also like to clarify my point a bit. I don�t believe that any type of inline code generation (live templates in Idea) are a good substitute for simply ridding the language of the need for such code. Less is more. When I talk about programmers being more proficient with a strongly typed language, I was referring to �average� programmers. The learning curve with such languages is not as steep because the languages are somewhat self-documenting. Sure, once a programmer is proficient in all the APIs they use on a daily basis, productivity can be measured in keystrokes. But beginner and intermediate programmers spend much more time looking up API information than typing. And in my experience, intermediate programmers outnumber expert programmers by a very large margine.

Either way, after reading this entry in Martin Fowler�s blog, I�ve come to realize this is just a difference in point of view. I�ve spent the last few years of my life working with complete newbies to Java/OOP. Those experiences have pushed me whole-heartedly into what Martin Folwer refers to as the Directing Attitude of software design. I can understand where these features would be very helpful to someone who can handle them, but I�m just not optimistic that enough of these programmers exist. I just know too many people who rely on a strict interface to push them in the right direction.