I should start by saying that I know comparing VS.net with Java/Eclipse is ignoring the choice of which language I'm using in VS.net. IMO, it doesn't matter that much because the nature of .net is such that the object models you work with are largely the same, as is the IDE. There are syntax differences, but I'm not really attempting to compare the "value" of one language or another. I just have some observations on what its like to program with the tools.
Very briefly on the languages themselves -- I've decided I prefer Java as a language to VB.net; though I haven't done much with C# yet. Java still bugs me from the standpoint of case sensitivity -- something I place no value in -- but VB bugs me in the way variable declaration is handled and its strange type casting rules. I don't do C or C++ any more. I did a long time ago, but its been so long that any comparison would be unfair.
The first thing to get used to, is that vs.net tends to take an approach that starts with look and feel, and provides drill-down mechanisms for putting code behind the features. Unless you've installed plug-ins and add-ons, Eclipse development is more focused on starting with functional object creation with the idea being to later on in the process control those objects with a user interface. This sounds subtle, but its got far reaching implications in the code you write. Of course, you can ignore the UI stuff and start by creating class modules in VS.net; and you can go right to a plug-in visual UI tool for Eclipse-- but in both cases you're taking the steps to go outside the normal way they tend to work. I tend to work on functionality first, producing only as much UI as I need to test the core code. Most of the time that original "unit test" user interface gets tossed out when the real one is made. As a result, Eclipse as an IDE matches my work style much better. With VS.net I find I end up with a thousand machine generated declarations with names like "ButtonBar1" that I don't need or want. I am forever deleting them. Yes, I know why they get created and how to avoid it -- but its not the way I work.
What could be more important than the debugger environment? Eclipse is built around the idea of "perspectives" so when you're debugging the whole screen is oriented around debugging operations -- and the settings for what goes where are specific to debugging. In VS.net this doesn't seem to be true at all. The code window, variable windows, browsers and so on are all the same no matter if you're writing code or debugging running processes. I'm spoiled -- I want my perspective to change with my activity.
So for development work, particularly when working on complex functionality the Eclipse style is much more effective for me. Where VS.net shines, however, is building the front the end. The drag and drop UI tools are solid and easy to work with (as you'd expect). Best of all is the ability to very quickly create an installer application which manages version control and dependancies. You can do that for Java, but of course its got to be done through add-on products and tools.
The two other things to look at are documentation and add-on libraries. Both Java and .net have no shortage. VS.net is a much more commercial crowd with the java people being more likely to open source a good library. That said, both sides have no small amount of garbage floating around out there calling itself good tools. If you want to work with Windows services, Microsoft provides quite a view SDK's as well, including DirectX (sound and video). Documentation, however, is where Microsoft loses all the points. I'm surprised by this but its not up for debate. I found the language package came with documentation only on CD which was so bloated and at the same time poorly laid out that its incomprehensible. You end up spending most of your time on MSDN where the on-line documentation is BIG and has LOTS of topics, but almost no detail or explanation. Its also very poorly organized and in many cases the only way to find anything is a search. Searching landed on plenty of 401's (page not found) and worse into outdate documentation for older versions with no indication that I was headed down the wrong path. I have four books on the environment and didn't find them to be much better. By contrast, I have found documentation on the Java core libraries to be remarkably rich and detailed.
My conclusion -- VS.net provides some really powerful tools for making Windows client specific user-oriented applications. This coupled with the difficulties in predicting what the local JVM environment will be like on a client machine makes VS.net the way to go for user apps. Its worth the frustration of doing code heavy-lifting in the environment to get the benefit of an easily managed user application. For back-end work, Java done in Eclipse has really matured and together they make a very enjoyable and powerful place to build things.
What a shame that the two code bases play so poorly together. The tie in from front end Win32 to back end Java pretty much has to happen as web services or customized network calls. I think if the local JVM was just more predictable on the average Joe-User machine, I'd invest in an install kit tool for Java on Win32.
