Pinderkent

I recently saw an article about the accepted Project Coin changes that are planned to be included in JDK 7. This is some good news for the Java community. After a relatively long period of stagnation concerning the evolution of the Java language, and some fierce competition from C#, these are the sort of practical changes we need to see.

Most of these proposed changes aren't exactly revolutionary. Several of them have already been implemented for some time in C# and other .NET-based languages. They've proven to be effective there, and will hopefully bring the same benefits to Java.

The Automatic Resource Management proposal is a good example of a feature that is badly needed in Java. The using statement of C#, and the Using statement of VB.NET, have proven this concept. They make it safe and easy to ensure that certain non-memory resources are disposed of appropriately. This is exactly the sort of practical language-level change that Java needs.

The Strings in Switch proposal is another one that suggests a very useful change. Not being able to use a switch statement to select a case based on a string value has always been an annoyance to me.

The Improved Type Inference for Generic Instance Creation proposal may help making coding quicker, although I'm not convinced it's as beneficial as it sounds. Although it reduces what some may consider to be redundancy in code, most decent Java IDEs offer auto-completion support that helps prevent a programmer from actually typing out the parameterized types. And we do lose some detail within the object instantiation code, which otherwise is self-documenting in some sense. I think the benefits of this change will require some experimentation once an implementation is available.

Some of the other proposed changes, such as the addition of language support for JSR 292 and the collection-related changes don't seem as sensible to me. In the case of adding more support to the JVM and the Java language for supporting dynamically typed languages, I think this is a bad idea. The JVM itself is better suited to statically typed languages, and trying to hack on support for dynamically typed languages may just result in further bloat.

In the case of the collection-related changes, we are getting to the point where a major reworking of the collection classes is in order. We already have older classes like java.util.Hashtable and java.util.Vector, as well as the Java Collections Framework, and then all the changes that were made to both groups during the introduction of generics with Java 5. Trying to further build on the existing mess may just make the situation worse. But a clean up would be massive, and would have many repercussions on existing software. So there may be no easy answer here.

The acceptance of these proposals is a very good sign. They show the sort of activity and change needed to keep the Java programming language and platform relevant in the face of numerous other competing programming languages and platforms. I do hope that we get to see these implemented in JDK 7, as some of them do sound to be practical and badly needed by Java developers.

Guido van Rossum, of Python fame, recently twittered about how using CSS instead of tables for Web page layout just isn't worth it. This was submitted to Reddit, and the discussion it generated there is somewhat predictable. Many of the comments get into the typical arguments surrounding the topics of HTML tables versus CSS for layout, and the necessity of separating content from presentation. But I think most of the comments that are currently there miss some key issues.

First of all, a number of the posters point out that once you learn the many quirks and incompatibilities of the various popular Web browsers, CSS-based layout becomes quite natural. To a great extent, this is true. There are many Web designers out there who can make very good looking sites using CSS. Unfortunately, it takes literally years of effort, learning, experimentation and failure to get to this point. And with browser technology continually evolving, it takes further effort just to keep pace.

Now, some people will argue that any inherently complex task will take much time and effort to master, and they're correct. But in this case, CSS-based layout shouldn't be such a task. Reality, however, shows that it is, mainly due to artificial difficulties created by low-quality, inconsistent and obsolete-yet-widely-used Web browsers.

Another thing to consider is that not everybody wants to make complex Web layouts. Many people who aren't Web designers want to quickly throw together a site that has a relatively simple layout, and looks decent. On one hand, they can battle with the many troubles that CSS brings to inexperienced users. On the other, they can just use HTML tables, which for many simple layout tasks end up being much more practical and efficient to work with.

CSS should be able to cater to people in both camps, namely those professionals who want to develop complex pages with a high degree of control, and those who just want to throw together a page quickly and easily. Unfortunately, it fails both groups of people a lot of the time. The trend seems to be that most professional designers struggle with it until they finally learn how to wrangle it, most of the time. By that point they've invested so much time and effort that the only way they can obtain some degree of payback is to employ their hard-earned "knowledge", which itself is more an understanding of numerous broken and poorly-implemented Web browsers than anything else. And those people who deem their time better spent on other tasks, like Guido, apparently, just resort to HTML tables.

The fact that the CSS versus HTML tables debate has raged for so long should suggest that CSS is a dead end. It doesn't do a sufficient job in fixing the huge variety of problems associated with what should otherwise be a straightforward task. Perhaps Internet Explorer 8's better support for the CSS table model will help improve the situation. Then again, it may just make things worse. Perhaps the only solution is to throw out the sub par technologies that we employ now, and find a better way to solve the problems of Webpage layout.

If you go into the office of any professional, such as a lawyer, doctor or civil engineer, you will likely find bookshelf after bookshelf of books, journals, and other reference material. Any computer programmers striving to achieve and maintain even the lowest levels of professionalism should likewise have an extensive hardcopy library.

Antonio Cangiano recently wrote about how the wide availability of online content can lead computer programmers to avoid buying physical books. While he makes some very good arguments in favor of buying printed material, many of the programmers I work with on a daily basis don't seem to think that way.

Recently while at lunch with a group of developers, the topic of books came up. Some of the younger developers, already several years out of university, admitted that they hadn't purchased any programming-related books since graduating. I was somewhat surprised by this. I find myself purchasing, and actually reading, at least one book a month. Depending on what technologies my clients are using, this may sometimes reach a book or two a week.

Now, eventually computing books do become quite outdated. So every few years I donate some of the worst offenders to local thrift stores. This helps keep my personal library focused and relevant, and helps maintain its usability and efficiency.

Most of the older developers said they were in the same position as I am, with them purchasing a large number of hardcopy books each year. We thought that perhaps this had something to do with how things were when we started in the industry a few decades earlier. We could all recall the shelves and shelves of books, similar to these DEC manuals, that'd be located near most significant computer installations.

To us, it just seems natural to have easily-accessible printed documentation available, be it a book or a manual. Admittedly, things have changed significantly over the past couple of decades, and we find much more content online or in various electronic forms. So it's seems reasonable that younger programmers would be more accustomed to reading such documentation. However, I hope that they don't neglect to recognize the value of a large printed library. It's the sort of thing that can make a very good programmer even better.

Recently, Adrian Bateman of Microsoft raised some questions, concerns and thoughts about HTML 5. Although Microsoft doesn't have the best reputation for supporting and complying with standards, especially when it comes to Web technologies, we shouldn't use those feelings as an excuse to ignore these questions. Had some other non-Microsoft individual or organization made these same remarks, they'd be just as valid and just as worthy of some serious consideration.

A number of questions are raised about the necessity of a number of the new elements. Indeed, many of the new section elements of HTML 5 do seem quite unnecessary. The use of <div> or <span> tags with an associated class should be more than sufficient replacements.

The same goes for the proposed <dialog> element, which is meant for representing a back-and-forth conversation between parties. Aside from the lack of necessity for this element, I personally don't like its name very much. Within the field of software development, the term "dialog" is often used to refer to dialog boxes, which is the first thing that comes to my mind when I see that tag. However, dialog boxes and the <dialog> tag are clearly two very different concepts.

With respect to some of the new tags relating to time and date handling, I have to agree with Adrian's description of such handling as "notoriously complex". Earlier this year I wrote about how care is needed when implementing time and date handling. But now HTML 5 seems to be opening this can of worms with its new <time> tag, and its <input> tag changes. I hope these new elements don't just introduce more problems than they solve.

The <bb> element sounds quite questionable. Aside from the completely non-descriptive tag name, the security implications of this element are obvious. Thankfully, both Microsoft and Mozilla seem aware of the potential dangers of this element.

The <progress> and <meter> elements theoretically sound useful, but I suspect that in reality, they just wouldn't be flexible enough for most Web developers. If their appearance couldn't be heavily modified, they'd likely just be passed over in favor of existing image-based approaches.

HTML 5 has always felt like a hodge-podge of different ideas from various groups, thrown together and called a "standard". It's good to see some realistic, solid criticism from one of the major Web browser developers. Hopefully their input will help HTML 5 resolve some of these issues surrounding unnecessary, impractical and potentially dangerous elements and changes.

For several years now, those of us involved even in the slightest degree with Web development will no doubt have run into the numerous problems associated with supporting Internet Explorer 6. Although it has survived longer than much other software, and even today still has a significant number of users, many Web developers are finding that it's just not worth supporting IE6.

So while many Web developers and sites are beginning to phase out support for IE6, apparently even including heavyweights like YouTube, others aren't ready to do so yet. Toby Joe Boudreaux, for instance, suggests that we shouldn't stop supporting IE6.

All in all, this is a situation that those of us who have been in the industry for years have faced time and time again. There ends up being a platform of some sort that was heavily used at some point, but has clearly become obsolete. And there's always some resistance towards moving away from it, or no longer supporting it. Yet we typically find that once we've moved on to newer versions or newer platforms, we're much better off that we were in the past.

A good example of this is the JS2E 1.3 and J2SE 1.4 releases of the Java platform. A huge number of businesses standardized on it a few years back. Large systems were build upon it, and it became quite entrenched. Eventually, we had Java 5 available to us, and then Java 6. Yet there was a huge amount of resistance within these enterprise operations when it came to moving forward from 1.3 or 1.4.

I work with a number of different clients who have each standardized on different versions of Java. If there's one trend that is quite clear, it's that those who have transitioned to newer versions of the Java platform are much better off. For instance, one of those clients uses Java 1.3, even today. While it is generally suitable for their needs, they've been finding it more and more difficult to find good Java developers willing to work on such an old version of the platform. They also find it difficult to make use of the numerous class libraries and frameworks that don't support Java 1.3.

On the other hand, some of those clients are on Java 6. One of them is even actively developing some upcoming projects targeting Java 7. And what we see with them is a development team that is on the cutting edge, eager to use the new language features and third-party code or frameworks to develop more effective software in a more efficient manner. Whatever effort is spent on transitioning to newer versions of the Java platform ends up being dwarfed by the benefits the newer versions have brought to the developers, and then the users of the software systems themselves.

So one main lesson we can take away from this is that we shouldn't be afraid to discard old software, especially when we know there is much better out there, even if it means ruffling the feathers of some entrenched users. This is exactly where we are with IE6 today. Firefox, Safari, Opera and Chrome are clearly superior browsers, in just about every way. There are significant benefits, for both developers and users, to moving away from IE6. It's just one of those things that we should do, and the sooner the better. We shouldn't be afraid.