C# vs Java Part 3: The Frameworks (IO, DB, Concurrency, Collections)
The part of development you interact with most, besides the language itself, is the standard framework. It is very important to have a good framework to do the basic operations that are needed when writing code. I want to take a look at a very high level comparison of C# and Java and the corresponding base libraries of frameworks that are available to a programmer choosing either technology and language. I am aiming at a high level overview, trying to look at things that are important to me as a developer, such as: ease of use; flexibility; power. It is important to consider closely the framework usages for things that will be commonly used. The ability to easily read or write to a file, send a message over the network, or parse some text is very important because of how commonly these operations are needed in developing an application today.
File IO is something most of us have to do at one time or another and we expect it to be fairly painless. It amazes me sometimes how painful this simple operation is. How many times I have written an algorithm to read a number of bytes into a buffer, then loop until there are no more bytes to read, and finally put it together in a format I can use, hoping to not make a mistake. How many times I have made a mistake in that code, and spent wasted time debugging it. As a developer, I expect the framework to handle this for me. I don't want to pack around my special utility classes from project to project, like a 1990s C++ developer with his ‘floppy disk of wonder'.
If you google or bing (if you prefer) for reading a file into a string in C#, you will find plenty of hits on code like this:
I know this will be a topic of debate, but do the same kind of search for Java. You will see some mess like what I described above using a buffer in a loop, or you will see some reference to another library like Apache commons. FAIL. Every single time I have to write file IO code in Java, from back when I was learning it in college to today as a professional programmer, I have to look it up. Perhaps I am just dumb. Perhaps I have run out of brain buffer, but I can't remember it. I think I shouldn't have to. I know the C# example above is probably very inefficient, but when you just need to read the text of a short file into a string, it should be that easy. When you need to read a file in some other way, it should be pretty close to that easy. Bottom line for me is, it is pretty much that easy in C# but in Java file IO is painful and error prone.
Both Java and C# are pretty close to equal here if you don't count concurrency, which I will cover in the concurrency section. The names are slightly different, but between the two languages, I would say that both provide easy-to-use and understandable implementations of most of the standard collections, with one exception, which I know will be remedied in C# 4.0… The tuple. I like the tuple; when you need the tuple, only the tuple will do. Every time I reach out to grab a tuple, it is never there. I frown, spend 10 minutes debating between creating my own custom object, or using a list or map, or writing my own tuple class, and then finally rewrite the method so that it doesn't beg for a tuple solution. (Alas, I digress). Anyway, both are pretty similar. Java had a better collection framework, but now they are pretty close. I have used both quite often, and have felt like both are fairly straightforward and do what you would expect.
If you don't want to read this section because the idea of thread safe code scares you, I won't blame you. If you don't have any problem reading this section because you're not afraid of concurrency issues, I don't believe you. If you don't like reading this section because it scares you, but you know you must do it, I respect you.
I'll be honest. I try to avoid dealing with concurrency as much as possible. It has been a good strategy up till now, but it is becoming less and less possible to do so with the changing computing environments. Almost everyone has a multi-core cpu on their desktop nowadays.
I've heard a large amount of discussion back and forth that C# concurrency in the framework is inferior to Java, but I'm not entirely convinced of this. As far as I can tell, the main advantage Java has in this area is concurrency safe collections and atomic data types. Most of the other features exist in some form in .NET, just under a different name. .NET framework provides asynchronous support for web service proxies and other parts of the framework that allow a thread to be created that triggers a callback method when it is finished. .NET 4.0 is going to add concurrent collections, which will help even the playing field in this area.
Overall, until .NET 4.0 is released, Java will have the advantage here, but neither really handles concurrency at a level where a developer doesn't have to be an expert in concurrency. .NET 4.0 will also contain Parallel Extensions, which will automatically handle some of the concurrency issues commonly dealt with. Axum is also a promising technology under incubation, which seeks to design a domain specific concurrent programming language.
One of the most common things applications do today is interact with some form of database. It is very important to be able to easily work with a database in any development environment.
Both languages have made major leaps here in terms of framework. I won't even compare JDBC and standard ADO anymore, since those are relics of the past. Instead I want to look at LINQ to SQL, Entity Framework and JPA.
On the .NET side there are two technologies that are jointly developed by Microsoft; LINQ to SQL and Entity Framework. In my mind the major difference between the two is that LINQ to SQL is a lightweight one-to-one mapping ORM for a database while Entity Framework is for more complex mappings where you are transforming a relational schema to a domain object. Either way you go here, the main advantage is the ease-of-use which comes from the LINQ side of it. The language integrated features and the framework for using them are pretty tightly coupled here. It is very easy to set up and get going, especially with LINQ to SQL.
For Java JPA is also a very nice and easy to use framework that abstracts the database nicely. There isn't much setup required and it uses annotations instead of implementing a large number of interfaces. (Which is a major change from EJB 2.1, which was much more painful). You can use Plain Old Java Objects (POJOs) which are annotated with JPA specific classes that tell the framework how to persist the entities. Everything is done within a transaction, and the developer doesn't have to think much about database interaction.
Overall the two languages provide very similar functionality built into the frameworks for interacting with databases. C#'s use of LINQ does make C# a winner in my mind because of how easy it is to move complex database operations down to the code level.
To be continued …
In my next post I'll finish up frameworks by taking a look at Networking, Reflection, Security and Text Manipulation.