Java 1.5 vs C#

SexyFingers writes "Sun released Java 1.5. The non-API stuff that they've added made it finally "catch-up" with C# - since both languages are built to support OOP from the ground-up, their constructs become almost identical as additional OOP "features" are supported. So if you're doing C# and your foundations in OOP are rock-solid, there really isn't any difference whether you're coding C# or Java."

Here's the list of enhancements to the Java Language:

1. Generics (C# 2.0 already supports this)
2. Enhanced For-Loop (the foreach construct in C# 1.0, duh!)
3. Autoboxing/Unboxing (C# 1.0 already has this, everything is an object, even the primitives - not really, but they do it so well...)
4. Typesafe Enums (again C# 1.0 already implemented this, but I think they've added a little bit more twist in Java, that its actually a better implementation)
5. Varargs (C# 1.0's params construct, ellipsis construct in C++)
6. Static Import (I don't know if C# 1.0 has this, or C#2.0, but C# has a construct for aliasing your imports - which is way cooler. Static Import, actually promotes bad coding habits IMHO)
7. Metadata/Annotations (this is C# 1.0's Attributes, Sun's upturned noses just gave it a fancier name - also, C#'s implementation is better and more intuitive)

They've beefed up the API some, and integrated several packages with the regular JSDK that used to be a part of a separate package or installation ---in my NSHO, the Java API has become bloated...

At this point (even before Whidbey) the deciding factor (as always) for Enterprise work, when choosing a language platform, should be the support it has behind it, in terms of IDE, tools, api, and longevity of the vendor pushing it (forget the OpenSource crap argument, those guys are too in love with Perl, Python, and Ruby - Java could become the child nobody wants to talk about if Sun dies) - right now that's C# and the .NET Framework ---

If you ask Paul Graham though, both language would be utter crap and fit only for idiots :) http://www.paulgraham.com/gh.html [I'm exaggerating, so hold off on those flames.]

Comments

Re:Fair and Balanced

[Anonymous Coward]

Seems like the author has a bias towards C#. Is slashdot becoming Fair and Balanced like Fox News.

Oh, you mean "Fair and Balanced" like the usual open source/Linux fanboyism that nomally occurs?

Common sense prevails again!

[Blitzenn]

Hey a story written by another real world coder! Hurray for slashdot! This stuff matters to me. I have to code for corporate enterprise environments and HAVE to use the bohemoths for my studios.

Java has always given me the pieces of the puzzle that I have needed where MS languages left off. It is nice to see another vendor meeting the bar. I think now the question is becoming Java OR C# rather than MS augmented by mutterings of java code slipped in here and there to make up for what the MS's failings. Sure all languages will frustrate you in one area or another. It's just not possible to see how somethings will be adapted in the real world until it is actually out there. That is when the language builders stop back and say, hmmm, should have implemented that one differently. Problem has been that MS would never admit that they could have done something better and laughable to even think they would change it even if they did realize it. Java has more work to do, but at least it is getting really close to where they need to be for us corporate coders to look at it seriously as a platform of choice.

Now they just need to work on their web server a bit more.

Re:APIs

[jchoyt]

That should be, "Any other features you'd like me to find for you, dumbfuck?"

Re:Java 1.5 vs c# 2.0?

[PhrostyMcByte]

C# 2.0 has a working implementation in Visual Studio Express and its generics are more than the syntax sugar Java gives you.

Re:Maybe I'm an oldtimer, but...

[vidnet]

Oh, how I pine for the days of vi vs. Emacs.

Yes, me too. It's a shame that Vim cut the debate so tragically short. Rest in pieces, Emacs!

Re:Meanwhile, C++ goes nowhere

[Animats]

OK, more details.

The classical problem with C was the failure to distinguish between a pointer and an array. (In the late 1970s, this was considered a feature. Now we know it's a bug.) This led to passing arrays around without size information, and to pointer arithmetic. C++ tries to paper over those issues with the STL, and it almost works. Almost.

"Smart pointers" don't work all that well in C++. The "auto_ptr" mess is instructive. After three published revisions, it still doesn't work well. And that's the simplest case. Reference-counted pointers have worse problems. Making an efficient, airtight smart pointer does not seem to be possible within C++. It needs some language support. Perl's strong and weak references (not Java's) are a good model here. With optimization and language support, the overhead of reference counting can be brought way down. But you can't do that at the template level.

(Incidentally, retrofitting garbage collection to C++ is probably a mistake. It's been tried. The interaction with destructor semantics is too ugly. Calling destructors at random times is not a good thing. And it leads to horrors like "re-animation" in Microsoft Managed C++).

The other huge area of trouble in C++ is threading. The language ignores the whole issue. Locking is considered a library issue. The compiler gives you no help in determining whether a program is free of race conditions.

Because C++ is unsafe, the usual advice is to be "very very careful". This has led to much talk of "patterns", rituals and taboos which supposedly keep bad things from happening. This helps a little, but it's more of a cult than a tool set.

So what we really have is C, with C++ cruft on top of that, then STL cruft on top of that, then "patterns" cruft on top of that. Not good.

And what is the committee doing? Adding more cruft, in the form of "generic programming". There's a way to abuse the template system into pretending to be a recursive term-rewriting engine which can be used to perform arbitrary computatations at compile time. This is being pursued as a foundation for a new generation of incomprehensible template libraries. (If you've ever had to debug someone else's template, you know how hard it is. Imagine something far worse. If you want to go beyond imagining it, go over to Boost, download something, and try to fix it. Suffer.)

I've written a bit on Strict C++. It's not impossible to fix this. It can almost be made backwards compatible. I don't claim to have all the answers. But at least I'm trying to improve safety and reliability. This is far more important than adding cool features.