Anders Norås' blog

The difference between cats and dogs

Earlier today I went “sleeping with the enemy” – I attended a Java user’s group meeting. The topic of the day where the new features in Java 5 (“Tiger”) and a quick peek into what is planned for Java 6 (“Mustang”) and Java 7 (“Dolphin”).
Just like the .NET community, the Java community is facing extensive changes to their programming language.

The key new features of the Java 2 Standard Edition version 5.0 are:

• Generics
• Enhanced “for” loop, which basically means “for-each” support.
• Boxing and unboxing
• Typesafe enums
• Static import
• Annotations

In addition there is a new version of the Enterprise Java Beans (EJB) framework, changes to the class library amongst other things.
As a C# programmer many of the new features, such as boxing, “for-each” and annotations, are already commonplace.  Others, such as generics, are similar to the new features in .NET 2.0.
Unlike the .NET community, who welcome the new features with open arms, the new features are not that popular with the Java community.
If I was to judge by what many key people in the Java community are saying, they would rather be without these changes for now. Many feel that the new features are being forced upon them and there is a fear in the community that new features such as annotations, akin to .NET attributes, will flood applications with unexpected errors and render them indebuggable.
The Java annotations differ from .NET attributes by having support for compile-time code injection, in addition to metadata retrieval via reflection. This gives the debugging argument some validity, but apart from that I think they’re all crying wolf.
Attributes is a feature I’ve come to love in .NET. As reflected attributes are interpreted by the hosting application, unknown metadata on an object should not affect or be of importance to this application. I’ve heard arguments like “If transactions are controlled by annotations what will happen if the hosting application has no knowledge of these attributes?” This is theoretically a relevant problem, but in reality no sane person would run a transacted object outside a transacted environment without being aware of the implications. Compile-time code injection should be familiar to most enterprise Java developers. XDoclets, a much used Java based open source technology, is a framework for code generation and injection.

Novice developers find it difficult to write strongly typed collections. This is highly understandable. When doing this you have to relate to multiple interfaces and base classes. On top of that, it is dead right boring to do. Luckily we have tools like Code Smith to help us out. Unfortunately, not many novice developers are aware of such tools.
This has caused many mission critical applications to have collections in their cores without support for “for-each” iteration, databinding or any of the other features we are used to with regular .NET collections. Generics are a panacea to this. Still, members of the Java community have strong objections to generics being introduced in the Java language. The arguments against generics range from them being different from similar features in Python to the Java Virtual Machine not having proper support for them.

One should expect the JVM to have some limitations ten years after its first release. The mistakes made in the design of the virtual machine are fundamental to the improvements made in .NET. With new languages such as Groovy running atop the JVM, I see it moving in the direction of .NET. This and the ability to introduce the Tiger features prove that Sun did a good job designing it.

Cats and dogs are different. I can’t really see the problem with Java 5. These features make the language easier to use, opening it for a larger audience. In the same time they make the lives of many Java developers much easier. It might be that these features hinder some developers in their work, but this group will be ridiculously small compared to those who benefit from these improvements.

The geography of Microsoft product codenames

Sanjeeb Sarangi has a post about the codenames of some upcoming Microsoft products.
Is it just me or does there seem to be a relation between the distance from Redmond to the places lending their names to the products and the length of the project timeline?
For example Whidbey, a.k.a. Visual Studio 2005, is an island just north of Seattle whilst Orcas, a.k.a. “The next” Visual Studio is an island further north.

By the way, Windows XP was code-named Whistler, after a ski resort in British Columbia, Canada. Blackcomb is named after another ski resort close by. The Longhorn Saloon and Grill is located between these two mountains, Microsoft’s Longhorn will ship between Whistler and Blackcomb.

Its code-behind, not design-behind

During the last couple of weeks I’ve seen many blog posts about altering HTML elements programmatically in ASP.NET pages. To make any HTML element available in the code-behind class, just set the value of the element’s runat attribute to “server” and provide an identifier.

<HEAD id=”HeadHtmlElement” runat=”Server”>

To access the HEAD element in the code-behind class simply declare a class member of HtmlGenericControl with the same name as the identifier.

public class MyPage : System.Web.UI.Page {       protected HtmlGenericControl HeadHtmlElement; }

Making the HEAD element available as a class member makes it possible to, for example, programmatically add metadata to the page.

private void Page_Load(object sender, System.EventArgs e) {        HtmlGenericControl metadata=new HtmlGenericControl("meta");        metadata.Attributes.Add("name","pragma");        metadata.Attributes.Add("content","no-cache");        HeadHtmlElement.Controls.Add(metadata); }

Note that ASP.NET 2.0 has a Page.Header.Metadata collection which enables you to add metadata to the page.

Making the head of a page available for metadata injection is an acceptable. However, it would be much more elegant to use an HttpModule to inject the metadata into the pages.

Many of the blog posts I’ve seen have turned the code-behind class into a “design-behind” class moving the HTML into the class by setting the InnerText  property of the TITLE elements e.g. in code. A much better way to do this is to use the ASP.NET page as intended.

Do this:

<TITLE><%# GetResourceString(“PageTitle”) %></TITLE>

Don’t do this:

public class MyPage : System.Web.UI.Page {      protected HtmlGenericControl Title;      private void Page_Load(object sender, System.EventArgs e) {            Title.InnerText=GetResourceString(“PageTitle”);       } }

I’ve also seen examples of people creating the TITLE element as an HtmlGenericControl and adding this to the HEAD element controls collection. I’ve even seen code-behind files writing HTML code directly to the Response stream making the HTML code appear before the root HTML element.

The intent of code-behind files is to separate content from code. Exploiting the ASP.NET programming model to pull the content into the code-behind class is like using a time machine to get back to the ASP “classic” mix of HTML code and VB Script code. It’s already difficult to write maintainable code. There is no need to search for ways to make it harder.