Slashdot Mirror
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."
However, I mostly code in C# .NET and I dabble in Java in my spare time to model financial markets. What I have found is that C# has some powerful features that other languages do not have. This allows the .NET framework to be a little more robust than Java. Also my opinion is that C# and .NET creates a more syntactically elegant and coder friendly experience whereas Java is good, but not as good as .NET.
In closing, C# .NET > Java.
Please address .NET hate-responses to /dev/null
Damn my Java client!
As much as I like Java, there's a few obvious features that it's somehow still missing:
C# has all of these, of course.
There's no -1 for "I don't get it."
C# was the direct result of MS being blocked from using Java, and was their J# product re-branded into .net. The core is nearly identical with the exception that C# has access to things like DirectX, and a few other nice to have APIs from MS
C# does not appear to have 40 Critical bug fixes every quarter like Java does either. The latest Java update has caused a _lot_ of business systems to crash.
Once I was a four stone apology. Now I am two separate gorillas.
As they are the harbingers of the new age, post dotcom world, where overspecced hardware fixes everything, where there are legions of entitled douchebag "developers" who took a certification course, and of apps which can't run in less than 8GB of memory (our resident BOFH hung up on our developers when they asked for a 64GB VM because they kept getting OOM errors in Java).
In short, both languages rode the crest of the cultural revolution where it is now OK to suck, to offshore code development with no expectation of quality coming back, of "agile" methods where your next version is always going to be the stable one. I'm not exactly saying that these languages CAUSED any of this, but there is at least a temporal correlation.
Yes, I am a Unix guy, and yes, I have grey hair.
I want to delete my account but Slashdot doesn't allow it.
Async methods (huge!)
Generator methods
Partial classes/methods
Reified generics
LINQ (as in LINQ to objects, LINQ to Entities, LINQ to XML - all part of the core framework)
Dynamic typing and -interop
Value types
Operator overloading
Implicit/explicit type conversions
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
'Win'? 'Lose'? They can't take away your choice to use a different framework/language on your own time.
:D
BASIC forever muddafuggas !
I read TFA and all I got was this lousy cookie
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.
2003 called, it wants its article back.
Don't blame me, I voted for Baltar.
Both have big APIs.
Um, as someone who is somewhat (but not only somewhat) familiar with generics in both systems, I don't see anything in TFA's explanation which is misleading or incorrect, nor contradicted by your link. Care to elaborate on what you mean?
You can add lambda expressions as well, although, that's coming in JRE 7, no, 8 maybe.
Yup. I actually forget how often I use those.
Recently we have also seen expression trees put to good use, e.g. in Entity Framework code first to define relations, keys etc.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Apparently he's a corporate drone, he will follow one of these corporations blindly and unquestionably, the only thing to decide is which one.
I'm wondering how a comparison of the event models got skipped. Rather useless article.
I object to power without constructive purpose. --Spock
What about Mono? Just asking, haven't tried it.
I object to power without constructive purpose. --Spock
OK... so is what you're saying that there is a greater difference between the two runtimes than what TFA says, because .NET doesn't have the possibility of heap pollution? Something like that?
Um, as someone who is somewhat (but not only somewhat) familiar with generics in both systems, I don't see anything in TFA's explanation which is misleading or incorrect, nor contradicted by your link. Care to elaborate on what you mean?
I can help. The author claims this:
That is wrong. In Java, type checking happens at *runtime*. During the type erasure the compiler will add downcasts into the code which will be evaluated at runtime. When a collection has been declared with item type as Person, you can insert Person specializations into it, like Student or Teacher. But because of type erasure the collection will in reality be a Object collection. Hence, when you read from the collection the compiler must ensure that it is indeed a Person being read.
Nevermind how the authors hastens to apologize for the shortcomings of type erasure. He also fails to mention one very big difference: Java generics do not support primitive/value types. Storing Integers in collections incur a significant overhead compared to int's because of boxing, heap allocation, unboxing and garbage collection.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
You're right, the article does a pretty accurate reflection of the realities of both systems. I'd love to have runtime generics to work with under very rare conditions, but just as the article mentioned, there are workarounds that lead to slightly less elegant code to do so. Mind you, this is generally only a problem for generalized frameworks more so than day coding tasks, but its still a nice to have.
Bye!
The business doesn't really care, but who else has puked in their own mouth watching a Windows admin work? I'm so sick of even talking to these dumb fucks that I loath the IT department because of them.
I object to power without constructive purpose. --Spock
I haven't seen many job postings for Java as of late. PLENTY of .NET.
I object to power without constructive purpose. --Spock
I'm wondering how C# async methods got skipped. Because there's nothing similar in Java?
Async/await is huge. It makes composing async methods as terse as regular synchronous code. Unlike with the library defined task/future models, async/await adds a composable model which lets you write async methods that can loop, branch, try-catch etc. while staying perfectly async.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
OK... so is what you're saying that there is a greater difference between the two runtimes than what TFA says, because .NET doesn't have the possibility of heap pollution? Something like that?
Type erasure foregoes a number of constructs available with reified generics in C#:
* Support for primitive/simple and value types without boxing/unboxing overhead
* Ability to use typeof() operator (.class in Java) on generic parameters
* Ability to create new instances of generic parameter types (with the C# new() constraint)
* Ability to declare, throw and catch generic exceptions.
* No per-realization static scope. Statics behave strangely in Java generics as all realizations share static members.
There are other more esoteric restrictions because of Java type erasure (yes, heap pollution is one of them).
Also consider that C# generics are fully verified at compile/load time, whereas Java generics need to perform downcasts at runtime, every time you return something that is of a generic parameter type.
None of them huge restrictions - until you hit upon them and realize that you will have to create strange code to circumvent them.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Easy. Mono + Apache. Have done it with our vertical market product.
Maybe I'm a corporate drone that can only do so much as advise my superiors that either choice is wrong, but they receives "gifts" from either company.
Get free satoshi (Bitcoin) and Dogecoins
So my coworker used some funny introspection workaround to get that private field.
WFT, Microsoft?
Did you think that the private modifier is a security feature?
...over all these wonderful features of both languages. And here I am, a mobile developer on the vanguard of technology, still stuck with dumbshits that suggest maybe we ought to somehow shoehorn ourselves back into JS.
I can hear them now: "Here, just use this mile high stack of libraries with hipster names and it'll be workable, I swear. It really is a functional language, and the New Assembly, after all. P.S. CSS3 Sucks Less(TM)!"
Forgive the troll.
I was hoping to provide some insights, but the article is just riddled with misunderstandings. I stopped reading after this line:
"Generally speaking, the API makes use of properties in the case where you supply a class or object; but the classes in the API typically donâ(TM)t make use of properties."
No, not at all. Properties are used pretty much everywhere in the API. Examples abound with get only properties (ahem Length?).
Methinks Mr. Cogswell is in way over his head. Language design is not an easy subject, and it requires more than a cursory glance for the perspective of everyday programming.
As others have noted here, C# does seem to be adopting more language features. And, having used the new async programming model, I have to say C# has taken a noticeable lead in useful features.
Nothing prevents Java from doing the same, but given the slow progress of implementing and adopting things like lambdas, I can't say the future of Java will look all that different than today. Which is too bad; there are new ideas that are worth the effort.
How can you call it a tie after listing tons of features that java doesn't even have? C# is the clear winner with the following features that are lacking in Java: -Properties -REAL generics (not type erasure) -async/await -value types (struct) -the ref and out keywords -the dynamic keyword (and dynamic types) -the var keyword (or type inference) -LINQ -Better introspection and reflection (Reflection.Emit) -Named parameters -Partial classes -Extension Methods -The new Roslyn (Complier-as-a-service) in C# 5 -Better built-in bindings to C++ -The ability to pin memory and get pointers to it for high-performance operations -The but-in HttpClient library -Far better GUI WYSIWYG editors and development tools for desktop, mobile and web applications C# pretty much destroys Java. It sounds like Jeff Cogswell is a Java developer that barely knows C# and therefore doesn't know what he doesn't know.
Check out EL 3.0 / JSR 341
https://java.net/projects/el-spec/pages/CollectionOperations
One of the things that's always bugged me about Java generics: array allocation. The following code works in C#. It does not work in Java:
class bar<t> {
t[] baz;
public bar() {
baz = new t[10];
}
}
To make something like that work in Java (which I've had to do before), prepare to get your hands dirty with Reflection or to be doing a lot of explicit casts. It's really annoying.
There's no place I could be, since I've found Serenity...
His analysis is superficial, and his conclusion makes everyone dumber. "And then they ate ice cream," might as well been the result. Talk about s
I think what a lot of people forget (or don't know) is that Type Erasure was used in order to make the generated .class files backwards-compatible with older .class files when they added generics in a later version. A lot of Java's limitations are due to stringent backwards-compatibility and due to it taking risks first, realizing the problems, and trying to rectify it, while C# benefited from this greatly. History and the overall picture should be taken into consideration.
To me, this article and arguments are of little value. I use Java because it is a language close to C/C++ with garbage collection that works on many different platforms (any with a JVM). The reality of "write once, run everywhere" did not really come to fruition, but Java is at least a lot closer to it than C#. Mono is a pit stain upon Linux. Others use C# because they need to easily call Microsoft-specific code without the harder-to-write JNI and JNA code; C# runs better on Microsoft than Java, hands down.
You pick languages based on your need (or your customer's need). When I need a complex script (that bash can't handle), I won't be using Java or C#. I'll be using Ruby, Python, etc. If I need strong Gtk support, then I will pick a language easiest to me that has the highest supported version (http://www.gtk.org/language-bindings.php). If I need strong Windows support, then I will use C#.
The G
Oracle does not own the Java API. They own the Java trademark, and they are the current curators of the API.
it has specifically licensing it to the public and has the capacity to shutdown Mono at any time.
*sigh* unfortunately this comment is going to attract a lot of MS chills repeating ad nauseam phrases like "community promise" and "estoppel".
You are obviously aware of it, so why do you continue to spread this FUD? I find it especially ironic in a discussion about comparison between Java and C#, where only one of the vendors have actually tried to sue. And it is not Microsoft.
The history with the community promise is that first Microsoft submitted C# and the core libraries to ECMA and ISO for standardization. In doing so Microsoft committed to offer license for any patents essential to implementation under RAND terms (Reasonable And Non Discriminatory).
"IT IS A TRAP" cried the FOSS community! "While they may be forced to license the patents they can still sue and open source projects cannot afford a trial against Microsoft, so they can still force Mono underground!!"
Microsoft then ALSO placed C# specification and core libraries under it's community promise. Such a promise has (as you pointed out) legal estoppel - which in layman's terms means that if Microsoft sues you can invoke the unilateral promise and have the case dismissed.
You may be correct that if we follow your wild FUD that Microsoft can sell off an essential patent and that way wiggle out of the estoppel promise. Then again you could very well be wrong, because the legal basis of the estoppel is that you acted in good faith. A buyer of the patent cannot change the fact that you acted in good faith.
But your FUD is a strawman anyway, since you have not explained how Microsoft could escape the patent grant they have given to anyone who implement C# and core libraries. Such grants cannot be revoked by a buyer of a patent.
The gist of it is that rather than an actual license MS published a statement, a (quote) "promise not to sue".
You are wrong. The promise not to sue came after MS granted anyone who requests it a free license on any essential patent necessary for the implementation of C# and/or core libraries.
And now get ready for the flurry of comments defending .NET most of which will fall in one of the following 4 categories.
With the amount of FUD, inaccuracies, speculation and free fantasy you should certainly expect to be corrected.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I'm sorry. C# being ahead in desktop might hold true if you run your clients on Windows. If you want cross-platform apps, (and I plain refuse to work on systems that won't run on Linux), then C# is completely useless.
--Coder
... management is, at least most of the time.
Let me say that it is easy to create GREAT systems in Java (and I assume in C#/.NET). However, in enterprise world, that seldom happens. That is not because of languages, but because of several management related issues:
1. Technical excelence is rarely seen as a goal, implementing features is.
2. Technical fixes do not drive development, satisfying business requirements does.
3. Things are rarely if ever refactored, consolidated or tidied up, as business does not see the benefit of doing that. And they do see the risk of regressions and breakage caused by refactoring.
4. There are few really good architects & developers, and because of lack of refactoring and technically driven changes, any problems in design or mistakes in code will stay there forever.
5. Management sometimes makes insane technical decisions, because of stupidity or corruption, or because they read an article that X is great and now everyone must use X, or whatever. Technical decisions must be made by technical people, otherwise bad things happen.
6. When system becomes unmaintainable and unusable, it gets rewritten, causing all "Version 2" problems. Everything and the kitchen sink gets included into Version 2, and it ends up worse than Version 1.
7. Hardware costs less than developer time, so throwing hardware at the performance problems is often easier and cheaper.
--Coder
IMHO one of the worst aspects of C# is that Microsoft have decided to use XML for documentation.
I've already complaining a lot to use HTML for Javadoc in the source code, but XML is so many orders of magnitude worst.
I understand why Javadoc is using Html, because Html is hipp and modern or whatever.
But there are so many better altrenatives. For example Textile.
At least with Javadoc they saw the trouble and introduced tags:
@author
@version
@since
etc.
It's already difficult to write and read Javadoc comments:
/**
* <code>JPanel</code> is a generic lightweight container.
* For examples and task-oriented documentation for JPanel, see
* <a
href="http://java.sun.com/docs/books/tutorial/uiswing/components/panel.html">How to Use Panels</a>,
* a section in <em>The Java Tutorial</em>.
* <p>
* <strong>Warning:</strong> Swing is not thread safe. For more
* information see <a
* href="package-summary.html#threading">Swing's Threading
* Policy</a>.
* <p>
* <strong>Warning:</strong>
But to read or to write C# XML comments you have to be really a masochist.
<summary>
btnImport control.
</summary>
<remarks>
Auto-generated field.
To modify move field declaration from designer file to code-behind file.
</remarks>
<list type=""table"">
<listheader>
<term>Employee</term>
<description>Employee Type</description>
</listheader>
<item>
<term>XXXX</term>
<description>Administrator</description>
</item>
<item>
<term>YYYY</term>
<description>User</description>
</item>
</list>
PS: Filter error: Please use fewer 'junk' characters. with the XML stuff.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
Someone compares A with B and claims that one of those lacks featers the other has.
Then a lot of people give comments how A and B both lack even more featers.
The only thing you clearly understand as someone who *actually* used BOTH *extensive* is:
The people who claim A is better don't know much about B ... e.g. recently added featrues etc.
The people who claim B is better usually don't know much about A ... as we obviously don't use it.
Example: in what practical purpose is there any significant (if at all) difference between Java Generics and C# Generics? From a programmers point of view: there is none at all!
Ofc the .Net IDE is superiour to Eclipse, IDEA IntelliJ, Netbeans ... we all know that.
Windows forms is much better than Swing, seriously! (Did you ever do a big App in *both*of them? Likely not, so your statement is not valid). That was sarcasm ... btw. Swing is one of the best GUI Frameworks ever written, only topped by Qt.
Anyway, there are only a few people who indeed work with both platforms/languages intensively. Those might care about a comparision.
No one who read this comparision or this article about it or my comment here will switch.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The private modifier *is* a security feature, and in Java you can set up a SecurityManager that prevents you to use introspection/reflection to accessing such a field.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
In recent posts about implementing languages like Clojure over .NET's virtual machine (and why those projects tend to atrophy and die), the point was made that C# has a very good compiler, so the VM running underneath need not be as powerful as compared to what the JVM offers.
Well, apparently, you only have to fool the majority of people for a little while.
Lolwut? The private modifier is not a security feature, it's to enforce build-time encapsulation.
Microsoft submitted C# and the core libraries to ECMA and ISO for standardization. In doing so Microsoft committed to offer license for any patents essential to implementation under RAND terms (Reasonable And Non Discriminatory).
But your FUD is a strawman anyway, since you have not explained how Microsoft could escape the patent grant they have given to anyone who implement C# and core libraries. Such grants cannot be revoked by a buyer of a patent.
Make up your mind, are "C# and the core libraries" offered free or under a RAND? Also "C# and the core libraries" is only a part of what the Mono project needs to subsist independently.
I'm unconvinced. I'm not a layer but the FSF has lawyers that understand this much better and they recommend against it. I'd rather take advise from the lawyers of the FSF than some random guy in slashdot.
I find it especially ironic in a discussion about comparison between Java and C#, where only one of the vendors have actually tried to sue. And it is not Microsoft.
He asked about Mono. The situation with Java is similar I know.
But... the future refused to change.
I suggest to read a book about security then.
How do you plan to ninja my private RSA key on a JVM, when it is hold in a private variable? Hint: you can't!
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Thanks!
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I suggest to read a book about security then.
You go first.
Private modifier is not a security feature IN ANY LANGUAGE. Neither in C#, neither in Java, neither in C++. C# reflection can read private fields just like Java. To have any kind of security, you mustn't allow untrusted code to run in your JVM/CLR.
If configured correctly you CAN NOT read private fields in Java.
Hint: Security Manager.
Obviosly, you have no clue about JVM security mechanisms ...
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
And it is not configured that way by default neither in the JVM or the CLR.
It is, e.g. when an Applet is run.
In a standard JV which I start by typing "java.exe" (or just "java") it is not configured, as it it up to the Java Application that I run to decide if it needs security features or not.
My point is: with java bytecode you can not access private attributes or methods (of another class). You can only do it with reflection and only if you know what you are doing (setting the 'access private' flag). Reflection however can easily be disabled by a security manager.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.