Java [and C#] Design Issues

I recently found an interview with Ken Arnold, one of the original designers of CORBA, via The ServerSide. He mentions Effective Java which many people I know including myself consider to be one of the best C# books around. Doug has referred to it as Effective Java and C# on his blog which isn't too far of the mark given the similarities between both languages.

The first thing discussed in the article is the wisdom of marking entire classes or methods within a class asfinal thereby preventing derivation. Ken Arnold is strongly against making classes final because it hinders potentially interesting reuses of the class. I tend to agree and have seen many users [including myself] brush up against frustration when faced with a class that is closed off to derivation. Of course, one may wonder why if I favor composition over inheritance I have any complaints about this practice. This leads to the main point where I disagree with Ken Arnold.

I believe derivation is the right option in situations involving polymorphism that satisfy the Liskov Substitution principle. Basically my checklist given a potential derived type D and a base class B is to ask

1. Are the behavior and properties of D a superset of the behavior and properies of B?
2. Can an instance of D always [except for extenuating implementation related issues] be used in a situation where an instance of B is expected?

given my above checklist I think java.util.Stack is a bad design and question Ken's statement that inheritance is still desirable if all the methods in the class are marked final. If all the methods in a class are final as they are in the case of java.lang.String (and for good reason) then one is as well served by composition as they are by polymorphism. Of course, some may consider providing the same interface to the wrapping class as unnecessary and inefficient overhead.

Being on the other side of the fence working on class implementations that may eventually be used by thousands to millions of developers there is a significant test cost to ensuring that derivation is not gratuitiously blocked yet one does not violate Liskov substitution. This is hard. Very few developers actually write code that considers that given that a given method parameter is of a type which doesn't have derivation blocked then the behavior of object or its most specific type are not guaranteed. This constructor for the System.Xml.XmlValidatingReader class is an example of poorly supporting derivation scenarios. The constructor accepts an instance of the System.Xml.XmlReader class but somewhere along the line it turns out that the code fails unless it is passed a specific subclass (in this case an instance of System.Xml.XmlValidatingReader).

This USENET post is another example of not expecting a derived type to appear at some core part of the architecture and breakage occuring when it does.

Ken Arnold's critique of the copy constructor approach to avoiding the problems with Object.clone() are spot on. Secondly, the fact that the clone() method is on java.lang.Object and not on the java.lang.Cloneable interface is very broken and something that definitely can only be fixed by deprecation and starting afresh. I definitely second the idea of a java.lang.Copyable interface.

I think marker interfaces are a poor hack around the lack of a concrete metadata feature like .NET Framework Attributes. With any luck JSR 175 will pass and the irritating hack that are marker interfaces will cease to exist.

#

Design Goals and Common Usage of W3C XML Schema

Alexis Smirnov wrote his opinion of Noah Mendelsohn's Web Services DevCon presentation. Sam Ruby was cool enough to hook me up with the slides to the presentation entitled W3C XML Schema: what you might not know (and might or might not like!). The summary on Smirnov's webpage implies that [Noah said] the W3C XML Schema working group intentionally designed the schema language to be used on more than XML data. I assume this is why it is described working on the XML Infoset as opposed to in terms of operations on XML 1.0 syntax and constructs. I should note that I didn't really get this impression from Noah's slides but this may have been something that he said and didn't actually have planned.

Alexis asks whether there has been much use in W3C XML Schema being used outside document validation scenarios. Funny enough, at least in the .NET Framework it sees more usage as a mapping format for XML to objects or XML to relational and back than it does as a validation language for XML documents. Neither of the XML technologies described in the previous links (XML Serialization and SQLXML) actually uses the rules of W3C XML Schema for validation of the mapped results which I've assumed are due to performance reasons and the fact that many W3C XML Schema concepts simply do not transfer well to objects or relational schema

#

Cool .NET Open Source Project

What I always liked about being a Java developer were the number of innovative Open Source projects that took Java in many interesting directions. I keep looking for similar projects for the .NET framework but for now it seems most major Open Source .NET projects are primarily clones of Java Open Source projects which I guess is to be expected until people become more comfortable with the framework and start using it as their primary development environment.

The first really cool [and XML savvy] .NET Open Source application I've seen is NMatrix which according to the NMatrix SourceForge Project Page has 47 developers signed up. Sweet.

#

BSD Privilege Elevation

Every once in a while I get involved in a thread on Slashdot that reveals the fact that I really want to be a *nix system level hacker

#

KaporWare or VaporWare?

Slashdot recently carried a story about Mitch Kapor's plans to build an Outlook killer. An Outlook/Exchange killer is considered by many in the Linux crowd as one of the largest impedements to Linux on the desktop in corporate environments. However I'm not sure if this is that strong of a case given Miguel's work in trying for interop via Evolution which would seem to be the more likely catalyst for getting Linux on corporate desktops than trying to replace Outlook/Exchange.

#

Bob Abooey: Dev Lead of the Apple Two Button Mouse Team

Great question for Donald Becker from K5's own Bob Abooey

Disclaimer

The opinions in this diary are my own and do not reflect the opinions, thoughts, intentions or strategies of my employer.