Pinderkent

There has been some discussion lately on several blogs about Java and its feasibility as a programming language for practical development these days. The articles I'm talking about are Bruce Eckel's "The Positive Legacy of C++ and Java", "Java as Legacy Language" by Kas Thomas, and "Is it time to retire Java?" by David Arno.

The general theme of all three articles is that the Java language has not kept up with the times. That's not to suggest that it's useless or will disappear any time soon, however. Anyone with experience in industry knows that there is an absolutely huge amount of Java code out there, critical to many business operations. But it is true that Java does not offer the productivity it once did. Relative to languages like C and C++, it did allow for more complex systems to be developed with less effort, and in a shorter period of time. But languages like Python and Ruby have been attacking it from beneath, and now prove to be a better option for many software development projects.

The general feeling after reading those articles is that although the Java programming language isn't as beneficial as it once was, it did provide us with the JVM, and this in turn proves to be a useful platform for languages and implementations like Scala, Clojure, JRuby and Jython.

I'm not so sure that this is the case. The JVM has never really been a spectacular platform. Performance problems have plagued it from the very beginning. Some of the problems are inherent to the Java language itself, namely in limiting what optimizations the compiler, runtime and programmers can perform. Although there have been improvements relating to JIT compilation, for instance, I think a lot of the performance problems of Java have only been mitigated somewhat by hardware consistently getting much faster during the late 1990s and most of this decade.

When the topic of Java performance comes up, some people like to toss around various microbenchmarks showing that some obscure task can be done relatively quickly using code running on a Java virtual machine. Unfortunately, these results don't translate well to the real world, where applications tend to be far more complex. Part of the reason why desktop Java apps never really took off, for instance, was because most of them felt sluggish relative to other applications written in languages like C and C++. Application startup time has also always been a problem with applications running on the JVM. Were it not for server-side applications typically being long-running and typically running on more powerful hardware, it's doubtful that Java would have made the inroads it managed to make there.

Bloat is another issue plaguing the Java platform. The earliest versions of the runtime had installers that were 2 to 5 MB in size. While that seems like almost nothing today, in the mid-1990s that was a hassle to download over a dail-up connection, especially if one was paying by the hour. Although not as much of a problem now due to the prevalence of broadband Internet connections, the Java 1.6.0_12 runtime installer for x64 Linux is still relatively large at over 18 MB.

Even today, with many computers having two or more gigabytes of RAM, we see Java applications using a disproportionate amount of memory. On Linux using Sun's 64-bit 1.6.0_12 runtime, we see the Scala 2.7.3.final REPL using 593 MB of virtual memory, with 153 MB resident, as reported by top. And this is just after starting up the REPL while it's still at its first prompt, without having entered any expressions that may have increased the memory usage. Some applications are even worse. Just after startup, before loading any projects, NetBeans 6.5.1 is already using 1029 MB of virtual memory, with 249 MB resident. We can't blame just the JVM for such problems, but we also can't overlook its involvement.

The Java class library was once one of the key selling points of Java and the Java platform. It provided a lot of common functionality in a manner that could be easily reused by developers, thus increasing their productivity dramatically. But over the past decade, we've seen a variety of libraries for other languages arise that provide the same functionality, but often with much nicer and effective abstractions or APIs. Microsoft's .NET class library is one of the most widely used. Faced with such competition, the Java platform just doesn't look as attractive as it once did.

The Java class library is also starting to really show its age. While many classes and methods have been officially deprecated, they do remain around cluttering up the library. Others, like the AWT, are impractical for use today, but still must remain around due to later technologies, like Swing in the case of AWT, being built directly upon them.

Furthermore, a great deal of the classes don't make good, if any, use of generics, enumerations and the various other language features introduced since Java 5. The benefits of having such language features in Java are negated when many of the core library classes we use don't support them. We're often stuck still using integer constants where enumerations would be much more appropriate, for instance. Unfortunately, there is great reluctance to change the library in ways that would impact compatibility with older Java applications. So it's unlikely we'll ever see these problems fixed up appropriately.

When it comes to running non-Java languages on the JVM, we end up with even more problems. A language like Scala offers features, functionality and concepts that we just don't find within the scope of the Java language. So although it can be used, actually using the Java standard class library from a language like Scala negates many of the benefits of using the newer language in the first place. While such interoperability and reuse is often touted as a benefit of using advanced languages that target the JVM, I fear it's actually a significant downside, as it doesn't promote the effective use of the new language features that really do boost programmer productivity or application quality. They're crippling themselves by trying to reuse existing code that doesn't fit their philosophy.

So while languages and implementations like Scala, Clojure, Jython and JRuby are bringing more impressive languages to the JVM, they can't really do anything about the poor performance or the excessive resource usage of the JVM, nor can they do much about the poor state of the Java class library. But I'm also not suggesting that we have a viable alternative. Even though they recently released Parrot 1.0.0, it's still not a platform suitable for widespread production deployments. The Mono project is making some good progress, although they're typically playing catch-up to Microsoft's implementation, and don't have complete freedom to dictate how their runtime should behave. LLVM is perhaps the most promising alternative, but as the name implies, it is very low-level, not offering functionality we've come to expect from virtual machines (like garbage collection).

If the Java platform is to continue to serve us into the future, I suspect a significant overhaul is necessary. Performance and memory usage improvements to the JVM would be of a huge benefit to many. Better support for acting as the target of non-Java languages would likely be beneficial, as well. And a complete cleanup and reworking of the Java class library is a must. Unfortunately, this would not be a small undertaking, and would require huge amounts of time and effort. So it seems unlikely at this time that we'll see such a rework occur. This is somewhat unfortunate, as now is probably the best time to do it, while languages like Scala and Clojure have really started to mature, but just before they become so widely used that momentum against change develops.

Recently, a new version of the freshmeat.net Web site was made public. For those who may not be aware, it is (or at least was) one of the best software directories out there. Its emphasis on open source software makes it particularly useful. But until this new version, it also presented a very clean interface that was practical to use. Unfortunately, I think we have lost much of this usability with this latest version of the site.

Let's start with one thing the previous design of the Freshmeat site did right. Notice that it uses the entire width of the browser window. This is very useful for those of us with larger monitors or those of us with higher screen resolutions. While we often want to restrict the width of a prose-based Web site to improve readability, as in the case of blog postings and news articles, I don't think it works so well in the case of Freshmeat's new design. Its width is currently 960px, which leaves literally inches of wasted space on even just a 22-inch widescreen monitor at a resolution of 1680x1050.

The image below compares the old design at the top, above the red line, to the new design at the bottom of the image, demonstrating how the old site made more effective use of screen space:

On the old design's main page, along the left side and throughout the center of the page, we get a listing of the most recent software releases. This very quickly tells us the name of the project with the new release, the new release version number or identifier, when the release notice was posted, a summary describing the software, a summary describing the changes, as well as other information like categories the software falls under, its license, and relevant URLs. We get access to a lot of information very quickly. This is something else the new design isn't as effective at doing.

As an example, we can look at the entry for the NorfelloCMMS OS 2.0.0 release, made on November 22, 2007. Under the old design, it looked like:

With the new design it now looks like:

One thing to notice is the different date format. The previous design mentioned the release year, which is absent from the new design. As is shown by this example, it's important to show the year, as we may be looking through the archives at releases several years old.

Another difference is that of the length of the description. This is perhaps the worst aspect of the new design. Notice that with the new design, it's truncated after a couple of lines, with it necessary to click the "more.." link to see the full description. On the other hand, the old design provided the full description. While something can be said for writing short, concise descriptions, sometimes it isn't possible to do that effectively in the mere 200 characters that the new design seems to allocate to project descriptions. A truncated description like that is more awkward to work with than a description that is slightly too long.

Although not visible in the NorfelloCMMS OS 2.0.0 release example, it looks like the change descriptions are truncated as well under the new design. The old design displayed the full changelog, without truncating it and forcing the user to click on a link to see the rest of the changes.

Where available, a screenshot is shown for each release. Unfortunately, on the main page, the screenshot thumbnail is nearly useless. They're just too small to be of any practical value at 90px by 70px. Unfortunately, clicking on the thumbnail brings you to the project page, which has only a slightly larger, but nearly as useless, 133px by 100px image. It takes yet another click on that thumbnail to finally display a larger, somewhat comprehensible, version of the screenshot.

One other useful feature of the old release entries was the hierarchical categories. For example, the NorfelloCMMS OS 2.0.0 entry was listed under "Information Management :: Issue Tracking", "Office/Business" and "Office/Business :: Scheduling" with the old design. With the new design, it's under the single-level "Office/Business", "Information Management" and "Scheduling" tags. I personally found the old hierarchy more organized than the new scheme.

The greater usage of images, in the form of per-release screenshots and gravatars, has also increased the size of a request for the various pages. Although it's not a perfect example because it's an archived version of the page, the November 22, 2007 release listing comes in at a mere 48 KB, according to Firebug. The new listing for that date comes in at 426 KB. Although not a huge deal in these days of widespread broadband Internet access, that does translate to the difference between a site that feels snappy, and a site that feels slow.

The above highlights just a few of the problems I've noticed with the new site. I've tried to give it several days of use, to see if it'll grow on me, but so far it hasn't. Some of the more serious issues, such as the truncation of the descriptions and changelogs, would be relatively easy to fix. Others, such as the new tagging scheme, may be more difficult. And although I probably won't stop using Freshmeat altogether, as it is a valuable resource, its usability has taken a hit for me.

Today at Reddit there was a posting about a simple 2D bouncing ball physics simulation written in JavaScript. This is the latest example of a simple JavaScript demo that, for some inexplicable reason, gets many people excited.

Thankfully, there are some other people who see these JavaScript demos for what they truly are: something to not get excited over! One of the best replies to that Reddit posting points out how it ought to be easier to make such demos in JavaScript than in other programming languages. And that poster also correctly points out that there's no need to get excited over such trivial applications.

Another reply pointed out the demo's extreme similarity to Pong, a game from the early 1970s. It's also somewhat similar to Breakout, a game from the mid-1970s. Indeed, many of these JavaScript demos are often no more original than what we had over 30 years ago. Mind you, the equivalents from 25 or 30 years ago ran on computers with a small fraction of the processing power and memory of a typical desktop PC today. The developers back then actually had significant hardware constraints, unlike those behind the JavaScript demos of today.

Several others noted just how poorly this demo performs, even on modern systems when using modern Web browsers. One such user reported that it could animate at most five balls on his laptop with an Intel Atom processor before it became unusable. Although Atom processors aren't the most powerful by any means, they should be more than sufficient for the computation necessary to perform basic 2D collision detection and animation.

One user reported that it lagged in Firefox 3 on Mac OS X. Another reported performance problems while using Firefox on Linux.

As usual, we can't have a discussion about JavaScript demos or games without mentioning the unreasonable memory requirements of these demos. I think that poster's claim of 200 MB of RAM usage is, unfortunately, quite realistic. Using Firefox 3.0.5 on Linux, just starting up Firefox resulted in a process that was using 456 MB of virtual memory (as reported by top), with a resident size of 75 MB. Drawing a slightly downward sloping horizontal line, which allowed for approximately three balls to be on the screen simultaneously at the default drop rate, bumped the virtual memory usage up to 523 MB, with 176 MB resident. And extending that line somewhat longer, to allow about eight simultaneous bouncing balls at the default drop rate, bumped the memory usage up to a whopping 587 MB virtual, with 204 MB resident. After leaving the demo running for several minutes, it had stabilized at that point.

I don't think I'll ever understand how somebody could possibly become excited, even in the slightest, over these sorts of JavaScript demos. What they demonstrate was usually demonstrated better, using a fraction of the resources and processing power, two or three decades ago! The performance is typically terrible, even on higher-end PCs a month or two old, using modern Web browsers. It's not surprising to see 100% CPU usage, as well as hundreds of megabytes of memory being used. So in the end, all they do is exhibit essentially no innovation, poor performance, poor resource usage and prove yet again how awful JavaScript is for such simple applications. In short, there's absolutely nothing to be "amazed" or "excited" about with these JavaScript demos.

There have been reports recently suggesting that IBM may soon acquire Sun Microsystems. For those of us in IT, acquisitions of these types are always a big deal. While Sun's server hardware is widely deployed and of great importance to many, my interest is mainly in software, so that's the area I'll focus on in this article.

In the software world, Sun is most well known for Java and Solaris. I suspect that we'll see two very different outcomes for these technologies if an acquisition does occur. It's difficult to say what will happen for some of the smaller or more obscure software products and projects that Sun was involved with, such as OpenOffice.org and NetBeans.

In terms of Java, I don't think we'd see much, if any, negative change. IBM has embraced Java, and understands its use, at least for business users. For some time now they've provided their own JDKs for a number of platforms. Java also plays a significant role in their prominent WebSphere Application Server. They're actively involved with developing new Java-based technologies. And their involvement and contributions to Eclipse have had a huge impact within the development community.

In some respects, such an acquisition may be quite good for Java. Although known for generally being more conservative, IBM does have the resources needed to make the changes to the Java language and platform that are necessary for it to compete better with Microsoft's .NET platform. We need to see half-baked technologies like JavaFX and JavaFX Script discarded. But we also need to see functional or object-functional languages like Clojure and Scala perhaps brought in as core components of the platform.

If IBM put their weight behind such technologies, we very well may see more developers be willing to adopt them. As we move into a world with massively multi-core CPUs, we will need to make use of functional programming techniques to write scalable software that effectively uses such hardware. Given IBM's (and Sun's) emphasis on high-end server hardware, a willingness to adopt and support Scala and Clojure could really put them in the lead in this area.

Things don't look as good in terms of operating systems. As basically everyone in the industry knows, Sun has offered Solaris for years, while IBM has offered AIX. While both high-end UNIX-based operating systems, I'm not certain if they could be successfully integrated. At a technical level, I suspect they are just too different.

If an acquisition were to take place, I imagine that Solaris would be supported for some time, but eventually deprecated in favor of AIX. This would be similar to what happened to Tru64 UNIX when HP and Compaq merged. If I recall correctly, HP originally planned to transition Tru64's more advanced features to HP-UX, but this didn't end up happening, for the most part. Now Tru64 is essentially on its last legs.

Given that Sun has released much of the Solaris source code over the past few years in the form of the OpenSolaris project, it seems likely that it will live on in at least some form. A truly self-sustaining community, akin to the Ubuntu project for Linux never seemed to develop, however. So it's difficult to say how much, if any, innovation we'd see out of the OpenSolaris project were Sun no longer supporting it.

Another interesting area to consider is that of the MySQL-related technologies and business that fell into Sun's fold with their acquisition of MySQL AB at the beginning of 2008. Given IBM's pivotal role in the development of relational databases, and their offering of the very solid and professional DB2 family of database products, MySQL's future in such an organization seems quite limited. Even within the open source community, MySQL is generally considered an inferior RDBMS. I really can't see it having much of a future, especially with Marten Mickos and Monty Widenius out of the picture.

We'll just have to wait and see what comes out of these rumors. But in terms of the software world, such an acquisition could have some significant impacts. They'd mainly be felt by those working with and developing enterprise systems, but may still be noticed by others, including, for example, OpenOffice.org users. So I see such an acquisition as potentially being good for Java, but less so for the Solaris, and potentially disastrous for MySQL.

There was recently a posting at the The Daily WTF site entitled The Quest for the Unique ID. It gives an example of a software system that generated unique invoice identifiers by randomly generating a value, checking if that identifier had already been used by an existing database record, and repeating until an unused value was found.

Some people may laugh and doubt that software like this exists, but after years in the industry, one sees enough mistakes of that type to know they are a very real problem. No matter what platforms or technologies are used, software will be written incorrectly. Usually this is unintentional, and due to unclear specifications, typing mistakes, misunderstandings, and so forth. But there are other problems, like that of the The Daily WTF article, that go far beyond being bugs.

Almost any software developer, regardless of training or experience, should be able to see the obvious problems with the approach that was described in the article. Unfortunately, there are some software developers who do not, for whatever reason. It's difficult to even consider such people as "developers" or "programmers", because they lack even the most basic of knowledge of the craft. Having worked with a very wide variety of software systems, platforms, programming languages, and database systems, I have to say that I've seen most of these types of mistakes in software developed using PHP and MySQL.

I suspect this has to do with the general attitude within both of those communities. Namely, they have focused on quickly developing software, all without putting much emphasis on quality, security, and reliability. Both implementations, for instance, have a long history of having poor performance, numerous security flaws, numerous bugs (that often aren't fixed for years), poor architecture decisions, and a lack of critical features. Much of the software that is written in PHP and uses MySQL tends to absorb these negative traits, and then somehow manages to amplify them into the creation of spectacularly horrible software systems like that of the The Daily WTF article.

Far too often I've been at the bookstore and seen books that promise to teach both PHP development and MySQL development in just a few hundred pages. Unfortunately, such books appeal to those without much, if any, software development experience. And once they have read one such book, they come away mistakenly believing that they're on par with professionals who have spent years studying database and software development. Soon enough they've convinced somebody to hire them, and soon after a business software system has been developed that generates unique identifiers by random trial-and-error, avoids the use of primary keys, avoids the use of foreign keys and other constraints, is vulnerable to SQL injection attacks, performs extremely poorly, and is full of bugs.

Over time, I have become more and more hesitant towards taking consulting jobs that involve PHP and/or MySQL. The systems we see are often so broken that there is little that can be salvaged. From the database model to the highest levels of the UI, it's not a matter of fixing minor bugs or architectural deficiencies. Most of the time, the entire system is in dire need of replacement. Unfortunately, this often proves to be a process that most clients cannot afford nor justify. But perhaps if things had been done more correctly in the first place, they wouldn't be in such a bad position. Thus the lesson we can usually take away is that PHP and MySQL should be avoided whenever possible.