When Java was first released is was hailed as a revolution. Many lawsuits and arguments followed, chiefly between Sun and Microsoft. With their C# language, Microsoft have created what Java should have been 6 years ago – but Sun have still failed to get it there.
I’m not referring to the .NET platform in general – I am not a big fan of the way the platform is arranged. However, C# the language has a number of advantages over Java (the language, not the platform) which give it the edge.
C# uses essentially the same structure as Java – in fact, the Code Explorer which I’m currently working on for .Edit will parse C# files almost as well as Java. The only obvious difference at the start is that C# uses the “using” statement, while Java has “import”.
What Gives C# The Edge?
I’ve said that the languages are essentially the same, but C# has an advantage. That might seem to be a contradiction, but I’ve found some small things which make the difference. I often find myself yelling at the screen because there’s a feature I want Java to have – C# seems to have most of them.
Anonymous Exceptions
With the initial release of Java, exception handling caused me some frustration. I often found myself with code which threw different types of exceptions, so I wanted to catch them separately. This sort of code often appeared:
catch(FileNotFoundException e)
{
}
catch(IOException e)
{
}
This caused an error in the first releases, since the compiler insisted on each exception type having a different name. If many different exceptions were being caught I’d end up with e1, e2, e3, etc. Or maybe fnfe, ioe. To their credit, the latest releases don’t force this bizarre rule on you, but one thing is still missing.
Quite often, you don’t need the exception object at all. It’s normally only of real use if you want to print debug messages – in release code the content of the exception is irrelevant. If you catch a FileNotFoundException it is fairly obvious what the problem was. However, Java doesn’t let you remove the identifier. C# does. Code such as the following is possible:
catch(SecurityException)
{
}
This is not only less to type, but also makes it clear that you aren’t using the exception object within the exception handler.
Proper “Property” Support
One of the most useful features for me, especially coming from a component-based background, is the native support in C# for properties. Say that you have an object which draws a coloured box on the screen – you expose a “property” of this object which controls its colour, say boxColour. Whenever this property is changed, the box on screen needs to be repainted. The code to do this in Java looks something like:
private Color boxColour;
public void setBoxColour(Color value)
{
boxColour = value;
repaint();
}
public Color getBoxColour()
{
return boxColour;
}
The only way to change the colour is to call the setBoxColour method. For me, this isn’t as pleasant as it could be – I’d like to just say boxColour = Color.red.
In C#, the code would be more like:
public Color boxColour
{
set
{
boxColour = value;
repaint();
}
get
{
return boxColour;
}
}
It is then possible to just assign to boxColour. This is a tiny syntactic change, but makes for a much better component-based model.
With the file format change in Java 1.4 Sun could have added support for these features, but hasn’t. I would be perfectly happy writing C# code and compiling it into Java bytecode. It keeps the advantages of the Java platform but with a slightly improved Java language. I hope Sun realise that the Java language is still deficient in certain areas and takes steps to correct it.
Microsoft may take a lot of flak for their behaviour – mainly as a result of sales and marketing getting them into trouble. But their developers know what they are doing.
Original article published at http://www.ashleybrown.co.uk
Visit Ashley on the Web at http://www.ashleybrown.co.uk.
