afongen

When I first mentioned that I had started diving into Darkstar and Wonderland and doing Java 3D programming, I wrote:

All that interesting work being done making Swing programming easier and more tolerable with JRuby? Yeah, Java 3D could use some of that.

Not long afterward, watching Joshua Marinacci demonstrate JavaFX at Sun’s Midwest Java Days, I got to thinking that JavaFX would be the natural way to make Java3D programming easier, much as it alleviates the pain of Swing. Something gave me a hunch that it just might be in the works. Sure enough, it has been:

As many of you are aware, Sun’s emphasis on client technologies has led to the creation of JavaFX — a platform for creating rich content applications for mobile, set-top, and desktop devices. The majority of our current effort is focused on building out the 3D support for JavaFX. … Specifically, we are working on a new 3D scene graph, as part of the JavaFX player, that will complement the 2D Scenario scene graph. Its initial focus will be 3D effects, casual games, and simple 3D viewing applications. We anticipate that future versions will include additional features that may meet the needs of many existing Java 3D applications.

Oh ho! This is good news. It gives me hope for the future of both Java 3D and JavaFX.

As soon as the Erlang book was released, I started to dig into Erlang and was enjoying stretching my brain, but I kept running into some of what Tim Bray has been going through. (That’s a really interesting thread, by the way. I’m looking forward to seeing what happens when he can run all that code on a Sun T2.) And all along I really wanted to be working more with Scala, especially the lift framework. They’re doing some really cool stuff, and I’d like to be contributing. But my time is limited, and what have I been doing with it?

Raising children, mostly.

But when I get a chance to do some coding, I’ve been diving into Darkstar and Wonderland. Darkstar is game server written in Java and recently open sourced by Sun. It’s essentially an app server for networked, multiplayer games, dealing with all the plumbing so you don’t have to. Wonderland is a multi-user 3D virtual environment that builds on top of Darkstar. Sun has used it to build MPK20, a virtual workplace that you’ll see in all the demos.

What have I learned playing around with this stuff?

• My math skills are rusty. Java 3D programming uses math that I haven’t touched in about 20 years. I could use a refresher.
• All that interesting work being done making Swing programming easier and more tolerable with JRuby? Yeah, Java 3D could use some of that. I might just have to do something about it unless someone beats me to it.
• I’m enjoying writing Java. I’ve missed that. My day-to-day work with Java is nothing but frustration. This is different. It actually makes sense to use Java for a high-performance, distributed game server. And it’s fun! 3D virtual worlds? How could it not be fun?

I’ll write more as I explore further.

Some years ago, right about the same time that I started to move into Java, it became clear that Macromedia was trying more aggressively to woo Java developers. ColdFusion was rewritten in Java, so it’s now an app running inside a servlet container / app server, allowing ColdFusion developers to tap into the rest of the Java platform. With the introduction of Flash remoting, they positioned Flash more clearly as a development platform for rich internet applications. They released Flex, making Flash RIA development a hell of a lot easier for programmers unfamiliar with or intimidated by a Flash toolset aimed squarely at visual designers. No more confusing timelines! Just sweet, sweet XML. ;-)

Pretty sure JRun is dead, though. No complaints here.

Since the acquisition of Macromedia, Adobe has been keeping up the pace, with new releases of ColdFusion and Flex. And now AIR, which I’ll get to in a bit.

I don’t know how successful the ColdFusion rewrite has been in getting Java developers to start using it. I’m not suggesting that my personal experience is any guide, but I know more CF developers who have been introduced to Java and to object-oriented programming in the last few years than I know Java developers who have discovered ColdFusion. I did give it honest consideration at work a few years back but was turned off by its being an expensive, closed-source platform. Remember, my background is largely in the open source world.

Because of that background and bias, I was more than a little bit pleased to see Adobe open source the Flex SDK. As I wrote at the time, Flex’s being open source meant that I would consider recommending it to my employer. This is still true.

My employer is in the process of rewriting their ERP from a Win32 client-server desktop app to a Java EE web application. A decidedly nontrivial undertaking, especially considering that the developers have little background or understanding of web apps. This lack of experience and skills makes it difficult to create a compelling HTML/CSS/JavaScript replacement for a desktop app. Browser environments are limiting. It is possible to bend HTML to your will, and well-implemented Ajax helps, but to make it, well, not suck requires skill. To make it really kick ass requires serious skill. If you’re lucky and well-funded, you can hire enough people with that skill to pull it off. If you’re a state agency… well, good luck.

I remain hopeful, though. I just set my standards absurdly high.

I should insert a disclaimer here. I am by no means speaking for my employer. I’m just exploring the type of situation when I think a Flash-based RIA would make sense.

It is no accident that Adobe has been pushing Flash for RIAs. Flash apps look cool. They can suck, too, sure. But with a toolset like Flex, creating something that at least looks and acts more than halfway decent is a hell of a lot easier than creating an equivalent UI with HTML/CSS/JavaScript.

I’m not trying to sell Flex as a panacea. I know enough not to believe that a technology will solve development woes. But I have played around with Flex enough that if I’m writing a network-aware back-office app, one that’s likely to do well as an RIA, I’m very likely to use Flex because it will be easier to create better UIs. (Insert warnings about forking the web here. Except that I’m talking about RIAs here, not crappy Ajax apps.

Enter AIR.

AIR is something new from Adobe — the second beta is being announced at this week’s Adobe MAX — for creating Flash-based desktop applications. As desktop apps, they have access to operating system resources that browser-based apps don’t. The AIR installer is damn easy to work with. But the magic behind the acronym (Adobe Integrated Runtime) is that you can build the app with either HTML / JavaScript or Flash / Flex. Your JavaScript code can use ActionScript APIs to access the desktop goodness or Flash components on the page, and vice versa.

Color me impressed.

So when I saw that Adobe was going on a cross-country bus tour this summer to evangelize AIR, I signed right up to learn more. Last week the on AIR bus tour came to Minneapolis. The venue was a great choice: the old Varsity theater in Dinkytown, which I honestly didn’t think was still used as often as it appears to be. Comfortable seating. Catering by the Loring. Toss in an open bar, and we were prepped for one of the finest vendor events I’ve attended.

Since I’ve been watching video from the tour all summer, there weren’t a whole lot of tutorial surprises awaiting me. But it was about what you’d expect: Mike Chambers walked through building an AIR app with Flex, Kevn Hoyt showing us an app built with HTML & JavaScript. Show a bit more whiz-bang techie goodness for the next couple hours, and we all leave happy, planning blog entries like this one.

Actually, I planned a better blog entry than this one, but I want more of a chance to play with both Flex and AIR before I write that.

I mentioned earlier that I don’t know any Java developers who have been drawn into the ColdFusion world. Likewise, I don’t know many Java developers who have been doing anything with Flex. It could just be that I don’t hang out with enough Java developers. It seems, though, that the scope is expanding, and Adobe’s setting their sights a bit wider than Java. Good news all around.

“Let’s set aside for the moment the possibility of using another language. Assuming that we must continue to use a Java web framework, what would you suggest instead of Struts or Spring MVC?”

Seam or RIFE.

I hesitate at Seam partly because it still feels heavy-handed — the simple examples do a disservice by requiring far too much configuration — and I’m not sold on JSF (JSF 2 will help), but I do like much of what I find there. Easier management of conversational scope, for instance. More transparent association between objects and HTML. Given Java 5 or 6, and accepting the whole JBoss thing, this seems a reasonable framework, even if it’s not one that I would really love. The new Seam book is on the way. I’ll let you know how it goes.
RIFE has always held some fascination for me, not in the least because they offer native Java continuations. (I highly recommend that interview with Geert Bevin about continuations, by the way: its the most accessible explanation I’ve seen yet.) They just get a lot right: less painful configuration, decent templating, good testing… I’d really like to dig more into it but am always drawn to other things first. Like Rails. And lift.

Coté pointed to Mylar a couple weeks ago and I gave it a shot. So far, so good.

Mylar is a sort of overlay on the Eclipse UI that lets you focus on and manage tasks. This is something I’ve struggled with for what seems like forever: how to manage my to-do list without breaking my workflow. Basecamp was never a good fit. Remember the Milk is a great little web app, but after a few months I found myself going there less and less, especially as I used Bugzilla more and more to drive my daily development work. Over the years I keep coming back to paper, but I kept feeling like bigger-picture to-do items got lost. For some reason I never became a GTD geek.

Mylar lets you manage personal tasks as well as those in a bug-tracking system. If I used it for nothing else, it would be the really nice face that it puts on Bugzilla, whose default web interface is pretty much crap. While working in Eclipse, all the bugs assigned to me are right there, accessible at a glance. I’m notified of any incoming bugs without having to switch context. This is what IDEs are for.

But the genius in Mylar is how it focuses the UI on the task at hand, hiding from view everything but the files you’re working on. If you’re editing a Java file, it shows only the relevant methods. Just not having to scroll up and down all the time looking for a particular file saves time. Or if it doesn’t save time, it saves frustration. Best of all, Mylar keeps track of what you are working on for a given task, so when you come back to a task, all the context is right there and you can focus in quickly. This context can even be committed back as an attachment to the bug-tracking system, to be shared with others. Cool! It can also support interaction with your version control system, but I haven’t played with that yet.
Mylar is not nearly so great for JSP as Java, but that could be because I’m using the MyEclipse JSP editor instead of the Web Tools Platform‘s. I’ll figure that out when it becomes painful enough.

Each feature in Mylar is small, but together they add up to a compelling overall experience. Since I’m already a to-do list kind of guy, it wasn’t that hard to make the transition to task-driven development, so I felt at home in Mylar right away. Try it!

Java SE 6 was released last week. How many of us are now running 2 major versions behind? :)

There are a few goodies in this release, including performance gains and better debugging and monitoring, but the one I’ve been waiting for is JSR 223, explicit support for “scripting” languages. I first got excited about this JSR when it seemed that the reference implementation would be PHP. At the time I did most of my work in PHP, and I was excited about bridging the languages. Instead Java 6 ships with Rhino, a JavaScript interpreter written in Java, but that’s just fine if not better. There’s a longer list at scripting.dev.java.net anyway, including PHP on the JVM.

Why does this matter? I believe that the future of Java is not so much Java-the-language as Java-the-platform. I have felt this from the day I first encountered Jython (four years ago already?). Encounters since then with JRuby, Rhino, and Scala have only made my convictions firmer. Recent actions from Sun (and the JCP) lead me to believe that more than a few people there there recognize that if the JVM is one of Java’s core strengths, then the Java platform has a future somewhat distinct from the language. Sun hired two lead JRuby developers (locals Charles Nutter and Thomas Enebo). With JSR 223 and now JSR 292 (“Supporting Dynamically Typed Languages on the Java Platform”), which I believe we can expect in Java 7, it will be taken a significant step further. As Danny Coward points out in a recent interview, JSR 292 introduces the first bytecode in the JVM that is not used by Java. To me, this is a fairly clear endorsement of non-Java languages as part of a broader Java platform.

Microsoft is doing the same thing, by the way. Sure, much was made of multiple languages running on the .NET Common Language Runtime when it was first announced, but I have the distinct impression that C# is very much the canonical language for .NET development. But a few things have happened in the past year that tell me this is changing: Microsoft hired Jim Hugunin, lead developer of IronPython, a Python implementation for .NET (Hugunin is also the creator of Jython), then released IronPython for ASP.NET They’ve also been working with Zend to make the PHP experience better on IIS, including writing FastCGI for IIS 7.

I’m kind of surprised that I haven’t written about this more here. I think I’ve avoided it because it seems so damn obvious. But it isn’t, not really. It may be obvious within the areas of the blogosphere where I spend time and in the local Ruby community. But in the real world of day-to-day Java development to which I subject myself, in which most are unaware even that Sun has open sourced Java (it’s a culture thing), much less that Java 6 has been released and what it includes, talk of languages other than Java is very strange and uncomfortable news. I still get polite nods and bemused or uncomprehending looks. Daily.

It also occurs to me that there are readers of this blog who do not live immersed in the world of Java and who have valid reasons for being unaware of recent events. :-)

A quick note. I put “scripting” in quotes above because labelling languages like Ruby and Python as “scripting languages” is unfair and indicative of the historically dismissive attitude that some programmers have held toward them. To sound au courant, you should know that the currently favored term is “dynamic” or “dynamically typed” to distinguish them from statically typed, early binding languages like Java. The wrinkle is that in JSR 223, those languages are used for scripting, playing second fiddle to Java. JSR 292 shifts this balance.

So there. Nothing earth-shattering, but now at least maybe you understand why I talk about JRuby a lot.

I’ve spent my life immersed in language. By the time I graduated from high school, I’d studied at least a dozen: French, Spanish, Italian, Esperanto, Russian, Mandarin, Irish Gaelic, German, Latin… French is the only one I learned very well, but still I developed a profound appreciation for how study of one language can enrich my understanding of others, including and especially my native tongue, English. In college, as a French major with a linguistics emphasis, I of course studied even more languages. Frequently I found myself better able to express or understand certain ideas in languages other than English.

My father was a programmer and often expressed his conviction that there is a connection between languages used for programming and those for human communication, asserting that they occupy the same area of the brain. I have no idea whether that’s true, but it sounds reasonable and I’d believe it. He, too, had occasion to learn new languages for his work, although the only ones I ever knew about were C, C++, Ada, and possibly COBOL. I think it no accident that the first programming language in which I felt truly at home was Perl, which is strongly influenced by linguistics and ideas about human language and expressiveness (see, for example, Allison Randal’s “On Topic“).

It should come as no surprise that now, as a working programmer, I believe the study of multiple programming languages to be not only extremely valuable, but essential. And maybe it’s close-minded of me, but it surprises and disappoints me when other programmers do not feel the same. I work on a team of Java programmers, and with one exception I am the only one who is even remotely interested in things outside the Java world. This is crippling. That sounds like an exaggeration, but I believe it to be true. A monoculture is limiting and dangerous. It doesn’t matter whether you’re working with .NET, Java, Ruby, or whatever. Working under the assumption that a single tool can be an effective one-size-fits-all tool is a serious mistake. It limits your thinking, it limits your creativity, it limits your ability to solve problems.

Here’s some advice I recently gave someone who was looking to hire a .NET web developer:

I’m not suggesting that you hire someone who isn’t strong in .NET. If you don’t currently have strong .NET skills, then obviously that’s a very important consideration. Neither am I suggesting that you look only at developers with experience in .NET and something else. I’m suggesting that a candidate who has experience with .NET and another platform may — may — turn out to be a stronger candidate because s/he can critically assess what .NET has to offer rather than blindly follow the One True Microsoft Way.

I work with Java programmers. That’s what they are: Java programmers who happen to be working on web apps. Except for maybe something like Scheme covered in an intro computer science course, they don’t have experience with anything but Java. And it hurts us. Because when they look at a problem, all they see is Java. When I suggest a way of doing things that isn’t a canonical approach in the Java world, I get strange, uncomprehending looks. And we end up with overarchitected, overcomplicated application designs that solve problems we don’t have — or that fail to solve the ones we do have.

Example. An complicated call stack for a form submission that retrieves search results. POST form, push criteria to the call stack, redirect to a GET to the results display page, pull criteria off the stack. Okay, the call stack isn’t complicated, but the code behind it was. The programmer who designed this spent a long time working this out and unsuccessfully trying to address problems like dealing with multiple windows. Solution? Submit the form with GET in the first place. Dead obvious to a web developer, not so much to a Java programmer who’s not used to the web. But maybe that’s not fair since it’s a domain problem.

Example. A former coworker insisted that the text output of a certain COBOL program could never be parsed and made into something more meaningful. Why? Because he was exclusively a Java programmer, and Java’s a pain in the ass for text manipulation. Well, I work with languages like Perl and Ruby, steeped in a history of text manipulation. I munge text for breakfast. I looked at the problem and figured it would take about half an hour with a few regular expressions. Java didn’t even have regular expressions in the core API until four years ago, so this way of approaching a problem still doesn’t occur to most Java programmers.

Example. I find myself cleaning up a lot of clunky JavaScript code, written by people who treat it as “Java Lite” and who don’t understand JavaScript’s object model, which is quite different from Java’s. Different, not worse — and certainly not the One True Java Way.

I’m not writing this to rag on Java programmers, it’s just that they happen to be the source of my daily frustrations.

All this said, it’s quite possible to have an excellent web developer who knows only Java, or .NET, or ColdFusion, or PHP, or whatever. Regardless of whether they’ve worked in a diversity of languages or have been steeped in a monoculture, I think it’s worth asking about the strengths and weaknesses are of their chosen platform, because it’s a strong indication of how carefully and how creatively they’re thinking about the problems before them.

This is part of why I worry about what to suggest instead of Java EE, or rather what we can introduce to Java EE to be more productive. Part of my growth as a developer has been learning that not everyone has an easy time learning another language. I have always had an easy time learning languages, whatever the sort. I love to learn a new language, to stretch my mind and see what it has to teach me. This is far from universal. But I have to keep reminding myself of that, especially when I have trouble understanding why so few people are interested in extending the Java platform with non-Java languages.

More on that another day.

A prediction: if a couple years from now I am still mired in a Java monoculture, I will strangle someone. Probably myself.

As I have explained before, and with some apology for the double negative to which I am about to subject you, I do not believe that Java can never be viable for web application development, or that it is a bad language. I simply assert that it is an exceedingly poor choice for the web applications that I work on. Because it’s past 1 a.m. and my son will be waking me up in less than five hours, and maybe because despite my curmudgeonly nature I am reasonably polite after all, I will spare my employer the (mild) embarrassment of an all-out rant. Suffice it to say that working among the Convinced as I do, I am very much in the minority in my belief that Java EE — really, a Java monoculture — is the number one culprit for the project I’m working on being so very, very late. It isn’t the only problem we have, but it’s a big one.

The question I’m left with is this: what do I propose as an alternative?

.NET is out. We’d need lots of new hardware and be locked with a single, closed-source vendor. Please do not bring up Mono.

Cold Fusion? Same single-vendor problem, and I remain unconvinced.

There are Python frameworks like Django and TurboGears. I like them. They’re just not compelling enough for me to suggest using them.

Tcl? Sorry, private joke.

To my mind, it comes down to PHP (using any of a number of frameworks) or Ruby on Rails.

We would stand to benefit more from both Ruby and Rails, but I am concerned about deployment scenarios. Large-scale Rails deployments are possible, but it’s still a new enough platform that people are still working out the kinks for how to do it well. To be honest, we’d just be talking about a medium-size deployment, but the same concerns apply. Could we do it? Yes. I have faith in our system administrators and our developers. I would just feel really guilty about going to them every 3-6 months with a new way of setting up the servers to deploy Rails apps. I admit that I haven’t been following that scene for a while, but it does seem every time I poke my head in that there’s something significantly different.

On the other hand, I’m satisfied that we know how to work well with PHP, at least from a sysadmin perspective. On the development side we would certainly move a lot faster than we do with Java. As PHP becomes more Java-like, you’d think that a transition from Java would be easy. That’s the whole point, right? PHP has a low barrier to entry. On the other hand, its similarities to Java (at least in the object model) may make the transition harder, as I’ve found that Java programmers are somehow blinded to or misunderstand significant platform differences — e.g. PHP’s share-nothing architecture. We would also struggle with maintaining a large PHP codebase, much as we struggle maintaining Java code in reasonable order.

But honestly? In my gut, I hesitate to propose PHP because of the language itself. It doesn’t feel that much better to write PHP code than Java code — sometimes it’s worse, especially some of PHP 5’s Java-inspired syntax. Mostly, though, I think it’s the lack of closures and blocks, language features that I’ve come to expect and rely on. Peter Williams brings up the same point about PHP.

I first learned blocks and closures about two years ago and now find programming without them mildly painful. I think that Mark Jason Dominus got it right when he said

in another thirty years people will laugh at anyone who tries to invent a language without closures, just as they’ll laugh now at anyone who tries to invent a language without recursion.

There are just so many common classes of problem that are simply and cleanly solved by closures that not having them seems like a crime.

I think I’m holding out for JRuby on Rails.

The Java Posse have posted a delightful three-part interview with Van Simmons of the ComputeCycles Project: one (#82), two (#84) and three (#86). This is an excellent introduction to Jini. I’ve been excited about Jini since it was first announced, but it kinda fell off the radar for a while and I haven’t pursued it. I might grumble about working with Java (okay I do more than grumble!), but to my mind Jini rescues it from the dustbin. I just haven’t had need for it at work, which is no excuse, and I spend as little of my free time as possible working with Java. That might change. The whole area of distributed computing  intrigues me deeply. That and concurrency; it’s about time I read Java Concurrency in Practice, which is just collecting dust on my shelf.

Also of note, a presentation about Jini by Daniel Steinberg, “Beyond the Choir.”

On a tip from Todd Ditchendorf, I’ve had JavaScript and Ruby interactive shells running in Dashboard widgets for some time now. It’s fan-frickin-tasic. If you do anything with Ruby you probably already spend a fair amount of time in irb, and I imagine that Python programmers also understand. But it’s a fair guess that few JavaScript programmers are firing up a JavaScript shell to, say, test a regular expression. Maybe that will change with Java 6 adoption, since it has a native, defined API for interaction with dynamic languages.

Having the shell just a keystroke away is a huge help, all through the magic of WidgetTerm.

In “Taming the Rhino: Making Mozilla’s Javascript Command Line a Little Less Brutish”, Charles Lowell suggests using JLine to bring Rhino’s shell up to snuff. I have to admit, not having history is a pain in the butt. So I’ve dropped the JLine jar into ~/Library/Java/Extensions so it’s in my classpath along with Rhino’s js.jar, changed my js alias to java jline.ConsoleRunner org.mozilla.javascript.tools.shell.Main, and life is a tiny bit sweeter. Thanks, Charles!