Fatal Exception | Neil McAllister » TAG: Languages

June 26, 2008 | Comments: (0)

Java is free at last. Now what?

TAGS: Languages

Java started down the road to openness more than a year ago. Today it's finally free.

According to Red Hat, its open source IcedTea Project has passed Sun's Java Technology Compatibility Kit, a rigorous suite of tests designed to verify that a Java implementation conforms to the full Java specification. That makes it official: IcedTea does everything that Java is supposed to do, and it's fully open source.

It's impossible to overstate the significance of this milestone. At last, a full-blooded Java implementation is available under a 100 percent Free Software license. At last, the open source community can put aside any lingering objections to developing in Java.

So is this it -- the beginnings of Java's golden age? I wonder.

In terms of raw popularity, it's hard to argue that Java has been anything but a runaway success. Doubtless it will continue to enjoy a loyal following among enterprise application developers for years to come. Despite its newly relaxed license terms, however, actually growing Java's installed base could prove more challenging.

I wouldn't be the first to argue that Sun missed the boat by not releasing Java under an open source license sooner. As Apache Project co-founder Brian Behlendorf said in 2006, "I think had they done it, they would have established Java further as the language of choice by so many more people."

The Linux community, in particular, has long viewed Java with ambivalence. Sun makes prepackaged binaries of the JDK available to Linux users at no charge, but that simply isn't good enough for Linux distributions that bundle only software that's available under a Free Software license, such as Debian and the Red Hat-sponsored Fedora project.

The lack of a proper Free Software version of Java has left Linux application developers with a dilemma. Should they go ahead and code in Java, taking advantage of its rich collection of cross-platform APIs, knowing that by doing so they will alienate that portion of the Linux community that objects to proprietary software licenses? Or should they choose another tool?

Take note: Developers have no shortage of free and open source tools to choose from. In an ironic twist, some have even preferred to work with Mono, the Novell-sponsored open source implementation of Microsoft's .Net platform, rather than fall into the so-called Java Trap.

Removing Java's license restrictions, then, tackles only half of the problem. The larger challenge is for Java to remain competitive in a developer tools market that's significantly different than the one that existed when the platform launched in 1995.

The problem, as I see it, is twofold. First, as the Java platform has matured, it has become incredibly complex. Today it's possible to do anything with Java, but no one developer can do everything -- there simply aren't enough hours in the day to learn it all. Second, and most important, even as Java has stretched outward to embrace more concepts and technologies -- adding APIs and language features as it goes -- newer, more lightweight tools have appeared that do most of what Java aims to do. And they often do it better.

In the 1990s, Sun told us "the network is the computer," and Java was to be the tool that enabled this new idea. Today, RIAs (rich Internet applications) are all the rage, but the buzz isn't about applets and JavaBeans; it's about JavaScript, Flash, and Ruby on Rails. Google is the leading Internet company, and the language of choice for its application platform isn't Java, but Python.

It's true that Java ME powers millions of mobile phones, but that has largely been a matter of expediency. As 3G networks and full-fledged browsers for handhelds become commonplace, there simply won't be any reason to run applications on the phones themselves. If mobile computing switches over to a pure thin-client model, there will be little use for Java.

Meanwhile, at this year's JavaOne conference, Sun demoed JavaFX, its new UI design component for the platform, along with its associated scripting language, JavaFX Script. Is that really what we were all hoping for? New APIs? Still more syntax to remember?

Don't get me wrong. I do believe Java is a valuable platform, and certainly a powerful one. But the decision to release the JDK under a free and open source license casts light on the bigger issue for the Java platform, which is the competitive crisis it now faces.

Imagine if Java were released today, brand-new, as is. That's almost how it is for the Free Software community. Java is now an option for Free Software development, for the very first time. Now ask yourself this: If Java really were released today, brand-new, would it be a tool you'd choose?

Posted by Neil McAllister on June 26, 2008 03:00 AM

May 15, 2008 | Comments: (0)

Parallel processing calls for a Fortress mentality

TAGS: Languages

When you're the inventor of one of the most successful and influential programming languages of the last decade, what do you do for an encore? Judging by demos at the recent JavaOne conference, if you're Sun Microsystems, you invent another programming language.

But Fortress is more than just another syntax to remember. Instead, Sun Labs is taking lessons learned from Java and applying them to the thornier problems of application development for HPC (high-performance computing). If it succeeds, Fortress could become the language of choice for the new computing era.

The problem with most existing languages is that they were designed for an earlier generation of machines. Processing resources were scarce. Desktop computers typically gave you only one CPU to worry about, and parallel supercomputers enjoyed the rarified air of academia, where coders were accustomed to jumping through mathematical hoops to get their applications running efficiently.

Flash forward to today, however, and the computing landscape looks considerably different. Low-cost, commodity processors, clustered together over high-speed networks, have made HPC accessible to nearly anyone. The lowliest desktop PC might be powered by a multicore CPU. There's a boundless world of processing power out there, waiting to be tapped. Unfortunately, the popular programming languages of today simply weren't designed for the parallel-processing model.

Take, for example, the humble for-next loop. It seems unambiguous enough. If I tell the computer to perform the same task a hundred times, the program loops through exactly 100 cycles and then proceeds to the next instruction.

In real life, however, a task that can be described as "doing the same thing 100 times" is often more nuanced than it seems. If my task is to fetch water from a well, for example, one person armed with one bucket could make the trip 100 times to complete the task. But if I had a hundred buckets, and a hundred strong backs to carry them, I could complete the mission in one one-hundredth of the time. Barring any other bottlenecks, there's nothing about a trip to fetch water from a well that depends on anyone else's trip to the well; you can complete all the trips at roughly the same time.

This, of course, is exactly the same kind of efficiency that you get from parallel computing. But writing algorithms that can take advantage of parallel processors isn't easy in today's languages. There's nothing about the grammar of a for-next statement that lets the system know that it's OK to parallelize that loop. Instead, you have to manage the calculus of making it parallelizable by hand. Lose track of what's happening in the system and you can quickly end up in a "Sorcerer's Apprentice" scenario.

In Fortress, on the other hand, language constructs such as for-next loops are parallelizable by default. The Fortress specification supports the concept of transactions within the language itself, which means that complex calculations can be computed as atomic units, independent of any other program threads that might be running.

To aid developers in conceptualizing complex parallel-processing applications, Fortress' syntax is based on mathematical notation. In Fortress, programmers don't need to translate abstract concepts such as physical units into representations designed for the machine. Wherever possible, the goal of the language is to do away with obsolete programming concepts and concentrate on making the coder's job easier. In addition, Fortress was designed to be a "growable" language, to which new features can be added easily.

Don't plan on writing your next major business application in Fortress just yet, however. So far the language exists mostly on paper. A reference interpreter that implements most of the core language features is available from the Fortress project community site, but this is still bleeding-edge stuff.

Still, as multiple cores replace megahertz as the new benchmark of CPU power, a new kind of software development needs to emerge to ensure that software can continue to take advantage of the latest hardware. If work on the project continues apace, Fortress could very easily become one of the most important developments in computer science since parallel processing itself. I'll be keeping my eye on this one.

Posted by Neil McAllister on May 15, 2008 03:00 AM