It's been quite sometime since I made it to a SeaJUG meeting. Jayson Raymond, our host, mentioned that SeaJUG's 10 year anniversary is coming up, but I haven't been gone quite that long. It's just that SeaJUG is (apparently -- I'm not up on JUG lifetimes) one of the older JUGs. In fact it's been so long that I didn't even know that we were meeting in a new location. Normally I ride over with a friend who lives in Seattle, but he wasn't available, so a bunch of us from Bainbridge piled into a car and drove over.

Last night's meeting was a presentation by Ramnivas Laddad on "What's new in AOP". This was our yearly preview presentation ahead of the excellent Pacific Northwest Software Symposium. Several years ago I did a SeaJUG presentation on AspectJ, and I was curious to see how much things have changed.

There are now more syntaxes for expressing pointcuts and advice. You can have your choice of AspectJ syntax (nice because the AspectJ compiler can verify your pointcut expressions), Jave 1.5 annotations (nice because you aren't learning a special syntax, except that you are because you have to learn the mini-language for specifiying pointcuts), and even an XML based syntax (handy for instantiating abstract aspects at deployment time).

Also, you can now write pointcuts that rely on JDK 1.5 metadata. This is controversial. You get more control if you limit your pointcuts to annotations, but then you have to add annotations, which goes against the AOP idea of not having to modify the crosscut code.

The tooling has improved a lot. There's now very decent support in Eclipse (and some other IDE's), and that support does cool stuff like show you all the advised methods and so forth. There's also a history view that lets you view how aspects have been added or removed to parts of the system over time -- a nice usability improvement would be the ability to do this between revisions in the version control system.

When I gave my presentation, we had a long discussion about applications of AOP. I wish that there had been more discussion about this topic. It's easy to see the application of AOP to systems types of concerns, logging, performance testing, security, transactions, and so forth. It would be nice to see some patterns of aspect use as it relates to problem domains. Of course, the whole field is still pretty new, so it's understandable that there isn't a lot of data about this just yet. One interesting usage the was discussed was to advise constructors or factory methods as a way of injecting mock objects for use during unit testing.

I'm not doing a lot of Java these days, but I like to keep my nose in what's going on. As I was listening, I was thinking about having some of these capabilities in Python. Of course, you can do a lot of AOP style things fairly easily in Python, because various kinds of interception are easy to do. The things that I think are really missing are the pointcut expression language for expressing where interception is to take place, and whatever runtime support is needed to do the weaving. It sure would be handy...

It seems that the Netbeans and Eclipse partisans are trading one ups over the inclusion of hippie-expansion in their text editors. I like hippie expansion -- I've been using it since my days as a grad student in the early 90's. However, I'm puzzled by the fuss over it. According to my copy of the Emacs Lisp sources, hippie-expansion has been around since at least 1992. Is it really such a great achievement to be incorporating this feature 8 or 13 years after it appears in Emacs? I'm being a little extreme here, but it seems crazy to be touting the appearance of hippie-expansion as some indicator of IDE prowess.

I'm switching the feed that java.blogs picks up, so that only Java related posts will appear.

First it was IKVM, which can JIT compile JVM bytecodes to CLR bytecodes. Now commenter Paul Boddie has written javaclass, which aims to do a similar thing with the Python bytecodes as a target:

The javaclass collection of packages and utilities (also known as ClassFile) provides a means of importing Java classes and packages directly into Python, without the need for a Java virtual machine, so that the classes may be instantiated, accessed, run and manipulated just like Python classes, and that the resulting objects and methods can be accessed and manipulated just like Python objects and methods. It should be possible to run compiled Java programs with the Python interpreter and not notice that it isn't the Java virtual machine being used - given sufficient library support for the program concerned, of course.

Tonight I went to the December SeaJUG meeting It was fun because our reading group here on the island decided to go all together, although we did kind of get split up due to differing transportation arrangements. There was a pretty big crowd because Doris Chen from Sun was coming to talk about Java 5.

Every meeting before the speaker goes on, Jayson Raymond, our fearless leader, does a matchmaking poll. He asks how many people are looking for work, followed by how many people are looking to hire. For the past few years, this has been a depressing exercise. I remember some months where it seemed like half the group was out of work. I remember other months where we didn't even ask the question because we didn't want to know the answer. Tonight was a very pleasant surprise. Not a single person in a very full room was looking for work. What's more, there were a number of companies looking to hire. It's just one month, but its a nice change.

The talk got hung up in generics (which we had already had a fine presentation on in October) and on the enhanced foreach loop. We never even got to annotations, which is one of the features that I actually care about. As I listened to the generics discussion, my mind was thinking something like this:

Generics extends the amount of static type checking that you can do.

Static typing checking is good because you make fewer mistakes.

But wait, now you have to worry about wildcards and type bounds.

It seems that for average programmers this could be more work than writing the code itself.

So now you can make a mistake in writing the specification (type) that is supposed to keep you from making a mistake.

Doesn't sound like a bargain to me.

There was also a nice demo of the new JMX based monitoring console for the VM. All those displays just reinforced the notion that a VM is a platform. In fact, would that some operating systems had such a nice monitoring console.

If course, all of this Java 5 stuff is academic for me since there is still no Java 5 for OS X. I suppose I could install it on one of the Linux boxes....

Tim Bray has reported on a dynamic languages summit that was held at Sun recently. Aside from the timing (years too late), I think that this is a very positive development. There were key implementors of multiple languages (the notable exceptions being Lisp and Smalltalk folks), the list of stuff issues/features that was discussed seems to be the right list, and (most importantly) it looks like there is some acceptance of the fact that the JVM bytecode set could do more for dynamic languages.

My guess of a timeline looks something like this:
3-6 months to decide whether bytecode instructions are really necessary or not
Another year for a JSR to approve those instructions
Another year to do the work to the VM (including compatibility testing etc)
As much as 18 months (is the JDK on an 18month cycle now?) sync of with a JDK release, depending on the JDK schedule.

So, we're looking at 2 years (at least), or 2007, before anyone would be able to count on JDK support for their dynamic language implementation. Once that JDK ships, there's the typical adoption cycle, which means another few years before you'd be able to deploy a dynamic language solution on top of the JVM. That's a long time. Fortunately for Sun, there's not a lot of dynamic language support in CLR 2.0, and that doesn't even ship until 2006, or as late as 2007. So a MS designed and implemented dynamic language enhanced CLR could also be quite far off. 2010, maybe? It has a nice ring to it.

This means that anybody else has 2-5 years to get their act together and get going.

Tonight's SeaJUG meeting was the annual panel of JavaOne attendees. One interesting thing that happened during the discussions was the amount of concern raised over the new language features, particularly generics and attributes. There was some feeling that Java 5 was going to create two languages, pre Java 5 and Java 5. The fact that many of the new JSR's are already incorporating generics and attributes will only strengthen that separation. A few people felt that it would be even worse, that due to the timing of the releases, Java developers would actually have to deal with 3 dialects of Java. Takes a bit of wind out of the write once run anywhere sails. Thanks to an unknown SeaJUGer for the title of tonight's post

Another thing that I found interesting was that there was almost no mention of EJB 3, despite the fact that it's much simpler than EJB 2. Most of the time was spent talking about J2ME, JNDC and JDIC, Looking Glass, and generics. A few people lauded the benefits of JNDC -- apparently one of the panelists discovered that some of the JNDC components were Swing extensions that were written when members of the Swing team tried to actually write a Swing application. A few people spent portions of their reports talking about whether or not Sun was understanding the importance of developers, and on their perceptions of Sun's financial health.

Joe Bowbeer and I disagreed over the usefulness and openness of the JCP. Joe has had a good experience with the JCP, while I've mostly had indigestion over JSRs, and the long process of getting the JCP to be more open. It appears that some SeaJUG members have me pegged as Mr. Groovy, a title which should be reserved for James. I haven't actually been very involved with Groovy in the last few months. I haven't made up my mind over whether I'm going to participate in the JSR process, for a variety of reasons. One if them is that since the announcement of the JSR, I feel that there are more people pushing for Groovy to be more like Java, which (at least in my mind) defeats the purpose of having Groovy in the first place. Apparently, I'm not alone in my thinking -- this week eWeek published an interview with James Gosling in which he said

I think they could be a little more outlandish and get a little more interesting.

(thanks to Dion Almaer for the pointer to this - you'll have to read Dion to find the eWeek interview). I'm not really in the mood to fight with a whole bunch of people who have a different outlook on what Groovy ought to be, especially when it's starting to look like there are other people out there who have an outlook closer to mine (more on this another day).

As we got into the car to go over for our ritual after meeting beer and food, I turned to Wilhelm and said "this session made me glad that I'm not doing Java stuff at the moment". He responded that all the hue and cry over generics was reminiscent of the hue and cry when objects got introduced. We talked a bit more, and I said "if you're going to have static typing, then I want the computer to figure out what the types should be". I've done templates in C++ -- I used some of the template metaprogramming techniques that Barton and Nackman first showed. Of course, I'm not a fan of statically typed languages to begin with.

Java programmers are going to have a lot to swallow over the coming years. The good news for them is that C# isn't any better. C# already has annotations (attributes) and is about to add generics, so the two languages are remaining essentially equivalent. But as one person asked "what happened to making it easier"?

Today my copy of ACM SIGPLAN Notices arrived, except that it was 20 Years of the ACM SIGPLAN Conference on Programming Language Design and Implementation (1979 - 1999): A Selection. This is great volume and would be perfect for a graduate seminar in programming language implementation -- most of the selected papers are related to implementation rather than language design.

The New and Noteworthy stuff starts here. The best thing I see here is code folding, but there's probably something for everyone.

Dan Steinberg is having an epiphany. It's all about boilerplate code. Reams and reams of code that's repetitive, boring, and highly automatable. I'm glad to see that the ideas behind Groovy make more sense to him, but he also correctly points out that other languages can help as well. There's a point in the solution space of languages, which is full of little known languages, but not yet occupied by a popular solution. I can only hope that a new resident is on the way...

Tonight I did a presentation (slides here) at SeaJUG on Groovy. Things got off to a rough start, due to glitches with the Powerbook. This was the first presentation that I've done with it, and I was unfamiliar with the vagaries of Mac PowerPoint and managing a projector. It all started when I tried to hook up to the projector and was told that the example code was too small in the back of the room. I used 16 point unbolded Courier New, which I've used for presentations before (albeit in bigger rooms and screens). So there was a period of futzing with the display management to get Powerpoint on the projector and then getting the projector resolution to 800x600. Next followed the usual SeaJUG introduction and rituals. After I was introduced I discovered that I couldn't unlock the screensaver -- no matter how much of my password I typed, the dialog only showed three characters. Perfect timing. I just pressed and held the power button. After the machine rebooted, I was able to log in and get going. (Perhaps I need to get a copy of Keynote...)

There were lots of questions, some technical and some philosophical. I tried to just explain the features in Groovy to people as well as potential benefits. There was a group of people that really liked what they saw, and there was a group of people who really didn't like what they saw. I expected this, because to fully buy into Groovy, you have to buy into some assumptions about how software should be developed, which is philosophical bordering on religious. Not to mention that it's a whole talk by itself to do it right.

In addition to the philosophical questions, there were a lot of reasonable and sharp technical questions about various aspects of the language. I wish I had had a tape recorder so that I could have gotten all of them, as feed back for the Groovy development team. On the whole, I felt pretty good about it. I was a little less prepared than I wanted to be, but people didn't seem to mind.

One bonus for the night was getting to meet Kellan Elliott-McCrea. Kellan needed a ride to the meeting so he (and I) hitched a ride with Wilhelm.

Ok, so the news on the Groovy JSR is out, just in time for my SeaJUG talk tonight. Between Tim Bray's comment's yesterday, the Ask Joel thread on Python, Russell's wistful thinking on Java without semi-colons (semi-colons optional in Groovy), and this quote from Guy Steele, I'm looking forward to a lively discussion tonight.

Glenn writes about the Java interlude in programming language development. As he said, it's nice to discover other people of a similar opinion.

During the time that Java was getting started, I was very interested in Dylan, an OO dynamic language (dialect of Lisp, really) under development at Apple. In fact I almost took a job working at Harlequin, which was doing a Windows port of Dylan, but my interview with Peter Norvig convinced me that Dylan was likely to lose the mindshare battle with Java, so I ended up at Apple working on a port of Java to the Newton OS.

I would love to see the Dylan effort get off the ground again. The Gwydion hackers are keeping it on life support, but it really needs a shot in the arm. A while back Functional Objects (the name for the remnants of the Harlequin team) was talking about open sourcing their Linux port, which would have been excellent. The company's web page has been silent for a while and there haven't been many posts in comp.lang.dylan, either. I guess they'd rather have their technology go silently into the night rather than give it a chance to revive in the open source space.

In the meantime, James has been looking at the Dylan stuff, and the semantics of Groovy are headed for Dylanness, although there's a fair bit left to go, and the voices calling for Java compatibility may prevent it from getting there. There are three talks on improving Python performance at PyCon this year, so perhaps someday python might be in the running for high performance dynamic language. Or maybe there's a dark horse sitting in some arch repository somewhere (I can dream)...

This coming Tuesday, March 16th, I'll be giving a presentation about Groovy at the Seattle Java User's Group. So if you are interested in finding out about alternative languages on the JVM, I'd encourage you to come on out. James and the other Groovy developers have been hard at work, and I hope to be able to explain why I'm excited about Groovy. I will put my slides up after the presentation.

EclipseCon is running, so here are some reports from EclipseCon, as well as a new Eclipse Plugin site, Eclipse Plugin Central complete with RSS feed.

Also in Eclipse news, here is IBM's Proposed contribution to the Eclipse Web Tools Platform Project. This is the contents of a zip that was posted to the newsgroup -- making it a pain to reference. I hope that the whole system of passworded newsgroups will be done away with now that Eclipse is independent.

Today I was playing with the Eclipse on Mac OS X, and I wanted to move the workspace directory out of the Eclipse install directory. On the Windows version of Eclipse (and I assume the Linux version), you can specify the -data flag to the Eclipse launcher to do the job. Unfortunately, this doesn't work on the Mac. I posted a query to eclipse.tools.jdt and got instructions on what to do.

You'll have to edit the Info.plist file:

- do a Control-click (or right button mouse click) on the Eclipse application
- from the context menu select "Show Package Contents"
- in the new folder double click on "Contents"
- open the file "Info.plist" with your favorite text editor
- at the end of your file (after the "Eclipse" key) change the existing
  arguments or add a new argument (enclosed in a <string> </string> pair).

Be aware that there is already a "-data" argument.

If you want to have your workspace in your home directory, you can use a '~'
character as a shortcut for your home directory.

So with the following two arguments your workspace will be created in your
Document folder:
    <string>-data</string><string>~/Documents/workspace</string>

I've been hoping that the Eclipse folks would steal a feature from IBM's Websphere Studio Application Developer, which allows you to select a workspace directory from a dialog at startup. This plist editing on the Mac is a really good reason for doing the dialog. What if I wanted to switch among a few workspace directories?

I mentioned in the last post that my interests are taking me away from the details of XML, in particular, the nitty gritty, language lawyering aspects of XML. Part of this is that I'm tired of language lawyering over angle brackets. On the positive side, I'm very engaged with what's happening in Chandler (which is good since that's my day job).

In the Java space, one of the things that I'm most excited about is James Strachan's Groovy which has just gone beta. As I mentioned in my ApacheCon notes, I managed to convince James to give me the skinny on Groovy while we were both in Las Vegas. Since then, he's been hard at work, and recently, I've set my IRC client to autologin to #groovy -- so that I can at least log what's happening. I hope to be able to actually participate soon (I need to do the same for #joiito, which Mark Pilgrim and Joe Gregorio were advocating to me - one thing at a time). What James has done with Groovy was already impressive at ApacheCon, and my personal feeling is that if you want a Python or Ruby like language for Java, you want Groovy. Sam asked James if he could do a .NET/C# version of Groovy, which I think is an interesting idea. The only problem is that Groovy uses the Java libraries as its libraries, so a .NET Groovy would be incompatible. Oh, did I mention that there's an Eclipse plugin for Groovy too?

I hope that I'll be able to report more about Groovy in the weeks ahead -- I've downloaded my copy. Go get yours.

Dave Johnson saw these screenshots of Whidbey and despaired of having such an easy to use environment in a Java based toolset. I don't know if Dave has seen the IBM WSAD version of the HTML/JSP editor, but it can do a lot of what the Whidbey HTML editor can do. If you select rendered HTML and switch to source view, it highlights the tags responsible. It works backwards that way too. Of course, it costs $$$, but so will Whidbey.

In other Eclipse news, codesugar is a new plugin that generates equals(), clone(), toString(), and hashCode() methods.

Eclipse is having its own convention. When you look at how many of the presentations are by IBM'ers, you have to wonder how successful Eclipse has been at attracting outside developers to the Eclipse core. Eclipse is definitely open source from a licensing point of view, but from a community point of view, the core still seems pretty closed. It takes time to build a community, and getting involved with such a big project is hard, so maybe I shouldn't be too hard on Eclipse just yet...

Changes are here.

Lots of new refactorings, and improved integration with CVS. The ability to edit files outside the workspace.