Slashdot Mirror
Java 1.5 vs C#
Here's the list of enhancements to the Java Language:
- Generics (C# 2.0 already supports this)
- Enhanced For-Loop (the foreach construct in C# 1.0, duh!)
- Autoboxing/Unboxing (C# 1.0 already has this, everything is an object, even the primitives - not really, but they do it so well...)
- 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)
- Varargs (C# 1.0's params construct, ellipsis construct in C++)
- 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)
- 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.]
It's a bit unfair to compare the new Java 1.5 release with c# 2.0 since c# 2.0 is not due to be released until sometime Q2 or Q3 next year. But I do agree that before the 1.5 release Java had a lot of catching up to do to c#, but now c# is a bit behind (Mainly because of it's lack of support for generic classes which Java now supports).
Perhaps /. will correct the error. I emailed the editor when the story was in preview, but it was too late.
XML Parser
You mean like JAXP and JAXB?
Attention deficit disorder is a complicated issue, spanning several major... HEY LET'S GO RIDE BIKES!
It's not so much the language that is a question of contest, but the platform they run on. I've done Java programming since 1.1.8, and have deployed on Tomcat, Resin and Weblogic.
.Net? What the fuck is up with IIS (oh yeah, it's crap)?? Where is any sort of replicated server side session management (no, long ass hidden fields are *not* sessions - and a M$SQLServer *only* solution doesn't count).
.Net's deployment platform (singular). Man I miss working with J2EE platforms and loathe IIS...even though it is my job to keep all this stuff running on IIS! :(
Recently I switched to C# (new job) and I have to tell you, the language is pretty neat with some of the tricks you can do. Nothing ground breaking though.
What's really missing is the platform for release, and release management. Where are WARs and EARs for
The constructs and tricks of a language can be debated as long as you want. You will probably find something nice in every language. But when you have to [operationally] deploy any application, great or not, on some cheap as shit, crap ass, hard to manage, non-repeatable platform such as IIS, that's when the real rubber hits the road with Java.
J2EE deployment platforms are light years ahead of
-bk
ikvm.net ( http://www.ikvm.net ) is a java VM for .NET/Mono that uses classpath for the JDK API. It can also statically cross-compile java bytescodes into IL code. For example, you can compile a .jar into a .dll (even the resources are preserved).
/..sig file not found - permission denied.
Trust me, we looked at that one. The "tool" can only be used in extremely simple circumstances and is not much more than a marketing trick from Microsoft.
"For my own opinion I prefer unchecked exceptions as the code is far cleaner. "
No, the code will just appear cleaner. Hiding exception propogation is an invitation to ignore exceptions. If someone wraps code in a single catch, you can at least see where they've been sloppy. The equivalent in a non-forced exception check is to do nothing, which is invisible.
Basically, Sun did a bunch of things they could do without changing the VM too much and without breaking old code. But for a bunch of other features, they punted and just added a bit of syntactic sugar to the compiler that makes Java look superficially like it's doing the same thing but is much less efficient under the covers.
For enterprise applications, those differences may not matter much (and they may even be harmful), which is probably why Sun doesn't do anything about them. But for desktop use and application programming, they do matter. Microsoft wanted to create a new language that their legions of C++ programmers could use, and C# is a pretty credible answer for that. Those people don't care about cross-platform features, they care about getting the job done, and if that involves the occasional unsafe module, it doesn't matter to them.
it just does not force you to declare and handle checked exceptions, an issue of strong contention within the Java community
Um, Java supports both checked and unchecked exceptions.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
.NET in the enterprise is currently painful.
It's not about the enterprise, it's about the desktop. Microsoft had to do something there because C++ and MFC and COM was seriously getting in the way of getting the job done. Java isn't even trying to compete seriously on the desktop, so C# wins by default on the desktop. And (crazy as those people may seem to you and me) Microsoft desktop application developers actually seem to like Visual Studio. If Microsoft can additionally win market share from Java in the enterprise, that's icing on the cake for them.
Seriously, I tried most of the IDE's you mentioned and then some, but Eclipse just blows them all away. The fact that it builds a complete syntax tree of your project which can basically be queried in any way you see fit makes refactoring so easy. It can rename method calls for an entire project, add new parameters, reorder parameters, change return code, display what methods call what method in tree form (especially if you suspect the code is dead), displays lots of very useful compiler warnings (unused parameters, variables, methods, unneeded casts, often surprising how many you can find of those in non-Eclipse projects and the possible subtle bugs they introduce). That's just scratching the surface really... it's very evident that Eclipse was written by programmers for programmers, and even after using it for more than a year it still manages to surprise me :)
Sometime in 1999 after I'd worked at Sun for about a year, a routine all-hands meeting was held for all of the Java Software division. JDK 1.1.8 was the current version of Java on the street and JDK 1.2 was in the works, almost ready for release. We sat there and listened to the usual rah-rah speaches from the divison's head honcho (can't recall who it was at the time), and then he introduced us to a marketing guy to tell us about the launch for JDK 1.2. As he begun talking he displayed a new slide on the project and it read, in all its powerpoint glory, 'Java 2000!' And he went on to say that the new JDK would be called, not Java 2, but Java 2000. Everyone in the audience started laughing hysterically. We all thought it was a big joke. I mean, Microsoft was on the verge of releasing Windows 2000, so you don't really mean.... Turns out this marketing guy didn't have much of a sense of humor. "I'm not joking", he said. The laughs and knee slappings turned into boos and hisses. Head honcho guy says something like the marketing guys have worked hard on this and that's the name they've choosen. The Q&A session was next and, boy, did both of these guys get an earful! Anyway, I can't say for sure, but I think that had it not been for the outrage and disbelief at that all-hands we'd be stuck with even weirder Java naming convenstions today.
Rich
Behold BigInteger and its evil twin, BigDecimal. They laugh at silly-big numbers.
"Honey, it's not working out; I think we should make our relationship open-source."
While 'ref' paramters are debatable, 'out' parameters are stupid. They should have created a way to return multiple values from a function. Allowing first class tuples would have been the correct way to do this (in most C-style languages, tuples are allowed as arguments to functions and disallowed everywhere else). Adding tuples would also have eliminated the need for the hacked up delegate functionality. Then again, Java doesn't have any equivalent functionality, so it could be seen as an advantage for C#.
Operator overloading is a good thing. It can be abused, but so can anything else. Removing operator overloading doesn't even come close to making it impossible to write obfuscated code. There are many situations where operator overloading makes things a lot simpler.
Properties are also good. Instead of identifying them through string matching ("get*", "set*"), language-level support for properties allows more accurate data type modelling. In the end, however, the CLR doesn't really have true support for properties. They implement them as methods (like Java, except at a lower level so most programmers don't have to care about it). This implementation mistake resulted in different opcodes for field access and property access, which means you cannot switch between fields and properties without changing the class's public interface (and breaking binary compatibility with client code). It's still better than what Java does...
Function pointers and anonymous functions. This has got to be the biggest improvement over Java. Unfortunately, class libraries were already designed before the anonymous function feature so they probably wont be designed to take advantage of it. Also, VB and C++ are probably holding things back because, as everyone knows, "language agnostic" is just a euphemism for "lowest common denominator".
You also forgot generator functions. They make it easier to write pull-style classes (a "pull" XML parser, for example). Though it isn't as powerful as full-blown continuation support, I think it'll still be useful for many coding tasks.
C# has more comprehensive generics support (aside from variance). Though both languages made the mistake of allowing arrays to be fully covariant (ArrayStoreException), Java got screwed when they decided not to maintain dynamic type information for generic type parameters. This limits the use of generics in often confusing ways. Type erasure isn't a problem in languages that have a good enough type system to avoid resorting to dynamic typing (like ML or Haskell). But C# and Java do not have good enough type systems and the C# people recognized that and chose to keep the dynamic type information around.
C# is better than Java in almost every way. Java has better enums and support for covariant and contravariant generic type parameters, but that's about it.
For covariant and contravariant exist several definitons depending on context (inheritance versus template parameters, e.g.)
Suppose you have a class like this:
class A {
A method() { return new A() }
}
And another class like this:
class B extends A {
B method() { return new B() }
}
This construct is called covariant. The class B is ingeriting from A, while the method method() is overwritten in B. Not only is the mthod redefined but also the return value is. As it is redefined to the taype of the class, this is called covariant.
If the method in A would return a B and the method in B an A, it would be called contravariant.
For template parameters there are similar definitions, but they are a bit more complex.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.