Java API and Microsoft's .NET API: a Comparison
Nerval's Lobster writes "Previously, developer Jeff Cogswell focused on the respective performances of C# and Java. Now he's looking at yet another aspect of the languages: the runtime libraries—what exactly the libraries are, how they are called, and what features the languages provide for calling into them. Examining the official Java API (now owned by Oracle) and the official .NET API owned by Microsoft, he finds both pretty complete and pretty much a 'tie' with regard to ease-of-use and functionality, especially since Java version 7 release 6 allows for automatic resource management. Read on and see if you agree."
This is the wrong question. What matters is the quality of the apps that are written in either language. In that respect C# is way ahead on the desktop, but in other areas Java is king.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I use both, and I find that .NET really shines when you're in unfamiliar territory and working with a part of the framework that you don't touch every day. Features are more easily discovered and idioms tend to be more consistently applied in .NET, whereas it feels like Java suffers from implementers applying the pattern du jour, forcing you to wade through more docs.
I attribute much of .NET's success in this regard to the absolutely awesome book "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries," which includes a lot of direct insights from the designers of the framework. Microsoft has been really good about sticking to those guidelines, and it shows.
http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613 ...or maybe I just understand the .NET Framework better because I read that book. I'm not aware of a Java corollary that would give me the same insights, though.
Microsoft also had the benefit of Java going first and making all the mistakes, and then Microsoft got lucky when Java lost its first-mover advantage chasing down several blind alleyways -- "Applets", Sun's mismanagement, a bureaucratic open source strategy.
Don't blame me, I voted for Baltar.
I am both a professional java and C# developer. Each one has their advantages:
On the C# camp:
* delegates and events
* functional constructs
* automatic variable types
* LINQ
* Value types (efficiently allocate thousands of value objects in an array, you need some really nasty workarounds in java)
* Generics that keep their types at runtime
On the java camp:
* Spring (There is Spring.Net, but lets be honest: it does not compare)
* Collections library (much more complete and better thought out than C#'s)
* Maven
* J2EE
* A million other libraries freely available, that do _anything_ you want.
* Portable to more platforms (Mono sometimes leaves something to be desired)
So in my humble opinion, C# is much more complete as a language, but java has much better libraries and community. So which one would I pick? well, it depends on the project, the platform, and the amount of code I can reuse from open source libraries.
Especially since what it actually does, doesn't seem to match up with what they tell you it does. At least in the simple cases they use for examples.
Citation needed. Care to elaborate?
Grand Central Dispatch has had similar functionality. The key differences being that Await has more concise syntax for the simple cases, but it gets progressively uglier the more complicated your cases become (such as awaiting a group of tasks that can all be done in parallel to each other
You mean like
await Task.WhenAll(task1, task2, task3); ?
You find that too complicated? I am curious how you would make that code simpler in Java, Objective-C or C?
GCD's syntax starts off somewhat ugly
Indeed
..., but doesn't really change as you do more complicated things, partly because the syntax already assumes you probably want to use blocks/lambdas by default so you can spin off 2-3 lines of code that don't really need a full function.
Apart from being verbose and ugly, GCD still does not solve the problem with composability of asynchronous operations. GCD is the equivalent of TPL (Task Parallel Library) in .NET or Futures in Java.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
ISO is no longer a standards body in many people's opinion after some of their previous dealings with Microsoft. They can quite obviously be bought.
He may be a genius, but .NET and C# are still tools for Microsoft to create a vendor lock-in. Color me uninterested.
-- Linux user #369862