This is my final installment of the C# vs Java series, but I think this is one of the most important. Tools make or break a development environment. Good tools can make a hard job seem easy and bad tools can make an easy job seem hard. My definition of a tool is: anything that helps you work. This could include IDEs, external libraries, frameworks, testing tools, etc.
IDEs
A good place to start looking at tools is IDEs. You have heard it said that you should buy a good mattress because you spend 1/3rd of your life in bed. If you are a programmer, you spend 1/3rd of your life in an IDE. (If you are a bad programmer you spend 1/3rd of your life in the debugger in the IDE, but that is another story.) For that reason, an IDE is very important, perhaps one of the most critical choices when choosing a programming environment. Fortunately, both Java and C# have good choices here.
As far as IDEs go, C# basically has Visual Studio. There are some open source and other strange things out there claiming to be a C# IDE, but as far as I have seen, they are not serious considerations. (Correct me if I am wrong here.) Being the only game in town means that Visual Studio had better be really good. It is good; there are many things it does automatically for you. For the most part Visual Studio does everything you would want it to do, but it is missing some things that the Java world has.
In Visual Studio, classes are not auto imported when you start to type. This is kind of hard to explain, but in Eclipse, I can start typing the name of some class and the IDE will search all the code I am linked to and try to find any matches for it. If I select that class, Eclipse will automatically import that namespace for me. Visual Studio requires you to know the namespace of the thing you are looking to use. Not a huge deal, but if you start using Eclipse and then switch back to Visual Studio, you will certainly feel the pain in that area. Now, most of the ails of Visual Studio can all be remedied by the use of a plug-in that I highly recommend, Resharper. Resharper makes Visual Studio awesome. It is not free, but it is money well spent. It adds many automatic refactoring options and many of the features that are available in Java IDEs that are missing from Visual Studio.
In the Java world, there are 3 major choices: Eclipse, IntelliJ and Netbeans. I have mainly used Eclipse, so I do not have as much of an idea about the others. I have heard many good things about IntelliJ, and considering it is made by the same company that makes ReSharper, it is probably pretty good. The reason I like Eclipse though is because of all the plug-ins. It is also the reason I don't like Eclipse. The Eclipse community is thriving with plug-ins; as a result there isn't much you can't do from that IDE. There are so many plug-ins for Eclipse that entire companies exist just to bundle them together. Think about that for a minute. This is both good and bad. It is good because you can do just about anything you want to do in Eclipse. It is bad because too many choices are confusing and you always wonder if you are doing the right thing since there is no clear-cut answer. Visual Studio doesn't have very many plug-ins at all, but Eclipse thrives on them. Eclipse is also very good at searching code. There are many hot keys in Eclipse which will allow for searching for classes or files and finding methods in classes.
The IDEs in both environment are similar, offering much of the same basic functionality, but overall Eclipse is more powerful than Visual Studio. One the flip side though, Visual Studio is much easier to use.
The Rest
There are far too many other tools to handle in direct comparison. Instead, I can make some generalizations about the tools available in general. A large amount of the tools available to C# are direct ports of the same tools which were first created in Java. In this respect C# and Java have a pretty equivalent tool set for unit testing, logging, builds, and dependency injection. This is very helpful in transitioning from one language to the other, as knowing one of the tools in one language gives a benefit of knowing how to use the tool in the other language.
The big difference I see here though is open source versus commercial software and tools. In the C# world, there are plenty of open source tools, but a good majority are tools that are not free. Contrast this to the Java world, where most of the tools are open source. This aspect can be quite deceiving. It seems like free tools are good, and they can be, but often the cost of free tools is overlooked. There are several companies that do nothing but sell support contracts for free software. Often the support contracts are more expensive than equivalent commercial software on the C# side.
Another common issue I face when working in the Java world and trying to get or find tools is the road of dead software. There are tons of open source projects which no one has been actively working on for several years. Often, I find it extremely difficult to figure out which tool is being used and actively worked on the most. Even when I am able to sort through the hundreds of options, only some of which are still alive, it is often very difficult to find information about how to use the tool or framework. On the C# and .NET side, there are much fewer projects and much fewer dead projects. I find it much easier to find the tool most people are using and to get it up and running quickly.
Conclusion
In general, I feel like I can find a tool for a job much more quickly in the .NET/C# world than I can in the Java world. I can also quickly find out how to use a tool instead of hunting through documentation. I would say it is just more simple. On the other hand, Java has a much larger selection of tools that can typically do more, at a cost of increased complexity and difficulty in finding the right tool. My personal preference is C# and .NET tools because I don't like to waste a large amount of time trying to figure out what to use and how to use it.
Well, that is it for my coverage of C# vs. Java for now. I am actually getting kind of tired comparing the two. Hopefully I have done a good job of presenting a fair picture from the perspective of a developer currently using both technologies. Now… on to more exciting stuff!