Ted Leung on the air: Open Source, Java, Python, and ...
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.
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.
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"?
-dataflag 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.
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?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>